Tester QA Manual

Módulo 1 - Resolución del laboratorio

Tester QA Manual

Resolución del ejercicio 1

1. Testing: Es la forma de evaluar la calidad del de la que hubiera salido si no pasaba por
SW. Hablamos de resultados objetivos y nuestras manos.
medibles. En la escala del 1 al 100, ¿cuánta
2. Visión antigua y actual: Históricamente, la
calidad tiene ese sistema?
visión del Testing era: buscar fallas, reportar
Se hace por medio de pruebas. Pueden ser fallas, ver que está mal en el sistema. Hoy en
desde la revisión de los documentos donde día, hace mucho más que eso. Evalúa un
está explicado el requerimiento, hasta la sistema completo para ver en qué medida se
prueba del sistema, es decir, someterlo a adecúa a lo que pidió el cliente. También para
prueba. “De las pruebas que hice sobre el recomendar cómo el sistema podría ser mejor.
sistema, el 60% de las pruebas fue exitosa.”
Evaluamos el sistema para detectar fallas, y
lograr que el sistema salga con mejor calidad
Tester QA Manual

3. Propósitos del Testing: 4. Actividades de un Analista QA/Tester:

a. Detectar y resolver problemas tan pronto a. Confeccionar estrategias y planes de

como sea posible. prueba.

b. Verificar que las pruebas cumplan con el b. Analizar requisitos y/o requerimientos.
requerimiento.
c. Diseñar casos de prueba.
c. Generar compromiso en los usuarios.
d. Establecer ambientes de prueba.
d. Trabajar con cero defecto desde el inicio.
e. Generar set de datos de prueba.

f. Ejecutar casos de prueba.

g. Administrar, registrar e informar las

pruebas.

h. Realizar reportes y seguimiento de defectos.

i. Etc.
Tester QA Manual
5. Qué es Validación y Verificación:
● Validación: comprobar que el sistema hace
lo que el cliente pidió.
● Verificación: comprobar que lo que hace el
sistema, lo hace bien.
Por ejemplo, en un ticket de compra debe figurar
cuánto te cobraron por el IVA. La validación,
significa comprobar en el ticket que imprime la
máquina que tiene un renglón que diga IVA. Esto lo
pidió el cliente. Ahora, comprobar que el cálculo de
ese IVA es correcto, es verificar. Se valida según lo
que pidió el cliente y verifica en función de genera
ese resultado.
6. Error, falla y defecto:
● Error: equivocación humana. Acción de
equivocarse. El desarrollador se puede
equivocar, o el que escribe lo que el cliente
pide, se equivoca. “Quiere un sistema
amigable”, no nos sirve a nosotros; eso
estaría mal. Cuando alguien se equivoca en
el proceso de desarrollo de SW, puede dejar
un defecto en el código.
● Defecto: desperfecto que puede causar que
un componente o sistema falle. Una de las
cosas que rige el lenguaje de programación
es que tiene que cumplir con cierta sintaxis,
con un formato particular.
Tester QA Manual

Algunas veces, cada oración tiene que terminar Ejemplo: una empresa de vuelos, quiso actualizar
con punto y coma. Si el programador se olvida de sus precios. Y en el SCRIPT, en vez de multiplicar
por 10 (para aumentar un 10%), multiplicaron por
esto, deja un defecto. Esta imperfección puede
0 (dejando el precio en 0 pesos).
causar que el sistema falle.
- Error: que se olviden de poner un 1 en una cuenta
● Falla: diferencia entre el resultado esperado y (la omisión).
el obtenido. “¿Qué pasa si me deja transferir
- Defecto: que falta un 1.
más plata de la tengo?” Eso es una falla.
- Falla: lo que ve el usuario. Ej.: los pasajes a 0
Los desarrolladores pueden equivocarse y pesos, porque en vez de multiplicar por 10, se
cometer un error, dejando un defecto que a multiplicó por 0 (se olvidaron de poner un 1).
su vez genera una falla. La falla es lo que ve
el usuario y eso está mal. Como usuarios,
detectamos fallas.
Tester QA Manual

7. Trazabilidad: A veces la falla viene por una

