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.
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
Solo registro de incidencias. Sin definición de Casos de Prueba.
Un axioma es una proposición que se considera evidente y se acepta sin requerir demostración previa.
Edsger Wybe Dijkstra fue un científico de la computación de los Países Bajos.
Nota: Los tests de regresión no se ejecutan únicamente cuando se agrega nueva funcionalidad. También pueden ser cuando se modifique otra ya existente. El concepto, es simplemente, asegurarse de que lo que ya se desarrollo siga funcionando
Input: Es lo como se llama al cuadro de entrada de texto.
Abierto: El tester encuentra un bug y lo reporta.
En progreso: El bug ha sido asignado a un desarrollador, y se encuentra en proceso de corrección.
Resuelto: El desarrollador ha resuelto el problema en el ambiente de desarrollo.
No pudo reproducir: El desarrollador no pudo reproducir el bug. Es trabajo del tester verificar que el error siga pasando y agregar información para que el desarrollador pueda reproducirlo y corregirlo.
No es bug: El desarrollador cree que el defecto reportado no es un bug, y el mismo lo comenta con el líder, quien está de a cuerdo. Éste estado está acompañado de una descripción con los motivos. En caso de que el tester no está de acuerdo con el motivo del desarrollador, y cree que realmente es un defecto, puede poner el bug en el estado “Reabierto”. Ante conflictos es el líder quien decide.
En Testing: El líder cambiara el estado a “En testing” una vez que se realice un nuevo pasaje a Testing. El tester ya puede verificar la corrección del bug.
Anulado: Si el bug fue mal cargado o está duplicado, se pasa a éste estado.
Reabierto: Si al verificar una corrección el bug se sigue produciendo, se debe cambiar su estado actual a éste.
Cerrado: Una vez el tester ha verificado que el bug fue corregido y el mismo ya no ocurre, pasa la incidencia a éste estado.