Director /Editor

C. Marcelo Cusmai
Diseo y Diagramacin
Stabilitas

Editorial
Por Marcelo Cusmai

Artculos y Colaboraciones
Febrero 2012
Alfonsina Morgavi - Argentina
Fernando Waisman Argentina
Luis Mercadal - Argentina
Raynald Korchia - Espaa
Gustavo Mrquez Sosa Espaa
Mara Jos Rodrguez Espaa

Traducciones
Sergio E Cusmai
Sitio Web
www.infotesting.com

Realizar una publicacin de estas caractersticas, dedicada a los

profesionales de calidad de software, sin lugar a dudas es un gran
desafo que no sera posible sin el apoyo incondicional de quienes
aportan contenido y de quienes se encuentran vinculados de algn
modo al desarrollo de la propuesta. En esta nueva entrega,
realizamos un recorrido por los interesantes inicios del proyecto
Nahual, detalles de recursos humanos y nos introducimos en una
vanguardista e importante actividad profesional como es la
ingeniera de requisitos. Conocer sobre Tcnicas de educcin en
ingeniera de requisitos es un aporte que va de la mano con las
nuevas tendencias de la calidad de software internacional y el
conocimiento cada vez ms profundo que deben poseer los Testers
Profesionales. En distintas partes del globo diferentes equipos de
trabajo coordinan actividades que se realizan de manera similar,
siguiendo parmetros y acciones establecidas por diferentes
normas y por certificaciones que han apoyado la profesionalizacin
mundial del testing.
Para los interesados en convenciones y eventos internacionales,
nuestra publicacin apoya el evento ms importante de habla
hispana en el mundo: "expo:QA"; por esa razn en esta entrega
presentamos un beneficio exclusivo que consiste en un descuento
del 25% para los suscriptores de la revista que quieran asistir a la
propuesta.
Muchas gracias por compartir y permitirnos llegar una vez ms con
estas hojas llenas de contenido sobre Calidad de Software.

Contenidos
Proyecto Nahual

.............................................................. 6

Errores de Software en el Typhoon .................................................. 11

Eventos Internacionales .............................................................. 13
Sobre Tcnicas de educcin en
ingeniera de requisitos ................................................................. 15
Equipos de QA distribuidos
Geogrficamente .......................................................................... 19

Entrevista www.infotesting.com

El proyecto Nahual, un proyecto de inclusin social

Qu es el proyecto Nahual?
Nahual es un proyecto pensado para que todos
podamos programar y testear. El desarrollo de
sistemas puede ser mucho ms divertido de lo que
parece y sobre todo despus de aprender algunas
cosas es muy fcil empezar a crear y programar y
probar tus propias pginas y sistemas. El que
programa, vive creando. Estamos convencidos que
cualquiera puede programar y que es necesario
llegar a aquellos lugares a donde la Universidad no
suele llegar.
Existe una enorme demanda de personas que tengan
conocimientos para realizar actividades relacionadas
con el desarrollo de software y por eso es una buena
oportunidad para aprender y utilizarlo como salida
laboral.
El proyecto basicamente se divide en 2 partes. La
primer parte est orientada a ensenar Ruby a chicos
desde los 7 aos en adelante, tenemos piojitos muy
chiquititos que tratan de aprender programacin y
esto es sper divertido. La segunda parte del
proyecto est orientada a testing y exigimos que
tengan el secundario completo o al menos por
terminar para estimularlos a que lo terminen. Ms
que nada porque dentro del taller de testing les
comentamos que tienen oportunidad de conseguir
trabajo en el rea de sistemas, y no podemos
presentar CV's de chicos que no hayan terminado el
secundario. Tenemos un manifiesto que tambin
quiero compartirlo:
Nuestras metas son la contencin y la integracin.
Contencin e integracin en respuesta a la
desesperanza y a la fragmentacin social que

