Antes de que el software se envíe para uso público o comercial, los programadores pasan horas solucionando todos los errores, y el producto permanece en el limbo hasta que todas las partes interesadas estén satisfechas.
Los gigantes del software de Silicon Valley como Google y Facebook a menudo lanzarán productos populares al mercado a pesar de los errores de baja prioridad de su software. Los inversores y millones de usuarios leales tolerarán actualizaciones de software y problemas temporales en los productos que ofrecen estas empresas.
La mayoría de las empresas de software no tienen este lujo. Los clientes quieren que los productos funcionen como se anuncian y, con razón, se alarman si hay vulnerabilidades no abordadas.
¿Por qué son necesarias las habilidades de prueba?
Con tantas opciones de desarrollo de software disponibles, los clientes no lo piensan dos veces antes de abandonar el barco si el producto apesta a tiempo y dinero perdidos. Las empresas de software deben realizar pruebas rigurosas en sus productos antes de entregarlos a los clientes. Estas pruebas ofrecen los siguientes conocimientos:
- Destacan las diferencias entre el concepto original y el resultado final.
- Verifican que el software funciona según lo planeado por los diseñadores.
- Evalúan características y calidad.
- Validan que el producto final cumple con los requisitos del cliente.
Las pruebas siguen un plan estricto para optimizar la carga de trabajo, el tiempo y el dinero, al tiempo que brindan a las partes interesadas información esencial para hacer avanzar el producto. El objetivo es facilitar una experiencia positiva para el usuario final manteniendo un programa de aseguramiento de la calidad (QA) completo. Dados los grandes riesgos para los desarrolladores, los gerentes de control de calidad son algunos de los que más ganan en la industria de la tecnología. Las pruebas suelen seguir estos pasos:
Las personas pueden convertirse en probadores de software certificados a través de BCS, The Chartered Institute for IT, ISTQB (International Software Testing Qualifications Board) y ASQ (American Society for Quality).
Métodos de prueba de software
Las pruebas de caja en blanco y negro son dos métodos fundamentales para juzgar el comportamiento y el rendimiento del producto. Las pruebas de caja negra, también llamadas pruebas funcionales o basadas en especificaciones, se centran en la salida. Los evaluadores no se preocupan por los mecanismos internos. Solo verifican que el software haga lo que se supone que debe hacer. No es necesario tener conocimientos de codificación y los probadores trabajan en el nivel de la interfaz de usuario.
Las pruebas de caja blanca utilizan la experiencia en codificación como parte del procedimiento de prueba. Cuando un producto falla, los evaluadores profundizan en el código para encontrar la causa. Los desarrolladores de software harán esto ellos mismos porque los clientes esperan que hagan que un producto funcione. La prueba de caja blanca también se conoce como prueba «basada en estructura» o «caja de vidrio».
Las pruebas estáticas examinan el código fuente y la documentación que lo acompaña, pero no ejecutan el programa. Las pruebas estáticas comienzan temprano en el desarrollo del producto durante el proceso de verificación.
Las pruebas dinámicas utilizan varias entradas cuando el software se está ejecutando y los probadores comparan las salidas con el comportamiento esperado. Las pruebas de interfaz gráfica de usuario evalúan el formato de texto, cuadros de texto, botones, listas, diseño, colores y otros elementos de la interfaz. Las pruebas de GUI requieren mucho tiempo y las empresas de terceros a menudo asumen la tarea en lugar de los desarrolladores.
Niveles de prueba
Se utilizan diferentes niveles de prueba para identificar áreas de debilidad y superposición en cada fase del ciclo de vida del desarrollo de software . Los niveles de prueba son:
- Prueba de unidad
- Pruebas de integración
- Prueba del sistema
- Test de aceptación
Cuando se realizan pruebas unitarias, los desarrolladores prueban las partes más básicas del código, como clases, interfaces y funciones / procedimientos. Saben cómo debe responder su código y pueden hacer ajustes según la salida.
Las pruebas de integración también se conocen como pruebas de «módulo» o «programa». Es similar a las pruebas unitarias pero contiene un mayor nivel de integración. Los módulos del software se prueban en busca de defectos para verificar su función. Las pruebas de integración identifican errores cuando los módulos se integran. Los diferentes métodos para las pruebas de integración incluyen «ascendente», «descendente» y «funcional incremental».
La prueba del sistema prueba los componentes de un proyecto en su conjunto en diferentes entornos. Las pruebas del sistema se incluyen en el método de caja negra y es una de las pruebas finales del proceso. Determinará si el sistema está preparado para satisfacer las necesidades comerciales y de los usuarios.
Generalmente hay dos tipos de pruebas de aceptación. En las pruebas alfa, el software se ejecuta internamente en el sitio del desarrollador en un entorno real o simulado. El software se ejecuta como si lo estuvieran utilizando usuarios finales en vivo. Los desarrolladores toman notas de cualquier problema y comienzan a corregir errores y otros problemas.
También bajo el alcance de las pruebas de caja negra, en las pruebas de aceptación, los clientes prueban el software para averiguar si el desarrollador ha desarrollado completamente el programa para que se ajuste a las especificaciones deseadas.
Las pruebas beta, o pruebas de campo, permiten a los clientes probar el producto en sus sitios en condiciones reales. Los clientes pueden ofrecer a un grupo de usuarios finales la oportunidad de probar el software a través de versiones preliminares o beta. Las pruebas beta tienen como objetivo obtener comentarios reales de los usuarios, que se envían al desarrollador.
Tipos de prueba
Los diferentes tipos de pruebas de software están diseñados para enfocarse en objetivos específicos. El ingeniero de pruebas y el administrador de configuración utilizan las pruebas de instalación para garantizar que el usuario final pueda instalar y ejecutar el programa. Cubre áreas como archivos de instalación, ubicaciones de instalación y privilegios administrativos.
Las pruebas de desarrollo implementan una variedad de estrategias sincronizadas para detectar y prevenir defectos. Incluye análisis de código estático, revisiones de código de pares, seguimiento y análisis de métricas. El objetivo es reducir riesgos y ahorrar costes.
La experiencia del usuario se destaca con las pruebas de usabilidad. Mide la facilidad de uso de la GUI. Comprueba la precisión y eficiencia de las funciones y las respuestas emocionales de los sujetos de prueba.
Una prueba de cordura indica si el software vale el tiempo y el costo para continuar con más pruebas. Si hay demasiados defectos, no se realizarán pruebas más agresivas.
Las pruebas de cordura se realizan durante la fase de lanzamiento del software, donde se realizan pruebas de humo para ver si el software se ejecutará lo suficiente como para ser comprobable.
Las pruebas de humo revelan fallas fundamentales que son lo suficientemente graves como para evitar la liberación. Cuando los desarrolladores prueban una nueva compilación, se denomina prueba de «verificación de compilación». Cuando el sistema sufre una modificación, las pruebas de regresión monitorean el comportamiento inesperado. Señala efectos adversos sobre módulos o componentes.
Los probadores ingresan entradas anormales y disciernen la capacidad del software para gestionar entradas inesperadas en pruebas destructivas. Esto muestra a los desarrolladores lo robusto que es el programa en la gestión de errores.
Cuando el hardware u otras funciones fallan, las pruebas de recuperación muestran qué tan bien el software puede recuperarse y continuar funcionando.
La automatización realiza funciones que son difíciles de implementar manualmente. Las pruebas implican el uso de software específico para ejecutar pruebas y proporcionar datos sobre los resultados reales frente a los esperados.
El software debe ejecutarse en varios entornos informáticos, por lo que las pruebas de compatibilidad verifican cómo responde el software a diferentes sistemas. Por ejemplo, los programadores prueban el software con varios sistemas operativos y navegadores web.
Las pruebas deben ser extensas y abordar todas las inquietudes del cliente, o el proyecto se convierte rápidamente en un desperdicio de recursos.
Las pruebas de rendimiento examinan el rendimiento del software en diferentes escenarios. Se recopila información sobre la capacidad de respuesta, la estabilidad, la asignación de recursos y la velocidad. Las subpruebas, como las de volumen, capacidad y picos, juegan un papel en este proceso.
Las pruebas de seguridad miden la capacidad del software para proteger la seguridad de los usuarios. Las funciones de autorización, autenticación, confidencialidad, integridad, disponibilidad y no repudio son ejemplos de características que deben probarse.
Las pruebas de accesibilidad son diferentes a las pruebas de usabilidad. Esto determina hasta qué punto los usuarios con diversas capacidades pueden utilizar el software.
Los resultados de las pruebas de internalización y localización muestran cómo el software puede adaptarse a diferentes idiomas y demandas regionales. Esto incluye agregar componentes para ubicaciones específicas y traducción de texto.
Tabla de contenidos
