¿Quién está a cargo? Cómo eliminar la vigilancia y aumentar la calidad

Jonny Steiner, director de marketing de productos

Estamos seguros de que debe haber experimentado un escenario como este antes: está caminando en algún lugar público y se encuentra con una persona más joven que lleva una camiseta de su banda favorita. Tal vez tu reacción inicial sea algo como esto: “Vaya, ¿una camiseta de Nirvana? Me pregunto si conocen alguna canción de Nirvana”. ¿Suena familiar? Entonces, ¡felicidades, tienes potencial de portero! Decimos potencial porque en ningún caso deberías acercarte a las personas y preguntarles sobre su derecho a usar una camiseta de Nirvana. Esa es una lección de vida proporcionada de forma gratuita con esta publicación de blog.

Sin embargo, ya basta de generalidades, estamos aquí para discutir la vigilancia en lo que respecta a los equipos de control de calidad y pruebas. En el mundo del desarrollo de software, un Gatekeeper es una persona que tiene control sobre cuándo una pieza de software o una actualización está lista para entrar en producción. Lo que eso significa es que, en este escenario, el guardián asume toda la responsabilidad por la calidad del software. A menudo, este papel lo desempeña un miembro dedicado del equipo de pruebas o control de calidad.

Quién Releases el Releases?

Las personas a menudo preguntan a los probadores cuándo dan su aprobación para release. Los evaluadores y desarrolladores a menudo expresan su frustración cuando han trabajado en proyectos en los que el control de calidad tenía las claves para el release. Colocar ese nivel de responsabilidad en un equipo puede generar disputas y demoras.

En cierto nivel, los equipos de pruebas están orgullosos de esta designación, ya que les otorga una gran cantidad de poder. Sin embargo, cabe preguntarse por qué los equipos de control de calidad o de pruebas deben aprobar un release en absoluto. Ciertamente, no estoy tratando de criticar al control de calidad o a los equipos de prueba. Todos sabemos que cuando se les coloca en condiciones difíciles, estos equipos hacen lo mejor que pueden con buen carácter y aplomo.

Por otro lado, poner a los probadores en esta posición como los responsables de la última palabra sobre releases pone mucha presión sobre ellos.

Veamos algunas de las consecuencias negativas de que el control de calidad sea su guardián:

• Todos los cuellos de botella - Los equipos de desarrollo suelen estar formados por cinco personas y una persona se designa como "probador". Es matemática bastante simple ver que hacer que una persona sea responsable de las pruebas y la calidad puede Lead a los cuellos de botella.
• Llevando la peor parte de la responsabilidad - Hacer a una persona responsable de releases significa que otros miembros del equipo funcionarán bajo la falsa noción de que todos los defectos se detectarán en el control de calidad. Quizás incluso peor, también les da la oportunidad de no asumir la responsabilidad de los errores que llegan a la producción porque simplemente pueden culpar al control de calidad.
• Nadie es perfecto, ni siquiera los probadores. Es mejor no basar todo su release proceso en una persona que encuentra todos los insectos. Ellos son humanos y tú también, y los humanos cometen errores.
• Circuitos de retroalimentacion - En el modelo de guardián, cuando un desarrollador termina su parte en el de compra, se lo entregan al evaluador o al control de calidad y luego pasan a su próximo proyecto. Sin embargo, cuando llega la inevitable retroalimentación en, necesitarán volver a cambiar de contexto a la función anterior. Eso puede resultar en un lío de proyectos a medio iniciar y detenidos.

La alternativa a Gatekeeping es Gatebreaking

Hay formas de ejecutar pruebas que aseguran que release aplicaciones de calidad sin necesidad de ningún control. Si le asigna el trabajo de control de calidad a todo el equipo de desarrollo, los hará responsables de la calidad. El control de calidad aún puede ser responsable de las pruebas, pero hay más pruebas por hacer y otros miembros del equipo pueden ayudar.

