17
Capacitación Tester QA Mayo, 2011

Capacitacitación Tester - QA 3

Embed Size (px)

DESCRIPTION

Capacitacitación tester qa 1

Citation preview

Page 1: Capacitacitación Tester - QA 3

Capacitación Tester QA

Mayo, 2011

Page 2: Capacitacitación Tester - QA 3

Análisis de Ambigüedades

Proceso de Pruebas Basadas en Requerimientos (RBT). Definición de Habilidad de ser Probado.

Los resultados se pueden medir/predecibles.

Dado un estado inicial del sistema y una serie de condiciones, es posible

predecir exactamente cuáles serán los resultados.

Probar = comparar un resultado esperado con un resultado observado.

Page 3: Capacitacitación Tester - QA 3

Análisis de Ambigüedades Modelo V

Page 4: Capacitacitación Tester - QA 3

Análisis de Ambigüedades Proceso de Pruebas Basadas en Requerimientos (RBT).

Page 5: Capacitacitación Tester - QA 3

Análisis de Ambigüedades Proceso de Pruebas Basadas en Requerimientos (RBT).

Page 6: Capacitacitación Tester - QA 3

Análisis de Ambigüedades Proceso RBT: Pasos Básicos

1. Validar requerimientos comparado con los objetivos.

2. Aplicar casos de uso en base a los requerimientos.

3. Realizar un análisis inicial de ambigüedad.

4. Realizar una revisión de contenido por especialistas en la materia.

5. Graficación de causa-efecto.

6. Realizar revisiones de consistencia lógica y diseño de casos de pruebas.

7. Verificar los casos de pruebas con los autores de los requerimientos.

8. Verificar los casos de prueba con los usuarios/expertos en la materia.

9. Verificar los casos de prueba con los desarrolladores.

10. Utilice los casos de prueba en la revisión del diseño.

11. Utilice los casos de prueba en la revisión del código.

12. Valide el código con los casos de prueba derivados de los requerimientos y casos de uso.

Page 7: Capacitacitación Tester - QA 3

Análisis de Ambigüedades

Beneficios de las Técnicas RBT.

Revisión de Ambigüedad Aplica a los requerimientos funcionales y a los no-funcionales: Puede ser utilizado con requerimientos y especificaciones documentados.

Proporciona requerimientos y especificaciones que son claras, precisas,

predecibles, correctamente lógicas, consistentes y que se pueden probar.

Involucra y beneficia a todos los interesados (stakeholders) (es decir diseñadores / arquitectos / DBA’s, programadores, probadores).

Establece la plataforma para la revisión de productos de trabajo posteriores y seguimiento de los requerimientos.

Page 8: Capacitacitación Tester - QA 3

Análisis de Ambigüedades

Revisión de Ambigüedad:

Ejercicio 1

Imagine un coche que ha sido diseñado para que “se maneje a si mismo”.

Lo que sigue representa uno de los requerimientos para este coche – ¿o no?

Anote todas las ambigüedades que usted pueda pensar - tiene 10 minutos.

“Si la luz es roja, entonces pare.”

Page 9: Capacitacitación Tester - QA 3

Análisis de Ambigüedades

Revisión de Ambigüedad:

Ejercicio 2

Requerimiento de Negocio Antes de la Revisión de Ambigüedad.

El Cajero Automático (ATM) enviará una alarma al departamento de tecnología de la información (IT) cuando el ATM se ha tratado de forzar. En caso que el ATM se abra sin la llave y el código de seguridad, el ATM alertará al departamento inmediatamente para que pueda tomar la acción apropiada.

Identifique las Ambigüedades -- tiene 10 minutos.

Page 10: Capacitacitación Tester - QA 3

Análisis de Ambigüedades

Ejercicio 2

Requerimiento de Negocio Corregido después de la Revisión de Ambigüedades

Un Cajero Automático (ATM) enviará una alarma electrónica al Oficial de Seguridad en guardia al departamento de IT cuando el ATM se ha tratado de forzar, es decir, abierto sin el uso de una llave física, seguido por el código de seguridad válido. Caso 1: (1) Si un operador autorizado de servicio inserta la llave física en la ranura del ATM, entonces mostrara el siguiente mensaje en la consola del ATM: "introduzca por favor el código válido de seguridad." (2) Si el operador del servicio introduce el código válido de seguridad, entonces la puerta del ATM se abre. Caso 2: Después de insertar la llave en el ATM, si el operador del servicio introduce un código de seguridad incorrecto, entonces (1) se muestra el siguiente mensaje en la consola del ATM: “Código de Seguridad inválido. Intente de nuevo por favor." (2) el operador del servicio ahora tiene tres intentos para introducir el código válido de seguridad. Si un código válido de seguridad se introduce en menos que o igual a tres intentos, entonces la puerta del ATM se abre. Después de cada uno de los primeros tres intentos con un código de seguridad inválido, el siguiente mensaje se mostrará en la consola del ATM: “Código de Seguridad Inválido. Intente de nuevo por favor.» Caso 3: Si un código válido de seguridad no ha sido introducido al tercer intento, entonces (1) el siguiente mensaje se mostrará en la consola del ATM: “Código de seguridad inválido. La oficina de seguridad será notificada." (2) El ATM envía una alarma a la Oficina de Seguridad inmediatamente. Caso 4: En caso que el ATM se abra sin la llave y el código de seguridad válido, entonces el ATM envía una alarma al departamento de Seguridad inmediatamente que el ATM has sido forzado.

