Tester vs Quality Assurance

Normalmente hablamos de Tester y Quality Assurance (QA) como si fueran el mismo perfil profesional. Sin embargo, bajo mi punto de vista, son dos roles muy distintos.

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 par de años, 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 ayudó a entender que me equivocaba cuando hablaba de Tester y Quality Assurance como si fueran el mismo puesto. 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, puedo decir que estas pueden ser unas rápidas descripciones de 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 debido a que se le han ido añadiendo tareas.

La 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.

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. Ayudando al product owner o directamente definiendo el mismo los criterios de aceptación. 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 los pasos de la integración continua, hasta configuración de herramientas, 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, instalación y configuración de herramientas…

Estas son algunas de las tareas más importantes 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. 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 la herramientas, lenguajes y frameworks… que se utilizan en su proyecto.

“La mejor forma de predecir el futuro es implementarlo” – David Heinemeier Hansson

Quality Assurance con más de 7 años de experiencia. Enamorado de las nuevas tecnologías y de todo lo relacionado con la calidad de software. Apasionado del deporte, con el “Manque Pierda” como filosofía de vida.

Ver toda la actividad de Rafael Márquez

Comentarios

  1. luisa fernanda sanchez dice:

    concreta y perfecta la definición
    me siento satisfecha

Escribe un comentario