vivimos.
Contencin para aquellos que viven una realidad
difcil y encuentran en este espacio un lugar
divertido, cordial e interesante. Divertido porque
genera risas, cordial por su buena onda e
interesante porque despierta inquietudes.
Contencin tambin de los profesores que, al
utilizar este espacio de enseanza y de reunin,
descubren nuevas formas de sentirse tiles; de dar y
recibir. Mediante juegos y compartiendo actividades
del da a da buscamos desestructurar la relacin
alumno-profesor para luego sembrar
perseverantemente una nueva relacin fundada en el
respeto, la paciencia, la comprensin. Slo as la
transmisin de nuestros valores rendir sus frutos.
Integracin al vincular el proyecto y sus miembros
con el entorno, creando y fortaleciendo lazos,
combatiendo la exclusin, los prejuicios y la
desesperanza.
Creemos en la integracin hacia adentro -donde
los dems se acercan al proyecto- y hacia afuera
-donde los alumnos salen a crear sus propios
proyectos y a caminar sus propios senderos-.
Como vehculo que transporta el espritu del
proyecto, elegimos la enseanza informtica
destacando la creacin de programas de
computadora. De esta manera, estimulamos
directamente: la imaginacin, el trabajo en equipo, la
comunicacin, la capacidad de anlisis, la curiosidad
por aprender. Estas herramientas, creemos, son
valiosas en cualquier disciplina y amplan el abanico
de oportunidades.

Entrevista www.infotesting.com

La construccin de programas entendida como oficio

puede ser una oportuna salida laboral. En Nahual,
nos interesa formar perfiles como programador,
diseador, tester u otros vinculados con la industria
del software. Queremos que el proyecto sea un
complemento para el desarrollo laboral de los
alumnos. En el proceso recogemos frutos que no son
buscados directamente; como ser la alfabetizacin
informtica, mayor contacto con el ingls,
razonamiento matemtico y lgico-deductivo.

Cundo arranc y quien lo impulsa?

El proyecto arranco hace mas de 6 anos y empez
bsicamente yendo a un comedor para divertirse con
los chicos del barrio de Villa Centenario, en
Banfield, en el comedor "Contra viento y marea"
Charly, Pablo, Robert, Marian y Lu fueron los
pioneros del proyecto.Somos desarrolladores,
testers, gente de diseo, gerentes de proyectos y
hasta alguno de los chicos tienen su propia empresa
de sistemas. Trabajamos hace mas de 10 anos en el
rubro de sistemas y tenemos perfiles totalmente
distintos, eso creo que le da una dinmica increble,
las clases suelen ser muy divertidas!

Fernando Waisman
Es Licenciado en Informtica, trabaja como QA
Manager en Teracode y posee ms de 10 aos de
experiencia en Calidad de
Software. Es Certified Scrum
Master, Consultor Interno
ISO. Participo de
evaluaciones CMMI y
certificaciones ISO. Trabaja
con metodologias Agiles
desde el 2006. Es profesor
titular en el Instituto de
Tecnologa ORT de la
materia Calidad de
Software, donde es parte
de la organizacin de la jornada de calidad que se
realiza anualmente. Forma parte de la sub comisin
de calidad de la CESSI. Particip como orador en
eventos internacionales (SEPG LA 2008 (Mar del Plata,
Argentina), Jornadas giles Latinoamericanas
2009(Florianpolis, Brasil) JAIIO 2010 (Buenos Aires))

Entrevista www.infotesting.com

Han recibido alguna subvencin para este

emprendimiento?
No, no hemos recibido ninguna subvencin y lo
hacemos todo a pulmn. Imaginate que la mayora
de los profes se toma el tren en constitucin los
sbados a las 8 de la maana y luego un colectivo
para poder llegar al comedor. Siempre nos jodemos
entre nosotros porque te das cuenta enseguida quien
sali la noche anterior y quien tiene cara de fisura!

Cuntas personas han pasado por estos talleres

de capacitacin?
Si preguntar como alumnos calculo que como 30
personas en el curso de testing (empezamos en el
2009 y lo dictamos en el segundo cuatrimestre del
ao) y como 100 al taller de programacin.
Cul es la educacin bsica solicitada para el
ingreso a estos programas?
Como te comentaba anteriormente exigimos que
tengan como minino el secundario completo para el
curso de testing para poder luego ofrecerles una
salida laboral.
Lo ms interesante de todo fue que varios de los
chicos empezaron a estudiar en el terciario de la
UTN la carrera de programador!
Cmo se armaron los programas de
capacitacin? Se confrontaron con las
necesidades de la industria?
Afortunadamente ese no fue un problema porque en
mi caso particular soy profesor de la materia calidad
de software en la carrera de analista de sistemas de
ORT, as que adems de trabajar en la industria estoy
actualizado a nivel acadmico, fue solo cuestin de
adaptar la materia y darle ms valor al punto de
testing. Muchos de los otros chicos tambin son
profes y ayudantes en universidades pblicas como
UTN y UBA, esto facilita el armado de los
programas por tener nocin de cmo hacer esto.

Otro tema para destacar fue que varios de los chicos

