Creando una Estrategia de Calidad
Republicado con permiso del excelente blog de Kristin, thinkingtester.
En mi última publicación, presenté el concepto del modelo de madurez de calidad: una serie de comportamientos vinculados a atributos de calidad que ayudan a los equipos a alcanzar diversos atributos de calidad en su software.
Una de las cosas importantes a tener en cuenta es que adoptar un Modelo de Madurez de Calidad requiere que todo el equipo contribuya a la calidad.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
La calidad no es algo que se deba "lanzar al otro lado del muro" para los testers; más bien, es un objetivo que tanto desarrolladores como testers comparten.
¿Pero cómo lograr que todo el equipo se haga responsable de la calidad?
Una manera es mediante la creación de una estrategia de calidad. Este es un documento con el que todo el equipo está de acuerdo. Piénsalo como un contrato que describe cómo el equipo desarrollará, probará y liberará software de calidad.
Aquí, hablaré sobre algunas preguntas que quizás quieras responder en la estrategia de calidad de tu equipo.
Creación y Refinamiento de Historias
Pregunta: ¿Cómo decide el equipo qué historias trabajar?
Esto podría ser una decisión de todo el equipo o solo del product owner. O la priorización podría ser realizada por alguien externo al equipo.
Pregunta: ¿Quién refina las historias para prepararlas para el desarrollo?
Podría ser todo el equipo o un subconjunto del equipo. Idealmente, querrías al menos la participación del product owner, un desarrollador y un tester.
Proceso de Desarrollo
Pregunta: ¿Cómo decide el equipo quién trabaja en cada historia?
Puede que los desarrolladores elijan cualquier historia del tablero, o puede que cada desarrollador tenga historias en áreas funcionales específicas entre las que puede elegir.
En algunos equipos, los testers de software también trabajan en historias de desarrollo sencillas, como cambiar palabras o colores en una página web o agregar IDs de automatización para facilitar las pruebas automatizadas.
Pregunta: ¿Cómo se define que una historia está "Hecha"? ¿Se mide cumpliendo todos los criterios de aceptación de la historia? ¿Es obligatorio que el desarrollador agregue pruebas unitarias antes de que la historia se considere hecha? ¿Cómo sabes cuándo una funcionalidad está lista para ser probada?
En muchos equipos, se espera que el desarrollador haga una prueba inicial para verificar que lo que ha codificado está listo para más pruebas.
Transferencia de Funcionalidades
Pregunta: ¿Cómo se entregará una historia para ser probada?
En algunos equipos, esto se hace simplemente moviendo la historia a la columna de “Testing” en el tablero. En otros equipos, se requiere una ceremonia de entrega más formal, donde el desarrollador demuestra la historia funcionando y ofrece sugerencias para realizar pruebas adicionales.
Pregunta: ¿Quién despliega el código en el entorno de pruebas?
Parece una cosa trivial, pero en realidad puede ser causa de muchos malentendidos y pérdida de tiempo. Si el desarrollador cree que es responsabilidad del tester desplegar el código en el entorno de pruebas, y el tester asume que el desarrollador ya lo hizo, el tester podría empezar a probar y no darse cuenta de que el nuevo código falta hasta haber invertido mucho tiempo trabajando con la aplicación.
Pregunta: ¿Quién hará las pruebas?
En algunos equipos, los desarrolladores pueden tomar historias de pruebas sencillas para ayudar a mejorar la velocidad del producto, mientras que las historias más complejas quedan para los expertos en pruebas.
Creación del Plan de Pruebas
Pregunta: ¿Quién creará los planes de prueba? ¿Cómo se crearán? ¿Dónde se almacenarán los planes de prueba?
Algunos equipos pueden preferir hacer pruebas exploratorias ad hoc con documentación mínima. Otros equipos pueden tener sistemas elaborados de gestión de casos de prueba que documentan todas las pruebas del producto. Y hay muchas otras opciones intermedias.
Cualquiera que sea la opción, debe ser la adecuada para tu equipo y tu producto.
Pregunta: ¿Quién escribirá la automatización de pruebas?
En algunos equipos, los desarrolladores escriben las pruebas unitarias y los testers escriben las pruebas de API y de la interfaz de usuario. En otros equipos, los desarrolladores escriben tanto las pruebas unitarias como las de API y los testers crean las pruebas de interfaz de usuario. Aún mejor es que tanto los desarrolladores como los testers compartan la responsabilidad de crear y mantener las pruebas de API y de la interfaz de usuario.
De este modo, los desarrolladores pueden aportar su experiencia en gestión de código, mientras que los testers contribuyen con su conocimiento sobre lo que debe probarse.
Pregunta: ¿Quién realizará otros tipos de pruebas, como pruebas de seguridad, rendimiento, accesibilidad y experiencia de usuario?
Algunas empresas grandes pueden tener ingenieros dedicados a la seguridad y el rendimiento que se encargan de estas pruebas. En startups pequeñas, podría haber solo un equipo de desarrollo que deba encargarse de todo.
Herramientas de Prueba
Pregunta: ¿Qué herramientas se utilizarán para las pruebas manuales y automatizadas?
Seleccionar las herramientas de prueba es muy importante cuando se quiere que todo el equipo sea responsable de las pruebas. Los desarrolladores probablemente querrán usar herramientas que utilicen el mismo lenguaje que están usando para el desarrollo, porque esto minimiza el cambio de contexto que tendrán que hacer.
Mantenimiento de Pruebas
Pregunta: ¿Quién es responsable de mantener las pruebas?
Es sorprendente lo rápido que la automatización de pruebas puede quedar desactualizada. Un solo cambio de palabra en una página puede significar una prueba fallida. Idealmente, un equipo debería tener una política de “si lo rompes, lo arreglas”, donde las pruebas sean corregidas por la persona que integró el código que las rompió.
Si eso no es posible, al menos asegúrate de que todos en el equipo entiendan cómo funcionan las pruebas y cómo arreglarlas en una situación en la que se necesite una solución rápida.
Errores y Deuda Técnica
Pregunta: ¿Cómo se gestionan los errores detectados durante las pruebas? ¿Los discuten el desarrollador y el tester, los prioriza todo el equipo, o se registran en un backlog para ser revisados después?
A menudo es una buena idea corregir los errores tan pronto como se encuentran, porque el desarrollador ya está trabajando en esa sección del código.
Pregunta: ¿Cómo abordará el equipo la deuda técnica?
¿El equipo tiene un acuerdo para asumir cierta cantidad de deuda técnica por sprint? Algunos equipos tienen una política según la cual, cuando un desarrollador se queda sin historias para trabajar, retoma ítems de deuda técnica del backlog.
Lanzamientos
Pregunta: ¿Qué tipo de pruebas se realizarán antes de un lanzamiento? ¿Habrá un plan de pruebas de regresión que pueda ejecutar todo el equipo en conjunto? ¿Y las pruebas exploratorias?
Un equipo de alto desempeño que conozco se reúne para realizar pruebas exploratorias justo antes de lanzar una versión. Usando esta estrategia, han detectado errores complicados y los han solucionado antes de que salieran a producción.
Pregunta: ¿Cómo se lanzará el software?
En algunas empresas, hay un responsable de lanzamientos que se encarga de ejecutar el lanzamiento. En otras empresas, los integrantes del equipo se turnan para lanzar el software. Una técnica muy útil es la Implementación Continua (Continuous Deployment), donde el software se despliega automáticamente y las pruebas se ejecutan automáticamente para verificar el despliegue en cada entorno, ahorrando tiempo y esfuerzo a todos.
Lectura Relacionada: CÓMO EJECUTAR PRUEBAS DE HUMO DE API EN TU PIPELINE DE IMPLEMENTACIÓN CONTINUA
Mantenimiento
Pregunta: ¿Cómo medirán el éxito del lanzamiento?
Una vez que el software ha sido lanzado, es fácil para los equipos de desarrollo olvidarse de él; pero en ese momento es cuando los usuarios empiezan a utilizarlo. ¿Qué tipo de métricas podrías usar para medir el desempeño de tu producto? Podrías llevar un registro de los defectos reportados por los clientes, o revisar los registros en busca de errores inesperados.
Pregunta: ¿Cómo monitorizaréis la salud de la aplicación?
Sería buena idea tener alertas configuradas para poder enterarse de los problemas de la aplicación antes que sus usuarios.
Pregunta: ¿Qué tipos de comportamientos deberíais observar?
Las estrategias de calidad pueden ser tan variadas como los copos de nieve. Imagina las diferencias entre una pequeña startup de diez personas haciendo una app de chat móvil y una empresa de veinte mil personas que diseña software para aviones. ¡Estas dos empresas necesitarán estrategias muy diferentes!
Puedes diseñar una estrategia de calidad que funcione bien para tu equipo debatiendo estas preguntas juntos y redactando una estrategia con la que todos estén de acuerdo.
Para herramientas y tecnología que ayuden en vuestros procesos, revisa esta lista de las 10 MEJORES HERRAMIENTAS DE GESTIÓN DE DATOS DE PRUEBA.
