Fundamentos de las pruebas de software

Las pruebas de software abarcan muchos dominios y sectores. Cada proyecto plantea un reto nuevo. Antes de empezar a probar, entiende la perspectiva del cliente y el dominio. Es posible que necesites métodos de prueba distintos en cada proyecto. Por eso, comprender bien los fundamentos es el primer paso para lograr buenos resultados.

¿Por qué son necesarias las pruebas de software?

El equipo de desarrollo puede introducir errores, defectos o fallos sin intención. El software moderno es complejo y los malentendidos pueden dar lugar a lógica y código incorrectos.

Las pruebas detectan fallos para que se puedan corregir y mejorar la calidad del software. El objetivo es desarrollar y entregar aplicaciones libres de defectos. Cuando una empresa acuerda desarrollar software para un cliente, los requisitos legales, contractuales y del sector determinan cómo se realiza el trabajo. Una empresa comprometida con la calidad incluye las pruebas entre sus buenas prácticas.

Es difícil determinar cuántas pruebas son suficientes. Una planificación cuidadosa y casos de prueba bien diseñados hacen posible entregar software de alta calidad.

¿Quién realiza las pruebas de software?

¿Quién debe probar el software? Quienes programan suelen revisar su código varias veces antes de entregarlo. Aun así, pueden quedar defectos porque cuesta ver los propios errores.

Quien realiza las pruebas adopta una perspectiva imparcial desde el punto de vista del cliente y se centra en las especificaciones y los requisitos. Esto permite descubrir aspectos que el equipo de desarrollo pasó por alto. Por eso las pruebas siempre deben estar a cargo de personal independiente.

Separar los equipos de desarrollo y pruebas también tiene desventajas. Pueden surgir problemas de comunicación. Quienes desarrollan pueden descuidar la revisión del código si consideran que la calidad es responsabilidad del equipo de pruebas, lo que aumenta la carga de trabajo de este último.

A veces las personas que desarrollan software prueban el trabajo de sus colegas. Este enfoque se conoce como pruebas entre compañeros (buddy testing). Todo equipo de desarrollo debe contar con personal dedicado a las pruebas y, por lo general, cada proyecto tiene al menos un equipo dedicado. Algunas empresas crean equipos separados para pruebas de usabilidad, rendimiento, seguridad y otros tipos. Otras contratan empresas especializadas, profesionales independientes o consultores.

¿Qué se debe probar?

Entiende los requisitos del proyecto y las condiciones reales en las que se usará el software. Esto te ayuda a decidir qué probar y a diseñar una estrategia de pruebas adecuada.

Abrir el diagrama a tamaño completo ↗

¿Qué se debe probar?

¿Cuándo se realizan las pruebas?

Empezar a probar pronto ayuda al equipo de desarrollo a terminar a tiempo y ahorra tiempo, dinero y esfuerzo. Los defectos encontrados al final pueden ser costosos de corregir. Divide el desarrollo en etapas y prueba el trabajo de cada etapa antes de avanzar. Esto facilita una entrega puntual y mejora los resultados. La integración también resulta más sencilla cuando cada módulo ya se ha probado de forma independiente frente a sus especificaciones.

¿Con qué frecuencia conviene probar?

Realiza pruebas a la par del desarrollo y busca tantos defectos como sea posible en las primeras fases. La frecuencia de las pruebas depende del nivel de calidad que necesites. Detectar problemas temprano permite ajustar el diseño mientras hacerlo es más fácil y económico. Los cambios importantes se vuelven difíciles y costosos más adelante.

Abrir el diagrama a tamaño completo ↗

¿Con qué frecuencia conviene probar?

¿Qué son los estándares de pruebas de software?

Los estándares de pruebas importan tanto a quienes compran software como a quienes lo producen. Los clientes invierten en software y quieren tener la seguridad de que su calidad justifica la compra.

Todas las empresas de buena reputación rigen la calidad de sus productos mediante estándares aprobados públicamente. Cumplir esos estándares ofrece garantías sobre el producto y su comportamiento esperado. Así, los clientes pueden confiar en que compran software que cumple el estándar adecuado.

Para quienes producen software, los estándares ayudan a mejorar el producto final. Una vez que la empresa elige sus estándares, puede aprovechar esa base en otros proyectos sin empezar de cero. Muchos estándares ayudan a evaluar la calidad y mejorar la eficacia de las pruebas. Sin embargo, ningún estándar abarca por sí solo todos los aspectos de las pruebas de software.

Pueden orientar tu trabajo tanto los estándares que incluyen las pruebas entre un conjunto más amplio de requisitos como los que se dedican específicamente a ellas.

¿Qué es la facilidad de prueba del software?

La facilidad de prueba, o testabilidad, indica qué tan fácil es probar un sistema de software. Evalúala pronto para estimar los recursos necesarios. Las pruebas descubren defectos y evaluar la testabilidad ayuda a identificar áreas en las que podrían quedar ocultos. Una testabilidad alta facilita las pruebas. Una testabilidad baja exige más esfuerzo. Ten en cuenta los siguientes factores.

1. Controlabilidad. Necesitas controlar el proceso de pruebas para poder optimizarlo.
2. Observabilidad. El comportamiento y los factores que afectan al resultado deben ser visibles para que los puedas probar.
3. Disponibilidad. Necesitas acceso al sistema para probarlo.
4. Simplicidad. Un diseño coherente, funciones sencillas y prácticas de programación claras reducen la complejidad de las pruebas. Cuanto más complicado sea el software, más difícil será probarlo.
5. Estabilidad. Los cambios frecuentes en el diseño pueden interrumpir las pruebas.
6. Información. La eficiencia de las pruebas depende en gran medida de la información disponible sobre el software.

