Conviértete en QA: rompe cosas y que te paguen por ello
¿Te gusta romper cosas y encontrar errores de software? ¿Siempre que estás en una aplicación piensas "qué pasa si hago esto" y esperas que algo falle? Entonces el rol de Quality Assurance (QA) te gustará.
Actualmente tengo cerca de 9 meses trabajando como QA y 1 año estudiando sobre el rol y sus funciones. Entonces ya tengo por lo menos una noción básica de cómo podrías llegar a serlo tú también o si solo quieres conocer cómo es nuestro trabajo.
Aclaremos qué es ser QA. La mayoría pensamos que este rol solo se encarga de encontrar bugs, sí lo hacemos, es parte de nuestras tareas, pero no es lo único. Como su nombre lo dice nos aseguramos de la calidad... ¿qué carajos es calidad?
De acuerdo con el ISTQB (International Software Testing Qualifications Board) la calidad se define como: "El grado en que un componente o sistema satisface las necesidades declaradas e implícitas de sus diversas partes interesadas.", en mis palabras "que haga lo que debe de hacer".
Lo que yo he aprendido
En estos casos siempre existe una gran cantidad de opiniones sobre el roadmap "correcto", por eso yo te contaré mi proceso y lo que fui aprendiendo para mi trabajo.
Empecemos con los fundamentos. Hay conceptos básicos que debes conocer como qué es White Box Testing, Black Box Testing y Gray Box Testing. También sobre los tipos de testing como Funcional (Unit Testing, Smoke Testing, Regression Testing, etc.) y No funcional (Load Testing, Security Testing, etc.) y los 7 principios de QA.
Con eso ya tienes una base sólida pa' el arranque. Ahora aprende lo que será tu día a día. Investiga qué es y cómo crear un Plan de pruebas, cómo reportar bugs, además de saber diferenciar los tipos de bugs. Esto último es importante ya que a los y las desarrolladoras deberás indicarles lo más claro posible cómo es que un bug sucede y en qué condiciones para que puedan reproducirlo y echarle Raid, o sea, solucionarlo.
Wait, wait, wait... ¿como que un Plan de pruebas? ¿Ese de dónde sale o qué? Te lo dije, encontrar bugs y romper cosas no es nuestro único trabajo, solo es la parte más divertida. El proceso de QA no empieza luego de la programación. Comienza desde la planeación de esa feature o software. O sea, tienes que estar en comunicación constante con tu PM/PO para definir qué es la calidad de ese producto y que esperan los stakeholders.
Ten claro el objetivo por el que se está haciendo, revisa wireframes y mockups para comenzar a evaluar que todas las opciones de lo que hará esta nueva feature y que todas estas tengan un camino claro de lo que pasará haciendo X, Y o Z acción. Si tienes dudas o no hay algo definido de lo que debe pasar revísalo con tu PM/PO. De esta forma cuando llegue a desarrollo todo será mucho más claro para quien lo programe.
Con todos estos flujos claros podrás crear tu ✨ Plan de pruebas ✨ para cuando llegue el momento del testing tengas claro qué se desarrolló y cómo deberás probarlo, considerando casos de uso extraños, conocidos como edge cases y si algo falla determinar con tu PM/PO y devs si debe corregirse pronto o si solo se incluirá al backlog para la siguiente iteración.
Esto que acabo de explicarte es la forma más resumida en la que pude decirte parte de lo que aprendí leyendo el libro Agile Testing Condensed: A Brief Introduction de Janet Gregory y Lisa Crispin.
Una vez que hayas creado tu plan de pruebas, hecho testing y que se lance a producción, ¿ya se terminó tu trabajo? Pues nope, tendrás que asegurarte que efectivamente está funcionando bien producción. Estamos trabajando con software, el software está roto y es mejor que hagamos double check.
¿Ahora sí ya es todo?
Nope x2. Para algunas personas esto podría ser suficiente y también en algunas empresas, pero si quieres ir a un nivel aún más allá de las pruebas manuales deberás adentrarte en el mundo de ✨ Automation ✨. La automatización se puede hacer de muchas formas, en algunas empresas puede que lo hagas usando una herramienta y a punta de clics puedes automatizar, pero en otras deberás escribir código.
La automatización popularmente se usa con Selenium, aunque existen otras herramientas como Playwright, Appium para aplicaciones móviles, Cypress y otro montón más según el tipo de testing. Las que mencioné son comunes para simular las acciones de un usuario y pruebas E2E, pero existen pruebas de carga o estrés que podrían ser con JMeter o Locust.
El lenguaje de programación que necesites variará según la empresa. Si no conoces ninguno te recomiendo empezar con Python, es un lenguaje fácil de aprender. Solo ten en cuenta que en ocasiones podrá ser con Java, C#, Ruby o JavaScript. Aprende lo fundamental de lógica de programación y de estas herramientas para que el lenguaje que conozcas no sea una limitante.
Como última recomendación, aprende a comunicarte de la mejor forma con tu equipo, tu trabajo no debe ser bloqueante y tampoco debe generar estrés a los y las programadoras. A veces tendrás que ser flexible con los detalles que encuentres, el software perfecto no existe. Si este detalle no afecta la experiencia de usuario, y tampoco al negocio, piensa que podría solucionarse pronto con algún hotfix dentro de las siguientes horas o días. Tu deber es reportarlo, pero en equipo se decide qué se hará con ese reporte.
Rompe el software no a tu equipo. 💚