¿Qué son las pruebas de software?

Las pruebas de software hoy en día son más efectivas cuando son continuas, lo que indica que las pruebas se inician durante el diseño, continúan a medida que se crea el software e incluso se producen cuando se despliega en producción. Las pruebas continuas significan que las organizaciones no tienen que esperar a que se desplieguen todas las piezas antes de que puedan comenzar las pruebas. Shift-left, que está acercando las pruebas al diseño, y shift-right, donde los usuarios finales realizan la validación, también son filosofías de prueba que han ganado terreno recientemente en la comunidad de software. Cuando se comprenden su estrategia de prueba y sus planes de gestión, la automatización de todos los aspectos de las pruebas se vuelve esencial para respaldar la velocidad de entrega que se requiere.

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

• Pruebas de aceptación: verificar si todo el sistema funciona según lo previsto.
  
  
• Revisión de código: confirmar que el software nuevo y modificado sigue los estándares de programación de una organización y se adhiere a sus mejores prácticas.
  
  
• Pruebas de integración: garantizar que los componentes o funciones de software funcionen juntos.
  
  
• Pruebas unitarias: validar que cada unidad de software se ejecute como se espera. Una unidad es el componente comprobable más pequeño de una aplicación.
  
  
• Pruebas funcionales: comprobar las funciones mediante la emulación de escenarios empresariales, basándose en los requisitos funcionales. Las pruebas de caja negra son una forma común de verificar funciones.
  
  
• Pruebas de rendimiento: probar cómo funciona el software con 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: comprobar si las nuevas características descomponen 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 seguridad: validar que su software no está abierto a hackers u otros tipos maliciosos de vulnerabilidades que podrían ser explotadas para denegar el acceso a sus servicios o hacer que se desempeñen incorrectamente.
  
  
• Pruebas de estrés: probar cuánta tensión puede tolerar el sistema antes de fallar. Las pruebas de estrés se consideran un tipo de pruebas no funcionales.
  
  
• Pruebas de usabilidad: validar qué tan bien un cliente puede usar un sistema o 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 evaluador 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 un gran número 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 eficacia de las pruebas se optimiza al ejecutar el menor número de pruebas para encontrar el mayor número 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 científico 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 mediante 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 próximas 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. 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 del desarrollo de software.

Pocos pueden argumentar en contra de la necesidad de un control de calidad al desarrollar software. Los retrasos en la entrega o los defectos del software pueden dañar la reputación de una marca, lo que genera frustración en los clientes, así como perderlos. En casos extremos, un error o defecto puede degradar los sistemas interconectados o provocar fallos de funcionamiento graves.

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 1200 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 4400 millones de clientes.²

Aunque las pruebas en sí 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 pueden detectar problemas antes de que un producto salga al mercado. Cuanto antes reciban la retroalimentación de los equipos de desarrollo sobre las pruebas, más pronto 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 margen 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 definir el entorno de prueba, desarrollar casos de prueba, escribir scripts, analizar los resultados de las pruebas y enviar informes de defectos.

Las pruebas pueden llevar mucho tiempo. Las pruebas manuales o ad hoc 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 rápidamente retroalimentación 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. Cuantas más pruebas se automaticen y se ejecuten antes, mejor. Algunos equipos crean herramientas internas de automatización de pruebas. Sin embargo, las soluciones de los proveedores ofrecen características que pueden optimizar las tareas clave de gestión de pruebas, como:

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 pruebas que se integra con el proceso de despliegue. 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.

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

Es posible que no se disponga de entornos de prueba, sobre todo 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 probar antes. Pueden reutilizar, desplegar y cambiar una configuración para probar distintos escenarios sin tener que modificar el entorno original.

El monitoreo de 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 rastrear defectos, medir su alcance e impacto y descubrir problemas relacionados.

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 métricas de proyectos y presentan resultados en un panel. Los equipos ven rápidamente el estado general de un proyecto y pueden monitorear las relaciones entre las pruebas, el desarrollo y otros elementos del proyecto.