1. ¿Qué son las pruebas ágiles?
Las pruebas ágiles son un nuevo proceso, método y práctica de prueba adoptados para adaptarse a los métodos ágiles. Ha adaptado el proceso de prueba tradicional y tiene un enfoque diferente, como reducir la proporción de trabajo, como la planificación de pruebas y el diseño de casos de prueba, y aumentar el diseño de productos. , Comunicación y colaboración de desarrolladores.
En el proceso de prueba ágil, participe en pruebas unitarias, concéntrese en las nuevas características de iteración continua y realice suficientes pruebas de aceptación para estas nuevas características Las pruebas de regresión de las características originales dependen de las pruebas automatizadas.
En pocas palabras, las pruebas ágiles son proporcionar continuamente comentarios oportunos sobre problemas de calidad del software y una iteración rápida, es decir, llevamos a cabo el desarrollo, el lanzamiento, la retroalimentación y la optimización a corto plazo, lo que hace que el proyecto sea fácil de ajustar y, por lo tanto, ágil.
2. El formulario de solicitud de pruebas ágiles en el proyecto
Reunión diaria de pie: es una reunión de 15 a 30 minutos cada mañana. El formato de la reunión es que los miembros del equipo del proyecto van a la pizarra para presentar lo que completaron ayer, los problemas encontrados o los buenos métodos. El contenido del trabajo planificado para completarse hoy, etc .; en la
pizarra estará escrito grupo de demanda, desarrollo listo, desarrollo y completado SR, prueba lista, prueba y completa SR, aceptación lista, aceptación SR y aceptación completa SR;
Analizando el progreso de la historia en la pizarra, vea si hay un retraso en el progreso del proyecto. Si es así, el gerente del proyecto hará preguntas, analizará las razones y descubrirá cómo mejorar.
Extreme Programming (XP) es un proceso de desarrollo de software que permite a los desarrolladores producir rápidamente código de alta calidad. Los desarrolladores de XP pueden emparejar la programación para mejorar la calidad del código.
Desarrollo impulsado por pruebas: en las pruebas ágiles, cada historia tiene una hora de inicio y finalización planificada. Cuando los desarrolladores analizan y diseñan sus propias historias, los evaluadores deben analizar y diseñar casos de prueba para las historias, y los desarrolladores deben mostrárselos a los probadores al enviar El caso indica que se implementó la función de historia desarrollada y se puede iniciar la prueba;
en este momento, el evaluador realiza la prueba. Si el desarrollador no ha completado el desarrollo de la función en el momento en que la historia debe enviarse al evaluador para que la pruebe, el evaluador debe supervisar al desarrollador para que envíe la prueba. , En el caso de presentación o análisis retrasados, es necesario retroalimentar el proyecto para la reformulación de medidas.
3. La diferencia entre las pruebas ágiles y las pruebas tradicionales
1. El proyecto es equivalente al desarrollo y las pruebas en paralelo, y el tiempo total del proyecto es más rápido.
2. El módulo se envía rápidamente y la prueba es más opresiva.
3. División clara de las tareas del trabajo y alta eficiencia laboral.
4. La planificación del proyecto debe ser razonable; de lo contrario, habrá nuevas pruebas durante las pruebas, lo que aumentará la carga de trabajo.
5. Necesita hacer un seguimiento cuando encuentre un problema Las personas en el proyecto están ocupadas y el problema es fácil de olvidar.
6. Los problemas que requieren mucho tiempo o son difíciles de resolver y que tienen poco impacto en el proyecto generalmente se dejarán en la siguiente etapa para su solución.
7. Se encuentra que el BUG se puede resolver rápidamente y el impacto en la prueba de los módulos relacionados es relativamente pequeño.
8. Los cambios de versión son frecuentes, lo que afecta la velocidad de las pruebas.
9. Comuníquese más con el desarrollo.
10. Preste atención a la actualización de la versión.
11. Los probadores tienen que participar en casi todas las reuniones de todo el equipo del proyecto.
Cuarto, el proceso clave
en las pruebas ágiles En un sprint, el contenido del trabajo de los probadores se divide principalmente en cinco partes: análisis de historias de usuario, diseño y desarrollo de casos de prueba, ejecución y análisis de pruebas, integración continua de pruebas y pruebas de regresión. El trabajo de estas cinco partes continuará hasta el final del sprint, pero la hora de inicio es temprana y tardía, como se muestra en la siguiente figura.
Trabajo de análisis de historias de usuarios: las pruebas ágiles son para confirmar continuamente la realización de las necesidades del cliente. Por lo tanto, el análisis y la comprensión de las necesidades del usuario deben continuar, y las desviaciones se corrigen a tiempo, y se establecen puntos de aceptación y elementos de prueba razonables.
Trabajo de desarrollo de casos de prueba: diseñe casos de prueba, complete el desarrollo del código de prueba, prepare los datos de prueba y comunique las interfaces de software con los desarrolladores de manera oportuna para garantizar que los códigos de prueba puedan impulsar con éxito los códigos comerciales.
Trabajo de prueba y análisis: realice pruebas, cuente la cobertura de la prueba, analice los resultados de la prueba, comuníquese a tiempo si se encuentran errores y ayude a localizarlos.
Trabajo de integración continua: integre el código de prueba para asegurarse de que si la función actual está contaminada por el código de integración posterior, puede generar una alarma a tiempo y mejorar continuamente la línea de base funcional del producto de software.
Trabajo de prueba de regresión: después de completar todas las historias de usuario, realice una prueba de regresión completa en todos los códigos y confirme todas las correcciones de errores.
5. ¿Cómo pueden los probadores ágiles mejorar la productividad del desarrollo?
En las pruebas ágiles, los probadores son personas que ayudan a acelerar el progreso, es decir, personas que aumentan la productividad.
1. Si el defecto se descubre de manera oportuna, más fácil es modificarlo, por
ejemplo, se puede descubrir en un día, luego hay pocos cambios que ocurren en un día y es fácil encontrar el problema. Esto requiere una herramienta de prueba automatizada para encontrar defectos casi en tiempo real.
Si la integración continua se realiza una vez al día, el motivo del fallo de la prueba de integración será muy sencillo y fácil de localizar. Imagina un sistema de TV digital, desde autorización / codificación / encriptación / multiplexación / modulación // visualización ... mucha información es muy opaca, si la integración se hace en el último minuto, es básicamente imposible decir dónde está el problema.
2. Si la persona que encontró el defecto es la persona que hizo el defecto, más fácil será modificarlo.
Si los desarrolladores tienen herramientas de prueba automáticas, pueden ver rápidamente si hay algún problema con sus propios programas, en lugar de entregárselos a los probadores para que lo averigüen, es más fácil de modificar. Imagine un compilador: si las actividades de compilación se delegan a otros (es difícil imaginarlo ahora, este es el caso en las primeras etapas del desarrollo de software), la eficiencia será muy baja.
3. Cuanto menos tiempo invierta un desarrollador en encontrar y modificar errores, mayor será la eficiencia del desarrollo.
Otra inferencia es que es mucho más fácil agregar una función a un producto con cero defectos que a un producto con defectos.
Por lo tanto, la inferencia de 1 y 2 es mejorar la eficiencia del desarrollo.
6. ¿Qué hacen los testers ágiles?
- Promover continuamente la eficiencia y eficacia de las pruebas automatizadas.
- Promover continuamente la eficiencia y eficacia de la integración continua.
- Mejore continuamente el tiempo que tardan los desarrolladores en desarrollar funciones en lugar de ocuparse de los defectos (incluso si los mismos desarrolladores los hacen).
Por supuesto, existe la premisa de que cada software tiene diferentes objetivos y estrategias para sus requisitos / cronograma / calidad / costo. Los probadores ágiles no pueden ser egocéntricos y no pueden perseguir los efectos de la actividad de prueba de manera unilateral, sino que deben ayudar al equipo de desarrollo a lograrlo. Metas y estrategias.