mala interpretación de lo que el cliente
necesita, lo cual acarrea una mala calidad.
Cada falla está relacionada con alguna
prueba que se pensó o se hizo. La prueba
busca evaluar un requerimiento en particular.

La relación entre estos conceptos (pruebas

con las fallas y con los requerimientos) se
llama trazabilidad, que relaciona lo siguiente:
Si hay una falla, ¿cuántas pruebas están rela-
cionadas con la misma?, y ¿qué requerimiento
está siendo afectada? No es lo mismo una
falla menor que una grave.
Tester QA Manual

Resolución del ejercicio 2

Metodologías: ¿Cómo trabaja el Tester?, ¿cómo
lo hace? Interactuando con desarrolladores y
analistas funcionales. Hay dos maneras de
trabajar: Ágil y Tradicional.
Hoy en día, la metodología más usada es la Ágil.
La Tradicional implica trabajar en una empresa
donde el Analista Funcional habla con el cliente,
interpreta lo que pide y lo escribe en un
documen-
to (que se conoce como “documento funcional”)
Cuando ese documento está listo, se lo pasa al
Desarrollador y éste, comienza con el proceso
de programación. Hace los cambios en el sistema
y cuando están listos, se lo pasa al Tester, quien
lee el documento y hace pruebas en el sistema,
reporta fallas, espera a que se lo corrijan y vuelve
a probar otra vez.
Cada uno de los actores trabaja uno a la vez y
bastante separados unos de otros. Dejó de ser
popular, porque genera que los proyectos tarden
mucho tiempo. Hay que adaptarse al ritmo de
mercado, o sea, lo antes posible.
Hace 20 años nació el Marco Ágil, específica-
mente Scrum. No es el único marco ágil pero
es el más popular y comercial. Tiene muchas
certificaciones.
Tester QA Manual
En Scrum, todos trabajan en conjunto en el Team
de la mesa ágil (o la célula ágil).
Al Analista Funcional se le cambia el nombre a
Product Owner o Dueño de Producto y todo el
equipo trabaja para realizar entregables
pequeños, con un tiempo finito, que pueden durar
entre 2 a 4 semanas, en un período que se llama
Sprint. Por cada Sprint, hay una reunión de todo
el equipo, donde deciden qué tareas son las que
van a trabajar durante ese tiempo; es una
planifica-
ción llamada Sprint Planning. Estiman cuántas
tareas pueden tener listas en ese período de 2 o
4 semanas.
¿Qué hacen en ese momento? El equipo define
qué tareas puede hacer en 2 semanas, las más
prioritarias para el cliente, y ocurre una reunión
diaria entre el Desarrollador, el PO y el Tester
para que todos estén a tono de lo que se está
haciendo.
El PO puede decir: “el cliente quiere el formulario
en rojo”. Al día siguiente, el desarrollador dice:
“para hacer el formulario en rojo, tengo que hacer
una nueva página HTML y unas tablas en base
de datos.” El Tester tiene en cuenta el impacto
que va a tener el desarrollo que tiene que probar.
Tester QA Manual

Al día siguiente, en la reunión que se llama Daily
(c/24 hs) el Tester dice: “empecé a probar y
reporté dos fallas, pero la nro. 1 es la más crítica,
la necesito para poder seguir trabajando porque
sino, no vamos a terminar en la fecha prometida.”
Bueno, se encarga de hacer esa gestión. Al final
se hacen dos reuniones: Sprint Review y Sprint
Retrospective, donde se revisa qué se logró en el
Sprint. La meta es que se pueda lograr lo que se
había dicho anteriormente.

Este proceso de planificar, elegir cuánto dura el

Sprint, hacer la Daily, es monitoreado por un rol
que se llama Scrum Master. Es quien vela por el
cumplimiento del marco de trabajo ágil, y que se
respete el marco de trabajo del Scrum. Muchas
veces se le confunde con el líder de proyecto,
porque vela por que las cosas salgan; ayuda a
destrabar cuando algo se bloquea. Por ejemplo:
“tengo una falla y no me la corrigen y no puedo
seguir probando”.
¡Sigamos
trabajando!