El documento presenta el proceso de pruebas basadas en requerimientos (RBT) para la capacitación de probadores de calidad de software (QA). Describe los pasos básicos del proceso RBT, incluida la validación de requerimientos, la aplicación de casos de uso, el análisis de ambigüedades y la revisión de diseño y código utilizando casos de prueba derivados de los requerimientos. También cubre los beneficios de las técnicas RBT como la revisión de ambigüedades y el involucramiento de

1. Capacitación Tester QA
Mayo, 2011

2. 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.

3. Análisis de Ambigüedades
Modelo V

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

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

6. 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.

7. 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.

8. 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.”

9. 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.

10. 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.

11. 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.

12. 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.

13. 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.”

14. 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 LISTACUENTAS-CLAVES.

15. 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."

16. 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.

17. 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-consultoresdesarrolladores-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.