Resumen del libro Guía práctica para las pruebas en DevOps, Katrina Clokie

El libro explica cómo crear pruebas, no solo para detectar errores, sino también para evitar que ocurran. Realmente nos gustó, así que decidimos, como veteranos, apoyar la tradición de los resúmenes sobre Habré y presentar las tesis más interesantes.

Cómo han cambiado los enfoques para la organización de pruebas:

Cascada
Todo comenzó con las pruebas con la metodología Waterfall. Esta etapa se caracteriza por el hecho de que las pruebas son la actividad de un solo miembro del equipo (adivina quién). Nadie, excepto el probador, sabe algo sobre la estrategia de prueba y no tiene acceso a casos de prueba y listas de verificación. Las tareas vuelan a una orden como una pelota en un ping pong. Este período se caracteriza por largos lanzamientos.

Ágil
En el trabajo sobre la metodología Agile, las pruebas se convierten en responsabilidad de todo el equipo. Esto significa que no solo los evaluadores, sino también los desarrolladores encuentran y resuelven problemas. Esta fase se caracteriza por lanzamientos frecuentes y comentarios rápidos.

Devops
Ahora las pruebas se ven afectadas por el soporte, análisis, infraestructura y monitoreo. Los límites y la naturaleza de las pruebas están cambiando. La información ahora llega al equipo desde varios canales: monitoreo, solicitudes de servicios de soporte, informes analíticos. Al mismo tiempo, las pruebas deben ser confiables, pero no interferir con los lanzamientos rápidos.

Pruebas en la era de DevOps y CI

El autor afirma que DevOps es mucho más grande que CI. CI se centra en prácticas técnicas que aceleran la escritura de códigos (por ejemplo, sistema de control de versiones, pruebas unitarias, compromisos frecuentes) y DevOps, en cambios organizacionales (en particular, soporte para una colaboración más estrecha entre los tipos de trabajadores de entrega de software: analistas, soporte, equipo de desarrollo).

Sin Agile, no habría habido una cultura DevOps. Las personas deben pensar con flexibilidad para llegar a DevOps, cuyo objetivo principal es la fiabilidad y la frecuencia de los lanzamientos. Al mismo tiempo, el tema de las pruebas a menudo se pierde en los informes sobre DevOps.

La tesis principal de Katrina es que siempre debe probar y en cada etapa, desde el comienzo del trabajo en la tarea hasta el último compromiso de lanzamiento.

El volumen de trabajo es muy grande. Surge la pregunta de cómo organizar todas las pruebas y no volverse loco.

Donde comenzar las pruebas

• Comprenda cómo se organiza ahora el proceso de prueba en el proyecto.
• Organice una retrospectiva de las estrategias de prueba para todo el equipo y responda la pregunta de qué estamos probando ahora y por qué. Puede resultar que los participantes en un equipo respondan preguntas sobre el proceso de manera diferente, lo cual es incorrecto.

DevOps es más que solo pruebas flexibles. La ideología de DevOps implica un proceso perfectamente depurado que no solo despliega rápidamente una nueva versión en producción o retrocede a la anterior, sino también una comunicación igualmente depurada entre los comandos de desarrollo y operación.

10 criterios para ayudar a verificar si Agile está en sus pruebas:

1. Todo el equipo sabe claramente qué debe probarse mientras trabaja en una historia de usuario en particular.
2. Todos tienen una comprensión común de los requisitos comerciales.
3. Cuando discute la historia del usuario, tiene la respuesta a la pregunta "¿Cómo vamos a probar esto?"
4. Todos los miembros del equipo saben cómo realizar pruebas automáticas y dónde ver el resultado.
5. Debatirá de antemano qué automatizará y en qué nivel para no duplicar las pruebas en diferentes niveles. (Este artículo nos pareció el más importante).
6. Sus scripts de prueba están versionados y almacenados con el código fuente, ya que las pruebas son parte del software.
7. No tiene errores en la cartera de pedidos porque los está solucionando tan pronto como los encuentra, y no solo los registra.
8. Sin tiempo de inactividad en el trabajo del servidor CI.
9. Durante el rally, no está claro quién es el desarrollador y quién es el probador.
10. Su equipo puede evaluar la calidad del producto. Todos entienden cómo funciona el proceso de prueba en el proyecto.

Puede comprobarlo usted mismo usando el enlace : aquí el autor explica por qué estos puntos están resaltados y por qué son importantes.

Prácticas de colaboración en DevOps

Cuanto más se comunican las personas, más entienden lo que hacen los colegas y cómo se les puede ayudar. Por lo tanto, Katrina les ofrece hablar sobre las pruebas con más frecuencia. Hay varias formas de hacer esto:

• Revisión de la lista de verificación por analistas y soporte. Participar en pruebas tempranas puede mejorar la calidad del lanzamiento.
• Pruebas en parejas: probador y analista, soporte y desarrollador.
• Rotación de empleados entre equipos de desarrollo y soporte.
• Dojo (como parte del desarrollo de software) es un entorno donde las personas pueden aprender y practicar sus habilidades de desarrollo juntas: clases magistrales, intercambio de conocimientos.

Pruebas de producción

Las siguientes herramientas ayudarán a facilitar las pruebas en producción:

• Monitoreo configurado para que pueda encontrar e identificar fácilmente el problema,
• Alertas que utilizan varios canales de comunicación: por ejemplo, un mensaje al messenger si el servidor falla, o un correo electrónico cuando se agota la memoria,
• Analytics (por ejemplo, Google Analytics), que muestra cuántos usuarios usan la funcionalidad,
• El registro se hizo legible.
• Comentarios de los clientes: comentarios en la tienda, formularios de comentarios en aplicaciones web.

PS

Este resumen no incluyó muchas cosas interesantes. El libro está bien escrito, lo recomendamos a los evaluadores que estén pensando en realizar pruebas en proyectos de DevOps.

Finalmente, un par de enlaces útiles:

• El libro se puede comprar aquí .
• Enlace al video de rendimiento de Katrina de Agile Testing Days 2017.
• Enlace al blog de Katrina Kloki.