Existen muchos tipos diferentes de pruebas de software, cada uno con objetivos y estrategias específicos:

• Pruebas de aceptación: Verifican si todo el sistema funciona según lo previsto.
• Revisión del código: Confirman que el software nuevo y modificado esté siguiendo los estándares de codificación de una organización y se adhiera a sus mejores prácticas.
• Pruebas de integración: Garantizan que los componentes o las funciones del software funcionan conjuntamente.
• Unit tests: Validan que cada unidad de software funciona según lo esperado. Una unidad es el componente comprobable más pequeño de una aplicación.
• Pruebas funcionales: Comprueban las funciones emulando escenarios de negocio, basándose en los requisitos funcionales. Las pruebas de caja negra son una forma habitual de verificar las funciones.
• Pruebas de rendimiento: Comprueban cómo funciona el software bajo diferentes cargas de trabajo. Las pruebas de carga, por ejemplo, se utilizan para evaluar el rendimiento en condiciones de carga reales.
• Pruebas de regresión: Comprueban si las nuevas características rompen o degradan la funcionalidad. Las pruebas de cordura pueden utilizarse para verificar menús, funciones y comandos a nivel superficial, cuando no hay tiempo para una prueba de regresión completa.
• Pruebas de seguridad: Validando que su software no está expuesto a ataques de hackers u otro tipo de vulnerabilidades maliciosas que puedan ser explotadas para denegar el acceso a sus servicios o hacer que funcionen incorrectamente.
• Pruebas de estrés: Prueban cuánta tensión puede soportar el sistema antes de fallar. Las pruebas de estrés se consideran un tipo de pruebas no funcionales.
• Pruebas de usabilidad: Validan lo bien que un cliente puede utilizar un sistema o una aplicación web para completar una tarea.

En cada caso, la validación de los requisitos básicos es una evaluación crucial. Con la misma importancia, las pruebas exploratorias ayudan al evaluador o al equipo de pruebas a detectar escenarios y situaciones difíciles de predecir que pueden dar lugar a errores en el software.

Incluso una aplicación sencilla puede ser sometida a un gran número y variedad de pruebas. Un plan de gestión de pruebas ayuda a priorizar qué tipos de pruebas aportan más valor, teniendo en cuenta el tiempo y los recursos disponibles. La eficacia de las pruebas se optimiza ejecutando el menor número de pruebas para encontrar el mayor número de defectos.

Las pruebas de software llegaron junto con el desarrollo del software, que tuvo sus inicios justo después de la Segunda Guerra Mundial. Al informático Tom Kilburn se le atribuye el mérito de haber escrito el primer programa informático, que debutó el 21 de junio de 1948 en la Universidad de Manchester (Inglaterra). Realizaba cálculos matemáticos mediante el uso de instrucciones de código máquina.

Por aquel entonces, la depuración era el principal método de comprobación y siguió siéndolo durante las dos décadas siguientes. En la década de 1980, los equipos de desarrollo ya no se limitaban a aislar y corregir los fallos del software, sino que probaban las aplicaciones en entornos reales. Sentó las bases para una visión más amplia de las pruebas, que abarcaba un proceso de garantía de calidad que formaba parte del ciclo de vida de desarrollo del software.

Muy pocos podrán argumentar en contra de la necesidad de un control de calidad a la hora de desarrollar software. Los retrasos en la entrega o los defectos del software pueden dañar la reputación de una marca, lo que genera clientes frustrados que se pierden. En casos extremos, un fallo o defecto puede degradar los sistemas interconectados o causar graves disfunciones.

Pensemos en Nissan, que tuvo que sacar de circulación más de un millón de coches por un defecto de software en los detectores de los sensores de los airbags; o en un fallo de software que provocó el fracaso del lanzamiento de un satélite militar por valor de 1.200 millones de dólares.¹ Las cifras hablan por sí solas. Los fallos de software en Estados Unidos costaron a la economía 1,1 billones de dólares en activos en 2016. Es más, afectaron a 4.400 millones de clientes.²