que tuvieron entrevistas en empresas han pasado por
exmenes tcnicos de testing y la verdad que les fue
muy bien al grado de que hoy da estn trabajando
en estas empresas.
Hay alumnos de este programa ya incorporados
en empresas? Cuntos?
Si y cada vez que pienso esto se me pone la piel de
gallina y me alegra el alma. Alrededor de 10
personas ya consiguieron trabajo como testers en
varias empresas privadas e inclusiva instituciones
pblicas! El feedback que tenemos de los chicos es
realmente alentador, las empresas estn muy
contentas con ellos e inclusive hemos tenido pedidos
de ms gente!.
Cunta gente trabaja tanto en la organizacin
con en la capacitacin en el proyecto Nahual?
Somos alrededor de 10 personas y nos vamos
rotando porque a veces se hace difcil ir todos los
sbados hasta Banfield, pero cada vez que vamos te
das cuenta que el esfuerzo vale la pena.
Recientemente fueron nominados como
finalistas en los Premios Sadosky, como impact
en el proyecto esta nominacin?
Nos di una alegra enorme, si bien no ganamos ya
habernos nominado para el premio ms importante
de la industria de software nos di un empujoncito
ms, nosotros no lo hacemos por el reconocimiento
pero la verdad que siempre es bienvenido. Imaginate
que competamos contra monstruos como Microsoft
e Intel (que gan) y no es para desmerecer ni mucho
menos pero lo nuestro no es bancado por ninguna
empresa e incluso muchas veces hemos tenido que
poner plata de nuestro bolsillo. Ojo, con esto no digo
que lo que hace la gente de estas empresas no sea
maravilloso, creo que se puede ayudar desde
cualquier lado y cualquier contribucin con la
sociedad es para felicitar.

Entrevista www.infotesting.com

Qu planes tienen para el prximo ao?

Para 2012 estamos pensando en algunos cambios. En
principio queremos largar el taller de testing 2 para
los chicos que ya consiguieron trabajo y darles una
especie de actualizacin profesional. La idea es dar
un cuatrimestre de automatizacin con herramientas
como Selenium y Jmeter, por nombrar algunas. Por
otro lado queremos repetir la excelente experiencia
que tuvimos este ltimo cuatrimestre donde Pablito,
uno de los profes, desarrollo una herramienta con
sus respectivas especificaciones y los chicos no solo
pudieron crear los casos de pruebas sino que tambin
pudieron reportar bugs reales de una aplicaciones
que se desarrollo a la par en que ellos tomaban las
clases. Fue un verdadero proyecto de software!

De varias maneras, en la pgina

http://www.nahual.com.ar pueden encontrar varias
formas de ayudarnos pero les comento algunas:
Sumndose como profes
Abriendo las puertas de las

empresa para que

estos chicos tengan entrevistas como
posibles testers.
Donando computadoras.
y otra ayuda es la que hacen Uds. que es difundir el
proyecto. Queremos que Nahual sea un proyecto
solidario Open Source, que pueda ser replicado en
cualquier parte del pas, de nuestra parte podemos
brindarles el programa y nuestra experiencia en estos
aos donde dictamos el taller.

De qu manera podra colaborar la industria y

quienes estamos en ella con el proyecto?

Alfonsina Morgavi
Es socia de la Consultora QActions, empresa dedicada en exclusividad al aseguramiento y control
de calidad de software.
Est certificada por el Quality Assurance Intitute como Software Test Engineer.
Desde hace ms de 15 aos est dedicada a la especialidad. Ha sido QA Manager por los ltimos
15 aos, formando equipos de trabajo capacitndolos y desarrollndolos.
Es impulsora de la mejora continua en la industria del software.
Forma parte de la comisin de calidad de software de la CESSI, como as tambin de la comisin
de calidad de Normas en TI del Instituto IRAM.
Es miembro del TMMI Foundation. Es habitual disertante en Congresos tanto a nivel nacional como Internacional.

Todos los programas de cursado de las Certificaciones Foundation Level y Advanced Level se encuentran en descarga directa en el sitio web: www.qaustral.com

Notas www.infotesting.com

Son numerosos los errores de software que han

