Buscando el problema (II)

Cómo enfocar la búsqueda del problema:

• Probar primero las cosas que han cambiado
• Probar primero las funcionalidades "core" antes que las agregadas
• Capacidad antes que fiabilidad
• Probar situaciones habituales antes que las condiciones esotéricas
• Probar los problemas con alto impacto antes que los que tienen pocas repercusiones
• Probar las áreas con más interés antes que las menos utilizadas

Y finalmente, lo que ayuda bastante a enfocar el testing eficiente es conocer bien el producto y a los usuarios que lo utilizarán.

Buscando el problema

Es importante ir a buscar el problema y no a encontrarse el problema... hay una gran diferencia.
Ir a buscar el problema es enfocar el testing conociendo el producto, su implementación y la relación con el resto de entidades para que con el subconjunto mínimo de pruebas tengamos cierto nivel de confianza sobre la construcción del producto. Encontrarse el problema es cuestión de suerte.
He conocido a testers con suerte, y creo que es un factor nada despreciable, al contrario, pero que tiene el problema que no sabes cuando te abandonará :)

La intuición es otro amigo invisible que nos acompaña a veces y que bien utilizado puede darnos ciertas ventajas. Si nos apoyamos en la intuición más una estrategia de buscar el problema tendremos la balanza equilibrada entre corazón y cabeza...

Documentación de testing (II): Testing steps

En las metodologías tradicionales, el "deliverable" más importante de pruebas es la documentación, tanto los reportes de ejecución como el detalle de los casos de prueba.
El tener una referencia de cómo se ha probado algo exactamente, con cada uno de los pasos ejecutados es en algunos proyectos un coste no asumible, sobretodo en los proyectos que se desarrollan con metodologías ágiles, en los que cada release puede tener contenido diferente o realizar modificaciones continuas sobre las mismas funcionalidades.

Así los planes de prueba de este tipo de proyectos, los basaremos en los criterios de aceptación y contendrán información del tipo

• Precondiciones / Provisión de datos
• Path de navegación
• Usuarios de test / Datos de entrada
• Resultados esperados

Documentación de testing

Las metodologías ágiles reducen la documentación también en el área de pruebas, pero por pequeño que sea el proyecto, no podemos prescindir de documentar la estrategia. Las pruebas deben seguir una estrategia y ésta deben de estar documentada. 

• La mayoría de las veces que se escapa un defecto grave, no es por falta de tiempo, sino porque la estrategia no era la adecuada. Aún teniendo el doble de tiempo no hubiéramos capturado el defecto, ya que estábamos mirando para otro lado. El análisis de la causa del defecto debe llevarnos a re-hacer o remendar nuestra estrategia de pruebas del proyecto, para no repetir los mismos errores y lo que es más importante, aprender y formar a nuestro equipo.
• Si por el contrario, el defecto que se escapa es un corner case, pero nuestra estrategia es la adecuada, no deberemos modificarla (ni torturarnos por ello), simplemente evaluar si no hubo tiempo suficiente para realizar todas las pruebas o si hay un conjunto de escenarios no contemplados (por desconocimiento o por coste) y si tenemos que ampliar nuestro juego de datos de pruebas.

En resumen, no prescindamos de la documentación de la estrategia de testing y mantengamosla en la medida de lo posible como un documento vivo... tan vivo como lo esté el proyecto

Requisitos: No sólo de documentación vive el tester

Los requisitos vienen de tres fuentes principalmente:

• Conversaciones: Preguntas a los PM o desarrolladores desembocan en nuevos requisitos
• Inferencia: Según la experiencia del tester hay requisitos que son más importantes que otros.
• Referencia: especificaciones explícitas e implícitas.

Requisitos implícitos 

Se denominan requisitos implícitos, aquellos que sin estar documentados son evidentes para la organización:

• Basados en estándares de la industria
• Basados en cómo se comporta la competencia u otros productos similares
• Basados en el comportamiento de la versión anterior del producto
• Basados en las guías de estilo de la organización
• Y finalmente basados en la experiencia del tester, que normalmente es quien mejor conoce el producto y que además tiene feedback de las reacciones de los usuarios.