¿Quién está al mando? Cómo eliminar la intermediación y mejorar la calidad

Jonny Steiner, Gerente de Marketing de Producto

 

Seguro que te ha pasado alguna vez: vas caminando por la calle y te encuentras con alguien joven que lleva una camiseta de tu grupo favorito. Quizá tu primera reacción sea algo como: «¿Una camiseta de Nirvana? Me pregunto si se sabrá alguna canción de Nirvana». ¿Te suena? ¡Pues enhorabuena, tienes madera de sabelotodo! Decimos «madera» porque bajo ningún concepto deberías acercarte a la gente y preguntarles por qué tienen derecho a llevar una camiseta de Nirvana. Esta es una lección de vida que te ofrecemos gratis en este artículo.

Basta de generalidades, hoy hablaremos del control de calidad en los equipos de control de calidad y pruebas. En el desarrollo de software, el responsable del control de calidad decide cuándo un software o una actualización está listo para producción. Esto significa que, en este caso, asume toda la responsabilidad de la calidad del software. Generalmente, este rol lo desempeña un miembro dedicado del equipo de pruebas o control de calidad.

Quiénes Releases el Releases?

Es frecuente que se pregunte a los testers cuándo dan su aprobación para una versión. Tanto testers como desarrolladores suelen expresar su frustración cuando han trabajado en proyectos donde el equipo de control de calidad tenía el control total de la versión. Asignar ese nivel de responsabilidad a un solo equipo puede generar disputas y retrasos.

En cierto modo, los equipos de pruebas se enorgullecen de esta designación, ya que les otorga un gran poder. Sin embargo, surge la pregunta de por qué los equipos de control de calidad o de pruebas deben aprobar una versión. Desde luego, no pretendo criticar a los equipos de control de calidad o de pruebas. Todos sabemos que, bajo presión, estos equipos hacen lo mejor que pueden con buena disposición y aplomo.

Por otro lado, colocar a los evaluadores en esta posición, como responsables de la decisión final sobre las versiones, les impone mucha presión.

Analicemos algunas de las consecuencias negativas de que el departamento de control de calidad sea el filtro principal:

• Todos los cuellos de botella – Los equipos de desarrollo suelen estar formados por cinco personas, una de las cuales se designa como "tester". Es bastante sencillo comprobar que asignar a una persona la responsabilidad de las pruebas y la calidad puede... liderar a los cuellos de botella.
• Soportar el peso de la responsabilidad – Asignar la responsabilidad de las versiones a una sola persona implica que el resto del equipo trabajará bajo la falsa premisa de que todos los defectos se detectarán en control de calidad. Peor aún, esto les da la excusa perfecta para no asumir la responsabilidad de los errores que lleguen a producción, ya que pueden simplemente culpar a control de calidad.
• Nadie es perfecto, ni siquiera los probadores. Es mejor no basar todo el proceso de liberación en la decisión de una sola persona. todos Los insectos. Son humanos, como tú, y los humanos cometemos errores.
• Bucles de retroalimentación – En el modelo de guardián, cuando un desarrollador termina su parte en el de compra, Se lo entregan al tester o al equipo de control de calidad y luego pasan a su siguiente proyecto. Sin embargo, cuando llega la inevitable retroalimentación... en, Tendrán que volver a la función anterior. Eso puede resultar en un caos de proyectos a medio empezar y abandonados.

La alternativa al control de acceso es la ruptura de barreras

Existen métodos de prueba que garantizan el lanzamiento de aplicaciones de calidad sin necesidad de filtros. Si se delega el trabajo de control de calidad a todo el equipo de desarrollo, se les responsabilizará a todos por la calidad. El equipo de control de calidad puede seguir siendo responsable de las pruebas, pero implican un mayor volumen de pruebas y otros miembros del equipo pueden colaborar.

• Los desarrolladores pueden cubrir el trabajo que realizan escribiendo sus propias pruebas unitarias.
• Los responsables de producto pueden comprobar los entornos de prueba para asegurarse de que las nuevas funciones operan según lo previsto.
• DevOps Los responsables pueden utilizar sistemas de integración continua (CI) para supervisar las pruebas a medida que se incorpora cada nuevo código.

