Qué es el Testing y por qué es necesario
Hacer testing es llevar a cabo una investigación sobre un producto de software para garantizar su calidad y detectar posibles fallos. Es la manera de contrastar si el resultado cumple con los requisitos técnicos que se especificaron para llevarlo a cabo.
A esos requisitos se les llama de muchas maneras, te pongo una tablita para no volvernos locos:
requisitos técnicos = especificaciones técnicas = technical requirements = software requirements = business requirements
En la industria del software podemos distinguir tres grandes roles:
El programador (software developer): la persona que escribe el código.
El business analyst: a veces se le llama por otros nombres como project manager o product owner, por motivos que no vienen al caso, pero básicamente es la persona que escribe y organiza los requisitos técnicos que debe tener un software.
El tester: también llamado QA o Testing engineer, es la persona que revisa el resultado de los programadores, informa de posibles fallos e intenta anticiparse a posibles problemas en el software.
Aunque el tester tenga ese papel de guardián de la calidad del producto, todo el equipo es en cierta medida responsable de la calidad. Esto es algo que aprendió la industria IT a base de cabezazos, porque el testing, a lo largo de la historia, ha sido bastante infravalorado. Por suerte, esto empezó a cambiar hace años.
Hoy por hoy, el testing es una pieza fundamental en el desarrollo de software, ya que las empresas han entendido la importancia y el coste de detectar errores a tiempo (cuanto antes, mejor), porque no es lo mismo que se detecte un bug cuando el producto está en pre-producción a detectarlo cuando ya está en el mercado. Y para muestra, un botón:
Qué es el Software Development Life Cycle (SDLC)
El SDLC es una forma de llamar a las diferentes etapas por las que pasa un software desde su concepción hasta su entrega al cliente final. Esas etapas se detallan en un plan de acción bien definido, donde cada miembro del equipo tiene su papel.
Estas son las típicas etapas del ciclo de vida de un software:
maintenance
DEPLOYMENT
PLANNING
SDLC
TESTING
DESIGN
IMPLEMENTATION
Fase de planning
En esta fase se decide qué vamos a construir. Es fundamentalmente responsabilidad del product owner.
Fase de design
Aquí es cuando se recaban business requirements, se ponen en orden y se diseña la arquitectura del software y la UI. Aquí se implica todo el equipo.
Fase de implementation
Aquí es cuando los developers construyen la app o el software mediante código.
Fase de testing
En esta fase se comprueba si lo que han construído los developers se ajusta a lo definido previamente en los business requirements, porque no olvidemos que el código lo construyen personas, y por tanto, siempre habrá errores, porque somos humanos, no máquinas. Por eso los testers son imprescindibles.
Para comprobar que todo se ajusta a lo definido, los testers crean y ejecutan pruebas (en inglés, test cases).
Fase de deployment
Aquí es cuando llevamos nuestro código a producción, es decir, lo hacemos público para el cliente final, que podrá ver así el resultado en forma de, por ejemplo, una página web o una app.
Fase de maintenance
Es posible, por no decir seguro, que nuestro software necesite un cierto mantenimiento a lo largo de tiempo para que siga manteniéndose operativo y actualizado. De eso va esta fase, que, una vez que el software está en producción, nunca acaba.
Veamos un ejemplo de todo esto en el mundo físico que nos sirva como equivalente en el mundo IT: una receta de cocina.
maintenance
Asegurarte de que les ha gustado y mejorar lo necesario para la próxima vez
DEPLOYMENT
Servirla a tus invitados
PLANNING
¿Qué vamos a cocinar? Una pizza
PIZZA
DEVELOPMENT
LIFE CYCLE
TESTING
Comprobar que no se haya quemado y que los ingredientes estén bien cocinados
DESIGN
¿Qué ingredientes necesitamos? Agua, harina, aceite, mozzarella y albahaca.
¿Cuánto tiempo de preparación necesitamos? varios días
IMPLEMENTATION
1. hacer masa y dejar reposar
2. extender masa y añadir los ingredientes
3. meter al horno a 250º
La definición del SDLC tiene más años que Matusalén, y en los años 90 se creó una manera nueva de llevarlo acabo. Antes, cada etapa del SDLC podía durar semanas, meses e incluso años, y no se pasaba a la siguiente fase hasta que la anterior se había cerrado por completo.
Esto conducía a desvíos gigantes entre las expectativas y el producto final. Por eso, en los 90 se creó una metodología ágil (en inglés, agile methodologies), que respetaba completamente el SDLC, pero lo ejecutaba en periodos muy cortos de tiempo (entre 1 y 4 semanas). Pero esto es material para otro post 
.
Actividades de testing
Ya sabemos lo que hace un tester, ahora vamos a ver a grandes rasgos cómo lleva a cabo su trabajo.
Un tester está involucrado en (casi) todas las fases del SDLC y se encarga tanto de planear y definir tests hasta ejecutarlos y sacar conclusiones de estos. Sí, has leído bien, un tester, sobre todo en empresas que trabajan con agile, participa en la mayoría de las fases del SDLC, porque es vital que a la hora de crear los business requirements, tanto los testers como los programadores sepan exactamente lo que van a construir y probar.
1
Test planning
Un documento donde el tester define qué va a probar y cómo va a hacerlo. Ahí se identifica el scope (= ámbito) de la prueba, qué funcionalidades (en inglés, features) se van a probar, en qué environments, etc.
2
Test specification
Aquí el tester crea test cases basados en la fase anterior de planificación.
No debemos confundir los test cases con los bug reports. Un test case es un escenario determinado que el tester se imagina que puede llevar a cabo el usuario del software. Por ejemplo, si tenemos un página para iniciar sesión, el tester debe analizar (con los business requirements a mano) qué se supone que el usuario puede y no puede hacer.
Como tester se me ocurren varios escenarios que podrían ocurrir y que por tanto deberíamos probar:
- intentar iniciar sesión con usuario y contraseña correctos
- intentar iniciar sesión con usuario y contraseña incorrectos
- intentar iniciar sesión con algún campo vacío
Un test case tiene una estructura determinada para facilitar su lectura: título, descripción, pre-condiciones, pasos, estado y resultado esperado.
3
Test execution
Aquí el tester ejecuta los test cases basados en la fase anterior, cuyo objetivo principal es comprobar si los resultados coinciden con lo esperado. Por ejemplo, si creo un test para comprobar que un botón cambia de color cuando hacemos clic sobre él, y lo que sucede al hacer clic es que no cambia de color, el resultado esperado no coincidiría con el resultado real.
Cuando se da este caso, el tester toma nota y crea un documento para informar del error (en inglés, un bug report), y lo deriva a quien deba encargarse de resolverlo.
En esta fase es muy importante trabajar con prioridades, ejecutando los tests más importantes primero.
4
Test completion
Aquí todos los tests que el tester había planeado ejecutar ya se han ejecutado y se han sacado las conclusiones pertinentes. Si los tests más cruciales han sido satisfactorios, el tester da el visto bueno para pasar el software a producción.
Qué es un bug y cómo informar sobre uno
Un bug (por lo que más quieras, ¡no lo pronuncies con "u"! Una simple "a" basta) es un fallo en el software, cualquier tipo de error que suponga que nuestro software no funcione como esperado.
Los bugs en el código son la cosa más común del mundo, y mientras los humanos seamos los que escribimos código en lugar de las máquinas, los bugs están garantizados ?.
Todo el equipo es responsable de generar un código lo más libre de bugs posible, y el trabajo del tester es localizar los bugs lo más antes posible en el proceso del desarrollo del software.
Existen varios tipos de bugs, pero esta es una de las clasificaciones más comunes:
Visuales (visual bugs): imágenes cortadas, textos mal alineados, colores que no coinciden con el diseño, etc.
Funcionales (functional bugs): relacionados con el funcionamiento del software. Por ejemplo, si al hacer clic en un botón, no pasa nada o me redirige a la página incorrecta.
De rendimiento (performance bugs): relacionados con la velocidad de carga y otros aspectos del rendimiento del software.
Sea cual sea el tipo de bug, la labor del tester es localizarlo, redactar un bug report (un informe) dando detalles del bug y ponerlo en conocimiento del equipo para que se puedan encargar de resolverlo. Una de las herramientas más populares para redactar bug reports es JIRA. Yo la uso y me parece una maravilla.
Un bug report tiene esta estructura típica:
TÍTULO DEL BUG
resumen/descripción del bug
responsable (asignee)
informante (reporter)
estado
PRIORIDAD
archivos adjuntos (screenshots, vídeos)
Lo que debe caracterizar un bug report es su simplicidad. Nada de enrollarnos como las persianas. Debemos ser concisos y ponernos en el lugar de la persona que va a leer el report y encargarse de resolver el fallo. Lo último que quiere esa persona es ponerse a leer rollazos.
Para mí, esta es una de las soft skills más importantes de un tester: la capacidad de síntesis.
Un truquito para escribir títulos concisos y relevantes es pensar en el actual result primero. De ahí puedes sacar un buen título.
El ciclo de vida de un bug (bug life cycle)
Hablemos de la vida de un bug. Un bug nace cuando se descubre y muere cuando el programador lo arregla. Por el camino pasa por distintas fases, que cambian un poco según la empresa, pero en general serían:
nuevo bug
Creamos un informe como el de arriba y el bug es asignado a un programador. El estado pasa de "to do" a "active".
TO DO --> ACTIVE
si el programador considera que el bug no tiene razón de ser, cambia su estado a "closed" y aquí acabaría el ciclo de vida de este bug 
bug en proceso de resolución
El programador resuelve el bug y lo pasa al siguiente estado, "ready for testing".
ACTIVE --> READY FOR TESTING
testing in progress
El bug pasa al tester, quien se encarga de verificar si aún existe (si lo puede reproducir), o si efectivamente el programador lo ha arreglado. Si aún existe, el bug da un paso atrás en su estado y vuelve al paso 2, y si está arreglado, lo movemos a su último estado: closed.
READY FOR TESTING --> TESTING IN PROGRESS
bug cerrado
Fin de la vida del bug. Normalmente es el tester quien pasa el bug a este estado, pero a veces también el product owner puede querer comprobar que todo esté resuelto.
TESTING IN PROGRESS --> CLOSED
Tipos de tests
Existen muchas maneras de clasificar las pruebas que pueden hacerse. Las clasificaciones más comunes son:
Black-box testing | White box testing |
|---|---|
Functional testing | Non-functional testing |
|---|---|
Esto es como dividir personas en "bajas versus altas" o "rubias versus morenas". Habrá personas que entren dentro de la categoría de "bajas" pero también dentro de "rubias". Pues con los tipos de tests pasa igual, un test puede ser black-box y funcional.
Cómo desarrollar una mentalidad de tester
Ya he hablado un poco de ellas más arriba, pero las soft skills de un tester son tan importantes como las habilidades técnicas (en inglés, hard skills), y difieren un poco de las soft skills de un programador. Las que yo destacaría serían:
THE END!
¡Y con esto terminamos esta introducción al software testing! Espero que hayas aprendido algo nuevo 
. Si te queda alguna duda, ¡nos vemos en los comentarios!
Sobre la autora de este post
Soy Rocío, una abogada reconvertida en programadora. Soy una apasionada de aprender cosas nuevas y ferviente defensora de que la única manera de ser feliz es alcanzando un equilibrio entre lo que te encanta hacer y lo que te saque de pobre. Mi historia completa, aquí.
Otros artículos que pueden interesarte