Cómo integrar las pruebas de control de calidad en su proceso de desarrollo de software Tres pasos para una estrategia de prueba de software eficaz que garantice que su producto no se convierta en una responsabilidad
Por Chris Cardinal Editado por Jessica Thomas
Este artículo fue traducido de nuestra edición en inglés.
Las opiniones expresadas por los colaboradores de Entrepreneur son personales
Incluso los equipos de desarrollo más innovadores y mejor financiados se enfrentan a desafíos de software. Solo mire la falla de software imprevista reciente que retrasó un vuelo de prueba tan esperado y mantuvo temporalmente el rover de Marte Ingenuity en tierra.
Si puede suceder con decenas de millones de dólares invertidos y los ojos del mundo mirando, puede apostar a que le puede pasar a las nuevas empresas y las pequeñas empresas. Aunque es posible que no estén en el negocio de explorar mundos extraterrestres, su software, ya sea un producto en sí mismo o parte de un ecosistema de apoyo, puede ser igualmente crítico para la misión. Pero si la NASA ni siquiera puede evitar un lanzamiento fallido, ¿cómo pueden esperar las pequeñas empresas?
La respuesta es una estrategia de prueba de garantía de calidad completa y detallada. Es la única manera de asegurarse de que el software en el que invierte su tiempo, dinero y reputación (y el de sus inversores) pueda despegar con éxito.
Por qué las pruebas de control de calidad a menudo se quedan en el camino
Muchas empresas pasan por alto los procesos de prueba de control de calidad adecuados en aras de llevar productos innovadores al mercado rápidamente. Las nuevas empresas tienden especialmente a dejar las pruebas de software en un segundo plano, y por razones comprensibles: en primer lugar, la mayoría de las empresas nuevas quieren interrumpir. Su juego es moverse rápido, romper cosas y hacer olas. Están desarrollando e iterando rápidamente en su software. Y un proceso de prueba de control de calidad exhaustivo podría ralentizar ese impulso.
Es más, las pruebas de software pueden parecer como una cosa más que agregar a una lista de verificación en crecimiento. Los desarrolladores están ocupados y atascados regularmente con listas de responsabilidades y fechas límite de miles de kilómetros. Cuando las empresas asumen que los desarrolladores ocupados o los equipos de productos se encargarán de las pruebas, crean simplemente otra casilla de verificación en estas listas ya masivas. La mayoría de los desarrolladores y equipos de productos no tendrán la capacidad de verificar todos los detalles y ejecutar las pruebas de control de calidad tan a fondo como deberían.
Esto no sugiere que a los fundadores de startups y desarrolladores de software no les importe el software con errores. Han experimentado problemas de software antes y saben que no quieren quemar su reputación creando experiencias de usuario deficientes. Al mismo tiempo, no están acostumbrados a configurar un departamento de control de calidad o adaptar estrategias de prueba de software a sus ritmos cotidianos. Sin esas medidas y análisis, sin embargo, ponen a su empresa, e incluso a los usuarios, en algunos casos, en grave riesgo.
Relacionado: " Por qué las pruebas de control de calidad pueden ser un problema para su empresa "
El costo de restar prioridad a las pruebas adecuadas
Desde una perspectiva financiera, la falta de pruebas por parte de un equipo de control de calidad dedicado equivale a una mala asignación de recursos. Hacer que los desarrolladores ejecuten una estrategia de control de calidad es tremendamente caro, porque los desarrolladores tienden a recibir una buena paga. Esperar que dediquen su tiempo a realizar pruebas de control de calidad cuando podrían estar desarrollándose tiene poco sentido fiscal. (También, en términos generales, resienten el trabajo).
Otro riesgo tiene que ver con la marca y la calidad. Las empresas que lanzan productos insatisfactorios a menudo son mordidas por la mala prensa, las malas críticas y la mala reputación. Eso hace que sea mucho más difícil ganar dólares de inversión futuros o llevar con confianza más productos al mercado. Si el producto con errores genera un problema importante para el usuario, la falta de pruebas de software también podría convertirse en una responsabilidad legal.
Tomemos el conocido caso de ética informática de Therac-25 . La máquina fue diseñada para administrar radioterapia a pacientes con cáncer con la ayuda de una computadora a bordo. Mientras que los modelos exitosos anteriores se basaban más en el hardware para los controles de seguridad, sin embargo, Therac-25 se basaba en el software. Los desarrolladores lanzaron el producto en 1982, pero solo cinco años después, se recordó cuando los pacientes informaron haber sido "quemados" por la máquina. Resulta que Therac-25 expuso a seis pacientes a sobredosis de radiación, matando a cuatro y dejando a dos con heridas graves. Una revisión posterior de las agencias reguladoras expuso las pruebas de software inadecuadas como parte del problema.
Relacionado: " El curioso caso de la inteligencia artificial y la responsabilidad legal "
Por supuesto, como uno de los errores de software más desastrosos de la historia, Therac-25 es un ejemplo extremo de lo que puede salir mal. Pero destaca que incluso los pequeños errores en el software pueden causar problemas masivos. Aún así, muchas empresas no saben por dónde empezar a armar una estrategia de prueba de software eficaz. Los siguientes pasos pueden ayudar:
1.Hacer de las pruebas de control de calidad una prioridad en las etapas de planificación
La superposición de pruebas de control de calidad en una estrategia de desarrollo de software existente puede presentar desafíos importantes. Es más fácil agregar QA en las etapas iniciales, incluso si el juego final no es contratar a una persona, equipo o agencia subcontratada dedicada a QA. Realmente, tener un proceso consistente y estructurado es más de la mitad de la batalla cuando se trata de pruebas de control de calidad.
En mi empresa de desarrollo de software, comenzamos a integrar las pruebas en el proceso de desarrollo con historias de usuarios. Básicamente, estas son solo descripciones de alto nivel de requisitos específicos. Creamos historias de usuarios en cada nuevo proyecto para que todos tengan claras las expectativas. Estas historias de usuario incluyen criterios de aceptación objetivos que debemos cumplir antes de considerar la historia completa. Sin historias de usuario y criterios de aceptación, los requisitos del producto se vuelven problemáticos y mal definidos. Tener las historias de los usuarios en su lugar evita la falta de comunicación sobre cuándo un producto está realmente terminado y si está haciendo lo que se supone que debe hacer.
Considere el caso de un gerente de producto que escribe una historia de usuario que describe la función del producto, pero no identifica ningún criterio de aceptación. El ingeniero podría malinterpretar la historia del usuario, desarrollando un producto que no se ajusta a la visión prevista del gerente de producto. Sin nadie ni forma de confirmar que el producto ha cumplido con los requisitos iniciales, el producto sigue siendo aprobado sin ninguna garantía de que realmente vaya por buen camino. Los criterios de aceptación proporcionan un conjunto claro de expectativas con las que realizar la prueba.
2. Cree listas de verificación y planes de prueba de control de calidad con anticipación
En las primeras etapas de mi empresa, confiamos en nuestros desarrolladores (o peor aún, en nuestros clientes) para probar nuestros productos. Esto fue antes de que tuviéramos un equipo de control de calidad o cualquier tipo de procedimiento de prueba de software. Una noche, un cliente llamó para decir que su sitio era una página en blanco. Después de la investigación, descubrimos la raíz del problema: la compilación que implementamos solo funcionaría cuando las personas ya estaban conectadas al sitio. Aquellos que se desconectaron experimentaron un fracaso inmediato. Nuestro desarrollador solo había revisado brevemente el sitio mientras estaba conectado.
No era un buen aspecto para nuestra empresa en ese momento, pero la experiencia sirvió como un gran incentivo para instituir listas de verificación de pruebas de control de calidad. Después de todo, si hubiéramos pasado por un proceso de prueba, nunca hubiéramos implementado un sitio que se rompiera para casi todos los usuarios.
Los gerentes de producto deben implementar listas de verificación tanto previas como posteriores a la implementación para mantener todo funcionando como se espera. Si no está familiarizado con la práctica de las listas de verificación creativas y efectivas, eche un vistazo al libro de Atul Gawande The Checklist Manifesto . Gawande describe cómo las principales industrias, incluida la medicina, utilizan listas de verificación para evitar la complacencia y hacer cumplir la calidad. Al mismo tiempo, da buenos consejos cuando se trata de asegurarse de que una lista de verificación de prueba de software de control de calidad no se ahogue en detalles minuciosos y se vuelva insostenible.
Relacionado: " La lista de verificación de la Fuerza Aérea lo ayudará a construir un equipo duradero "
3. Configure una canalización para informar y realizar un seguimiento de los problemas.
Ningún proceso de prueba de control de calidad está completo sin un marco sólido para informar y rastrear problemas y correcciones. Los desarrolladores necesitan una forma conveniente de ver los errores informados por los evaluadores y los clientes y otros problemas, y realizar un seguimiento del progreso para solucionarlos.
Un rastreador de problemas como Jira, GitLab o GitHub puede mantener a todos al tanto de los problemas informados y las respuestas. GitHub en realidad tiene una herramienta de escaneo de código para alertar a los desarrolladores sobre problemas en su trabajo. Estas herramientas también mantienen un historial completo de la discusión sobre la historia del usuario o el error que se está trabajando. Esto asegura que siempre tendrá conocimiento heredado y el contexto del alcance completo del proceso de desarrollo e innovación.
No importa cuán excelente sea su equipo de desarrollo, simplemente no existe el código libre de errores. Pero una estrategia de prueba de control de calidad exhaustiva y detallada que se incluye en el proceso desde el principio puede ayudar a proteger su reputación y asegurarse de que sus inversiones valgan la pena.