ocasionado todo tipo de costes en el mundo de la
aviacin. Uno de los mas resonantes de las ultimas
dcadas es el protagonizado por el caza europeo
Typhoon. Es resonante por la magnitud de la
tecnologa implicada en el proceso de produccin,
por la cantidad de recursos de diferentes pases que
han intervenido en su desarrollo y por el alcance de
la inversin en millones de euros que ha costado
solo llegar a un producto final, sin tener en cuenta
las inversiones millonarias en la produccin
posterior y en las mejoras de aerodinmica,
armamento y correcciones de software. Otra
caracterstica del proyecto que lo hace nico, es la
coordinacin de equipos en diferentes pases, que
deben incluso adaptar cambios en tiempo real en el
software de la aeronave.
El proyecto
El Eurofighter Typhoon es un caza multi-rol de gran
agilidad propulsado por dos motores gemelos,
diseado y construido por un consorcio de naciones
europeas creado en 1983 y nombrado . Eurofighter
GmbH. Los miembros iniciales del consorcio
EuroFighter eran Reino Unido, Francia, Alemania,
En 1985 Francia dejo el consorcio para dedicarse a
su propio proyecto de Avin de Combate
Experimental (ACX) que desemboc en el caza
Rafale.

Es el nico avin de combate modernos que tiene

lneas de montaje diferentes (el F-16 slo se produce
internacionalmente bajo licencias limitadas). Cada
socio ensambla sus propios aviones, aunque
construye las mismas partes de las 620 aeronaves.
Alenia
Ala izquierda
Bordes de ataque externos
Secciones de fuselaje traseras
BAE Systems
Fuselaje frontal (incluyendo canards)
Pabelln
Espina dorsal
Aletas de cola
Bordes de ataque internos
Secciones de fuselaje traseras
EADS Germany
Fuselaje central
EADS CASA
Ala derecha
Superficies de bordes
El error en el software
La coordinacin de diferentes equipos de trabajo ha
sido fundamental para este desarrollo. El software,
hardware de la computadora y radar han sido
encomendados a las firmas Enosa e Indra Sistemas,
y la turbina a MTU, Rolls Roice y Avio.

11

Notas www.infotesting.com

Durante una de las pruebas en vuelo de uno de los

primeros Eurofighter que tuvo el Ejrcito del Aire
espaol, uno de los tests consista en simular un fallo
de uno de los dos motores del avin, apagndolo
para ver cmo reaccionaba el avin con un solo
motor.
Efectivamente, lo peor que poda pasar, pas.
Cuando se apag el motor, los pilotos rpidamente
se percataron de que el otro motor tambin se
apagaba. Intentaron realizar las pruebas de reinicio
del reactor en vuelo, pero sin resultado. Al llegar a la
altura mnima de seguridad, no tuvieron ms
remedio que eyectarse.
Estudios posteriores revelaron que el software del
avin estaba mal programado, y que el apagado
manual de un motor en vuelo causaba el cierre
errneo de la vlvula de combustible, que no poda
volver a ser abierta en vuelo.
El testeo de los sistemas del avin, no solo se
realizan en laboratorios internacionales, sino
tambin en diversos ambientes y con equipos de alto
nivel. Esta aeronave utiliza desarrollos en C# entre
otros lenguajes que coordinan el funcionamiento
integral de las partes construidas en diferentes
regiones. Sin embargo despus del accidente y la
perdida de millones de dolares ocasionadas, segn
las comunicaciones oficiales por el software de la
aeronave, ninguna de las firmas vinculadas ha
emitido ningn mensaje de reconocimiento o
explicacin de las causas que llevaron a la cada del
Typhoon.

En 2001, se anunci que la RAF no iba a usar el

can interno del avin. Esto no se debe a que se
perciba el can como inadecuado, sino por
considerarlo innecesario ya que con el armamento en
misiles se considera adecuado para el rol de caza del
Typhoon. De todas formas la eliminacin del can
afectara a las caractersticas de vuelo del avin,
requiriendo modificaciones en el software de vuelo
del avin que debera ser costeadas por la RAF.
Debido a esto la RAF anunci que todos sus
Typhoon llevaran el can aunque no sera
utilizado. Los tcnicos de la RAF aseguran que esto
ahorrar dinero al reducir el coste de los
requerimientos para los equipos de tierra y evitar los
efectos de fatiga al disparar el can. La RAF
mantiene la opcin de activar los caones en un
tiempo mnimo si los requerimientos operacionales
varan.

Fuentes
Errores Histricos
EFE
Wikipedia
Diario el Pas.
EAE

La prensa internacional haba remarcado que la

firma responsable de este fallo tambin es la
responsable de los simuladores de vuelo, y en los
simuladores la prueba se realiz exitosamente.
Costes en cambios de software
Como es bien sabido en cualquier proyecto de
desarrollo de software, la inversin y los costes
juegan un papel determinante. Incluso a sabiendas de
cual es el camino correcto, muchos directivos optan
por el camino menos costos. En el Typhoon tambin
se han vivido situaciones semejantes.

