Hace 7 años (2013), se publicó un artículo con el mismo título en InfoQ, pero este artículo es completamente nuevo . Antes de responder "¿qué son exactamente las pruebas ágiles?", déjame hacerte una pregunta: ¿ entiendes el desarrollo ágil?
Si no lo entiende, primero debe comprender Agile. Por ejemplo, lea un artículo que escribí antes de que Scrum ya no sea Scrum, Scrum sigue siendo Scrum , que puede ayudarlo a comprender Agile. Para entender ágil, es más importante ir a agilemanifesto.org para leer detenidamente el famoso manifiesto ágil y los 12 principios del desarrollo ágil.
Con el pensamiento escucha el caso que te cuento a continuación, en el proceso de escucha puedes examinar el caso para juzgar cuáles se ajustan a los valores ágiles y cuáles violan los principios del desarrollo ágil, finalmente analicemos el caso juntos Y responda "¿qué es exactamente la prueba ágil".
*** Casos de transformación de testing tradicional a testing ágil ***
Este caso proviene de una empresa nacional cuyos productos son principalmente terminales inteligentes basados en el sistema Android. La historia sucedió hace 6 años, en 2013, cuando el departamento de I+D de software de la empresa inició una serie de intentos ágiles orientados a las pruebas .
Permítanme presentarles primero los antecedentes del caso . El departamento de I+D de software de la empresa tiene cuatro departamentos de desarrollo y un enorme departamento de pruebas. Entre ellos, un departamento responsable del desarrollo de varias herramientas de I+D también está afiliado al departamento de pruebas. La proporción de desarrolladores y evaluadores es casi 1: 1. Las responsabilidades del departamento de desarrollo se dividen de acuerdo con los módulos funcionales responsables, mientras que el departamento de pruebas es responsable de todas las pruebas a nivel del sistema de software, incluidas las pruebas funcionales, las pruebas de rendimiento, la seguridad pruebas y pruebas de confiabilidad. , pruebas de compatibilidad, etc. En ese momento, se adoptó el modelo tradicional de desarrollo en cascada, es decir, el modelo V, y la escritura de código y las pruebas de productos se dividieron claramente en dos etapas.
-
intento de integración continua
Las herramientas que se utilizan aquí incluyen: herramienta de control de versión de código distribuido Git + herramienta de revisión de código Gerrit + herramienta de integración continua Jenkins + marco de prueba automatizado de desarrollo propio basado en Monkey Runner. Basado en Git + Gerrit + Jenkins, el departamento de desarrollo ha realizado la construcción automática del código.
El objetivo deseado es completar la construcción automática, la implementación automática y las pruebas automáticas después de enviar el código y generar automáticamente informes de prueba. En el proceso de implementación, no hay problema con la cadena de herramientas, y no hay problema con la construcción automática y el despliegue automático, el problema radica en las pruebas automatizadas.
Hay alrededor de 1000 casos de prueba manuales para un producto, pero solo hay más de 100 casos de prueba que pueden convertirse en scripts automatizados y ejecutarse en un entorno integrado durante mucho tiempo, y solo se implementa la verificación de versión, que es lo que solemos hacer. llamada "prueba de humo". Esto significa que cuando el desarrollador envía el código, la cobertura de la prueba automática desencadenada es muy limitada Incluso si el entorno integrado puede soportar la verificación continua, todos sienten que es de muy mal gusto.
-
Test-forward e intentos organizacionales
La definición de prueba avanzada en ese momento era probar en la etapa de codificación del software, en lugar de esperar hasta el final del desarrollo para comenzar a probar. En pocas palabras, está probando mientras se desarrolla, con la esperanza de acortar el ciclo de desarrollo del producto a través de esto .
(1) La primera etapa
El departamento de desarrollo se divide según el Scrum Team y los ingenieros de pruebas se contratan según una proporción de 3:1. Al principio, no quería entender qué tipo de probadores necesitaban, por lo que los reclutas eran básicamente pruebas manuales y la mayoría de ellos no podía entender el código.
Sus tareas principales en el Equipo Scrum incluyen : pruebas manuales, reproducir errores de acuerdo con los requisitos de desarrollo una y otra vez, realizar tareas para los desarrolladores, como actualizar una nueva versión del terminal, encontrar el modelo de hardware que el desarrollo desea verificar y pronto. En las primeras etapas del proyecto, cuando el hardware del producto no está instalado o la integración del software no funciona en conjunto, no se pueden realizar pruebas manuales.
(2) La segunda etapa
Originalmente, los líderes esperaban que el modelo ágil pudiera reducir la cantidad de probadores, pero contrariamente a las expectativas, la cantidad de personas en el departamento de pruebas responsables de las pruebas del sistema no disminuyó, pero se agregaron docenas de probadores más dentro del departamento de desarrollo. La razón es que los métodos de prueba que utilizan los dos grupos de personas son similares, si hay más personas simplemente se refleja en que hay más errores reportados, lo que valora el departamento de pruebas es la tasa de cobertura de los requisitos, y el número de personas no se puede reducir.
Por lo tanto, en una reorganización, el líder anunció que todos los evaluadores serían transferidos al departamento de pruebas y solicitó al departamento de pruebas que redujera la cantidad correspondiente de subcontratación de pruebas. Scrum Team puede pedirle al departamento de pruebas que equipe probadores en una proporción de 3:1. El departamento de pruebas puede comprender el alcance de las pruebas del Equipo Scrum, lo que reduce las pruebas repetidas. Después de la reorganización, se ha reducido el número de personas, pero las pruebas manuales siguen siendo el método principal. Debido a los cambios en la estructura organizativa, el desarrollo y las pruebas a menudo discuten sobre quién tiene la última palabra sobre las pruebas en la fase de desarrollo. Desarrollo y las pruebas se han vuelto más distintas, y la relación entre Aún más nerviosa .
(3) La tercera etapa
Después de un tiempo de funcionamiento, sentí que esto no era factible y no se ajustaba a las características de un equipo ágil, por lo que decidí trasladar al departamento de desarrollo al personal responsable de las pruebas durante la fase de desarrollo. Un buen cambio es: cada equipo Scrum comienza con un ingeniero de pruebas sénior como propietario de la prueba, responsable de formular estrategias y planes de prueba, y de coordinar el arreglo entre las pruebas de desarrollo y las pruebas del sistema. El departamento de desarrollo también ha comenzado a entrenar las capacidades de desarrollo de los ingenieros de prueba en la fase de desarrollo.
-
Un intento de prueba unitaria
Al principio, la tasa de cobertura de las pruebas unitarias era casi 0, y los desarrolladores solo escribían el código y solucionaban los defectos enviados por los evaluadores. Debido al fracaso de la integración continua y el reenvío de pruebas, todos creen que el departamento de desarrollo debería exigir a los desarrolladores que realicen pruebas unitarias y midan los resultados de las pruebas unitarias por cobertura de código. El desarrollo también prometió hacerlo, pero no ha sido efectivo durante todo un año. La razón es: ocupado, sin experiencia y habilidades en pruebas unitarias .
-
Un intento de probar la renovación de la capacidad
El departamento de pruebas es consciente de la importancia de la automatización, pero solo el 5% de los ingenieros del departamento son responsables de las pruebas automatizadas. Después de capas de aplicaciones, la empresa acordó reemplazar el 10% de los ingenieros de pruebas manuales con el último sistema de eliminación. A través de varios métodos de transferencia interna, contratación externa y capacitación de empleados, la proporción de ingenieros de pruebas automatizadas finalmente alcanzó el 25 % después de un año. El equipo comenzó a construir un marco de prueba automatizado unificado. La tasa de cobertura de las pruebas automatizadas en las pruebas de API y UI finalmente experimentó un aumento significativo, pero la tasa de cobertura de requisitos general no superó el 30 % y la falta de pruebas unitarias sigue siendo defectuosa. Sin la participación de los desarrolladores, las pruebas siempre están en La capa de interfaz de usuario Tossing, por supuesto, está obteniendo el doble de resultados con la mitad del esfuerzo.
A partir de este ejemplo, se puede ver que en el proceso de transformación de pruebas tradicionales a pruebas ágiles, el departamento de I+D de esta empresa no sabía qué es una prueba ágil real, pero cruzó el río palpando las piedras y siguió intentándolo. difícil y tomó muchos desvíos. Al final, aún no ha llegado al otro lado de las pruebas ágiles. Sin mencionar que la calidad de los productos y la eficiencia de las pruebas han mejorado significativamente.
*** ¿Qué son las pruebas ágiles? ***
Entonces, ¿qué son exactamente las pruebas ágiles? Lo cierto es que el "testing ágil" no es ni un método de testing ni un método de testing, sino un conjunto completo de soluciones de testing de software especialmente diseñadas para adaptarse al desarrollo ágil . Esta solución debe ser capaz de admitir la entrega continua, cubriendo los valores correctos requeridos, la forma de pensar, el proceso de prueba, una serie de prácticas de prueba excelentes y un entorno de prueba más adecuado, un marco de prueba automatizado y herramientas. Las pruebas ágiles pueden adoptar varios métodos y métodos de prueba existentes, y el énfasis es diferente al de las pruebas tradicionales, pero las principales diferencias son los valores, el pensamiento de prueba, los procesos y las prácticas.
Las pruebas ágiles deben tener los valores preconizados por el "Manifiesto Ágil", por lo que podemos redactar el siguiente "Manifiesto de Pruebas Ágiles" según el formato del "Manifiesto Ágil":
Las pruebas ágiles enfatizan la "colaboración con el desarrollo", las "pruebas automatizadas", el "pensamiento del cliente" y el "ajuste de la estrategia de prueba dinámica" son más valiosos.
Luego, regresemos y veamos los casos anteriores, al menos 1 y 2, no lo hicieron: los probadores no recibieron suficiente atención y respeto, y la colaboración de desarrollo y prueba no fue suficiente, pero:
-
Hubo un departamento de pruebas separado durante un tiempo, "el desarrollo y las pruebas se volvieron más distintos y la relación se volvió más tensa"
-
"Sin la participación de los desarrolladores, las pruebas siempre implican la capa de interfaz de usuario, por supuesto, es la mitad del esfuerzo"
-
"Las pruebas automáticas desencadenadas logran una cobertura muy limitada"
-
……
En la etapa inicial de transformación, no se fortaleció la capacitación de los probadores relevantes, ni siquiera se conocían los requisitos del modo ágil para los probadores, y los probadores reclutados no estaban calificados. En el proceso de implementación, faltan estrategias de prueba y no se pone énfasis en partir de las necesidades de los clientes y ajustar dinámicamente las estrategias de prueba.
El desarrollo ágil todavía tiene 12 principios. ¿El equipo en el caso anterior los siguió uno por uno y de manera específica? Aunque los 12 principios del desarrollo ágil no parecen hablar de pruebas, las pruebas son parte de todo el desarrollo de software, por lo que es natural cumplir con estos principios y adaptarse a los requisitos básicos del desarrollo ágil, tales como:
-
¿Cómo apoyar o ayudar a la "entrega continua y temprana de software valioso"?
-
Cómo aceptar el cambio: "Fácil de enfrentar los requisitos cambiantes, incluso al final del desarrollo"
-
……
Solo adhiriéndose a estos principios se puede obtener la postura correcta para adaptarse al desarrollo ágil, y solo adoptando excelentes prácticas de desarrollo ágil, como el desarrollo basado en pruebas, y cooperando estrechamente con el desarrollo, las pruebas no se convertirán en un "bloque de tropiezo". de desarrollo ágil.
Basado en los 12 principios del desarrollo ágil, desarrollé los siguientes 8 principios de pruebas ágiles:
Estos principios se explican en detalle en el contenido de seguimiento de la columna "Pruebas ágiles eficientes" .
referencia: