¿Tenemos que poner atención en los Test Cases?

Algo normal al empezar un proyecto, es que te digan queremos el Test Plan con sus casos de usos. Esto no sería ningún problema, si ya estuvieran bien definidos y cerrados los requerimientos. Al principio, me curraba los casos de uso, pero luego, te das cuenta que no es allí donde tienes que poner el foco, ya que la gran mayoría de Test definidos al principio del proyecto, quedan obsoletos cuando llegamos al final del proyecto.

Hoy en día con las metodologías ágiles, se piensa que no es necesario escribir test cases, pero con la experiencia te das cuenta de lo importante que es definirlos y sintetizarlos para obtener un producto de mejor calidad. Por eso creo que sí, que debemos hacerlos, pero cambiando la visión y no siendo tan tradicionales:

  • El número de casos de prueba no dice nada a nadie sobre “cuantas pruebas” estas haciendo. Normalmente menos, es más.
  • Cuando las reglas de negocio son muy complejas, en lugar de definir Test Cases con todos los pasos a probar, es recomendable trabajar con escenarios, sólo describiendo lo que debe hacer la aplicación.
  • Es importante definir Qué cubren, Qué errores se pueden detectar con estas pruebas, con que riesgos nos podemos encontrar.
  • Antes de escribir ninguna prueba, se han de analizar y entender bien los requerimientos. Muchas veces en esta fase, me he encontrado el no entender bien el requisito, levantar la mano y descubrir deficiencias en el análisis que podría provocar desvíos en el futuro del proyecto.
  • Los casos de prueba deben ser escritos con clara comprensión de los requisitos. Ya que estos test tendrán que pasar por muchas manos.
  • Una prueba no es un objeto físico. Una prueba es una actuación; una actividad; Al hablar de una prueba como un objeto en lugar de una actuación, se salta directamente sobre la parte más importante de la prueba: la atención, la motivación, la integridad y la habilidad del que lo prueba.