12

Ingeniera de requisitos www.infotesting.com

Un proceso de Ingeniera de Requisitos debera aportar

al proceso software las
caractersticas del producto a desarrollar (tanto en un
nuevo desarrollo como en un mantenimiento de
cualquier tipo). Con independencia del proceso de
Ingeniera de Requisitos (especfico) que se utilice, sin
lugar a dudas, habr una actividad de educcin dado que
sin esta actividad no hay requisitos para el futuro sistema
o versin del sistema.
Una vez educidos los requisitos hay que lograr que stos
presenten una serie de caractersticas de calidad. Segn
el IEEE Std 830-1998 los requisitos deben ser:
a) Correctos;
b) No ambiguos;
c) Completos;
d) Consistentes;
e) Clasificados por importancia y/o estabilidad;
f) Verificables;
g) Modificables;
h) Trazables.
En este artculo se abordan mecanismos para solventar
ciertas limitaciones relacionadas con el tipo de
conocimiento del que se extraen los requisitos.
1.0 Introduccin
Segn IREB [1], las actividades principales en un proceso
de ingeniera de
requisitos son, educcin (elicitation), documentacin,
validacin/negociacin y
gestin.
El objetivo de la educcin es encontrar, detectar, deducir,

inferir los requisitos de las distintas fuentes. De todas las

posibles fuentes, los implicados constituyen (como
grupo) la ms importante. Qu variables debe tener en
cuenta la actividad de educcin con respecto a los
implicados?
Los requisitos se encuentran escondidos / recluidos /
presos / ocultos
/residentes en distintos niveles de conciencia de los
distintos implicados
Hay ms de un tipo de implicado
Cada uno de los implicados tiene unas circunstancias
personales,
sociales, culturales y profesionales particulares
Para realizar la actividad de educcin el IREB propone
una serie tcnicas. A
stas se agregan las tcnicas discursivas y de exploracin
propias del anlisis
institucional y la investigacin social en empresas.
Tcnicas basadas en la documentacin
Tcnicas de observacin
Tcnicas de prospeccin
Tcnicas discursivas abiertas [2]
Tcnicas creativas
Cada tipo de tcnica puede contar, a su vez, con una gran
variedad de aplicaciones concretas o adaptadas al caso
de estudio, por ejemplo, cuestionarios y entrevistas
semiestructurados [3] han sido tcnicas clsicas
empleadas tradicionalmente en el paso de prospeccin.
Ocurre que, con mayor o menor frecuencia, las
organizaciones hacen uso de un limitado nmero de
tcnicas, en particular las tcnicas de prospeccin. Este
tipo de tcnica permite revelar un tipo de informacin

15

Ingeniera de requisitos www.infotesting.com

claramente limitada: en algunas circunstancias estas

tcnicas son suficientes, pero en otras no y se
deberan complementar con otras tcnicas.
Siendo los implicados la fuente ms importante de
requisitos, el conocimiento de stos es el esencial para
educir los requisitos del futuro sistema. Este
conocimiento presenta una estructura que, en parte,
escapa al mbito de la Ingeniera de Requisitos,
habiendo adems distintas corrientes o escuelas que
abordan el problema planteado desde soluciones
distintas. Por ello, se hace necesario describir, siquiera
brevemente, la estructura de conceptos que se
adopta en este caso y desde la que se puede aclarar la
exposicin al rea de operaciones planteada. Para tratar
el problema de la identificacin y profundizacin en las
necesidades reales de los distintos segmentos de pblico
implicado, se parte de experiencias previas en distintos
contextos empresariales.
El tipo de conocimiento que influye en los implicados y
su actitud frente al sistema a implementar debe ser
considerado - a efectos operativos del trabajo de
educcin en particular y del proceso de ingeniera de
requisitos en general - como mltiple y complejo:
Conocimiento explcito
o Informacin orientada al contenido (a la tarea)
o Informacin orientada a la posicin personal en la
organizacin (mantenimiento de su estatus, implica
sesgo) o Informacin referente a la cultura y clima de la
organizacin o Discurso errtico (sin objetivo definido, se
sabe que se quiere algo pero no se sabe qu es)
Conocimiento subyacente
o Implcito intencionado (se pretende ocultar)
o Latente (el propio sujeto no sabe que est en su
cabeza) o Emergente (tendencias an latentes que se
estn formando. Se tiene que buscar incidencia en otros
individuos para ser considerados verdaderos
emergentes)
o Flujo creativo (no est cristalizado, es amorfo y
dinmico) En todo tipo de conocimiento identificado ms
arriba, pero especialmente en el que hemos llamado
subyacente, operan variables (intermedias) que
interfieren en el flujo interior-exterior, y que hay que
modular en el proceso de trabajo:
o Variables culturales
o Sistemas de creencias aprendidos en el grupo de
referencia primario (familiolecto)
o Discurso del grupo de pertenencia o pares (grupolecto)
o Sistemas de valores personales (idiolecto)

