En qué se diferencian las pruebas ágiles
En los proyectos tradicionales, a menudo estamos más acostumbrados a definir estrictamente las distintas etapas del ciclo de vida del desarrollo de software. Por ejemplo, comenzando con el desarrollo de un plan de lanzamiento y definición de requisitos y terminando con pruebas y lanzamientos retrasados. Para las pruebas, a menudo se divide en el papel de guardián en los proyectos tradicionales.
Para el líder del equipo, o la mayoría de las partes interesadas del proyecto, a menudo se espera que las pruebas asuman la responsabilidad del control de calidad del proyecto. Sin embargo, esto es difícil de lograr en proyectos tradicionales, porque las pruebas no pueden controlar cómo se escribe el código, ni pueden controlar a los desarrolladores para que prueben su código, pero se espera que todo el control de calidad se comprima y se complete con éxito en la fase de prueba después del desarrollo.
En los proyectos ágiles, los evaluadores ya no se sientan a esperar que llegue el trabajo, sino que buscan activamente formas de aportar valor a lo largo del ciclo de desarrollo: escriben casos de prueba para los requisitos con los usuarios, encuentran errores en los programas con los desarrolladores y se enfocan en usar métodos de prueba más amplios y flexibles. En Agile, los desarrolladores nunca se adelantan a los evaluadores, porque una característica "no está lista" hasta que se prueba.
| pruebas ágiles |
prueba tradicional |
|---|---|
| adaptabilidad |
Planificado |
| escenificado |
Persistente |
| Énfasis en la colaboración |
centrarse en los registros |
| Centrarse en los productos |
Centrarse en los errores |
| equipo completo |
Independencia inteligente |
Podemos resumir brevemente varias características de las pruebas ágiles:
- Se pone énfasis en probar el sistema desde el punto de vista del cliente, es decir, desde el punto de vista de los usuarios que utilizan el sistema.
- Concéntrese en probar de forma continua e iterativa las características recién desarrolladas, sin enfatizar la fase de prueba rigurosa del proceso de prueba tradicional.
- Se recomienda comenzar con las pruebas lo antes posible. Una vez que se puede medir cierto nivel del sistema, como proporcionar funciones de módulo, se deben iniciar las pruebas unitarias a nivel de módulo. Al mismo tiempo, a medida que se profundiza en la prueba, se continúa con la prueba de regresión para asegurar la corrección del contenido previamente probado.
desafío organizacional
A continuación, echemos un vistazo a los desafíos que enfrentarán el equipo de pruebas tradicional, los evaluadores e incluso todo el equipo del proyecto durante el proceso de transformación ágil.
- desafío cultural
La cultura organizacional puede afectar el éxito de los equipos ágiles. A medida que nos embarcamos en una transformación ágil, el cambio es generalizado y esto inevitablemente incluye conflictos de cultura organizacional. La cultura organizacional toma tiempo para desarrollarse y una vez establecida es difícil de cambiar. Durante este proceso, los miembros del equipo se resistirán más o menos a los cambios y, naturalmente, tendrán dudas cuando se encuentren con fallas.
Esto requiere que el equipo aprenda a introducir y aceptar el cambio, a reconocer su impacto negativo al enfrentar el cambio, a poder prever y aceptar el caos, y a tomar medidas para salir del caos. Agile parece tener una velocidad muy rápida, pero los cambios pueden ser graduales. Los nuevos equipos que adoptan Agile pueden implementar algunas prácticas nuevas lentamente, como el desarrollo basado en pruebas.
- composición del equipo
Los equipos de proyectos ágiles son multifuncionales. La diferencia entre un equipo ágil y un equipo multifuncional tradicional es que ágil está trabajando hacia la operación general del equipo, pero es inevitable que cada miembro tenga sus propios antecedentes, especialmente en las primeras etapas de formación del equipo. Los miembros de diferentes orígenes traen tanto desventajas como beneficios al equipo, como una posición poco clara de sus propios roles y mala comunicación entre los miembros. La ventaja es que los miembros de diferentes orígenes a menudo tienen un pensamiento complementario, especialmente para los evaluadores, los evaluadores en equipos ágiles sentirán que tienen características obvias de representar a los clientes y aportarán su influencia en el pensamiento de calidad a otros miembros del equipo.
Muchos equipos han planteado la cuestión de la proporción de probadores a desarrolladores en equipos ágiles. En lugar de centrarse en la escala, los equipos deberían preocuparse más por las habilidades de prueba que necesitan. Las necesidades de cada equipo son diferentes, especialmente para los equipos de proyectos ágiles. La forma en que operan Agile y DevOps permitirá que los profesionales del equipo rompan sus áreas técnicas y se dediquen a otras actividades. Por lo tanto, para los probadores y desarrolladores, se deben considerar más problemas más allá del rol. Esto puede reflejarse en los requisitos de personal al expandir el equipo y, al mismo tiempo, prestar atención al cultivo de habilidades multifacéticas de los miembros del equipo.
- proceso de migración
En el proceso de transformación ágil, hay muchos contenidos que no se pueden migrar bien al modelo ágil, aquí nos fijamos principalmente en los contenidos relacionados con las pruebas que necesitamos migrar y son propensos a tener problemas.
El primero son las métricas, que es un tema de debate. El valor generado por diferentes indicadores de medición es muy diferente. Es posible que los indicadores en los que desperdiciamos energía para rastrear solo representen algunos números al final, y no generarán otro valor adicional excepto para la evaluación, y no serán útiles para el progreso del equipo. Por lo tanto, elegir un indicador de medición adecuado y obtener un alto retorno de la inversión en medición es de gran ayuda para el equipo.
El seguimiento de defectos también es una parte relativamente contradictoria del proceso de transformación del proyecto del equipo ágil. Muchos practicantes ágiles creen que descubrir y reparar defectos en el proceso de desarrollo ágil de proyectos es un trabajo necesario para los desarrolladores. Después de descubrir defectos, se repararán de inmediato, por lo que no es necesario rastrear y registrar defectos. Para los probadores, a menudo usan el sistema de seguimiento de defectos para rastrear y administrar defectos, y el sistema de seguimiento de defectos no solo se usa para el seguimiento de defectos, sino que también puede registrar información más relevante, como prioridad, gravedad, estado, persona a cargo, casos de uso asociados, requisitos y descripciones de defectos y métodos de reproducción, etc. Podemos utilizar herramientas para simplificar el complicado trabajo de gestión de los proyectos tradicionales y lograr más y mejores objetivos de gestión.
automatización de pruebas
En Agile y DevOps, la automatización de las pruebas es imprescindible. Necesitamos usar medios automatizados para administrar las actividades de prueba clave y proporcionar la retroalimentación necesaria para el desarrollo. Echemos un vistazo a lo que se incluye en la automatización de pruebas y cómo hacerlo bien.
- pirámide de prueba
Antes de comenzar a probar el contenido de la automatización, veamos un modelo clásico de automatización de pruebas: la pirámide de pruebas.
El propósito del modelo de pirámide de pruebas es guiar al equipo para obtener el máximo valor de la automatización de pruebas con la mínima inversión. La pirámide muestra 3 niveles diferentes de pruebas automatizadas.
La capa más baja es la base, que se compone principalmente de pruebas orientadas a la tecnología, como pruebas unitarias y pruebas de compilación. Esta capa también representa la mayoría de las pruebas automatizadas. En esta capa, el aislamiento unitario de los casos de prueba es el mejor, el problema de posicionamiento y análisis es el más fácil y el costo de uso también es el más bajo.
La capa intermedia de la pirámide contiene la mayoría de las pruebas comerciales automatizadas que se utilizan para respaldar al equipo. Estas pruebas funcionales solo validan que estamos haciendo lo correcto.
La parte superior de la pirámide rara vez utiliza la automatización porque tiene la eficiencia operativa más baja, la complejidad de desarrollo más alta y el ROI de prueba más bajo.
- ¿Qué es la automatización de pruebas?
Hay muchos métodos de prueba automatizados mencionados anteriormente, como pruebas unitarias, pruebas API, etc. Estos son la parte de ejecución de la prueba, es decir, el método de prueba manual de alguna ejecución de prueba se convierte en un proceso de prueba automatizado a través de herramientas. Pero la automatización de pruebas no es solo la parte de ejecución, también incluye la adquisición del entorno para generar datos de prueba, ejecutar pruebas automatizadas y, finalmente, generar resultados y proporcionar retroalimentación. Si hay un problema con el resultado de la prueba, el sistema lo enviará automáticamente a la persona correspondiente. Finalmente, el informe de la prueba se genera automáticamente y los probadores pueden obtener directamente los resultados de la prueba. Todo este proceso de circuito cerrado es la composición final de la automatización de pruebas.
A continuación, veamos qué herramientas se proporcionan en DevCloud para ayudarnos a completar la práctica de automatización de pruebas:
- En términos de gestión de pruebas, proporciona la gestión general del proceso de prueba mencionada anteriormente, los casos de uso y los requisitos de prueba, y la línea punteada se puede trazar en dos direcciones.
- En términos de automatización, se proporcionan pruebas de aplicaciones móviles, pruebas de API y pruebas de rendimiento.
- Las pruebas de aplicaciones móviles proporcionan una prueba de compatibilidad sistemática para los paquetes de software de aplicaciones para detectar si los paquetes de software tienen problemas de compatibilidad y cuántos usuarios pueden cubrirse.
- Las pruebas de interfaz proporcionan herramientas de prueba de API automatizadas para realizar pruebas automatizadas de API mediante la escritura de casos de prueba.
- Las pruebas de rendimiento pueden simular algunos escenarios de gran simultaneidad para los usuarios, proporcionar una variedad de estrategias de presurización y pueden realizar un análisis estructural general sobre el rendimiento, el tiempo de respuesta y la capacidad de carga del usuario durante el proceso de prueba. Una vez completada la prueba, también proporciona un kanban visual multidimensional, que puede proporcionar una comprensión detallada de la situación de ejecución de la prueba.
Resumir
Finalmente, deseo que todos puedan encontrar el trabajo que desean, trabajar felices, vivir felices, tener un mundo amplio y lograr grandes logros. También resolví una ola de recursos de prueba de software publicados anteriormente [haga clic en la tarjeta pequeña al final del artículo para obtenerlo gratis], ¡no hay rutina para obtenerlo!
Básicamente cubre todos los puntos técnicos centrales de las pruebas de software: teoría de pruebas, conceptos básicos de Linux, conceptos básicos de MySQL, pruebas web, pruebas de interfaz, pruebas de aplicaciones, herramientas de administración, relacionadas con Selenium, pruebas de rendimiento, redes informáticas, principios de composición, estructuras de datos y algoritmos, problemas lógicos, recursos humanos, mapas cerebrales técnicos, etc. ¡La calidad es muy alta ! ! ! ¡Más que suficiente para entrevistas técnicas!
El documento completo tiene un total de 308 páginas , y definitivamente es poco realista mostrarles todo. Para no afectar su experiencia de lectura, solo se muestra una parte del contenido. Espero que lo entiendan. Espero que pueda ayudarlos a revisar antes de la entrevista y encontrar un buen trabajo, ¡y ahorrarles a todos tiempo buscando información en Internet para aprender!