Introducción
Las pruebas de software se rigen por siete principios:
- Las pruebas muestran la presencia de defectos
- Es imposible realizar pruebas exhaustivas
- Pruebas tempranas
- Agrupación de defectos
- Paradoja de los pesticidas
- Las pruebas dependen del contexto
- Falacia de ausencia de errores
Es importante considerar que estos principios representan la base de nuestra práctica profesional, por tal motivo hay que leerlos, estudiarlos e identificar casos testigos que los representen para poder afirmar el concepto de cada uno de ellos y su alcance.
Principio 1: Las pruebas muestran la presencia de defectos
- ¿Que demuestran las pruebas? Con las pruebas podemos demostrar que hay defectos en el software que estamos testeando, es decir, demostramos su presencia. No obstante, también debemos hacer entender y/o comunicar que no está libre de ellos, y que por tal motivo hay que estar muy atento a cada nueva situación que ocurra.
- ¿Que permiten las pruebas? Con las pruebas podemos reducir la probabilidad de que se produzcan defectos ya sea por una evolución del software o por una corrección ante un defecto que se haya detectado. No obstante, aunque no se detecte ningún defecto, eso no da la certeza que el software que se esté desarrollando esté libre de defectos.
- ¿Cuál es el objeto principal de nuestra práctica? Nuestro objetivo es encontrar defectos/errores, y hay muchas maneras de hacerlo durante muchos momentos del ciclo de vida del desarrollo de software.
- ¿Cómo podemos perseguir dicho objetivo? Básicamente planificando nuestras pruebas para lograr encontrar el máximo de defectos posibles y así estar muy atentos.
El primer principio fundamental en el campo del software testing es que las pruebas tienen la capacidad de mostrar la presencia de defectos en el software. Esto implica que las pruebas no garantizan la ausencia de errores, pero son un método crucial para identificarlos y demostrar que existen.
Las pruebas son una herramienta esencial para identificar problemas, desde errores de codificación hasta deficiencias en la funcionalidad. Es importante comunicar que el software no está libre de defectos y que se deben abordar adecuadamente.
Al detectar y corregir los errores temprano en el ciclo de desarrollo, se disminuye el riesgo de que esos errores se propaguen y se conviertan en problemas costosos. Incluso si no se encuentran defectos, no se puede afirmar que el software esté completamente libre de ellos, ya que la ausencia de evidencia no es evidencia de ausencia.
Existen diversas estrategias y técnicas para lograr este objetivo a lo largo de todo el ciclo de vida del desarrollo de software. Desde pruebas unitarias hasta pruebas de aceptación, el enfoque está en identificar problemas antes de que lleguen a los usuarios finales.
Planificar implica, entre otras tareas, diseñar casos de prueba, establecer criterios de aceptación y llevar a cabo las pruebas de manera rigurosa. La planificación adecuada nos permite maximizar la detección de defectos y estar alerta a posibles problemas en el software.
Ejemplos relacionados con diferentes tipos de sitios web:
Sitio de comercio electrónico: Supongamos que estamos probando un sitio web de comercio electrónico y, durante las pruebas de compra, detectamos que el proceso de pago no funciona correctamente. Esto demuestra la presencia de un defecto en el software, lo que puede resultar en la pérdida de ventas si no se corrige a tiempo.
Sitio de venta de libros digitales: En este caso, al realizar pruebas en un sitio de venta de libros digitales, podríamos encontrar un error que impide a los usuarios descargar los libros que han comprado. Esta situación demuestra la existencia de un defecto que debe abordarse para garantizar una experiencia de usuario sin problemas.
Sitio de compra de productos de supermercado: Al probar un sitio web de compra de productos de supermercado, es esencial que las pruebas muestran la presencia de defectos, como problemas en la funcionalidad de agregar productos al carrito o errores en el cálculo de precios.
La identificación temprana de estos defectos es fundamental para brindar un servicio confiable a los clientes.
Debemos recordar que las pruebas son un proceso continuo a lo largo del ciclo de vida del desarrollo de software, y su objetivo es garantizar la calidad del producto final al identificar y corregir defectos en todas las etapas del desarrollo.
Principio 2: Las pruebas exhaustivas son imposibles
- ¿Podemos probar con todos los datos disponibles? Básicamente es imposible realizar nuestras pruebas con todos los conjuntos de datos, y de ahí a que haya técnicas que permiten y facilitan nuestra tarea de controlar la calidad del software que se está desarrollando.
- ¿Hay alguna factibilidad de probar todo? No sería factible probarlo todo salvo en casos triviales y que merezca el software ser sometido a prueba.
- ¿Hay alguna relación costo/tiempo? Por supuesto que sí, ya que efectuar pruebas completas costaría más tiempo y dinero, además del esfuerzo involucrado de los testers que participen.
- ¿Hay alguna relación con los recursos y los plazos del proyecto que se haya definido? Básicamente consumiría más recursos (tanto humanos como técnicos) y tiempo para probar todo y hasta podría no cumplir el plazo del proyecto, cosa que no sería deseable para nadie, menos para aquellos que están sponsoreando el mismo.
- ¿Hay algo que se puede considerar en cuanto a las pruebas exhaustivas? Nuestro foco debería estar centrado en priorizar las pruebas en función del riesgo.
El segundo principio esencial en el ámbito del software testing es la comprensión de que las pruebas exhaustivas son prácticamente imposibles de realizar. Esto se debe a diversas limitaciones y desafíos que enfrentamos en el proceso de evaluación del software. Vamos a explorar en detalle las razones detrás de esta afirmación y cómo podemos abordar esta realidad en la garantía de calidad del software.
Los sistemas de software son complejos y tienen una variedad casi infinita de posibles entradas y situaciones de uso. Esto hace que la idea de probar todo sea irrealizable.
A menos que estemos tratando con sistemas extremadamente simples y triviales, no es factible probar todo. La diversidad de casos posibles haría que las pruebas fueran inmanejables y consumiría recursos de manera insostenible.
Definitivamente, existe una relación directa entre el intento de pruebas exhaustivas y los costos asociados. Realizar pruebas completas llevaría mucho más tiempo y recursos, lo que no es viable en la mayoría de los proyectos de desarrollo de software.
Intentar pruebas exhaustivas podría superar los recursos disponibles y extender los plazos del proyecto. Esto sería perjudicial tanto para el equipo de desarrollo como para los patrocinadores del proyecto.
En lugar de intentar pruebas exhaustivas, nuestro enfoque debe centrarse en la priorización de pruebas en función del riesgo. Esto implica identificar las áreas críticas del software, los posibles problemas que podrían surgir y enfocar nuestros esfuerzos de prueba en esas áreas. Utilizar técnicas como la matriz de riesgo nos ayuda a dirigir nuestros recursos de manera efectiva.
Ejemplos relacionados con diferentes tipos de sitios web:
Sitio de comercio electrónico: En un sitio de comercio electrónico, sería imposible probar exhaustivamente todas las combinaciones posibles de productos, métodos de pago y condiciones de entrega. En su lugar, se pueden priorizar las pruebas en las funcionalidades clave, como la navegación, el proceso de compra y el pago en línea.
Sitio de venta de libros digitales: Cuando se trata de un sitio de venta de libros digitales, no se puede evaluar exhaustivamente cada posible libro y su compatibilidad con todos los dispositivos. En su lugar, se pueden enfocar las pruebas en aspectos como la descarga de libros, la visualización y la seguridad de la plataforma.
Sitio de compra de productos de supermercado: En un sitio de compra de productos de supermercado en línea, probar todas las combinaciones de productos y sus interacciones sería una tarea imposible. En su lugar, se pueden priorizar las pruebas en la funcionalidad de búsqueda, la gestión del carrito de compras y la seguridad de las transacciones.
La clave es entender que las pruebas no pueden abordar todas las posibles situaciones, pero deben concentrarse en las áreas de mayor riesgo y relevancia para garantizar la calidad del software de manera efectiva.
Principio 3: Pruebas tempranas
- ¿Cuándo iniciar el testing? Nuestro testing debe iniciarse lo antes posible, y cuanto más temprano mejor. Hay que tener en cuenta que a veces se puede y otras no, y que además mucho tiene que ver la madurez del tester y del propio equipo para llevar a cabo testing temprano.
- ¿En que momento convendría más realizar pruebas? Durante las primeras fases del SDLC sin lugar a dudas ya que son menos costosas. Los desarrolladores tardarán menos tiempo y esfuerzo en corregir los defectos, ya que sólo hay que modificar una pequeña parte del módulo.
Iniciar las pruebas lo antes posible en el ciclo de vida del desarrollo es crucial para detectar y corregir defectos de manera eficiente.
Cuanto más temprano se comience, mejor. Sin embargo, se debe tener en cuenta que la posibilidad de realizar pruebas tempranas puede depender de la madurez del equipo de desarrollo y del tester. En entornos ágiles, la integración de pruebas desde el principio es más factible.
En etapas tempranas, los costos asociados con la corrección de defectos son menores, ya que se pueden abordar antes de que el software se vuelva más complejo.
Ejemplos relacionados con diferentes tipos de sitios web:
Sitio de comercio electrónico: Imaginemos un sitio de comercio electrónico que está en proceso de desarrollo. Si esperamos hasta las etapas finales del desarrollo para comenzar las pruebas, es probable que se pasen por alto errores críticos en el proceso de compra. Iniciando las pruebas temprano, podemos identificar y corregir problemas como la falta de funcionalidad de pago o errores en la visualización de productos de manera más efectiva.
Sitio de venta de libros digitales: En un sitio de venta de libros digitales, iniciar las pruebas tempranas nos permite detectar problemas en la gestión de descargas, la compatibilidad de dispositivos o problemas de seguridad antes de que se conviertan en obstáculos importantes para los usuarios.
Sitio de compra de productos de supermercado: En un sitio de compra de productos de supermercado en línea, comenzar las pruebas en las primeras fases del desarrollo puede ayudar a garantizar que la funcionalidad de búsqueda, la gestión del carrito y la seguridad de las transacciones se implementen correctamente desde el principio.
La ventaja de las pruebas tempranas es que los problemas se abordan cuando son más fáciles de corregir y, en última instancia, resulta en un producto de software de mayor calidad. Esta práctica también es coherente con las metodologías ágiles, donde las pruebas son una parte integral del ciclo de desarrollo desde el principio.
Principio 4: Agrupación de defectos
- Principio conocido como «principio de Pareto», ya que se trata de la regla 80/20, donde se define que el 80% de los defectos se detectan en aproximadamente el 20% de los módulos de un sistema y el 20% restante se distribuye entre el 80% restante de los módulos. Esto significa que unos pocos módulos contienen la mayoría de los defectos de un gran sistema.
Este principio se relaciona directamente con la asignación eficiente de recursos en las pruebas y cómo priorizar la detección de defectos en un sistema de software.
Principio de Pareto: El «principio de Pareto» es una observación empírica que se ha aplicado en diversas áreas, incluido el software testing. En el contexto de las pruebas, se refiere a la idea de que la mayoría de los defectos se concentran en un subconjunto limitado de módulos o componentes del sistema.
Priorización de esfuerzos: Reconociendo que la mayoría de los defectos se encuentran en un pequeño número de módulos, los esfuerzos de prueba deben priorizarse en estos módulos críticos. Esto implica centrar la mayor parte de las pruebas en áreas de alto riesgo y probabilidad de defectos.
Eficiencia en pruebas: Al enfocar los recursos de prueba en los módulos más críticos, se maximiza la eficiencia en la detección de defectos. Esto significa que se pueden identificar y corregir los problemas más graves en un sistema antes de abordar los módulos menos críticos.
Ejemplos relacionados con diferentes tipos de sitios web:
Sitio de comercio electrónico: Si estamos probando un sitio de comercio electrónico, podemos aplicar el principio de Pareto identificando los módulos más críticos, como el proceso de pago y el carrito de compras. La mayoría de los defectos que pueden afectar la experiencia del usuario se encuentran en estas áreas clave.
Sitio de venta de libros digitales: En un sitio de venta de libros digitales, los módulos que gestionan la descarga de libros y la compatibilidad de dispositivos son críticos. Enfocar nuestras pruebas en estos módulos puede ayudar a garantizar que los usuarios puedan acceder a sus libros sin problemas.
Sitio de compra de productos de supermercado: En el contexto de un sitio de compra de productos de supermercado en línea, los módulos relacionados con la búsqueda de productos y la gestión del carrito son esenciales. La mayoría de los defectos que pueden afectar la experiencia de compra se encontrarán en estas áreas.
La aplicación del «principio de la agrupación de defectos» permite una asignación más eficiente de recursos y una detección más efectiva de problemas en el software. Esto es fundamental para garantizar que los esfuerzos de prueba se concentren en las áreas que tienen el mayor impacto en la calidad del producto final.
Principio 5: Paradoja de los pesticidas
- Luego de realizar varias iteraciones de pruebas planificadas y acordadas previamente con el equipo, la mayoría de los defectos se habrán corregido y la zona «caliente de defectos» se habrá saneado por así decirlo. No obstante es posible que los testers no se fijen en otras áreas que pudieran estar de alguna manera afectadas por los defectos antes mencionados.
- Para estar atentos a esta situación de problema y darle una solución, los testers deben revisar y modificar los casos de prueba con cierta frecuencia, ya que de esa manera ayuda a encontrar nuevos defectos. Esto significa lo siguiente, el caso de prueba es uno de los tantos artefactos de trabajo que debemos mantener actualizado por muchas razones, una de ellas es para cubrir este principio.
Sin embargo, esto puede llevar a una falsa sensación de seguridad, ya que es posible que los testers no se enfoquen en otras áreas que puedan haber sido afectadas de alguna manera por los defectos corregidos anteriormente.
Para abordar esta paradoja y evitar la complacencia en las pruebas, es esencial que los testers revisen y modifiquen los casos de prueba con regularidad. Los casos de prueba son uno de los artefactos de trabajo más importantes en el proceso de pruebas, y mantenerlos actualizados es fundamental por varias razones, una de las cuales es cubrir este principio. Aquí están los puntos clave de este principio:
- Falsa sensación de seguridad: Tras corregir los defectos identificados en iteraciones anteriores de pruebas, es posible que los testers crean que han cubierto todas las áreas críticas y que el software es libre de defectos. Sin embargo, esta confianza puede llevar a la omisión de otros posibles problemas.
- Necesidad de revisión y adaptación: Para evitar la Paradoja de los pesticidas, los testers deben ser proactivos al revisar y modificar los casos de prueba con regularidad. Esto implica actualizar los escenarios de prueba, identificar nuevos casos de prueba basados en riesgos emergentes y mantener la relevancia de las pruebas a medida que el software evoluciona.
Ejemplos relacionados con diferentes tipos de sitios web:
Sitio de comercio electrónico: Supongamos que estamos probando un sitio de comercio electrónico y, durante las primeras rondas de pruebas, se descubren defectos en el proceso de pago. Después de corregir estos defectos, sería un error asumir que no hay otros problemas. Los testers deben continuar revisando y adaptando sus casos de prueba, por ejemplo, para abordar problemas de seguridad que puedan surgir debido a cambios en la plataforma.
Sitio de venta de libros digitales: En un sitio de venta de libros digitales, es importante no confiarse después de solucionar problemas conocidos, como problemas de descarga. Los testers deben actualizar sus pruebas para asegurarse de que nuevas funcionalidades, como la integración de una biblioteca virtual, funcionen correctamente y no introduzcan nuevos defectos.
Sitio de compra de productos de supermercado: En el contexto de un sitio de compra de productos de supermercado en línea, es vital revisar y adaptar los casos de prueba incluso después de solucionar problemas evidentes, como errores en la gestión del carrito de compras. Cambios en la interfaz de usuario o en la base de datos, por ejemplo, pueden tener un impacto inesperado en la funcionalidad y deben abordarse con pruebas actualizadas.
La Paradoja de los pesticidas destaca la importancia de mantener la vigilancia en las pruebas y ajustar constantemente los enfoques para garantizar la calidad del software a medida que evoluciona. Este principio subraya la necesidad de mantener una mentalidad de mejora continua en el proceso de pruebas.
Principio 6: Las pruebas dependen del contexto
- ¿Cuánto de verdad habrá acá? Básicamente mucho ya que ciertamente el enfoque de las pruebas será diferente según el contexto en el que nos tengamos que manejar con nuestro testing. De hecho y para ponernos a pensar, hacer el testing de una aplicación móvil no es lo mismo que hacer el testing de una aplicación de escritorio ni hacer el testing de unos servicios web ni hacer el testing de concurrencia en un sitio de comercio electrónico ni hacer un testing del comportamiento que tiene una aplicación en relación a su usabilidad y accesibilidad.
- ¿Tiene este principio relación con el concepto de pérdidas? Por supuesto que sí, ya que cuanto mayor sea la posibilidad de pérdida (sea de imagen, económica o humana), más tiempo habrá que invertir en probar el software antes de implantarlo.
La estrategia de pruebas y enfoque variará significativamente según el contexto en el que se apliquen. Ciertamente, la verdad de este principio es innegable, ya que el enfoque de las pruebas será diferente en función del entorno, el tipo de aplicación y los riesgos asociados.
Las aplicaciones críticas, como sistemas médicos o de control aéreo, requerirán una estrategia de pruebas mucho más rigurosa que aplicaciones menos críticas, como una aplicación de entretenimiento.
Ejemplos relacionados con diferentes tipos de sitios web:
Sitio de comercio electrónico: En un sitio de comercio electrónico, las pruebas se centrarán en aspectos críticos, como la seguridad de las transacciones y la disponibilidad del sitio. En un contexto de alto riesgo, donde las pérdidas económicas podrían ser significativas en caso de un fallo, se requerirán pruebas exhaustivas y continuas para garantizar la integridad de la plataforma.
Sitio de venta de libros digitales: En el caso de un sitio de venta de libros digitales, las pruebas se enfocarán en la funcionalidad y la experiencia del usuario. La prioridad será garantizar que los usuarios puedan acceder y descargar los libros sin problemas, ya que esto afecta directamente la satisfacción del cliente.
Sitio de compra de productos de supermercado: En un sitio de compra de productos de supermercado en línea, la usabilidad, la capacidad de búsqueda y la precisión en el cálculo de precios serán áreas críticas para las pruebas. Las pérdidas en términos de tiempo y frustración del usuario pueden ser considerables si estas áreas no se prueban adecuadamente.
En resumen, el principio de que las pruebas dependen del contexto subraya la necesidad de adaptar la estrategia de pruebas a las particularidades de cada proyecto y su entorno. La evaluación de riesgos y la consideración de posibles pérdidas desempeñan un papel crucial en la determinación de cuánto esfuerzo y recursos se deben invertir en las pruebas.
Principio 7: Falacia de ausencia de errores
- Primero y principal es conveniente saber el concepto de falacia: Una falacia es, como señala Irving Copi (Introducción a la lógica – Irving Copi y Carl Cohen / 3.1. ¿Que es una falacia?), un error de razonamiento, un argumento incorrecto, pero psicológicamente persuasivo. Algunos sinónimos son: engaño, mentira, falsedad.
- ¿Encontrar y corregir defectos es la clave? Aquí está el punto de este principio ya que existe la creencia errónea por cierto de que encontrar y corregir defectos es la clave del éxito de un software/sistema, y que un software que presenta mínimos errores no está necesariamente listo para implantarse. Hay que pensar y discutir y debatir con el equipo de proyectos que también debe satisfacer las necesidades de la empresa, y acompañarla.
En este contexto, se utiliza para destacar la idea errónea de que la corrección de defectos es suficiente para garantizar la calidad del software.
El éxito de un software no solo se basa en su falta de errores, sino en su capacidad para satisfacer las necesidades del negocio y los usuarios.
Ejemplos relacionados con diferentes tipos de sitios web:
Sitio de comercio electrónico: En un sitio de comercio electrónico, es un error asumir que un software con muy pocos errores está listo para la implementación. La calidad de un sitio de comercio electrónico no solo se mide por la ausencia de errores, sino por su capacidad para procesar transacciones eficientemente, brindar una experiencia de usuario intuitiva y satisfacer las necesidades de los clientes.
Sitio de venta de libros digitales: En un sitio de venta de libros digitales, corregir todos los errores conocidos no garantiza su éxito. La plataforma debe ser capaz de gestionar adecuadamente la descarga de libros, ofrecer una amplia gama de títulos y mantener la seguridad de los datos de los usuarios. Estos factores son igualmente críticos para el éxito del software.
Sitio de compra de productos de supermercado: En el contexto de un sitio de compra de productos de supermercado en línea, la corrección de errores en la funcionalidad del carrito de compras no es suficiente. El software debe ofrecer una interfaz fácil de usar, una búsqueda eficaz de productos y un proceso de pago seguro para satisfacer las necesidades de los clientes.
Este principio destaca la importancia de no centrarse exclusivamente en la corrección de defectos, sino en el logro de los objetivos comerciales y la satisfacción de los usuarios. La calidad del software se mide por su capacidad para cumplir con éxito sus funciones y no solo por la ausencia de errores. Esto enfatiza la necesidad de una visión más amplia en el proceso de pruebas y desarrollo de software.
Fuente de inspiración
1. Fundamentos del Proceso de Pruebas > 1.3. Siete Principios de la Prueba
Pag 24 – Programa de Estudios del ISTQB CTFL v3.1.