En otro orden de cosas, cada tipo de conocimiento se

extrae con tcnicas distintas. Esta cuestin es lgica si se
tiene en cuenta que todos los conocimientos se forman
desde presupuestos mltiples, con lo cual para
distinguirlos y ponderar su importancia en la educcin de
requisitos tambin es necesario diseccionarlos y
jerarquizarlos desde distintas perspectivas con el
objetivo de utilizarlos con fines prcticos.
Se debe generar una serie de criterios para identificar y
seleccionar las tcnicas de educcin y para establecer su
secuencia de aplicacin en el proceso especfico. Esta
tarea recae en la Ingeniera de Requisitos, si bien su
ejecucin requerir del apoyo en un especialista. En la
siguiente tabla se proponen una serie de tcnicas
(discursivas abiertas [4] y creativas).
Autores
Gustavo Mrquez Sosa es consultor
independiente en el rea de ingeniera
de software, especializado en pruebas
software y gestin de requisitos. Con
una experiencia de ms de 15 aos en
el mbito de las TI ha colaborado con
organizaciones internacionales,
pblicas y privadas tales como AENA
(Madrid - Espaa), Air France (Pars - Francia), Escuela
Tcnica Superior de Ingenieros Industriales (Madrid Espaa), Telefnica Mviles (Madrid - Espaa), Icon
Medialab (Madrid - Espaa), Visure Solutions (Madrid Espaa) , Daz & Hilterscheid (Berln - Alemania),
IECISA (Madrid - Espaa) o MTP (Madrid Espaa).
Ha participado en eventos profesionales tales como
ExpoQa (Madrid - Espaa) o Testing & Finance
(Frankfurt - Alemania). Es miembro del IEEE, del
Comit Espaol de Pruebas (SSTQB - Spanish Software
Testing Qualification) y miembro tcnico (supporting) del
International Requirements Engineering Board (IREB).
Como miembro del Comit Espaol de Pruebas (SSTQB
- Spanish Software Testing Qualification), forma parte
del comit ejecutivo, pertenece al Grupo de Trabajo del
Glosario del ISTQB, es responsable del grupo de trabajo
para la traduccin del glosario para Espaa y su
coordinacin con Amrica Latina. Como miembro
tcnico de IREB es responsable de la traduccin del
programa de estudios y glosario para Espaa.

16

Ingeniera de requisitos www.infotesting.com

Tabla 1 - Tipos de Conocimiento y Tcnicas de Educcin

Ingeniera de requisitos www.infotesting.com

En general se ejecutarn las tcnicas de educcin

abordando los distintos tipos de sub conocimientos
segn el orden de la Tabla 1, con una posible
excepcin, el conocimiento implcito intencionado.
La idea de estas tcnicas es que se abre un proceso
divergente que se inicia con el citado discurso libre y
gracias a l, el pensamiento divaga de forma
productiva a travs de todas las posibilidades
proyectivas, abrindose en abanico. A continuacin hay
que condensar suavemente el discurso haciendo
converger todos esos pensamientos e ideas generados
hacia un nuevo un discurso libre - no ya proyectivo,
creativo, ilgico - en soluciones realmente prcticas y
adaptables al proceso.
Estas ideas podrn ser objeto de una validacin o ajuste
con una tcnica Delphi5 (se aporta el punto de vista
individual, y se puede incorporar un recurso
humano que no hubiera participado en el proceso)
Una vez recogida la informacin deber ser procesada
con el objeto de:
Documentar los requisitos en la forma adecuada
(lenguaje natural, modelos conceptuales, combinacin
de lenguaje natural y modelos conceptuales)
Lograr requisitos que respondan a las caractersticas de
calidad propuestas por la norma IEEE Std 830-1998
De tal forma que sea posible una gestin adecuada de
estos requisitos.
Conclusiones

No hacer uso de estas tcnicas podra implicar que un

