Cómo introducir calidad en el proceso de Software

Sin embargo, corregir errores o implementar cambios en una etapa tan tardía introduce riesgos asociados con la reingeniería y puede significar que no se pueda lanzar a producción a tiempo. En un mundo de Despliegue Continuo, la capacidad de una organización para entregar rápidamente es ahora esencial para su éxito, especialmente en el comercio electrónico.

¿Y si hubiera otro enfoque que se centre en la calidad antes de que cualquier persona comience a codificar? ¿Un enfoque que promueva un equipo multifuncional y tenga como objetivo prevenir errores en lugar de corregirlos?

En este artículo, exploraremos algunas ideas para "incorporar" calidad a tu aplicación para reducir el riesgo de rehacer el trabajo, aumentar la comprensión del equipo y generar confianza en la implementación.

La calidad es responsabilidad del equipo

Un gran obstáculo para muchos equipos es asumir que la calidad es responsabilidad del equipo de QA. Incluso en proyectos ágiles, el QA a menudo se trata como una actividad aislada después de que se haya completado el desarrollo.

Eliminar barreras entre el negocio, los desarrolladores y el QA es fundamental para el éxito de un enfoque de calidad primero. En un escenario ideal, el QA ni siquiera se consideraría una entidad separada, sino más bien un aspecto intrínseco y general del proceso de desarrollo más amplio.

Considera, por ejemplo, la cantidad de personas invitadas a tus ceremonias ágiles típicas (daily, refinement, planning, etc)). Incluir a demasiadas personas podría desanimar a algunas personas a hablar, lo que aumenta el riesgo de malentendidos y la falta de intercambio de conocimientos. Reuniones más pequeñas y equipos en general fomentan la participación de todos los miembros del equipo.

De manera similar, verificar frecuentemente el estado del desarrollo en curso puede ser útil para gestionar las expectativas de las partes interesadas. Por ejemplo, si resulta que una función es más compleja de lo estimado originalmente, una rápida revisión puede ayudar a identificar obstáculos y reaccionar a cambios inesperados, incluso si eso significa excluirlo de la próxima versión de producción.

Ahora que tienes comunicación abierta, ¿qué pasos puedes tomar para fomentar la colaboración y trabajar hacia la responsabilidad del equipo en cuanto a la calidad?

Define la calidad al inicio

Definir tu estrategia de calidad temprano puede ayudar al equipo de entrega a identificar riesgos, aumentar su comprensión sobre cómo probar la aplicación y brindar oportunidades para evaluar el éxito de manera objetiva.

Sin embargo, tu definición de calidad no tiene que limitarse solo a los aspectos funcionales de la aplicación, como user friendly o la compatibilidad con dispositivos. Las plataformas de comercio electrónico que utilizan un Modelo Devops, por ejemplo, podrían incluir las métricas DORA en su definición de calidad para ayudar a lograr un sistema eficiente.

Hay varias perspectivas sobre la calidad, y puede ser abrumador tratar de entender y definir tus aspectos de calidad.

Sin embargo, un buen punto de partida es el "riskstorming". Ya existen muchos recursos excelentes disponibles para aprender sobre este juego, por lo que no los volveremos a cubrir aquí. Por el contrario, en el contexto de definir la calidad, es una herramienta útil que comienza llegando a un acuerdo sobre los aspectos de calidad más importantes de un sistema. De esta manera, el equipo tiene una comprensión común y expectativas acordadas sobre cómo ellos y sus clientes deben percibir la "calidad".

Dada la subjetividad de la calidad, idealmente la sesión debería involucrar a personas de diferentes disciplinas dentro de tu proyecto, al menos representantes del negocio y del desarrollo. De esta manera, tanto los aspectos empresariales como los técnicos se consideran por igual. Sin embargo, dado que el cliente es en última instancia el juez más capacitado para juzgar la calidad, también deberían estar involucrados.

Prueba tus expectativas de calidad

Ahora que tienes una definición acordada, considera qué riesgos o barreras pueden evitar que tú y tus clientes perciban esa calidad. Una vez identificados, puedes pensar en qué actividades de prueba son apropiadas para mitigarlos.

