El rol de tester está evolucionando junto con la industria de la tecnología y su adhesión a las metodologías agil. Esta transición abre oportunidades inexploradas, emocionantes y desafiantes para todo tester.
Las viejas formas: Sólo encontrar defectos
En mis primeros años como tester poco me preocupaba por el pensamiento crítico. Cada mañana el equipo de testing nos daba una lista de aplicaciones a revisar, el recurso asignado instalaba las aplicaciones e intentaba romper su funcionalidad.
Nuestros análisis de desempeño eran simples: ¡Entre más bugs encontráramos, más inteligentes eramos! Sin análisis, sin estrategia, sin motivación. En nuestros descansos las discusiones giraban en torno al número de bugs encontrados, en lugar de discutir la calidad de estos bugs.
Eso me puso a pensar, ¿Qué valor estamos agregando? ¿Deberíamos probar sólo para encontrar defectos? Tenía muchas preguntas sin respuesta.
Desarrollando un proceso de QA
Mi siguiente empleo lo cambió todo. Como parte de las pruebas de una funcionalidad, el equipo de QA también debuggeaba, analizaba el track trace, y proveía la causa raíz del error cuando reportaba a los desarrolladores. Fue vigorizante ver a cada uno de los miembros colaborar como un equipo con un sólo propósito.
Me di cuenta que las tareas de un tester no eran actividades individuales para romper la aplicación, pero más las de un miembro de un equipo contribuyendo al esfuerzo común. A medida que los testers iban cambiando de equipos, empezamos a priorizar la mejora continua de la automatización y el conocimiento profundo de cada componente. Desarrollé una perspectiva totalmente diferente sobre QA, además de un gran respeto por todo el valor que proporcionaba este rol.
Cuando cambié de posición, me emparejaron con un arquitecto de QA. Nunca imaginé que esa mentoría tendría un impacto tan grande y duradero en mi. Me di cuenta de la importancia dar un seguimiento estructurado a QA; con la ayuda de este arquitecto, afiné y perfeccioné cuatro estrategias para mejorar el proceso de QA.
- Revisa los documentos de diseño y arquitectura
Siempre será una buena idea tener tanto conocimiento como se pueda sobre el producto que está siendo probado, si los documentos de arquitectura y diseño están disponibles para revisarse, dales una leída. Te sorprenderás de cuanto puedes entender del producto sabiendo su arquitectura, los componentes integrados, y del flujo de información que del solo hecho de probar. Toma notas y traza diagramas de como funcionan tus pruebas en paralelo y de cómo interactúa el sistema.
- Investiga defectos pasados
El pasado informa al presente. Es importante conocer las áreas riesgosas y las funcionalidades más susceptibles a fallar en cada modificación. Ese tipo de información puede provenir de la historia de los defectos.
Lleva a cabo una investigación en tu gestor de defectos y analiza los defectos que han sido reportados anteriormente. Cualquier patrón predecible que provenga de este análisis ayudará a automatizar esas áreas, también incluye los defectos que son reportados por los usuarios o clientes. Este ejercicio te ayudará a tomar decisiones sobre la estrategia a seguir en la mayoría de los releases.
- Triangula los defectos
QA encuentra un defecto y se reporta, pero el trabajo no termina ahí, hay que ir más allá y hacer algunas otras preguntas importantes. ¿Hay algo más que pudiste haber hecho?, ¿Sabes porqué ocurrió ese defecto?, ¿Qué lo causó?, y ¿Qué cambio en el código pudo haber causado el problema?
Ésto no es trabajo exclusivo de los desarrolladores. Tienes acceso al log, a los releases y al código, así que se puede excavar por información que ayude a resolver esos problemas. Dependiendo en que tan técnico seas, puedes profundizar tanto como puedas. Pero si estás en un alto nivel, mira en las excepciones en el log. ¿Hay un null pointer?, ¿Tiene que ver especificamente con tus datos o con alguna secuencia de pasos?
Delimita el problema y empieza una conversación con el equipo de desarrollo, sabrán apreciar la información detallada y la investigación.
- Ve más allá del defecto reportado
No te enfoques sólo en las pruebas de funcionalidad. Piensa también en como el back-end y el front-end interactúan con tu aplicación.
Por ejemplo, mientras revisas el log de pruebas, podrás darte cuenta que tal vez la aplicación esté funcionando correctamente, algunos errores están ocurriendo en el back-end. Aquí podrás preguntarte, ¿Son los logs lo suficientemente detallados?, ¿Se están manejando correctamente las excepciones?. Cuando pruebas aplicaciones web, abre las herramientas de desarrollador en el navegador y monitorea los componentes de red, ¿las respuestas están tomando más tiempo del debido? ¿Hay algún request que no está siendo llamado cuando se accede a la aplicación?
Todas esas preguntas permitirán al tester a ir más allá de lo que tiene asignado. También motivará discusiones con el dueño del producto y los desarrolladores al encontrar escenarios que no habían sido pensados.
Es vital tener una mentalidad ágil al momento de buscar y reparar discrepancias en el producto. Una enseñanza clave en testing es ser proactivo. Los bugs que descubres de esta manera pueden volverse historias técnicas, que de no haberse prevenido hubieran pasado desapercibidas y volverse en un error muy serio mucho más adelante.
Vuélvete el propietario de la calidad
Ser un tester de software ya no se trata sólo de encontrar defectos y de romper la aplicación; ahora se trata de la mejora continua, de definir una estrategia de pruebas, y de ir un paso más allá para mejorar la calidad. Seguir un proceso estructurado y consistente de QA te ayudará a adquirir más conocimiento del producto que estás probando, a hacer las preguntas que de otra forma no te hubieras hecho, y al final, volverte en el propietario verdadero de calidad.
Software Quality and Testing 