Ten presentes estas relaciones entre testabilidad y calidad.

1. Una mayor testabilidad favorece mejores pruebas y menos defectos.
2. Una menor testabilidad puede reducir la calidad de las pruebas y dejar más defectos en el sistema.

Verificación y validación de software

La verificación y la validación describen distintos tipos de análisis. La validación pregunta si estás construyendo el sistema adecuado. ¿Cumple los requisitos del cliente?

La verificación pregunta si estás construyendo el sistema correctamente. Se centra en la calidad de la ingeniería y en el cumplimiento de los estándares exigidos.

La validación comprueba que las especificaciones respondan a las necesidades del cliente. La verificación comprueba que el desarrollo siga los estándares de calidad y las prácticas de ingeniería de la organización.

Abrir el diagrama a tamaño completo ↗

Verificación y validación de software

Algunos enfoques incluyen la verificación en todas las fases del desarrollo, pero concentran la validación al principio y al final, durante el análisis de requisitos y las pruebas de aceptación. En la práctica es difícil seguir ese enfoque. Cuesta recopilar todos los requisitos del cliente al inicio y suelen cambiar una vez que empieza el desarrollo. Los propios equipos de desarrollo también pueden pedir cambios. Realiza tanto la verificación como la validación durante todo el desarrollo para responder a esa realidad.

Quienes realizan las pruebas utilizan la verificación y la validación, o V&V, para examinar diferentes aspectos de la calidad del software.

Pruebas y depuración de software

Las pruebas y la depuración tienen propósitos diferentes. Las pruebas revelan defectos. La depuración empieza después de encontrar un defecto y elimina su causa.

Cuando el equipo de pruebas informa de un defecto, el equipo de desarrollo investiga su causa raíz. Examina los módulos relacionados, localiza el problema en el código y lo corrige. La depuración identifica y resuelve la causa paso a paso.

Antes de intentar corregir un defecto, comprende sus posibles causas. Depurar sin información suficiente puede introducir otro defecto en un módulo conectado. Evita probar cambios sin un método. Después de aplicar la corrección, devuelve el trabajo al equipo de pruebas para que compruebe el módulo a fondo.

1. Las pruebas descubren defectos. La depuración localiza y corrige sus causas.
2. Las pruebas son una parte importante del desarrollo. La depuración se ocupa de los defectos que revelan las pruebas.
3. Las pruebas empiezan en las primeras etapas del desarrollo. La depuración comienza cuando se informa de un defecto.
4. Las pruebas incluyen la verificación y la validación (V&V). La depuración investiga y corrige la causa del defecto.

¿Qué es un defecto?

Un defecto es una desviación de la especificación de requisitos de software. Los defectos pueden aparecer en el código o en el diseño y producir resultados incorrectos al ejecutar el programa.

1. Al código con muchos defectos se le suele llamar código con fallos.
2. Un informe de defecto describe en qué consiste el problema.
3. Las herramientas de seguimiento de defectos permiten registrar y seguir los defectos de un sistema.
4. Una técnica de prueba consiste en introducir defectos a propósito en el código. Se observa el resultado para comprobar que el sistema responda como se espera ante esos problemas.

Abrir el diagrama a tamaño completo ↗

¿Qué es un defecto?

¿Qué significan la gravedad y la prioridad?

La gravedad describe el impacto de un defecto en el sistema. Las siguientes categorías clasifican ese impacto.

1. Crítica. La aplicación no puede funcionar correctamente debido a un fallo del sistema o a la corrupción de datos. El usuario no puede continuar.
2. Alta. El sistema puede fallar, pero el usuario dispone de otra forma de obtener el resultado sin capacitación adicional. Estos defectos son menos graves que los críticos.
3. Moderada. El sistema sigue funcionando, pero produce resultados incorrectos o contradictorios.
4. Baja. El defecto no causa fallos en el sistema ni afecta a la usabilidad, y se puede corregir con facilidad.
5. Estética. El defecto afecta a la apariencia del sistema.

Un informe de defecto registra tanto la prioridad como la gravedad. La prioridad indica al equipo de desarrollo en qué orden debe resolver los defectos.

1. Baja. Resuelve el defecto después de los de mayor prioridad. No requiere atención inmediata.
2. Media. Resuelve el defecto poco después de los de mayor prioridad.
3. Alta. Presta atención inmediata al defecto y resuélvelo lo antes posible.

Usa en conjunto la gravedad y la prioridad registradas para decidir con qué urgencia actuar.

Abrir el diagrama a tamaño completo ↗

¿Qué significan la gravedad y la prioridad?

1. Prioridad alta y gravedad alta. Un problema en una función básica impide que el usuario utilice el sistema. Resuélvelo de inmediato.
2. Prioridad alta y gravedad baja. Un error en el nombre de la empresa o un problema con su logotipo tiene poca gravedad funcional, pero requiere una corrección inmediata.
3. Gravedad alta y prioridad baja. Un defecto importante afecta a un módulo que el usuario no necesita de inmediato, por lo que su corrección puede esperar.
4. Prioridad baja y gravedad baja. Los defectos estéticos que no afectan al funcionamiento se suelen corregir al final.