Es ideal que los QAs y los testers estén involucrados en la captura de requerimientos y su posterior conversión en especificaciones. El agilismo así lo defiende y yo lo comparto, puesto que permite reconocer y alertar sobre áreas de riesgo, detectar potenciales problemas futuros, conocer de antemano los detalles de la funcionalidad que va a venir, adelantar el diseño de las pruebas… Es ideal, pero no siempre es posible.
En esos casos, la documentación disponible es de cosas ya hechas; es decir, funcionalidad ya implementada. En esa documentación pueden faltar detalles de implementación o meta-conocimiento del que disfrutaríamos si hubiéramos estado involucrados desde en un principio.
Hay varias maneras de recuperar ese terreno perdido, la idea de «Show & Tell» de Darren McMillan me parece fantástica (por la que el desarrollador hace una «demo» de la funcionalidad al tester, antes de submitar el código al repositório). Otra manera es mediante el própio testing exploratorio, mediante la própia exploración de la funcionalidad, apretando las tuercas a cada frase, cada palabra, cada coma, de la especificación de lo testeado.
En cualquier caso, los objetivos son los mismos:
- Disponer del conocimiento máximo de las aplicaciones a testear
- En caso de que el objetivo anterior no se cumpla, hacer todo lo que esté en nuestra mano para conseguirlo 🙂
Este objetivo no es un fin en sí mismo, es un medio para hacer mejor nuestro trabajo. Por ejemplo, un caso real con el que me he encontrado esta misma semana: nueva funcionalidad para una aplicación, me puedo incorporar a testearla sin haber podido participar en su concepción, luego valido y re-valido todo lo que dice en la especificación que viene con la funcionalidad, y me encuentro con…
El campo XXX puede albergar un máximo de 256 caracteres.
«Eso habrá que verlo», me digo. Y no era así, admitía 255, uno menos de lo esperado y especificado. En este punto, me podría haber parado, reportar el defecto y a otra cosa, pero en ello no ganaba conocimiento, luego me pregunté…
Y de dónde viene esta limitación?
Un dato así, a grandes rasgos, puede venir de…
- Exigencia expresa transmitida por el equipo de negocio
- Limitación técnica
- «Había que poner un máximo y no sabíamos cual»
Es fácil salir de dudas, preguntando al desarrollador responsable de la funcionalidad. En este caso, se trataba de (2): el límite viene del ancho de la columna de la base de datos que almacena el valor en el campo. Pero había un detalle, el campo es de tipo tinytext, cuyo ancho máximo es 255 caracteres y no 256, luego esto no es un defecto, es una errata en la documentación y ya está, puesto que no había problema por parte de negocio en que el campo tuviera una capacidad de 255 caracteres.
Learnings del caso concreto:
- Saber de donde viene el máximo establecido en el campo concreto
- Un defecto menos en el bugtracker, una errata corregida en la documentación
- Aprender que el tipo de dato tinytext en SQL admite hasta 255 caracteres, útil para futuras pruebas de esta y otras funcionalidades.
Admito que no es un aprendizaje enorme ni me va a arrojar luz sobre las grandes dudas del testing o de la humanidad, pero si de cada pequeño cambio en una funcionalidad sacamos un conocimiento así, al cabo de un tiempo estaremos bastante más cerca del conocimiento máximo de las aplicaciones que testeamos.
Testing funcional 