• Los desarrolladores pueden cubrir el trabajo que realizan escribiendo sus propias pruebas unitarias.
• Los gerentes de productos pueden verificar los entornos de prueba para asegurarse de que las nuevas funciones funcionen tal como se ejecutaron.
• DevOps los gerentes pueden usar los sistemas de CI para monitorear las pruebas a medida que se confirma cada nuevo código.

Puede comenzar a implementar esta práctica de manera simple.

Comience con una sesión antes de que comience el trabajo de desarrollo de una nueva característica. De esa manera, los desarrolladores y evaluadores pueden comenzar el sprint y comprender lo que deben hacer para demostrar que el trabajo se ha completado según los criterios de aceptación. Con el trabajo discutido con anticipación, la carga de trabajo se distribuirá de manera uniforme entre el equipo y con las pruebas de API escritas por los desarrolladores, el control de calidad puede trabajar en la interfaz de usuario y las pruebas funcionales.

A medida que avanza el proyecto y el equipo encuentra un problema que debe abordarse, pueden discutirlo entre ellos o entre equipos. Por ejemplo, si QA descubre un defecto, pueden mencionarlo con los equipos de desarrollo de productos para ver si es algo que necesita atención inmediata o si puede esperar.

Aún mejor, a medida que más personas se involucran en un proyecto y participan en las pruebas, se genera una mentalidad de cambio a la izquierda en la que las pruebas se realizan lo antes posible en el proceso. Nadie necesita esperar un momento específico para comenzar la prueba, simplemente se convierte en un aspecto de la rutina diaria de las personas. A largo plazo, esto debería ayudar a minimizar el riesgo hacia el final del ciclo de desarrollo.

En última instancia, conduce a más pruebas que se traducen en una mejor cobertura porque hace que los equipos interdisciplinarios se comuniquen entre sí en lugar de permanecer en sus propios equipos aislados. Si los equipos aislados son un problema en su organización, incluso puede mencionarlo a los propietarios del producto y a las partes interesadas. Promover la comunicación y la colaboración es extremadamente importante cuando se trata de una situación de control.

Los resultados se verán así:

• Responsabilidad compartida - Sin una sola persona responsable, todo el equipo asume la responsabilidad de entregar software de calidad.
• Adiós cuellos de botella - Ya no es una persona probando contra el mundo. Con todos probando, las nuevas versiones y aplicaciones llegarán a producción más rápido.
• Apretando el circuito de retroalimentación – No más cambios de contexto cuando se descubre un defecto. Los defectos se descubrirán y mitigarán temprano en el proceso, eliminando cualquier retraso en la producción.

Gatekeeping en QA es una reliquia

Todavía sucede en algunas organizaciones. QA se hace responsable de un proyecto release y tiene las llaves del release. Esta práctica dañina ejerce presión sobre los evaluadores y conduce a malas relaciones entre equipos aislados, ya que trabajan por separado hacia un objetivo en el que no están colaborando.

Hay dos escenarios negativos principales cuando se practica el control de calidad:

1. Proyectos retrasados ​​- Como QA bloquea ciertos problemas pequeños antes release.
2. Defectos en la producción – Cada vez que un error se desliza por las grietas, el control de calidad es el chivo expiatorio porque se lo considera responsable de la calidad en general.

Para deshacerse de este método de desarrollo y prueba anticuado, y francamente anticolaborativo, los equipos deben tener a todos en el proyecto trabajando en las pruebas a medida que se desarrollan, en lugar de que el control de calidad sea responsable de todo. También necesitan cambiar a la izquierda y probar temprano y con frecuencia. Tener esta comprensión básica ayudará a las organizaciones a crear un sistema en el que todos puedan hacer su parte y la calidad general de sus releases mejorará también.

La calidad como objetivo y como concepto debe ser uno de los fundamentos del flujo de trabajo de un equipo. También debe ser algo en lo que participen todos los que están involucrados en un proyecto. Si observa que algunos de los silos o la falta de cooperación entre los equipos comienzan a surgir en su empresa, debe comentarlo con aquellos que están en posición de cambiar eso. Cuando un equipo de control de calidad se enfoca en el control de acceso, la calidad general de su aplicación se verá afectada, y es una pena porque la palabra está literalmente en su título.