El documento presenta definiciones y conceptos clave relacionados con testing de software. Define términos como error, defecto, fallo, casos de test, datos de test, y cubrimiento. También describe técnicas de derivación de casos de test como partición de equivalencias y análisis de condiciones de borde. Por último, proporciona lineamientos para el reporte de incidentes de manera concisa y clara.

1. Taller de Testing
andres.grosso@engee.com.ar
Registro de bugs

2. Definiciones
• El testing es el proceso que compara “lo que es” con “lo que debería ser”.
• Error
 Equivocación cometida por un humano durante el proceso de desarrollo.
• Defecto (defect o fault)
 Consecuencia de un error: están presentes en un producto de software. La presencia de un
defecto diferencia un producto correcto de uno incorrecto.
• Fallo (failure)
 Manifestación del defecto: diferencia entre los resultados esperados y reales.
Recordando . . .

3. Más definiciones
• Testear
 Ejecutar un programa con el objeto de identificar fallos, comparando el resultado
esperado con el resultado obtenido a partir de la ejecución.
• Axiomas del testing
 “El Testing sólo puede mostrar la presencia de defectos, no su ausencia”. (Dijkstra)
 Un test sólo es exitoso si encuentra errores.
 Cuando cumplimos el rol de Tester debemos ser creativos… pero para destruir.
• Cobertura o Cubrimiento
 Es una medida de qué tan completo fue el testing (en función de una estrategia
particular).
 Toda estrategia tiene asociado su concepto de cobertura.
Recordando . . .

4. Más definiciones
• Casos de test
 Descripciones de qué se va a probar.
 Crear casos es un proceso creativo.
• Datos de test
 Lotes de datos necesarios para ejecutar un caso de test.
 Crear datos de test es un proceso laborioso, y muy poco creativo.
• Mito:
 Las tareas de testing muchas veces son mal llamadas como QA (Aseguramiento de la
calidad), cuando en realidad estas tareas son de QC (Control de Calidad).
Recordando . . .

5. Más definiciones
• Test Limpio (o positivo)
 Intenta mostrar que el producto satisface sus requerimientos.
• Test Sucio (o negativo)
 El objetivo es romper el sistema.
• Test de regresión
 Luego de agregar una nueva funcionalidad, se vuelven a probar
las funcionalidades ya existentes (casos más importantes).
Recordando . . .

6. Testing dinámico
• Se ejecuta y observa el comportamiento de un producto.
Estimulo  Proceso  Respuesta
• Tipos
 Caja Negra: Requerimientos
 Caja Blanca: Código
Recordando . . .

7. Técnicas de derivación de casos
de test
• Partición de equivalencias
 Particiona el dominio de entrada en un conjunto de clases de entrada (o
inputs) que tienen comportamientos similares .
 Luego se selecciona un valor representativo de cada partición para ser
testeado.
• Análisis de condiciones de borde
 Variación de la técnica de partición de equivalencias, que se focaliza en los
bordes de cada clase de equivalencia: por arriba y por debajo de cada clase.
• Test de robustez
 Es una variación de la técnica de análisis de borde.
 Consiste en ingresar no un valor apenas superior al máximo valor sino
muchísimo mayor, y un valor muchísimo inferior al mínimo valor.
Recordando . . .

8. Reporte de incidentes
• Comunicación hacia el equipo del proyecto sobre la calidad del producto.
• Información para evaluar y hacer seguimiento
• Los reportes útiles son aquellos que hacen que los defectos se corrijan.
• Los lineamientos que exponemos a continuación buscan:
 Uniformizar la manera en que se reportan los incidentes.
 Asegurar la calidad mínima de su contenido.
 Acelerar los tiempos de corrección y verificación

9. • ID de la incidencia
• Sección/módulo
• Ambiente
• Descripción
• Datos
• Pasos
• Estado
• Reportado por, resuelto por, cerrado por, etc.
• CP relacionado (tarea y requerimiento también si se puede)
Datos de una incidencia