volumen indeterminado de requisitos queden sin educir
y, por lo tanto, se llegue a situaciones anmalas como:
Identificacin errnea del alcance del producto
Problemas de validacin y verificacin parcial y total
del producto,pudiendo conllevar a su rechazo.
Proliferacin de:
o Solicitudes de cambio a todo nivel
o Incidencias
Limitacin en la definicin de criterios de calidad
Aumento de los costes de desarrollo
No siempre ser necesario utilizar tcnicas creativas, sin
embargo es altamente recomendable contar con
criterios que permitan identificar su necesidad, de lo
contrario se vern incrementados los riesgos de proyecto
y producto.
Hay tcnicas que deben ser ejecutadas por un
especialista para garantizar la fiabilidad del resultado.
Autores
Mara Jos Rodrguez
Licenciada en psicologa social y general por la UCM,
con estudios superiores en Filologa Hispnica (UNED),
Antropologa (UCM) e Interpretacin (Estudio Claudia
Fres).
Dedicada desde hace 27 aos a la investigacin social y
de mercados, dirigiendo siempre su orientacin haca la
confluencia de modelos para construir nuevos mtodos
de investigacin presencial y on line.

Tabla 1complementar
- Tipos de Conocimiento
y Tcnicas de Educcin
Es posible que sea necesario
las tcnicas
Ha trabajado en Metra Seis, Grupo Anaya (Responsable
que se utilizan con mayor frecuencia (prospeccin,
de Nuevos Mercados), Inmark Estudios y Estrategias,
tcnicas basadas en la observacin y documentacin)
GfK ad hoc research (Directora de divisin). En la
con tcnicas discursivas menos contaminantes (abiertas,
actualidad es Responsable de Desarrollos cualitativos
poco directivas), y con tcnicas creativas que
en Anlisis On line, parte del grupo AeI.
enriquezcan la perspectiva abriendo nuevos caminos a
Ha presentado conferencias, artculos y talleres en
requisitos emergentes que sean poco visibles desde el
distintas entidades (Cmara de comercio, SGAE,
exterior pero que estn gestndose en el pblico
AEDEMO, Club de Dirigentes de Marketing, Academia
objetivo implicado.
Internacional de GfK, Universidades)

1 International Requirements Engineering Board e.V.

2 Definir el concepto de tcnicas discursivas. No pertenece a la clasificacin del IREB.
3 Entrevista semi estructurada: preguntas cerradas y preguntas abiertas
4 Las tcnicas discursivas abiertas no estn incluidas en la clasificacin propuesta por el IREB.
Estas tcnicas, dentro de la prospeccin, son menos invasivas y ms eficientes de las
disponibles por su evitacin de los sesgos del entrevistador.
5 Delphi: revisin, ajuste final de un pre-documento elaborado sobre la produccin anterior y que en este punto es evaluado y corregido desde el individuo singular,
desde cada uno de los participantes por separado, pudiendo incorporar puntos de vista externos si se considera necesario o aplicable (uno o varios)

18

RRHH www.infotesting.com

Cada vez es ms comn, y, por ende, se ha tornado

normal que los equipos de QA, ya sea que sus
integrantes pertenezcan a la misma empresa que
desarrolla el software, a una empresa proveedora del
servicio, o a ambas empresas, se encuentren localizados
en distintos pisos, edificios, ciudades o pases.
A los equipos as conformados se los tipifica como
distribuidos geogrficamente, simplemente distribuidos,
o virtuales, en contraposicin de los equipos
presenciales o co-localizados que ocupan un mismo
espacio fsico. A su vez, a la distribucin geogrfica, se
adiciona lo multicultural y multinacional.
Antes de continuar, corresponde definir qu es un
equipo:
Un equipo es un grupo de personas que trabajan entre s
para alcanzar un objetivo comn. El equipo puede ser
eficaz o ineficaz, dependiendo de cmo sus integrantes
trabajen juntos para cumplir con los plazos y completar
tareas.
Esta definicin reafirma que los miembros de un equipo
de QA, aunque estos se encuentren distribuidos, son
parte del mismo equipo.
En lo que respecta a lo multicultural y multinacional, en
un pas como la Argentina, crisol de razas, con
profesionales de otras nacionalidades, culturas e idiomas
viviendo y trabajando en nuestro pas, formar parte de
un equipo de QA multicultural y multinacional es o
deber ser para todo aquel que integre un equipo de QA
tambin algo natural, debindose tener siempre en

cuenta la diversidad de cada uno de sus integrantes.

