¿Pruebas para Cumplimiento o para Calidad?
El mundo está lleno de software que cumple perfectamente con todos sus requisitos documentados, pero aun así no logra crear valor para sus usuarios.
Cuando estudié ingeniería de software —hace siglos— calidad significaba conformidad, es decir, ajustarse a los requisitos. También aprendí que la garantía de calidad implica todas las medidas tomadas para permitir, crear y verificar la calidad, y que las pruebas son un método clave de garantía de calidad.
Hoy en día, Wikipedia define pruebas como el acto de examinar los artefactos y el comportamiento del software bajo prueba mediante validación y verificación. Las pruebas se definen como una actividad, dejando abierto su propósito. Las definiciones que aprendí en la escuela de ingeniería son muy compatibles con la definición de Wikipedia para pruebas de cumplimiento: pruebas que determinan si un proceso, producto o servicio cumple con los requisitos de una especificación, estándar técnico, contrato o regulación. Curiosamente, ninguna de estas definiciones utiliza la palabra calidad en absoluto.
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
¿Qué es la calidad?
Hoy en día, evito la tentación de definir calidad excepto indirectamente a través de cuatro dimensiones: beneficios, funciones, procesos y experiencia. Pensemos en algo que todo el mundo conoce, por ejemplo, Paypal. La gente lo utiliza para transferir dinero en línea; esta es su función. Los beneficios que buscan son facilidad, seguridad y bajo costo. Usar PayPal implica varios procesos de usuario y el software guía al usuario a través de ellos. Las sensaciones, como felicidad, frustración o logro, que el usuario experimenta al usar Paypal conforman la experiencia. Sea lo que sea calidad, difícilmente puede existir sin estas cuatro dimensiones.
Las pruebas suelen centrarse en la conformidad funcional, es decir, comprobar que el software hace lo que dicen sus requisitos y no hace nada más. También puede haber requisitos no funcionales, como tiempos de respuesta, el número de transacciones paralelas gestionadas y la seguridad de los datos del usuario. Las normas y regulaciones, como SOC2 o GDPR, aportan requisitos adicionales, al igual que los acuerdos de Paypal con las compañías de tarjetas de crédito. Estos pueden tener poco que ver con las funciones reales y el valor del software, pero cumplirlos es un requisito previo para participar en el negocio.
La calidad va más allá de la mera conformidad. Para alcanzar ambos, consulta nuestra lista seleccionada de las mejores plataformas de pruebas de software
El mundo ideal
Los grandes testers aplican tanto una visión basada en el cumplimiento, que se centra en satisfacer los requisitos, como una visión basada en los resultados, que se centra en la consecución de los beneficios. En un mundo ideal, cumplir los requisitos documentados implicaría la obtención de los beneficios del usuario, pero el mundo rara vez es ideal. Incluso si el software fuera perfecto, los usuarios no lo son. La obtención de los beneficios depende en gran medida de las acciones del usuario, y las acciones del usuario dependen de cómo el software interactúa con el usuario y lo guía. Esto, a su vez, afecta la calidad de toda la experiencia. Estas características del software difícilmente pueden capturarse en los requisitos de cumplimiento o en los casos de prueba formales. Una vez más, en un mundo ideal, todos estos desafíos se resuelven lo suficientemente pronto con un diseño centrado en el usuario, pero el mundo está lejos de ser ideal, y el tester debe actuar como representante del usuario real.
Pruebas de cumplimiento vs. Pruebas orientadas a resultados
Las pruebas de cumplimiento y las pruebas orientadas a resultados requieren enfoques mentales distintos. Las pruebas de cumplimiento son como poner trampas: leer los requisitos, imaginar lo que podría salir mal y diseñar condiciones de prueba bajo las cuales el software probablemente falle. Las pruebas orientadas a resultados son más bien un acto de curiosidad: comprender lo que el usuario necesita lograr, imaginar todas las cosas que podría hacer, averiguar cómo debería reaccionar el software y luego probarlo.
El cumplimiento es un requisito previo para la calidad. En muchas industrias, cumplir con los requisitos formales de cumplimiento es incluso un requisito previo para participar en el negocio. También se pueden mitigar los riesgos de responsabilidad generando una prueba documentada de que el cumplimiento ha sido debidamente verificado. Yo tiendo a pensar que las pruebas de cumplimiento te ayudan a reducir el riesgo de fracaso y las pruebas orientadas a resultados te ayudan a aumentar la probabilidad de éxito.