Page 11: Capacitacitación Tester - QA 3

Análisis de Ambigüedades Lista de Comprobación de la Revisión de Ambigüedad: Un “de otro modo” pendiente.

Ambigüedad de referencia.

Alcance de la acción.

Omisiones:

– Causas sin efectos.

– Efectos faltantes.

– Efectos sin causas.

– Omisiones completas.

– Causas faltantes.

Operadores lógicos ambiguos:

– O, Y, Ni, Y No.

– Conectores implícitos.

– Operadores compuestos.

Negación:

– Alcance de la negación.

– Negación innecesaria.

– Doble negación.

Declaraciones ambiguas:

– Verbos, adverbios, adjetivos.

– Variables, Seudónimos innecesarios.

– Abreviaciones y acrónimos.

Organización aleatoria:

– Causas y efectos mixtos.

– Secuencia de casos al azar.

Supuestos integrados:

– Conocimiento funcional / de ambiente.

Relación de precedencia ambigua.

Casos implícitos.

Etcétera.

Es Decir (i.e.) vs. Por Ejemplo (E.G.).

Ambigüedad temporal.

Límite de la ambigüedad.

Palabras y frases ambiguas.

Page 12: Capacitacitación Tester - QA 3

Análisis de Ambigüedades

“De Otro Modo” pendientes:

Ejemplo con ambigüedad:

“El código debe ser cualesquiera A, B, o C.”

¿Entonces? ¿Una condición de error?

Ejemplo sin ambigüedad:

Si el CLIENTE es un CLIENTE-CORPORATIVO

Entonces:

FUNCION_1

De Otro Modo (CLIENTE es un CLIENTE-MINORISTA)

NO_ACCION

Fin.

Page 13: Capacitacitación Tester - QA 3

Análisis de Ambigüedades

Etcétera:

“Para la transacción 1, actualizar el registro del cliente, imprimir el estado de cuenta del cliente, etcétera.”

“La cantidad total debe de ser pagada para miembros plenos, miembros asociados, etcétera.”

Page 14: Capacitacitación Tester - QA 3

Análisis de Ambigüedades

Nombres Explícitos de Variables:

Sumar el INTERES-GANADO al BALANCE-DE-CUENTA.

Si es más de $1,000 entonces pasar al CLIENTE a LISTA-CUENTAS-CLAVES.

VERSUS

Sumar el INTERES-GANADO al BALANCE-DE-CUENTA.

Si el INTERES-GANADO es más de $1,000 entonces pasar al CLIENTE a LISTA-CUENTAS-CLAVES.

Page 15: Capacitacitación Tester - QA 3

Análisis de Ambigüedades

Descuidos:

De un libreto de seguridad de una línea aérea (encontrado en el bolsillo del asiento):

“Si usted está sentado en una fila de salida y usted no puede leer esta tarjeta ni puede ver lo suficientemente bien para seguir estas instrucciones, dígale por favor a un miembro de la tripulación."

Page 16: Capacitacitación Tester - QA 3

Análisis de Ambigüedades

Características a Buscar: Todas las ambigüedades eliminadas: Procesos descritos a un nivel predecible/que se pueda probar. Todas las reglas son explícitas. Todas las reglas son lógicamente consistentes. Se aplican consistentemente los estándares de proceso. Escritos en un estilo que es: – Consistente. – Que todas las audiencias pueden leer. Optimizado la probabilidad de re-uso. Da apoyo al seguimiento.

Page 17: Capacitacitación Tester - QA 3

Análisis de Ambigüedades

Claves para Requerimientos Excelentes:

Educar a los usuarios, desarrolladores, gerentes y probadores.

Una asociación de colaboración entre usuarios-consultores-desarrolladores-probadores.

Reconocer que hay diversas clases de requerimientos.

Desarrollo iterativo, incremental de los requerimientos.

Plantillas estándares de documentos de requerimientos.

Revisiones formales e informales de requerimientos.

Escribir casos de prueba contra los requerimientos.

Priorizar los requerimientos analíticamente.

Control de cambios practico y eficaz.