10. Estados
• Abierto
• En progreso
• Resuelto
• No pudo reproducir
• No es bug
• En testing
• Anulado
• Re-abierto
• Cerrado

11. Descripción
• Ser claros, breves, simples.
• Estructurar la descripción de manera que resulte claro que
pantalla/funcionalidad se estaba probando (y en lo posible en que
contexto se produjo)
• Por ejemplo,
 Incorrecto: “Si se presiona grabar al dar de alta se produce un error.”
 Correcto: “Usuarios. Alta. Grabar. Error java script. ”
Lineamientos

12. Descripción - Estructura
Usuarios. Alta. Datos válidos. Grabar. No graba al usuario.
Contexto DesencadenadorPasos Resultado
Como opcional, puede ir el
resultado esperado.

13. Descripción
• Debe ser un buen resumen del problema que se esta reportando.
• No debería ser necesario más detalle para entenderlo a alto nivel.
• Incorrecto
 “Se produce un error (ver detalle) al realizar la baja (ver adjunto)”
• Correcto
 “Usuario. Baja. Perfiles asociados = 1. Error de javascript.”
• Incorrecto
• “No puede ingresar al sistema.”
• “No se puede loguear un usuario con algunos perfiles.”
• Correcto
• “Login. Jefe de ventas. No es posible ingresar al sistema. El sistema presenta un mensaje
de error”
Lineamientos

14. Descripción
• Identificación rápida y unívoca
 Debe contener las palabras clave que faciliten su búsqueda.
 No deben existir dos bugs con la misma descripción.
• Describir, en lo posible, la diferencia entre el resultado obtenido y el
esperado.
• Ejemplo:
 Incorrecto: “Si el profesional no tiene disponibilidad la celda se muestra amarilla.”
 Correcto: “Profesional sin disponibilidad. La celda se muestra amarilla. Debería mostrarse
en rojo. ”
Lineamientos

15. Descripción
• Evitar la ambigüedad, explicar claramente las
condiciones en las cuales se produce el problema.
 Incorrecto: “Alta. País Duplicado. Permite dar de alta un país
ya existente.”
 Correcto: “Alta. País Duplicado. No es case sensitive.”
Lineamientos

16. Descripción
• No personalizar incidentes
• La gramática y ortografía deben ser correctas
• Evitar apreciaciones subjetivas (¡ojo con el tono!)
• En el detalle de la incidencia especificar con los datos con los que se produjo
el incidente.
• Si es necesario indicar pasos para su reproducción.
Lineamientos

17. Criticidad
• Bloqueante: Errores que imposibilitan la ejecución de una o más funcionalidades.
• Crítico: Errores de criticidad “Alta” que imposibilitan la ejecución de un circuito “principal”.
• Alta: Errores graves que, en general imposibilitan la ejecución del caso de prueba al que están
asociados.
• Media: Errores graves, pero que no imposibilitan la ejecución del caso al que están asociados. (por
ejemplo, errores de validaciones de formato). La funcionalidad por lo general puede ser accesible a
través de caminos alternativos, aunque estos no sean óptimos.
• Baja: Errores menores, que no impiden mayormente la utilización del sistema. En general, pueden ser
problemas de ortografía o de interfaz gráfica del sistema.
Lineamientos

18. Generales
• No reportar dos problemas diferentes en el mismo incidente.
• Verificar que el incidente no se encuentre ya reportado.
• Aunque el incidente no se pueda reproducir, reportarlo.
• Siempre que valga la pena adjuntar captura de pantalla.
• Reportar el incidente apenas es detectado.
• No hay que subestimar la importancia de reportar correctamente.
Un incidente bien reportado es fácil de entender y reproducir.
Lineamientos

19. ¿Preguntas?
Regresión: “Cuando arreglas un bug, introduces muchos nuevos.”