Esta diversidad se refiere a las caractersticas que hacen
nicas a las personas y que tenemos que reconocer y
apreciar, dando lugar siempre a un ambiente que
promueva y celebre los logros individuales y colectivos.
Ejemplos de estas caractersticas son: edad, estilo
cognitivo, cultura, discapacidad (mental, de aprendizaje,
fsica), entorno econmico y geogrfico, educacin,
identidad de gnero, idioma o idiomas que habla, estado
civil, apariencia fsica, afiliacin poltica, raza y origen
tnico, creencias religiosas, orientacin sexual.
Ahora, aunque esta distribucin de los equipos de QA, es
una realidad presente, tambin lo es que, al existir
distintas locaciones, zonas horarias, culturas e idiomas,
se agregan nuevos condimentos que se deben tener en
cuenta al coordinar o participar de un equipo distribuido.
Ventajas

Reduccin de costos por menor necesidad de

desplazamientos e infraestructura.
Acceso a habilidades y experiencias diversas.
Trabajar siguiendo al sol.

Desventajas

Diferencias idiomticas y culturales

Menos interacciones presenciales, cara a cara
Distintas zonas horarias.

19

RRHH www.infotesting.com

Herramientas Asncronas
Las herramientas asncronas son las que permiten que la
comunicacin entre los participantes no tenga que
realizarse en tiempo real. Estos no tienen que estar
conectados en el mismo momento.

Correo Electrnico (E-mail)

Listas de Distribucin
Blogs
Wikis
Foros
Redes Sociales
Microblogs

En lo que respecta a herramientas de prueba de

software, se deber elegir una a la cual se pueda acceder
tanto de manera local como remota, mejor si es una
aplicacin web, donde se pueda tener acceso a los
requerimientos; realizar el plan de pruebas, la ejecucin
de las pruebas, apertura y seguimiento de defectos, y
generacin de reportes. Por ejemplo: HP Quality Center.

Herramientas Sincrnicas
Las herramientas sincrnicas son las que permiten una
comunicacin en tiempo real. Los participantes deben
estar conectados en el mismo momento y se comunican
entre s mediante texto, audio y/o video.

Chat (solo texto)

Mensajera Instantnea (IM)
Pizarras Digitales Interactivas
Audioconferencia
Videoconferencia
Telepresencia

A continuacin, incluyo las recomendaciones provistas

por Sirkka L. Jarvenpaa y Dorothy E. Leidner, a travs de
sus investigaciones sobre equipos distribuidos
(Communication and Trust in Global Virtual Teams),
para el coordinador (lder o gerente) del equipo y para
sus miembros:
Se recomienda al coordinador

Definir claramente las responsabilidades de cada

miembro del equipo.
Proveer guas sobre la frecuencia de comunicacin
sugerida y la necesidad de ser predecibles en las
conductas.
Asegurarse de que cada una de las personas tenga
objetivos personales complementarios y comparta el
objetivo principal del equipo distribuido global.
Captar las incomodidades y descontentos lo ms
tempranamente posible.
Tratar los problemas de algunos participantes
individuales en una comunicacin uno a uno,
evitando copiar los mensajes al resto del equipo.
Tener muy en cuenta los perfiles de los individuos al
seleccionar los miembros de un equipo distribuido
global.

20

RRHH www.infotesting.com

Se recomienda a los miembros del equipo

Suplir la falta de contacto cara a cara con un

intercambio de mensajes lo ms explcito y completo
posible al inicio del proceso.
Dar al resto de los participantes, claves y detalles
sobre el trabajo que cada persona est haciendo.
Ser conscientes que lo ms importante no es la
cantidad de mensajes sino su calidad y previsibilidad.

Luis Mercadal
Ingeniero de Sistemas - UCC
Project Management
Professional (PMP) - PMI
Certified ScrumMaster
(CSM) - Scrum Alliance
Certified Tester Foundation
Level (CTFL) - ISTQB
Ex Corresponsal del
Consejo Profesional de Ciencias Informticas de la
Provincia de Crdoba (CPCIPC)
Ms de 16 aos de experiencia profesional en IT,
desarrollada en empresas nacionales y
multinacionales, en Argentina y Brasil.

Y concluyo con la Regla 90/10 de Jessica Lipnack y Jeffrey

Stamps (Virtual Teams: People Working Across
Boundaries with Technology), la cual hace hincapi en
que el xito de un equipo distribuido se basa un 90% en
las personas involucradas y un 10% en la tecnologa, o
sea que si no se han determinado las reglas, los roles y
las responsabilidades en el equipo, y si las relaciones
entre los miembros del equipo son pobres, no importa
que tecnologa est disponible; sin embargo,
seleccionando la tecnologa apropiada para cada tarea, y
luego utilizndola con eficacia, deber mejorar el
rendimiento de cualquier equipo.

21