Puedes empezar a implementar esta práctica de forma sencilla.

Comienza con una sesión previa al inicio del desarrollo de una nueva funcionalidad. De esta forma, los desarrolladores y testers podrán abordar el sprint comprendiendo lo necesario para demostrar que el trabajo cumple con los criterios de aceptación. Al discutir el trabajo con antelación, la carga se distribuirá equitativamente entre el equipo y, mientras los desarrolladores escriben las pruebas de API, el equipo de QA podrá centrarse en las pruebas de interfaz y funcionales.

A medida que el proyecto avanza y el equipo encuentra un problema que necesita solución, pueden discutirlo internamente o con otros equipos. Por ejemplo, si el equipo de control de calidad descubre un defecto, puede comentárselo a los equipos de desarrollo de producto para determinar si requiere atención inmediata o si puede esperar.

Aún mejor, cuanta más gente se involucre en un proyecto y participe en las pruebas, mayor será la tendencia a realizarlas lo antes posible en el proceso. Ya no es necesario esperar un momento específico para empezar a probar, sino que se convierte en una parte fundamental de la rutina diaria. A largo plazo, esto debería ayudar a minimizar los riesgos hacia el final del ciclo de desarrollo.

En definitiva, esto conlleva más pruebas, lo que se traduce en una mejor cobertura, ya que fomenta la comunicación entre equipos interdisciplinarios en lugar de que trabajen de forma aislada. Si los equipos aislados representan un problema en su organización, puede incluso plantearlo a los responsables del producto y a las partes interesadas. Promover la comunicación y la colaboración es fundamental para gestionar situaciones de control de acceso.

Los resultados serán entonces los siguientes:

• Responsabilidad compartida – Al no haber una sola persona responsable, todo el equipo asume la responsabilidad de entregar software de calidad.
• ¡Adiós a los cuellos de botella! Ya no se trata de una sola persona probando contra el mundo. Con todos probando, las nuevas versiones y aplicaciones llegarán a producción más rápido.
• Reforzando el ciclo de retroalimentación – Se acabó el cambio de contexto al descubrir un defecto. Los defectos se detectarán y mitigarán en las primeras etapas del proceso, eliminando cualquier retraso en la producción.

El control de acceso en el control de calidad es una reliquia.

En algunas organizaciones aún ocurre. El equipo de control de calidad (QA) es responsable del lanzamiento de un proyecto y tiene acceso a las claves de acceso. Esta práctica perjudicial presiona a los testers y genera malas relaciones entre equipos aislados, ya que trabajan por separado para alcanzar un objetivo sin colaboración.

Existen dos escenarios negativos principales al practicar el control de calidad:

1. Proyectos retrasados ​​– El control de calidad bloquea ciertos problemas menores antes del lanzamiento.
2. Defectos en la producción – Cuando algún error se cuela, el equipo de control de calidad es el chivo expiatorio porque se les considera responsables de la calidad en general.

Para abandonar este método anticuado —y, francamente, poco colaborativo— de desarrollo y pruebas, los equipos necesitan que todos los miembros del proyecto participen en las pruebas a medida que desarrollan, en lugar de que el departamento de control de calidad sea el único responsable. También necesitan implementar el enfoque "shift left" (preparar las pruebas desde el principio) y realizarlas con frecuencia. Comprender esto ayudará a las organizaciones a crear un sistema donde cada persona pueda contribuir y, a su vez, mejorará la calidad general de sus versiones.

La calidad, como objetivo y concepto, debe ser fundamental en el flujo de trabajo de un equipo. Además, debe ser algo en lo que participen todos los involucrados en un proyecto. Si observa que empiezan a surgir problemas de compartimentación o falta de cooperación entre equipos en su empresa, debe comunicárselo a quienes tengan la capacidad de cambiar esta situación. Cuando un equipo de control de calidad se centra en limitar el acceso a la información, la calidad general de la aplicación se verá afectada, lo cual es lamentable, ya que la calidad está implícita en su nombre.