Una plataforma de comercio electrónico podría considerar la velocidad como una medida importante de calidad, donde las actualizaciones diarias de precios o existencias son esenciales para brindar una experiencia de usuario precisa. En ese contexto, examina el proceso responsable de actualizar esos datos y prueba cuellos de botella y riesgos de datos inválidos o inexactos.

De manera similar, si tu plataforma se utiliza principalmente en dispositivos móviles, los problemas de conectividad pueden afectar el rendimiento para el usuario final. Los equipos de entrega deben aprovechar los datos de uso real para comprender las limitaciones de los dispositivos de usuario y, por ejemplo, probar el sistema utilizando una conexión de red limitada para simular de la mejor manera posible la experiencia del usuario.

Independientemente de si utilizas exploratory testing charters o los test cases tradicionales, documentar cómo evaluarás tu aplicación como equipo es tanto un buen ejercicio de colaboración como una forma de aumentar la comprensión común de una función. También sirve como un acuerdo sobre el alcance de las pruebas, para comprender mejor cuándo puedes considerar que la función está lista para ser lanzada.

Evaluación continua de la calidad

En cualquier momento durante el desarrollo de una característica del sistema, pregúntate "¿cuál es el estado actual de calidad?". Si no puedes responder con confianza, estás perdiendo un ciclo de retroalimentación que podría llevar a problemas más adelante en el desarrollo, cuando podría ser demasiado tarde para reaccionar.

Permitir ciclos de retroalimentación rápida significa implementar mecanismos que permitan al equipo de entrega probar en cualquier etapa del desarrollo. En este contexto, "probar" no necesariamente significa tener una versión funcional del sistema, sino más bien exponer cualquier información disponible para la crítica. Incluso involucrar al delivery team desde el principio, como en reuniones de descubrimiento, puede ser beneficioso, donde su conocimiento del sistema se puede utilizar para revelar dependencias técnicas desde el principio y ayudar a determinar la viabilidad de una feature.

Holistic Testing Model es un ejemplo excelente de cómo podemos evaluar la calidad durante el desarrollo y después del despliegue.

En etapas posteriores del desarrollo, las herramientas que permiten comenzar las pruebas prácticas antes de enviar el código a un entorno en vivo pueden simplificar la corrección de errores. Por ejemplo, he utilizado AWS Amplify como plataforma para acceder a una vista previa utilizable de una aplicación web mientras los cambios aún están en revisión de código. Esto significa que cualquier error en el frontend se puede encontrar y corregir en la revisión de código misma y elimina cualquier riesgo de reingeniería si se hubiera encontrado ese error después de implementarse. De manera similar, pedir a un desarrollador de backend que me pase una compilación de desarrollo de un servicio web para ejecutarlo localmente me permite comenzar a probar las respuestas exitosas o fallidas de un endpoint y reportar problemas cuando es más fácil solucionarlos.

Incluir al cliente en ese bucle de información también es importante, y recientemente hemos empezado a enviarle una encuesta después del sprint demo.  Aunque ya participaban en la definición de los requisitos, recibir sus comentarios sobre la demo en sí nos permite evaluar su comprensión de lo que se presentó y ayudarnos a mejorar nuestras habilidades de presentación.

En cualquier caso, tratar de medir la calidad en el sentido tradicional de "bondad" podría resultar un esfuerzo desperdiciado. En su lugar, al definir tus aspectos de calidad, piensa en qué evidencia se necesita para ayudarte a discutir y evaluar su estado en cualquier momento dado.

Una receta para la calidad

La calidad es difícil de definir, y medirla lo es aún más. Sin embargo, cualquier proyecto de desarrollo de software que busque tomar en serio la calidad debe comenzar a considerar lo que esa "Q" en QA realmente significa para ellos.

Prepárate para una entrega exitosa al:

1. Cambiar tu mentalidad hacia la responsabilidad del equipo en cuanto a la calidad.
2. Colaborar para definir y comprender tus expectativas de calidad.
3. Probar y evaluar esas expectativas a lo largo del ciclo de desarrollo.

Es una receta simple, pero con ingredientes complejos y matizados. Con suerte, este artículo te ha brindado algunas ideas sobre cómo comenzar.

¡Feliz horneado!