Casos de Prueba y Feature Files

Cuando se está en la fase de QA de diseño o se requiere documentar el como las pruebas serán ejecutadas, nos encontramos con diferentes opciones, los casos de prueba y los feature files (el termino en español sería archivos de características), ambos tienen un propósito común que es documentar las pruebas que los testers o QAs harán al momento de la ejecución de las mismas. He trabajado y usado las dos y a continuación describiré mis experiencias.

Los casos de prueba, como su nombre lo indica, son los casos que los testers o QAs van a probar durante el proyecto, son geniales para documentar que se va a probar y la funcionalidad a cubrir. Los casos de prueba generalmente tienen un identificador único, pre-condición para poder ejecutarlo, una serie de pasos a seguir y finalmente el resultado esperado, de la forma como yo he trabajado en el pasado, siempre agrego un resultado esperado por cada paso y no solo un resultado esperado al final de los pasos, me ha resultado mejor, pero por supuesto, eso está a la elección de cada persona, ambas formas funcionan. Los casos de prueba se hacen siguiendo un formato bastante formal y estructurado, desde mi experiencia los casos de prueba se comparten con el equipo de desarrollo (casi nunca los leen) y otros QAs para tener la referencia y documentación de que se va a probar, también se comparten con el cliente, pero no siempre pasa esto debido a lo robustos que pueden ser y porque no siempre son pedidos por ellos.

La mayoría de compañías que conozco en mi país (Colombia) y en el mundo trabajan con casos de prueba y la mayoría de metodologías (cascada principalmente) también lo usan, sin embargo, yo siempre he pensado que probar y ejecutar pruebas siempre será prioridad a documentar casos de prueba, hablando en una perspectiva ágil en donde todo se mueve tan rápido y son entregas cada dos semanas o un mes. Ahora bien, si un proyecto tuvo una mala planeación, siempre preferiré probar que documentar. Hay muchas herramientas para el manejo y administración de los casos de pruebas tales como TestLink, TestRail, Jira o incluso hojas de cálculo de Google Docs o Excel (por favor no usar Google Docs o Excel para casos de prueba)

Este es un ejemplo básico de un caso de prueba para probar un login válido:

Caso de prueba número: 001
Pre-condición: El usuario debe haber creado una cuenta anteriormente

Pasos                                                                                  Resultado esperado
1. El usuario va al sitio web                                                1. La página carga correctamente
2. El usuario hace clic en el botón login                           2. El sistema muestra la página de login
ubicado en la parte superior del menú                             3.  El sistema lleva al usuario a su perfil
3. El usuario ingresa un correo y contraseña                    
válidos y hace clic en el botón Ingresar                            

Ahora vamos con los feature files, estos archivos de texto simples y planos pueden abrirse con cualquier editor de texto y tienen dos objetivos, el primero es la documentación y saber que se va a probar y lo que el requerimiento hace y segundo, ser el punto de partida para la automatización de pruebas usando BDD y definición de pasos. Los feature files deben ser guardados con la extensión .feature por ejemplo login.feature y funcionan con una sintaxis bastante buena y coloquial llamada Gherkin (https://github.com/cucumber/cucumber/wiki/Gherkin) que es la sintaxis o lenguaje que entiende cucumber, hablaré de cucumber en otra ocasión. Gherkin ayuda bastante en términos de documentación y no solo apunta a ser compartido con el equipo de desarrollo sino con todas las personas del proyecto y porque no, también con el cliente, es muy sencillo de entender porque su sintaxis funciona con una combinación de palabras coloquiales tales como Dado/Y/Pero/Cuando/Entonces, en inglés descrito como Given/And/But/When/Then. Este es un ejemplo de un feature file para probar un login válido:

Feature: El usuario se debe poder loguear en el sistema para comprar
Para comprar un producto
Como un usuario normal
Me debo poder loguear en el sistema

Scenario: Loguearse en el sitio
  Given Voy a la página
  And Voy a la sección de login
  And Ingreso un correo y contraseña válidos
  When Hago clic en el botón Login
  Then La página me ingresa al sistema y me lleva mi perfil de usuario

Desde mi punto de vista, ambas formas de documentación funcionan, personalmente me gustan mas los feature files no solo por la automatización de pruebas con BDD, sino por el fácil entendimiento de los mismos usando lenguaje coloquial y no un lenguaje tan formal como el de los casos de prueba, con los feature files hasta las abuelas y las tías podrían entender los requerimientos del proyecto, y la forma de escribirlos provee mucho conocimiento sobre que probar, y por supuesto, no se requieren herramientas para verlos, solo editores de textos normales.

Ambos son trazables y se puede medir cuantos pasaron o fallaron, etc, se pueden hacer reportes con ellos y se pueden ingresar a cualquier herramienta para guardarlos, la diferencia es la forma de leerlos e implementarlos y la manera como son entendidos por todas las personas del proyecto

La decisión es suya!

Déjenme sus comentarios y no olviden seguirme en Twitter @LuchoAgileQA