Aunque las pruebas en sí cuestan dinero, las empresas pueden ahorrar millones al año en desarrollo y soporte si cuentan con una buena técnica de pruebas y procesos de control de calidad. Las pruebas tempranas de software revelan problemas antes de que un producto salga al mercado. Cuanto antes reciban los equipos de desarrollo los comentarios sobre las pruebas, antes podrán abordar cuestiones como:

• Defectos en la arquitectura
• Decisiones de diseño poco acertadas
• Funcionalidades no válidas o incorrectas
• Vulnerabilidades de seguridad
• Problemas de escalabilidad

Cuando el desarrollo deja un amplio margen para las pruebas, mejora la fiabilidad del software y se entregan aplicaciones de alta calidad con pocos errores. Un sistema que cumpla o incluso supere las expectativas de los clientes conduce a un aumento potencial de las ventas y a una mayor cuota de mercado.

Las pruebas de software siguen un proceso común. Las tareas o pasos incluyen la definición del entorno de prueba, el desarrollo de casos de prueba, la elaboración de scripts, el análisis de los resultados de las pruebas y la presentación de informes de defectos.

Las pruebas pueden resultar laboriosas. Las pruebas manuales o las pruebas ad hoc pueden ser suficientes para compilaciones pequeñas. Sin embargo, en los sistemas más grandes, las herramientas se utilizan con frecuencia para automatizar las tareas. Las pruebas automatizadas ayudan a los equipos a implementar diferentes escenarios, probar elementos diferenciadores (como mover componentes a un entorno en la nube) y obtener rápidamente comentarios sobre lo que funciona y lo que no.

Un buen enfoque de las pruebas engloba la interfaz de programación de aplicaciones (API), la interfaz de usuario y los niveles del sistema. Cuantas más pruebas se automaticen y antes se ejecuten, mejor. Algunos equipos crean herramientas internas de automatización de pruebas. Sin embargo, las soluciones de los proveedores ofrecen características que pueden agilizar las tareas clave de gestión de pruebas, como:

Realización continua de pruebas

Los equipos de proyecto prueban cada compilación a medida que está disponible. Este tipo de pruebas de software se basa en la automatización de las pruebas integrada en el proceso de implementación. Permite validar el software en entornos de prueba realistas en una fase más temprana del proceso, lo que mejora el diseño y reduce los riesgos.

Gestión de la configuración

Las organizaciones mantienen de forma centralizada los activos de prueba y realizan un seguimiento de las compilaciones de software que se debe probarse. Los equipos obtienen acceso a activos como código, requerimientos, documentos de diseño, modelos, guiones de pruebas y resultados de pruebas. Los buenos sistemas incluyen la autenticación de usuarios y registros de auditoría para ayudar a los equipos a cumplir con los requisitos de cumplimiento con un esfuerzo administrativo mínimo.

Virtualización de servicios

Es posible que los entornos de prueba no estén disponibles, especialmente al principio del desarrollo del código. La virtualización de servicios simula los servicios y sistemas que faltan o que aún no se han completado, lo que permite a los equipos reducir las dependencias y realizar las pruebas antes. Pueden reutilizar, implementar y cambiar una configuración para probar diferentes escenarios sin tener que modificar el entorno original.

Defecto o rastreo de fallos

El seguimiento de los defectos es importante tanto para los equipos de pruebas como para los de desarrollo para medir y mejorar la calidad. Las herramientas automatizadas permiten a los equipos hacer un seguimiento de los defectos, medir su alcance e impacto y descubrir problemas relacionados.

Métricas e informes

Los informes y analytics permiten a los miembros del equipo compartir el estado, los objetivos y los resultados de las pruebas. Las herramientas avanzadas integran las métricas del proyecto y presentan los resultados en un panel de control. Los equipos ven rápidamente el estado general de un proyecto y pueden supervisar las relaciones entre las pruebas, el desarrollo y otros elementos del proyecto.