Hablé con docenas de ingenieros de control de calidad de diferentes compañías y cada uno de ellos habló sobre el hecho de que usan diferentes sistemas y herramientas para el seguimiento de errores. También probamos varios de ellos y decidí compartir la solución a la que llegamos.
Introducción
Seré banal Aparecen errores y se detectan en varias etapas del proceso de desarrollo. Por lo tanto, puede dividir los errores en categorías, según el momento en que se detectaron:
- Deficiencias Estos son los errores que cometieron los desarrolladores al obtener una nueva funcionalidad. Tales errores se encuentran durante la investigación o las pruebas de aceptación de nuevas características en los stands de desarrollo de los equipos.
- Errores en la regresión . Estos son defectos que encuentran pruebas de regresión manual o pruebas automáticas de UI y API en el stand para la integración de código.
- Errores con una venta . Estos son problemas que los empleados o clientes encontraron y contactaron con el soporte técnico.
¿Dónde empezamos, o Jira?
Hace dos años, teníamos un equipo dedicado de probadores que probaron manualmente el producto después de integrar el código de todos los equipos. Hasta este punto, el código ha sido probado por desarrolladores en puestos de desarrolladores. Los errores que encontraron los evaluadores se registraron en la cartera de pedidos en Jira. Los errores se almacenaron en una cartera de pedidos común y se movieron de sprint a sprint con otras tareas. Cada sprint obtuvo dos o tres errores y los arregló, pero la mayoría permaneció en la parte inferior de la cartera:
- Una de las razones por las cuales se acumulan errores en el trabajo atrasado es que no interfieren con los usuarios. Dichos errores tienen una prioridad baja y no se solucionarán.
- Además, si la compañía no tiene reglas claras y comprensibles para establecer errores, los evaluadores pueden agregar el mismo problema varias veces porque no pudieron encontrar el informe de error ya agregado en esta lista.
- Otra razón puede ser que los evaluadores inexpertos están involucrados en el proyecto. Es un error para los probadores principiantes ingresar en el seguimiento de errores todos los errores encontrados durante la operación. Los evaluadores sin experiencia consideran que el propósito de las pruebas es buscar errores, en lugar de proporcionar información sobre la calidad del producto y prevenir la aparición de defectos.
Daré un ejemplo simple. Al generar informes en los campos de entrada de fecha, la fecha se sustituye de manera predeterminada. Al cambiar la fecha en la ventana emergente, puede volver a seleccionar hoy y se borrará el campo de entrada de fecha.
Sospecho que durante toda la vida de nuestra red, nadie, excepto los probadores, no ha reproducido este error. Dichos errores constituyen la mayoría de los errores que no se corrigen.
Con este enfoque, cuando se ingresan todos los errores encontrados, algunos de ellos se duplican y la mayoría de estos errores no se reparan. Surgen problemas:
- Los probadores están desmotivados porque los desarrolladores no corrigen los errores que encuentran. Uno tiene la sensación de que el trabajo no tiene sentido.
- Es difícil para el propietario del producto administrar una cartera de pedidos con muchos errores.
Adiós Jira, larga vida a Kaiten
En la primavera de 2018, abandonamos a Jira y nos mudamos a Kaiten. El cambio de herramientas fue causado por razones sobre las cuales Andrei Arefiev escribió en el artículo
"Por qué Dodo Pizza comenzó a usar Kaiten en lugar de un montón de Trello y Jira". Después de mudarnos a Kaiten, nuestro enfoque para trabajar con errores no ha cambiado:
- Las imperfecciones se registraron en los paneles de comando y los desarrolladores decidieron independientemente repararlas o no.
- Los errores que se encontraron en la regresión (fue realizada por un equipo dedicado de evaluadores) se repararon en la rama de lanzamiento y no liberaron el código hasta que se resolvieron todos los problemas. Decidimos que sería más lógico mantener y recopilar información sobre estos problemas en el canal de probadores en Slack. Los evaluadores escribieron un mensaje que contenía una leyenda, una lista de errores con registros y los nombres de los desarrolladores que tomaron la tarea para trabajar. Con la ayuda de emoji, cambiaron el estado, y en los oficios que discutieron, aplicaron capturas de pantalla, sincronizaron. Este formato es adecuado para los probadores. A algunos desarrolladores no les gustó este método, porque en el chat había otra correspondencia en paralelo y este mensaje subió y no fue visible. Lo arreglamos, pero no simplificó mucho la vida.
- Los errores que se encontraron en el producto se registraron en la cartera, Propietario del producto, se priorizaron y seleccionaron aquellos que repararemos.
Tiempo de experimento o no
Decidimos experimentar con los formatos y creamos un tablero separado en Kaiten, en el que guardamos errores y cambiamos los estados. Simplificamos el establecimiento de un informe de error para pasar menos tiempo. Al agregar una tarjeta a Kaiten, los evaluadores marcaron a los desarrolladores. Se envió una notificación a su correo sobre esto. Ponemos esta placa en un monitor que colgaba en el pasillo cerca de nuestro lugar de trabajo, para que los desarrolladores pudieran ver el progreso y el proceso de prueba se volviera transparente. Esta práctica tampoco se arraigó, porque el principal canal de comunicación es Slack. Nuestros desarrolladores no revisan el correo a menudo. Por lo tanto, esta solución dejó de funcionar rápidamente y volvimos a Slack.
Trae las hormigas de vuelta
Después de un experimento fallido en Kaiten, algunos desarrolladores todavía estaban en contra del formato del mensaje en Slack. Y comenzamos a pensar cómo rastrear errores y resolver problemas que impedían a los desarrolladores. Como resultado de las búsquedas, me encontré con una aplicación para Slack, Workast, que ayuda a organizar el trabajo con niños pequeños directamente en el messenger. Pensamos que esta aplicación le permitirá administrar el proceso de trabajar con errores de manera más flexible. Esta aplicación tenía sus ventajas: cambio de estado y asignación a desarrolladores con solo hacer clic en un botón, las tareas completadas se ocultaron y el mensaje no creció hasta alcanzar un tamaño enorme.
Entonces, los problemas resueltos se buscaron en la aplicación Todo y las solicitudes para devolver "hormigas". Después de que finalizó el período de prueba de la aplicación Workast, decidimos abandonarla. Debido a que usando esta aplicación, llegamos a lo mismo que cuando usamos Jira. Había algunos errores que iban de regresión en regresión en esta lista. Y con cada iteración, había más de ellos. Quizás valió la pena finalizar el proceso de trabajar con esta extensión, comprarlo y usarlo, pero no lo hicimos.
Nuestra manera perfecta de lidiar con los errores ahora
A finales de 2018, principios de 2019, se produjeron una serie de cambios en nuestra empresa que afectaron el proceso de trabajar con errores.
En primer lugar, no teníamos un equipo dedicado de evaluadores. Todos los evaluadores se dispersaron en equipos de desarrollo para fortalecer la competencia de los equipos de evaluación. Gracias a esto, comenzamos a encontrar errores antes, antes de la integración del código de comando.
En segundo lugar, abandonamos las pruebas de regresión manual en favor de las automáticas.
En tercer lugar, adoptamos una "política de cero errores". En el artículo "
#zerobugpolicy o cómo corregimos errores ",
bevzuk detalla cómo seleccionamos los errores que corregimos.
Hoy el proceso de trabajar con errores es el siguiente:
- Deficiencias Los evaluadores informan el problema a analistas o gerentes de producto. Caminan, muestran, reproducen, explican cómo afectará a los clientes y deciden si necesita repararse antes del lanzamiento, o si puede repararse más tarde, o tal vez no valga la pena repararlo.
- Los errores en la regresión de que las pruebas automáticas encontradas son reparados por el equipo que tocó esta parte del sistema y no publicaremos este código hasta que resolvamos el problema. Los probadores corrigen estos errores en un formato arbitrario en el canal de lanzamiento en Slack.
- Errores con una venta . Dichos errores van directamente a los propietarios de la tarea. Los analistas ejecutan errores en la Matriz de prioridades del error y lo agregan al trabajo atrasado o lo arreglan por sí mismos, acumulando estadísticas de aciertos en este tema.
Resumen
En resumen, básicamente abandonamos el sistema de seguimiento de errores . Usando este enfoque para trabajar con errores, resolvimos varios dolores:
- Los probadores no están molestos porque los errores que encuentran y desencadenan en el seguimiento de errores no son corregidos.
- Los probadores no pasan tiempo en una institución y una descripción completa de los errores que nadie leerá.
- PO es más fácil de gestionar el trabajo acumulado en el que no hay carga muerta.
No quiero decir que rastrear errores es inútil. Los errores que llevamos al trabajo se rastrean como cualquier otra tarea. Pero un sistema de seguimiento de errores no es un atributo de prueba requerido. No es necesario usarlo solo porque la mayoría de las empresas lo usan y, por lo tanto, es habitual en la industria. Debe "pensar con la cabeza" y probar las herramientas para sus procesos y necesidades. Es ideal para nosotros trabajar sin un sistema de seguimiento de errores ahora. Durante medio año de tal trabajo, nunca pensamos en volver a hacerlo y volver a encontrar todos los errores allí.
¿Y cómo se organiza el proceso de trabajar con errores en su empresa?