Las pruebas de regresión son responsabilidad de todos.

Las pruebas de regresión deben compartirse, ya sea dentro del equipo de desarrollo y el equipo de QA. Pero en muchas empresas, estas pruebas aún se consideran como un problema principalmente del equipo de QA.

Históricamente, los Testers han pasado días, y a veces semanas, ejecutando pruebas de regresión, generalmente al final de un sprint o al prepararse para una nueva versión. Durante estas pruebas, los equipos de desarrollo a menudo apoyan los esfuerzos de QA al estar disponibles para ayudar a corregir errores.

Sin embargo, aunque los desarrolladores están disponibles, por lo general están desconectados del proceso detallado de recopilación de información de pruebas de regresión, posiblemente la parte más importante, hasta que surgen errores.

Debido a que los desarrolladores se centran en otras tareas en este momento, no son conscientes de la valiosa información que QA está descubriendo. Esto está lejos de ser óptimo porque los desarrolladores se centran solo en su propia área.

El mejor enfoque es que los desarrolladores entiendan cómo se integran sus áreas con otras desde el punto de vista de “Proteger” al usuario. De esta manera, todos pueden solucionar problemas de manera efectiva cuando se encuentre alguno.

Entonces, por un lado, QA ejecuta las pruebas de regresión, registra defectos, etc, mientras desarrollo continúa avanzando con funcionalidades; En este punto desarrollo avanza mientras QA sigue con la regresión.

En un escenario como el anterior, QA siempre se está poniendo al día con el trabajo en el que debería haber estado involucrado integralmente desde el principio. En última instancia, esto conduce a la pérdida de tiempo, otras ineficiencias y el desperdicio de recursos.

He aquí por qué la responsabilidad de las pruebas de regresión debe compartirse entre el control de calidad y los desarrolladores.

QA se ha convertido en un apoyo para el desarrollador

Dev generalmente se considera un equipo más valioso que QA por varias razones. Los desarrolladores ven su valor principal como simplemente producir la mayor cantidad de código funcional posible.

Debido a esta perspectiva anticuada, el QA se ha convertido en un apoyo para el desarrollador. QA ha asumido la responsabilidad de garantizar que el trabajo del desarrollador cumpla con los estándares de calidad establecidos de la industria. Eso está mal. Y nuestro trabajo no debe ser solo el buscar errores.

Las personas a veces comparan los roles en el proceso de desarrollo de software con los de los oficios de la construcción de edificios, con títulos tales como contratistas generales, especialistas calificados, arquitectos, gerentes de proyectos y trabajadores en general. Si bien la analogía funciona hasta cierto punto, el papel de QA es mal entendido.

Un trabajador experto, como un plomero, se asegura de que el agua fluya y el drenaje funcione correctamente. Si bien los plomeros pueden asegurarse de que la estructura del diseño sea sólida, generalmente no brindan información sobre el diseño, los colores o las características del edificio; se centran exclusivamente en la fontanería.

Son expertos en sus áreas de especialidad, los aspectos técnicos de la creación e instalación de plomería, y solo en eso. Lo mismo es cierto con otros oficios.

QA debería ser el contratista general del proyecto.

Por eso necesitas un contratista general. Estos profesionales pueden asesorar, incluso en una capacidad técnica, pero generalmente no tienen una gran experiencia en cada oficio. El trabajo del contratista general es garantizar que se cumpla el nivel de calidad deseado, incluso en el diseño y la experiencia del usuario.

Finalmente, tienes a los inspectores. Estos profesionales tienen experiencia en al menos un oficio y se aseguran de que se hayan seguido los códigos de construcción asociados.

En el desarrollo de software, la gente piensa en QA como el inspector. Pero el control de calidad debería funcionar como el contratista general. Los equipos de control de calidad están familiarizados con múltiples componentes del ciclo del software, pero eso no significa que sean expertos en un área específica, como lo es un inspector de construcción.

Como contratista general, el control de calidad debe trabajar con el propietario / usuario durante el transcurso del proyecto, y deben ser responsables de determinar los requisitos del usuario y las necesidades específicas.

Mientras QA sea visto como el inspector en lugar del contratista general, QA continuará viéndose quizás como un apoyo para el equipo de desarrollo, encontrando todas esas incidencias y defectos, siendo que ellos también deberían preocuparse por mejorar la calidad del código.

El Rol correcto del QA.

El rol del control de calidad debe ser garantizar que se satisfagan las necesidades del cliente, el negocio y el producto a entregar. Los equipos de control de calidad pueden proporcionar servicios de consultoría cuando surgen dudas en el ciclo de desarrollo de software. Pueden examinar la situación desde una vista diferente y ver la totalidad del proyecto.

Debido a que QA es consciente de la totalidad del proyecto, QA está en el mejor lugar para ver el panorama general. A diferencia de los desarrolladores, que trabajan en piezas o funciones específicas, los equipos de control de calidad ven todos los aspectos del proyecto.

El control de calidad debe depender de la experiencia del Owner de cada componente en el ciclo de vida del software y debe fomentar las relaciones con ellos.

Es por eso que el área de QA no puede ser el único responsable de las pruebas de regresión. El control de calidad no debe ser simplemente un inspector del código de desarrollo, sino que debe explorar la experiencia general del cliente desde un punto de vista más amplio y más basado en el usuario.