Descargo de responsabilidad: mi nombre es Eric Burygin, he trabajado como tester durante mucho tiempo, enseño a los estudiantes en el curso "Test Engineer" , por lo que puede parecer que el tester solo quiere transferir un trabajo a los desarrolladores. De hecho, el enfoque descrito tiene pros y contras, por lo que el artículo es, entre otras cosas, discutible. Me alegraría ver las opiniones de desarrolladores y probadores en los comentarios.
Si el desarrollo escribe pruebas, puede resolver varios problemas a la vez, por ejemplo:
- Acelera sensiblemente el ciclo de liberación.
- Descargar pruebas.
En la mayoría de los comandos, el proceso se parece a esto:
- El desarrollador crea nuevas funciones y completa las existentes.
- El probador prueba todo esto y escribe varios casos de prueba.
- El automatizador, justificando el título del puesto, automatiza todo de acuerdo con los casos de prueba escritos de la cláusula 2.
Todo parece sencillo.
Pero hay debilidades en este paradigma.
Digamos que un desarrollador ha completado su función y la ha pasado de forma segura para la prueba. Pero la característica resultó no ser medianamente rara, sino francamente cruda. Esto conducirá a un redescubrimiento del problema y soluciones adicionales, y puede haber de una a N iteraciones, dependiendo del tamaño de esta característica, su complejidad, el impacto en los procesos relacionados y la conciencia del propio desarrollador. Y también sobre cómo se organizan sus procesos en principio dentro del desarrollo, qué tan cuidadosamente se ven las solicitudes de extracción, si la aplicación se inicia antes de enviarse para la prueba.
En general, hay suficientes variables.
Una vez que la tarea se prueba y está lista para su lanzamiento, es necesario escribir pruebas para toda la funcionalidad de los casos de prueba. Luego retrocede / fuma y finalmente suelta.
Después de recibir los casos de prueba escritos, el automatizador cubre la funcionalidad con pruebas. Existe una probabilidad bastante alta de que la tarea termine en una cola existente, por lo que las pruebas se escribirán con retraso.
- Solo necesito más desarrolladores
Por desgracia, no es una panacea. Todo lo contrario. Cuantos más desarrolladores tenga en este esquema, más fuerte será la carga de prueba. Como resultado, aumentará el ciclo de lanzamiento o el propio equipo de pruebas.
Y esto, de acuerdo con el principio dominó, aumentará la carga de los automatizadores, que tendrán que procesar cada vez más casos de prueba que les caigan de las pruebas. Habrá una situación de espejo: o aumentará el tiempo de cobertura de la prueba o lo hará el personal de automatización.
Por lo general, hay dos probadores y un ingeniero de automatización por cada ocho desarrolladores. Al mismo tiempo, la automatización no está directamente involucrada en el ciclo de lanzamiento, sino que está cerca. Y surge la pregunta: ¿cómo hacer que los procesos descritos sean más efectivos, e incluso que no pierdan calidad?
Intentemos mover la etapa de automatización del tercer lugar al primero, a la etapa de desarrollo.
Lo que pasa
Inmediatamente obtendrá un buen conjunto de ventajas, consulte:
- los desarrolladores escriben pruebas simultáneamente con la escritura de la función en sí, lo que mejora significativamente su calidad;
- la carga de las pruebas disminuye: los probadores ahora necesitan mirar los resultados de las pruebas y evaluar si la tarea está suficientemente cubierta por las pruebas;
- La regresión manual en el esquema ya no es necesaria.
¿Qué pasa con los probadores?
El evaluador, incluso en el paradigma actualizado, sigue siendo un experto en pruebas: es él quien revisa tanto la calidad como la integridad de la cobertura de la prueba automática de una característica en particular, así como analiza problemas complejos e inusuales. Pero ahora, gracias a la carga reducida, el probador libera parte de su tiempo, puede ocuparse de los procesos.
Al mismo tiempo, debe comprender que las pruebas manuales aún no irán a ninguna parte; siempre tendrá algo que, por alguna razón, es imposible de automatizar o no tiene sentido.
Entonces, a un nuevo paradigma. ¿Fresco? Sí, al menos impleméntalo ahora mismo. Si puedes hacer dos cosas.
- Vende esta idea al desarrollo. Porque no todos los desarrolladores querrán escribir pruebas de inmediato, porque puede ser aburrido, o simplemente no quiere: ¿tienes, de hecho, probadores allí para qué?
- Venda esta idea a los gerentes. Porque, con otras ventajas, aumenta el tiempo de desarrollo de cada función.
Cuáles son las desventajas aquí pueden aguardarle.
- La mayoría de los desarrolladores simplemente no saben cómo realizar pruebas, porque son desarrolladores, no probadores. Y eso está bien. Aquí puede enseñarles cómo realizar pruebas, que no será la tarea más trivial, o simplemente escribir casos de prueba para ellos. Lo que de facto rompe el proceso en sí.
- Al principio, la automatización llevará más tiempo, porque no habrá una base de código de prueba, infraestructura ni enfoques habituales; la tarea es nueva.
- Se necesitarán informes claros para las pruebas. Pero tenga en cuenta: incluso el informe más comprensible no siempre se puede leer correctamente de inmediato.
- No puede cubrir fácil y rápidamente todos los problemas con las pruebas. En algunos casos, tendrá que dedicar más tiempo a las pruebas que a la implementación real de la función.
- Será difícil realizar tareas a gran escala al mismo tiempo que las pruebas, ya que lleva mucho tiempo.
- Para estas mismas tareas complejas y a gran escala, aún tendrá que reservar tiempo para simplemente profundizar en ellas, porque no hay otra forma de verificar la exactitud de las pruebas que escribieron los desarrolladores.
¿Qué hacer?
Básicamente, cada problema tiene una solución.
- Los desarrolladores no saben cómo realizar pruebas. →
Puede consultarlos en las primeras etapas para ayudar a comprender. - , . →
. . - . →
, , . - . →
: . - , . →
, — . . - . →
. .
Un enfoque con todos sus pros y contras tiene derecho a la vida. Y si también configura los procesos correctamente, esto lo ayudará a acelerar el ciclo de lanzamiento y no inflar el estado (: