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

• Prueba de aceptación: verifica si todo el sistema funciona según lo previsto.
  
  
• Pruebas de integración: asegura que los componentes o funciones del software operen juntos.
  
  
• Pruebas de unidad: valida que cada unidad de software funcione según lo esperado. Una unidad es el componente de prueba más pequeño de una aplicación.
  
  
• Pruebas funcionales: verifica funciones mediante la emulación de escenarios de negocio, en función de los requisitos funcionales. La prueba de caja negra es una forma común de verificar funciones.
  
  
• Pruebas de rendimiento: prueba 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: verifica si las nuevas características rompen o degradan la funcionalidad. Las pruebas de cordura se pueden utilizar para verificar menús, funciones y comandos a nivel superficial, cuando no hay tiempo para una prueba de regresión completa.
  
  
• Pruebas de estrés: prueba cuánta tensión puede soportar el sistema antes de que falle. Considerado como un tipo de prueba no funcional.
  
  
• Pruebas de usabilidad: valida qué tan bien un cliente puede usar 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 crítica. Igual de importante, las pruebas exploratorias ayudan a un tester o equipo de pruebas a descubrir escenarios y situaciones difíciles de predecir que pueden conducir a errores de software.

Incluso una aplicación simple puede estar sujeta a una gran cantidad y variedad de pruebas. Un plan de gestión de pruebas ayuda a priorizar qué tipos de pruebas proporcionan el mayor valor, dado el tiempo y los recursos disponibles. La efectividad de las pruebas se optimiza ejecutando la menor cantidad de pruebas para encontrar la mayor cantidad de defectos.

Las pruebas de software llegaron junto con el desarrollo de software, que tuvo sus inicios justo después de la segunda guerra mundial. Al informático Tom Kilburn se le atribuye la escritura de la primera pieza de software, que debutó el 21 de junio de 1948 en la Universidad de Manchester en Inglaterra. Realizó cálculos matemáticos utilizando instrucciones de código de máquina.

La depuración era el principal método de prueba en ese momento y lo siguió siendo durante las siguientes dos décadas. En la década de 1980, los equipos de desarrollo miraban más allá de aislar y corregir errores de software para probar aplicaciones en entornos del mundo real. Estableció el escenario para una visión más amplia de las pruebas, que abarcaba un proceso de control de calidad que formaba parte del ciclo de vida del desarrollo de software.

"En la década de 1990, hubo una transición de las pruebas a un proceso más completo llamado garantía de calidad, que cubre todo el ciclo de desarrollo de software y afecta los procesos de planificación, diseño, creación y ejecución de casos de prueba, soporte para casos de prueba existentes y entornos de pruebas", dice Alexander Yaroshko en su publicación en el sitio para desarrolladores de uTest.

"Las pruebas habían alcanzado un nivel cualitativamente nuevo, lo que condujo a un mayor desarrollo de metodologías, la aparición de herramientas poderosas para gestionar el proceso de pruebas y herramientas de automatización de pruebas". ¹

Pruebas continuas

Tradicionalmente, las pruebas de software se han separado del resto del desarrollo. A menudo se lleva a cabo más adelante en el ciclo de vida del desarrollo de software después de la etapa de creación o ejecución del producto. Es posible que un tester solo tenga una pequeña ventana para probar el código, a veces justo antes de que la aplicación salga al mercado. Si se encuentran defectos, puede haber poco tiempo para volver a codificar o volver a probar. No es raro lanzar el software a tiempo, pero con errores y correcciones necesarias. O un equipo de pruebas puede corregir errores pero perder una fecha de lanzamiento.

Hacer actividades de prueba al principio del ciclo ayuda a mantener el esfuerzo de prueba al principio en lugar de después del desarrollo. Las pruebas de software anticipadas también significan que los defectos son menos costosos de resolver.

Muchos equipos de desarrollo ahora usan una metodología conocida como prueba continua. Es parte de un enfoque de DevOps, donde el desarrollo y las operaciones colaboran durante todo el ciclo de vida del producto. El objetivo es acelerar la entrega de software mientras se equilibran los costos, la calidad y el riesgo. Con esta técnica de prueba, los equipos no necesitan esperar a que se cree el software antes de que comience la prueba. Pueden ejecutar pruebas mucho antes en el ciclo para descubrir defectos antes, cuando resultan más fáciles de corregir.

Pocos pueden argumentar en contra de la necesidad de un control de calidad al desarrollar software. Los retrasos en las entregas o los defectos del software pueden dañar la reputación de una marca, lo que provoca la frustración y la pérdida de clientes. En casos extremos, un error o defecto puede degradar los sistemas interconectados o causar fallas graves.

Considere la posibilidad de que Nissan tenga que retirar más de 1 millón de automóviles debido a un defecto de software en los detectores del sensor de la bolsa de aire. O un error de software que provocó el fracaso del lanzamiento de un satélite militar de 1,200 millones de USD. ²  Los números hablan por si mismos. Las fallas de software en los EE. UU. costaron a la economía USD 1.1 billones en activos en 2016. Además, impactaron a 4.400 millones de clientes. ³

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

• Defectos arquitectónicos
• Malas decisiones de diseño
• Funcionalidad no válida o incorrecta
• Vulnerabilidades de seguridad
• Problemas de escalabilidad

Cuando el desarrollo deja un amplio espacio para las pruebas, mejora la confiabilidad del software y las aplicaciones de alta calidad se entregan con pocos errores. Un sistema que cumple o incluso supera las expectativas del cliente genera potencialmente más ventas y 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 escritura de guiones, el análisis de los resultados de la prueba y el envío de informes de defectos.

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

Un buen enfoque de prueba abarca la interfaz de programación de aplicaciones (API), la interfaz de usuario y los niveles del sistema. Además, cuantas más pruebas se automaticen y se ejecuten antes, mejor. Algunos equipos desarrollan herramientas de automatización de pruebas internas. Sin embargo, las soluciones de los proveedores ofrecen funciones que pueden optimizar las tareas clave de gestión de pruebas, como:

• Prueba continua: los equipos de proyecto prueban cada compilación a medida que está disponible. Este tipo de prueba de software se basa en la automatización de pruebas que se integra con el proceso de implementación. Permite que el software se valide en entornos de prueba realistas en una etapa 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 para probar. Los equipos obtienen acceso a activos como código, requisitos, documentos de diseño, modelos, scripts de prueba y resultados de prueba. Los buenos sistemas incluyen autenticación de usuarios y seguimientos de auditoría para ayudar a los equipos a cumplir con los requisitos de conformidad con un mínimo esfuerzo administrativo.
• Virtualización de servicios: es posible que los entornos de prueba no estén disponibles, especialmente en las primeras etapas 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 pruebas antes. Pueden reutilizar, implementar y cambiar una configuración para probar diferentes escenarios sin tener que modificar el entorno original.
• Seguimiento de defectos o errores: la supervisión de defectos es importante tanto para los equipos de prueba como para los de desarrollo para medir y mejorar la calidad. Las herramientas automatizadas permiten a los equipos realizar un seguimiento de los defectos, medir su alcance e impacto y descubrir problemas relacionados.
• Métricas e informes: los informes y la analítica 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. 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.