miércoles, 29 de enero de 2014

Características de un buen informe de defecto

Cuando se ejecuta un caso de prueba, si el resultado obtenido no coincide con el resultado esperado, decimos que existe un defecto en el software. Este defecto debe ser descrito en un informe de defecto para que pueda ser corregido por un desarrollador.
Un informe de defecto debe tener (entre otros), los siguientes datos:
  • Un ID único para identificarlo inequívocamente.
  • Un breve resumen del defecto.
  • Una descripción del entorno de pruebas en el que se ha realizado la prueba y su configuración.
  • Versión del software objeto de pruebas.
  • El o los casos de prueba afectados por el defecto.
  • Una descripción de los pasos seguidos hasta llegar al defecto (si es reproducible) y de los datos utilizados. Es importante incluir evidencias (capturas de pantalla, vídeos, sonido, etc.) de cada paso.
  • Su severidad: La severidad está relacionada con el riesgo de negocio que supondría no resolver el defecto. En ocasiones también se relaciona con el impacto que tiene en la continuidad del ciclo de pruebas. Normalmente se establecen 3 ó 4 niveles de severidad. Por ejemplo: Bloqueante, Alta, Media, Baja. Es muy importante que todos los interesados del proyecto tengan muy claros los criterios de asignación de severidades para favorecer la comunicación entre equipos y evitar malentendidos.
  • Su prioridad: La prioridad, que en ocasiones se confunde con la severidad, está relacionada con el riesgo del proyecto; es decir, que la prioridad está muy ligada a la urgencia de resolución del defecto.
  • La descripción de un único defecto: En un informe de defecto no se pueden explicar varios defectos, sólo 1.
  • El resultado esperado: Para evidenciar por qué esperábamos un determinado resultado se pueden utilizar referencias a la base de pruebas
  • El resultado obtenido (incorporando evidencias).
  • La fecha de detección.
  • El tester que lo ha detectado.
  • El desarrollador al que se asigna el defecto.
  • Estado de la incidencia (abierta, asignada, cerrada, etc.).
  • Un registro histórico de los cambios y actualizaciones que sufra hasta su cierre.
  • Cualquier otro dato que ayude al desarrollador a solucionar el defecto. Piensa que cuanto más claro y completo sea el informe, más probable será que el defecto sea resuelto con rapidez.


sábado, 18 de enero de 2014

Técnicas de prueba para Puntos de Decisión

Entre las muchas técnicas básicas de prueba podemos encontrar 5 relacionadas con los puntos de decisión.


Una decisión es un conjunto de condiciones relacionadas mediante operadores matemáticos.

Veamos un ejemplo:
S = (A and B) or (C and D)

  • S es la decisión
  • A, B, C y D son condiciones que pueden tomar 2 valores: 0 y 1
  • and y or son los operadores matemáticos

Las 5 técnicas básicas para probar la decisión S son:

Cobertura de decisión
El objetivo es encontrar el mínimo número de casos de prueba que permita que la decisión tome todos los posibles valores (0 y 1)

En este caso, con 2 casos de prueba (cada fila es un caso de prueba) se puede obtener El 100% de cobertura de condición:

A B C D S
0 0 0 0 0
0 0 0 1 1

Como se puede ver en la tabla anterior, esta cobertura es muy pobre porque apenas se prueba el funcionamiento de cada condición.

El número de casos de prueba necesarios para obtener el 100% de cobertura es n, siendo n el número de posibles salidas.

sábado, 11 de enero de 2014

Los oráculos de prueba y la evaluación heurística

Un oráculo de prueba podría definirse como toda fuente de información que puede utilizarse para determinar el resultado esperado de un caso de prueba.

Una vez que se conoce cuál es el resultado esperado, podemos comparar con él el resultado obtenido para así determinar si el caso de prueba está pasado o fallado.

Un oráculo de pruebas puede ser documentación formal como un catálogo de requisitos, especificaciones funcionales o casos de uso. También puede ser el actual sistema software que va a ser sustituido por el nuevo software a probar, un manual de usuario o el conocimiento de expertos o usuarios del sistema.

Evidentemente, el propio código fuente a probar no puede ser en ningún caso el oráculo de prueba.

En muchos proyectos la documentación es escasa, no contiene el detalle suficiente, está desactualizada, no está disponible en fases tempranas del proyecto o directamente, no existe. Todos estos problemas existen en la documentación relacionada con la funcionalidad del software pero aún más en la documentación de otros atributos de calidad como el rendimiento, la usabilidad o la seguridad.

En estos casos, como ya mencioné en un artículo anterior, el testing exploratorio es fundamental, en concreto, la evaluación heurística.

Los métodos de evaluación heurísticos son útiles pero no pueden aplicarse siempre. Hay que tener en cuenta el contexto del proyecto en el que se aplican y deben utilizarse como una ayuda para encaminar las pruebas no como una guía a seguir de forma estricta paso a paso.

Para realizar una evaluación heurística, al igual que para diseñar casos de prueba a partir de documentación y técnicas de prueba más formales, hay que tener siempre claro que el objetivo final es encontrar defectos y vulnerabilidades en el software a probar.

Para realizar una evaluación de este tipo puede ser útil construir una lista de verificación con puntos a analizar para encontrar problemas en el software. Quizás la lista más conocida es la creada por Michael Bolton y James Bach: FEW HICCUPPS.


Las siglas de este acrónimo significan lo siguiente:
  • Familiarity: Puede resultar muy útil buscar en un software problemas detectados anteriormente en programas similares.
  • Explainability: Si no podemos explicar a otra persona cómo funciona el software o no somos capaces de entender bien una funcionalidad podemos encontrarnos ante un problema de diseño del software.
  • World: El software debería ser consistente con aquello que ya conocemos o con lo que esperamos de él.
  • History: El software debe ser consistente con anteriores versiones de él mismo.
  • Image: El software debe estar en consonancia con la imagen de marca y con el mensaje que desea transmitir.
  • Comparable products: El software debe ser consistente con otros programas del mismo tipo, incluidos los de la competencia.
  • Claims: Los consejos, peticiones, quejas, ideas, etc. de los interesados de un proyecto deben ser tenidos en cuenta en el desarrollo del software.
  • User's expectations: El software debe ser consistente con lo que un usuario puede esperar de él.
  • Product: El software debe ser consistente con otras partes de software del mismo sistema.
  • Purpose: El sistema debe servir para dar respuesta a aquello para lo que se diseñó.
  • Statutes & Standars: El sistema debe cumplir con las leyes, estándares y regulaciones que puedan ser aplicables en cada caso (por ejemplo, la LOPD).

Si se detectan desviaciones al evaluar los puntos anteriores es muy posible que exista un defecto en el software pero no es algo seguro, sólo plausible, porque se ha utilizado una evaluación heurística.

Compartir