Tester vs Quality Assurance.

Normalmente hablamos de Tester y Quality Assurance (QA) como si fueran el mismo perfil profesional. Sin embargo,son dos roles muy distintos que suelen confundirse muy a menudo.

Asemejar ambos perfiles es como decir que un desarrollador y un analista son exactamente lo mismo. O que un pintor y un carpintero realizan las mismas funciones porque trabajan en la misma obra.

El objetivo de este post es mostrar las diferencias entre ambos perfiles y analizar cuál es el futuro cercano para cada uno ellos.

Cada cosa por su nombre

Hace un tiempo, en una ponencia escuché una frase que me llamó la atención. Muy posiblemente haberla escuchado es la razón por la que escribo este post, ya que me hizo reflexionar bastante sobre el asunto:

"Un Tester se encarga de encontrar fallos, pero un QA no solo los encuentra, sino que ayuda a prevenirlos”.

Esta frase me hizo ver que yo mismo me equivocaba cuando hablaba de Tester y Quality Assurance como si fueran el mismo rol. Sin meternos en profundidad en la tareas que realiza cada uno de ellos, esta puede ser la mejor definición que he encontrado a día de hoy para poder diferenciarlos.

Después de analizar varias definiciones que he encontrado en Internet, creo que estas son las que mejor describen qué sería cada perfil:

• Tester: persona encargada de probar un software durante su fase de desarrollo con el fin de detectar fallos e informar sobre ellos.
• Quality Assurance: persona que realiza un conjunto de actividades con el objetivo asegurar la calidad de un software durante todas sus fases.

La evolución de Tester a QA

En muchos casos, un QA realiza las tareas de un Tester, pero no podemos decir que un Tester realice las tareas de un QA.

Yo diría que un Quality Assurance es un tester que ha ido evolucionando gracias a la experiencia y a los conocimientos que ha ido adquiriendo. Estos nuevos conocimientos le permiten añadir nuevas y diferentes tareas a su día a día.

Las tareas son muy variopintas, pero tienen algo en común: todas ellas suman calidad al proyecto y con ello calidad al producto, que al fin al cabo es el objetivo principal de todos y especialmente del QA. Cabe recordar la importancia de la calidad para evitar desastres, como los comentados en este otro post.

Las tareas que realiza un QA son cada vez más y darían para escribir como mínimo otro post, pero vamos a centrarnos en las más comunes:

Análisis

Colabora en la definición del producto guiando a stakeholders y product owner. Incluso ayuda directamente en la definición de los criterios de aceptación del producto. Este papel es importantísimo por dos motivos:

1. El QA suele ser el que tiene una visión más horizontal del producto y por ello suele ser el que más puede aportar a la hora de definir ciertos requisitos.
2. Unos requisitos bien definidos evitan malos entendidos por parte del desarrollador y con ello ayuda a prevenir defectos.

Integración continua

Desde la definición de las fases de la integración continua, hasta configuración de herramientas implicadas en el flujo IC/CD, pasando por la creación de jobs. Se puede decir que el QA es un factor importante es esta área del proyecto.

Una buena integración continua, acompañada de buenos tests automáticos, aporta mucho a la calidad de un proyecto. No solo aumenta la velocidad con que tenemos código nuevo en producción, sino que ayuda a detectar y evitar defectos.

Scrum Master

Muchas veces cuando el scrum master necesita ayuda, es el QA el que le ayuda con tareas como: revisión de prioridades, definición de historias de usuario, asignación de tareas, documentación del proyecto…

Sistemas

Cada vez se dan más casos en los que el QA hace tareas que antes eran vistas como tareas de sistemas. Estas tareas son necesarias para que el QA pueda realizar de forma correcta y lo más cómoda y rápida posible su trabajo. Estas tareas pueden ser: creación y configuración de entornos de despliegue, instalación y configuración de herramientas y servicios en la nube…

Estas son algunas de las tareas más cruciales que suele realizar un QA dentro de un proyecto. Yo he escuchado bastantes opiniones de cuáles deberían ser las tareas que debería realizar un QA y no le puedo quitar su parte de razón a la mayoría de ellas. Lo que también tengo claro es que no deja de ser una profesión relativamente nueva y en continua evolución.

Dicho todo esto, tenemos que pensar que todos somos un equipo y tenemos un objetivo común y por ello debemos ayudarnos y apoyarnos sin pensar de quién es cada tarea.

Conclusión

A día de hoy, ambos perfiles son complementarios en un proyecto. Ninguno de ellos es mejor que otro. Simplemente son roles diferentes y hay personas que se adaptan más a uno que a otro.

Sin ir más lejos, a mí me hubiera gustado jugar en el Betis. Aunque llevo bastantes años trabajando de QA, ya que me adapto mejor a este puesto que al de futbolista.

En un futuro muy cercano, lo normal sería que el número de puestos de tester vayan decayendo, aunque creo que siempre serán necesarios, ya que hay una parte de pruebas funcionales que es muy complicada que desaparezca. Cada vez más, la gente que trabaja en el mundo de la calidad de software debe tener un perfil más técnico y tener conocimientos de cada una de las herramientas, lenguajes y frameworks… que se utilizan en su proyecto.

"La mejor forma de predecir el futuro es implementarlo” - David Heinemeier Hansson