Pruebas de software

La prueba de software es el acto de examinar los artefactos y el comportamiento del software bajo prueba mediante validación y verificación. Las pruebas de software también pueden proporcionar una visión objetiva e independiente del software para permitir que la empresa aprecie y comprenda los riesgos de la implementación del software. Las técnicas de prueba incluyen, pero no necesariamente se limitan a:

• Analizar los requisitos de productos para la integridad y corrección en diversos contextos como la perspectiva de la industria, la perspectiva empresarial, la viabilidad y viabilidad de la implementación, usabilidad, rendimiento, seguridad, consideraciones de infraestructura, etc.
• revisar la arquitectura del producto y el diseño general del producto
• trabajar con desarrolladores de productos en la mejora de técnicas de codificación, patrones de diseño, pruebas que se pueden escribir como parte del código basado en diversas técnicas como condiciones de límite, etc.
• ejecutar un programa o aplicación con la intención de examinar el comportamiento
• revisión de la infraestructura de implementación y scripts asociados y automatización
• participar en actividades de producción mediante técnicas de vigilancia y observabilidad

Las pruebas de software pueden proporcionar información objetiva e independiente sobre la calidad del software y el riesgo de falla para los usuarios o patrocinadores.

Las pruebas de software pueden determinar la corrección del software bajo la suposición de algunas hipótesis específicas (consulte la jerarquía de dificultad de las pruebas a continuación), las pruebas no pueden identificar todas las fallas dentro del software. En su lugar, proporciona una crítica o comparación que compara el estado y el comportamiento del producto con los oráculos de prueba, principios o mecanismos mediante los cuales alguien podría reconocer un problema. Estos oráculos pueden incluir (pero no se limitan a) especificaciones, contratos, productos comparables, versiones anteriores del mismo producto, inferencias sobre el propósito previsto o esperado, expectativas del usuario o del cliente, estándares relevantes, leyes aplicables u otros criterios.

Un objetivo principal de las pruebas es detectar fallas de software para que los defectos puedan descubrirse y corregirse. Las pruebas no pueden establecer que un producto funcione correctamente en todas las condiciones, sino solo que no funciona correctamente en condiciones específicas. El alcance de las pruebas de software puede incluir el examen del código, así como la ejecución de ese código en varios entornos y condiciones, así como el examen de los aspectos del código: ¿hace lo que se supone que debe hacer y hace lo que debe hacer? En la cultura actual de desarrollo de software, una organización de pruebas puede estar separada del equipo de desarrollo. Hay varios roles para los miembros del equipo de pruebas. La información derivada de las pruebas de software se puede utilizar para corregir el proceso mediante el cual se desarrolla el software.

Cada producto de software tiene un público objetivo. Por ejemplo, la audiencia del software de videojuegos es completamente diferente a la del software bancario. Por lo tanto, cuando una organización desarrolla o invierte en un producto de software, puede evaluar si el producto de software será aceptable para sus usuarios finales, su público objetivo, sus compradores y otras partes interesadas. Las pruebas de software ayudan a realizar esta evaluación.

Fallos y fallas

Las fallas de software ocurren a través del siguiente proceso: un programador comete un error (equivocación), lo que resulta en una falla (defecto, error) en el código fuente del software. Si se ejecuta esta falla, en ciertas situaciones el sistema producirá resultados erróneos, provocando una falla.

No todas las fallas necesariamente resultarán en fallas. Por ejemplo, las fallas en el código muerto nunca darán como resultado fallas. Una falla que no reveló fallas puede resultar en una falla cuando se cambia el entorno. Los ejemplos de estos cambios en el entorno incluyen el software que se ejecuta en una nueva plataforma de hardware de computadora, alteraciones en los datos de origen o la interacción con un software diferente. Una sola falla puede resultar en una amplia gama de síntomas de falla.

No todas las fallas de software son causadas por errores de codificación. Una fuente común de defectos costosos son las brechas en los requisitos, es decir, requisitos no reconocidos que resultan en errores de omisión por parte del diseñador del programa. Las brechas de requisitos a menudo pueden ser requisitos no funcionales, como la capacidad de prueba, la escalabilidad, la capacidad de mantenimiento, el rendimiento y la seguridad.

Combinaciones de entrada y condiciones previas

Un problema fundamental con las pruebas de software es que las pruebas bajo todas las combinaciones de entradas y condiciones previas (estado inicial) no son factibles, incluso con un producto simple. Esto significa que la cantidad de fallas en un producto de software puede ser muy grande y los defectos que ocurren con poca frecuencia son difíciles de encontrar en las pruebas y la depuración. Más significativamente, las dimensiones no funcionales de la calidad (cómo se supone que ser frente a lo que se supone que debe hacer) — usabilidad, escalabilidad, rendimiento, compatibilidad y confiabilidad — puede ser muy subjetivo; algo que constituye un valor suficiente para una persona puede ser intolerable para otra.

Los desarrolladores de software no pueden probar todo, pero pueden usar el diseño de pruebas combinatorias para identificar la cantidad mínima de pruebas necesarias para obtener la cobertura que desean. El diseño de pruebas combinatorias permite a los usuarios obtener una mayor cobertura de pruebas con menos pruebas. Ya sea que busquen velocidad o profundidad de prueba, pueden usar métodos de diseño de prueba combinatoria para crear una variación estructurada en sus casos de prueba.

Economía

Un estudio realizado por el NIST en 2002 informa que los errores de software le cuestan a la economía estadounidense 59 500 millones de dólares al año. Se podría evitar más de un tercio de este costo si se realizaran mejores pruebas de software.

La subcontratación de pruebas de software debido a los costos es muy común, siendo China, Filipinas e India los destinos preferidos.

Funciones

Las pruebas de software pueden ser realizadas por probadores de software dedicados; hasta la década de 1980, el término "probador de software" se utilizó generalmente, pero más tarde también se vio como una profesión separada. En cuanto a los períodos y los diferentes objetivos en las pruebas de software, se han establecido diferentes roles, como director de pruebas, líder de pruebas, analista de pruebas, < i>diseñador de pruebas, probador, desarrollador de automatización y administrador de pruebas. Las pruebas de software también pueden ser realizadas por probadores de software no dedicados.

Historia

Glenford J. Myers inicialmente introdujo la separación de la depuración de las pruebas en 1979. Aunque su atención estaba en las pruebas de rotura ("Un caso de prueba exitoso es aquel que detecta un error que aún no se ha descubierto)."), ilustró el deseo de la comunidad de ingeniería de software de separar las actividades fundamentales de desarrollo, como la depuración, de la verificación.

Enfoque de prueba

Pruebas estáticas, dinámicas y pasivas

Hay muchos enfoques disponibles en las pruebas de software. Las revisiones, recorridos o inspecciones se denominan pruebas estáticas, mientras que la ejecución de código programado con un conjunto determinado de casos de prueba se denomina pruebas dinámicas.

Las pruebas estáticas suelen ser implícitas, como la corrección de pruebas, además cuando las herramientas de programación o los editores de texto comprueban la estructura del código fuente o los compiladores (precompiladores) comprueban la sintaxis y el flujo de datos como análisis de programas estáticos. Las pruebas dinámicas tienen lugar cuando se ejecuta el propio programa. Las pruebas dinámicas pueden comenzar antes de que el programa esté completo al 100% para probar secciones particulares de código y se aplican a funciones o módulos discretos. Las técnicas típicas para estos son el uso de stubs/drivers o la ejecución desde un entorno de depuración.

Las pruebas estáticas implican verificación, mientras que las pruebas dinámicas también implican validación.

Las pruebas pasivas significan verificar el comportamiento del sistema sin ninguna interacción con el producto de software. A diferencia de las pruebas activas, los probadores no proporcionan ningún dato de prueba, pero miran los registros y seguimientos del sistema. Buscan patrones y comportamientos específicos para tomar algún tipo de decisión. Esto está relacionado con la verificación del tiempo de ejecución sin conexión y el análisis de registros.

Enfoque exploratorio

Las pruebas exploratorias son un enfoque de las pruebas de software que se describen de forma concisa como aprendizaje, diseño de pruebas y ejecución de pruebas simultáneos. Cem Kaner, quien acuñó el término en 1984, define la prueba exploratoria como "un estilo de prueba de software que enfatiza la libertad personal y la responsabilidad del probador individual para optimizar continuamente la calidad de su trabajo al tratar el aprendizaje relacionado con la prueba"., diseño de prueba, ejecución de prueba e interpretación de resultados de prueba como actividades de apoyo mutuo que se ejecutan en paralelo a lo largo del proyecto."

La "caja" acercamiento

Los métodos de prueba de software se dividen tradicionalmente en pruebas de caja blanca y caja negra. Estos dos enfoques se utilizan para describir el punto de vista que adopta el probador al diseñar casos de prueba. Un enfoque híbrido llamado prueba de caja gris también se puede aplicar a la metodología de prueba de software. Con el concepto de prueba de caja gris, que desarrolla pruebas a partir de elementos de diseño específicos, ganando importancia, esta "distinción arbitraria" entre las pruebas de caja negra y caja blanca se ha desvanecido un poco.

Pruebas de caja blanca

Diagrama de prueba de caja blanca

La prueba de caja blanca (también conocida como prueba de caja clara, prueba de caja de vidrio, prueba de caja transparente y prueba estructural) verifica las estructuras internas o el funcionamiento de un programa, a diferencia de la funcionalidad expuesta al usuario final. En las pruebas de caja blanca, se utiliza una perspectiva interna del sistema (el código fuente), así como las habilidades de programación, para diseñar casos de prueba. El probador elige entradas para ejercitar rutas a través del código y determinar las salidas apropiadas. Esto es análogo a probar nodos en un circuito, por ejemplo, prueba en circuito (ICT).

Si bien las pruebas de caja blanca se pueden aplicar a nivel de unidad, integración y sistema del proceso de prueba de software, por lo general se realizan a nivel de unidad. Puede probar rutas dentro de una unidad, rutas entre unidades durante la integración y entre subsistemas durante una prueba a nivel de sistema. Aunque este método de diseño de prueba puede descubrir muchos errores o problemas, es posible que no detecte partes no implementadas de la especificación o requisitos faltantes.

Las técnicas utilizadas en las pruebas de caja blanca incluyen:

• Pruebas de API – pruebas de la aplicación mediante API públicas y privadas (interfaz de programación de aplicaciones)
• Cobertura del código – crear pruebas para satisfacer algunos criterios de cobertura del código (por ejemplo, el diseñador de pruebas puede crear pruebas para hacer que todas las declaraciones del programa se ejecuten al menos una vez)
• Métodos de inyección por defecto – introducción intencional de fallas para medir la eficacia de las estrategias de prueba
• Métodos de prueba de mutación
• Métodos de prueba estáticos

Las herramientas de cobertura de código pueden evaluar la integridad de un conjunto de pruebas creado con cualquier método, incluidas las pruebas de caja negra. Esto permite que el equipo de software examine partes de un sistema que rara vez se prueban y garantiza que se hayan probado los puntos de función más importantes. La cobertura de código como una métrica de software se puede informar como un porcentaje para:

• Cobertura de funciones, que informa sobre las funciones ejecutadas
• Cobertura por declaración, que informa sobre el número de líneas ejecutadas para completar la prueba
• Cobertura de las decisiones, que informa sobre si la rama Verdadera y Falsa de una prueba determinada ha sido ejecutada

La cobertura de declaraciones al 100 % garantiza que todas las rutas de código o ramas (en términos de flujo de control) se ejecuten al menos una vez. Esto es útil para garantizar la funcionalidad correcta, pero no suficiente, ya que el mismo código puede procesar distintas entradas de forma correcta o incorrecta. Las funciones y métodos pseudo-probados son aquellos que están cubiertos pero no especificados (es posible eliminar su cuerpo sin romper ningún caso de prueba).

Pruebas de caja negra

Diagrama de caja negra

Las pruebas de caja negra (también conocidas como pruebas funcionales) tratan el software como una "caja negra" examinar la funcionalidad sin ningún conocimiento de la implementación interna, sin ver el código fuente. Los evaluadores solo conocen lo que se supone que debe hacer el software, no cómo lo hace. Los métodos de prueba de caja negra incluyen: partición de equivalencia, análisis de valor límite, prueba de todos los pares, tablas de transición de estado, prueba de tabla de decisión, prueba de fuzz, prueba basada en modelo, prueba de caso de uso, prueba exploratoria y prueba basada en especificación.

Las pruebas basadas en especificaciones tienen como objetivo probar la funcionalidad del software de acuerdo con los requisitos aplicables. Este nivel de prueba generalmente requiere que se proporcionen casos de prueba completos al evaluador, quien luego puede simplemente verificar que para una entrada dada, el valor de salida (o comportamiento), "es" o "no es" el mismo que el valor esperado especificado en el caso de prueba. Los casos de prueba se construyen en torno a especificaciones y requisitos, es decir, lo que se supone que debe hacer la aplicación. Utiliza descripciones externas del software, incluidas especificaciones, requisitos y diseños para derivar casos de prueba. Estas pruebas pueden ser funcionales o no funcionales, aunque normalmente funcionales.

Las pruebas basadas en especificaciones pueden ser necesarias para garantizar la funcionalidad correcta, pero son insuficientes para protegerse contra situaciones complejas o de alto riesgo.

Una de las ventajas de la técnica de la caja negra es que no se requieren conocimientos de programación. Independientemente de los sesgos que puedan haber tenido los programadores, es probable que el probador tenga un conjunto diferente y pueda enfatizar diferentes áreas de funcionalidad. Por otro lado, se ha dicho que las pruebas de caja negra son "como caminar en un laberinto oscuro sin una linterna". Debido a que no examinan el código fuente, hay situaciones en las que un probador escribe muchos casos de prueba para verificar algo que podría haber sido probado por un solo caso de prueba o deja algunas partes del programa sin probar.

Este método de prueba se puede aplicar a todos los niveles de prueba de software: unidad, integración, sistema y aceptación. Por lo general, comprende la mayoría, si no todas, las pruebas en niveles más altos, pero también puede dominar las pruebas unitarias.

Pruebas de interfaz de componentes

La prueba de interfaz de componentes es una variación de la prueba de caja negra, con el foco en los valores de los datos más allá de las acciones relacionadas de un componente del subsistema. La práctica de las pruebas de interfaz de componentes se puede utilizar para verificar el manejo de los datos que se pasan entre varias unidades o componentes del subsistema, más allá de las pruebas de integración total entre esas unidades. Los datos que se pasan pueden considerarse como "paquetes de mensajes" y el rango o los tipos de datos se pueden verificar, para los datos generados a partir de una unidad, y probar su validez antes de pasar a otra unidad. Una opción para las pruebas de interfaz es mantener un archivo de registro separado de los elementos de datos que se pasan, a menudo con una marca de tiempo registrada para permitir el análisis de miles de casos de datos que se pasan entre unidades durante días o semanas. Las pruebas pueden incluir la verificación del manejo de algunos valores de datos extremos, mientras que otras variables de interfaz se pasan como valores normales. Los valores de datos inusuales en una interfaz pueden ayudar a explicar el rendimiento inesperado en la siguiente unidad.

Pruebas visuales

El objetivo de las pruebas visuales es proporcionar a los desarrolladores la capacidad de examinar lo que estaba sucediendo en el punto de falla del software al presentar los datos de tal manera que el desarrollador pueda encontrar fácilmente la información que necesita y la información se expresa claramente.

En el centro de las pruebas visuales está la idea de que mostrarle a alguien un problema (o una falla en la prueba), en lugar de simplemente describirlo, aumenta en gran medida la claridad y la comprensión. La prueba visual, por lo tanto, requiere la grabación de todo el proceso de prueba, capturando todo lo que ocurre en el sistema de prueba en formato de video. Los videos de salida se complementan con la entrada del probador en tiempo real a través de una cámara web de imagen en una imagen y comentarios de audio de micrófonos.

Las pruebas visuales ofrecen una serie de ventajas. La calidad de la comunicación aumenta drásticamente porque los probadores pueden mostrar el problema (y los eventos que lo condujeron) al desarrollador en lugar de simplemente describirlo y la necesidad de replicar las fallas de las pruebas dejará de existir en muchos casos. El desarrollador tendrá toda la evidencia que necesita de una prueba fallida y, en su lugar, puede concentrarse en la causa de la falla y cómo debe solucionarse.

Las pruebas ad hoc y exploratorias son metodologías importantes para verificar la integridad del software, ya que requieren menos tiempo de preparación para implementarlas, mientras que los errores importantes se pueden encontrar rápidamente. En las pruebas ad hoc, donde las pruebas se llevan a cabo de forma improvisada, la capacidad de los probadores para basar las pruebas en métodos documentados y luego improvisar variaciones de esas pruebas puede dar como resultado un examen más riguroso de las correcciones de defectos. Sin embargo, a menos que se mantenga una documentación estricta de los procedimientos, uno de los límites de las pruebas ad hoc es la falta de repetibilidad.

Pruebas de caja gris

Las pruebas de caja gris (ortografía estadounidense: prueba de caja gris) implican tener conocimiento de estructuras de datos y algoritmos internos con el fin de diseñar pruebas mientras se ejecutan esas pruebas a nivel de usuario o de caja negra. El probador a menudo tendrá acceso tanto al código fuente como al binario ejecutable." Las pruebas de caja gris también pueden incluir ingeniería inversa (usando análisis de código dinámico) para determinar, por ejemplo, valores límite o mensajes de error. La manipulación de datos de entrada y el formato de salida no califican como caja gris, ya que la entrada y la salida están claramente fuera de la "caja negra" que estamos llamando el sistema bajo prueba. Esta distinción es particularmente importante cuando se realizan pruebas de integración entre dos módulos de código escritos por dos desarrolladores diferentes, donde solo se exponen las interfaces para la prueba.

Al conocer los conceptos subyacentes de cómo funciona el software, el probador toma decisiones de prueba mejor informadas mientras prueba el software desde afuera. Por lo general, a un evaluador de caja gris se le permitirá configurar un entorno de prueba aislado con actividades como la inicialización de una base de datos. El evaluador puede observar el estado del producto que se está probando después de realizar ciertas acciones, como ejecutar declaraciones SQL en la base de datos y luego ejecutar consultas para asegurarse de que se hayan reflejado los cambios esperados. Las pruebas de caja gris implementan escenarios de prueba inteligentes, basados en información limitada. Esto se aplicará particularmente al manejo de tipos de datos, manejo de excepciones, etc.

Niveles de prueba

En términos generales, existen al menos tres niveles de prueba: prueba unitaria, prueba de integración y prueba del sistema. Sin embargo, los desarrolladores pueden incluir un cuarto nivel, pruebas de aceptación. Esto puede ser en forma de prueba de aceptación operativa o ser una simple prueba de usuario final (beta), prueba para garantizar que el software cumpla con las expectativas funcionales. Según el plan de estudios de nivel básico de prueba certificado de ISTQB, los niveles de prueba incluyen esos cuatro niveles, y el cuarto nivel se denomina prueba de aceptación. Las pruebas se agrupan con frecuencia en uno de estos niveles según el lugar en el que se agregan en el proceso de desarrollo de software o según el nivel de especificidad de la prueba.

Pruebas unitarias

Las pruebas unitarias se refieren a las pruebas que verifican la funcionalidad de una sección específica de código, generalmente a nivel de función. En un entorno orientado a objetos, esto suele ser a nivel de clase y las pruebas unitarias mínimas incluyen a los constructores y destructores.

Estos tipos de pruebas generalmente los escriben los desarrolladores mientras trabajan en el código (estilo de caja blanca), para garantizar que la función específica funcione como se espera. Una función puede tener múltiples pruebas, para detectar casos de esquina u otras ramas en el código. Las pruebas unitarias por sí solas no pueden verificar la funcionalidad de una pieza de software, sino que se utilizan para garantizar que los componentes básicos del software funcionen de forma independiente entre sí.

Las pruebas unitarias son un proceso de desarrollo de software que involucra la aplicación sincronizada de un amplio espectro de estrategias de detección y prevención de defectos para reducir los riesgos, el tiempo y los costos del desarrollo de software. Lo realiza el desarrollador o ingeniero de software durante la fase de construcción del ciclo de vida del desarrollo de software. Las pruebas unitarias tienen como objetivo eliminar los errores de construcción antes de que el código se promueva a pruebas adicionales; esta estrategia pretende aumentar la calidad del software resultante, así como la eficiencia del proceso de desarrollo general.

Dependiendo de las expectativas de la organización para el desarrollo de software, las pruebas unitarias pueden incluir análisis de código estático, análisis de flujo de datos, análisis de métricas, revisiones de código de pares, análisis de cobertura de código y otras prácticas de prueba de software.

Pruebas de integración

La prueba de integración es cualquier tipo de prueba de software que busca verificar las interfaces entre componentes contra un diseño de software. Los componentes de software pueden integrarse de manera iterativa o todos juntos ("big bang"). Normalmente, lo primero se considera una mejor práctica, ya que permite que los problemas de la interfaz se localicen y solucionen más rápidamente.

Las pruebas de integración funcionan para exponer los defectos en las interfaces y la interacción entre los componentes integrados (módulos). Grupos progresivamente más grandes de componentes de software probados correspondientes a elementos del diseño arquitectónico se integran y prueban hasta que el software funciona como un sistema.

Las pruebas de integración normalmente implican una gran cantidad de código y producen rastros que son más grandes que los producidos por las pruebas unitarias. Esto tiene un impacto en la facilidad de localizar la falla cuando falla una prueba de integración. Para superar este problema, se ha propuesto cortar automáticamente las pruebas grandes en piezas más pequeñas para mejorar la localización de fallas.

Pruebas del sistema

Las pruebas del sistema prueban un sistema completamente integrado para verificar que el sistema cumpla con sus requisitos. Por ejemplo, una prueba del sistema puede implicar probar una interfaz de inicio de sesión, luego crear y editar una entrada, además de enviar o imprimir resultados, seguido de un procesamiento resumido o eliminación (o archivado) de entradas y luego cierre de sesión.

Pruebas de aceptación

Las pruebas de aceptación suelen incluir los siguientes cuatro tipos:

• Pruebas de aceptación del usuario (UAT)
• Pruebas de aceptación operacional (AT)
• Pruebas de aceptación contractual y reglamentaria
• Pruebas de alfa y beta

UAT, así como las pruebas alfa y beta se describen en la siguiente sección de tipos de pruebas.

La aceptación operativa se utiliza para llevar a cabo la preparación operativa (prelanzamiento) de un producto, servicio o sistema como parte de un sistema de gestión de calidad. OAT es un tipo común de prueba de software no funcional, que se utiliza principalmente en proyectos de desarrollo y mantenimiento de software. Este tipo de prueba se centra en la preparación operativa del sistema para recibir soporte o para convertirse en parte del entorno de producción. Por lo tanto, también se conoce como prueba de preparación operativa (ORT) o prueba de preparación y garantía de operaciones (OR&A). Las pruebas funcionales dentro de OAT se limitan a aquellas pruebas que se requieren para verificar los aspectos no funcionales del sistema.

Además, las pruebas de software deben garantizar que la portabilidad del sistema, además de funcionar como se espera, no dañe ni corrompa parcialmente su entorno operativo ni provoque que otros procesos dentro de ese entorno dejen de funcionar.

La prueba de aceptación contractual se realiza en función de los criterios de aceptación del contrato definidos durante el acuerdo del contrato, mientras que la prueba de aceptación reglamentaria se realiza en función de las reglamentaciones pertinentes del producto de software. Ambas pruebas pueden ser realizadas por usuarios o probadores independientes. Las pruebas de aceptación de la regulación a veces implican que las agencias reguladoras auditen los resultados de las pruebas.

Tipos de pruebas, técnicas y tácticas

Diferentes etiquetas y formas de agrupar las pruebas pueden ser tipos de pruebas, tácticas o técnicas de pruebas de software.

TestingCup - Campeonato Polaco en Pruebas de Software, Katowice, mayo 2016

Pruebas de instalación

La mayoría de los sistemas de software tienen procedimientos de instalación necesarios antes de poder utilizarlos para su propósito principal. La prueba de estos procedimientos para lograr un sistema de software instalado que pueda usarse se conoce como prueba de instalación.

Pruebas de compatibilidad

Una causa común de falla del software (real o percibida) es la falta de compatibilidad con otro software de aplicación, sistemas operativos (o versiones del sistema operativo, antiguas o nuevas) o entornos de destino que difieren mucho del original (como una aplicación de terminal o GUI destinada a ejecutarse en el escritorio ahora se requiere para convertirse en una aplicación web, que debe renderizarse en un navegador web). Por ejemplo, en el caso de una falta de compatibilidad con versiones anteriores, esto puede ocurrir porque los programadores desarrollan y prueban el software solo en la última versión del entorno de destino, que es posible que no todos los usuarios estén ejecutando. Esto da como resultado la consecuencia no deseada de que es posible que el trabajo más reciente no funcione en versiones anteriores del entorno de destino, o en hardware más antiguo que las versiones anteriores del entorno de destino podían usar. A veces, estos problemas se pueden solucionar abstrayendo de forma proactiva la funcionalidad del sistema operativo en un módulo de programa o biblioteca independiente.

Pruebas de humo y cordura

Las pruebas de cordura determinan si es razonable continuar con más pruebas.

La prueba de humo consiste en intentos mínimos de operar el software, diseñado para determinar si hay algún problema básico que impida que funcione. Estas pruebas se pueden utilizar como prueba de verificación de compilación.

Pruebas de regresión

Las pruebas de regresión se centran en encontrar defectos después de que se haya producido un cambio importante en el código. Específicamente, busca descubrir regresiones de software, como funciones degradadas o perdidas, incluidos errores antiguos que han regresado. Tales regresiones ocurren cada vez que la funcionalidad del software que antes funcionaba correctamente deja de funcionar según lo previsto. Por lo general, las regresiones ocurren como una consecuencia no deseada de los cambios en el programa, cuando la parte del software recién desarrollada choca con el código existente anteriormente. Las pruebas de regresión suelen ser el esfuerzo de prueba más grande en el desarrollo de software comercial, debido a la verificación de numerosos detalles en funciones de software anteriores, e incluso se puede desarrollar software nuevo mientras se usan algunos casos de prueba antiguos para probar partes del nuevo diseño para garantizar que la funcionalidad anterior aún sea compatible..

Los métodos comunes de prueba de regresión incluyen volver a ejecutar conjuntos anteriores de casos de prueba y verificar si las fallas previamente reparadas han resurgido. La profundidad de las pruebas depende de la fase del proceso de lanzamiento y el riesgo de las características añadidas. Pueden ser completos, para cambios agregados tarde en el lanzamiento o considerados riesgosos, o ser muy superficiales, consistentes en pruebas positivas en cada característica, si los cambios son tempranos en el lanzamiento o se consideran de bajo riesgo. En las pruebas de regresión, es importante tener afirmaciones sólidas sobre el comportamiento existente. Para ello, es posible generar y agregar nuevas aserciones en casos de prueba existentes, esto se conoce como amplificación automática de prueba.

Pruebas de aceptación

Las pruebas de aceptación pueden significar una de dos cosas:

1. Una prueba de humo se utiliza como prueba de aceptación de la construcción antes de nuevas pruebas, por ejemplo, antes de la integración o regresión.
2. Las pruebas de aceptación realizadas por el cliente, a menudo en su entorno de laboratorio en su propio hardware, se conocen como pruebas de aceptación del usuario (UAT). Las pruebas de aceptación pueden realizarse como parte del proceso de entrega entre las dos fases de desarrollo.

Pruebas alfa

Las pruebas alfa son pruebas operativas reales o simuladas por parte de usuarios/clientes potenciales o un equipo de pruebas independiente en la empresa de desarrolladores. sitio. Las pruebas alfa a menudo se emplean para el software listo para usar como una forma de prueba de aceptación interna antes de que el software pase a la prueba beta.

Pruebas beta

Las pruebas beta vienen después de las pruebas alfa y pueden considerarse una forma de prueba de aceptación de usuarios externos. Las versiones del software, conocidas como versiones beta, se lanzan a una audiencia limitada fuera del equipo de programación conocido como probadores beta. El software se lanza a grupos de personas para que las pruebas adicionales puedan garantizar que el producto tenga pocas fallas o errores. Las versiones beta se pueden poner a disposición del público abierto para aumentar el campo de comentarios a un número máximo de usuarios futuros y ofrecer valor antes, durante un período de tiempo prolongado o incluso indefinido (beta perpetua).

Pruebas funcionales vs no funcionales

Las pruebas funcionales se refieren a actividades que verifican una acción o función específica del código. Estos generalmente se encuentran en la documentación de requisitos del código, aunque algunas metodologías de desarrollo funcionan a partir de casos de uso o historias de usuarios. Las pruebas funcionales tienden a responder a la pregunta "puede el usuario hacer esto" o "funciona esta función en particular?"

Las pruebas no funcionales se refieren a aspectos del software que pueden no estar relacionados con una función específica o acción del usuario, como la escalabilidad u otro rendimiento, el comportamiento bajo ciertas restricciones o la seguridad. Las pruebas determinarán el punto de ruptura, el punto en el que los extremos de escalabilidad o rendimiento conducen a una ejecución inestable. Los requisitos no funcionales tienden a ser aquellos que reflejan la calidad del producto, particularmente en el contexto de la perspectiva de idoneidad de sus usuarios.

Pruebas continuas

La prueba continua es el proceso de ejecución de pruebas automatizadas como parte de la canalización de entrega de software para obtener comentarios inmediatos sobre los riesgos comerciales asociados con una versión candidata de software. Las pruebas continuas incluyen la validación tanto de requisitos funcionales como de requisitos no funcionales; el alcance de las pruebas se extiende desde la validación de requisitos ascendentes o historias de usuarios hasta la evaluación de los requisitos del sistema asociados con los objetivos comerciales generales.

Pruebas destructivas

Las pruebas destructivas intentan hacer que el software o un subsistema falle. Verifica que el software funcione correctamente incluso cuando recibe entradas no válidas o inesperadas, estableciendo así la solidez de las rutinas de validación de entradas y gestión de errores. La inyección de fallas de software, en forma de fuzzing, es un ejemplo de prueba de fallas. Varias herramientas de prueba no funcionales comerciales están vinculadas desde la página de inyección de fallas de software; también hay numerosas herramientas de software libre y de código abierto disponibles que realizan pruebas destructivas.

Pruebas de rendimiento del software

Las pruebas de rendimiento generalmente se ejecutan para determinar cómo se desempeña un sistema o subsistema en términos de capacidad de respuesta y estabilidad bajo una carga de trabajo particular. También puede servir para investigar, medir, validar o verificar otros atributos de calidad del sistema, como escalabilidad, confiabilidad y uso de recursos.

La prueba de carga se ocupa principalmente de probar que el sistema puede seguir funcionando bajo una carga específica, ya sea una gran cantidad de datos o una gran cantidad de usuarios. Esto generalmente se conoce como escalabilidad de software. La actividad de prueba de carga relacionada, cuando se realiza como una actividad no funcional, a menudo se denomina prueba de resistencia. Las pruebas de volumen son una forma de probar las funciones del software incluso cuando ciertos componentes (por ejemplo, un archivo o una base de datos) aumentan radicalmente de tamaño. Las pruebas de estrés son una forma de probar la confiabilidad bajo cargas de trabajo inesperadas o raras. Las pruebas de estabilidad (a menudo denominadas pruebas de carga o resistencia) verifican si el software puede funcionar bien de manera continua en un período aceptable o por encima de este.

Hay poco acuerdo sobre cuáles son los objetivos específicos de las pruebas de rendimiento. Los términos prueba de carga, prueba de rendimiento, prueba de escalabilidad y prueba de volumen a menudo se usan indistintamente.

Los sistemas de software en tiempo real tienen restricciones de tiempo estrictas. Para probar si se cumplen las restricciones de tiempo, se utilizan pruebas en tiempo real.

Pruebas de usabilidad

La prueba de usabilidad consiste en verificar si la interfaz de usuario es fácil de usar y comprender. Se refiere principalmente al uso de la aplicación. Este no es un tipo de prueba que pueda automatizarse; se necesitan usuarios humanos reales, siendo monitoreados por diseñadores de UI expertos.

Pruebas de accesibilidad

Las pruebas de accesibilidad se realizan para garantizar que el software sea accesible para personas con discapacidades. Algunas de las pruebas comunes de accesibilidad web son

• Asegurar que el contraste de color entre la fuente y el color de fondo sea adecuado
• Tamaño de la fuente
• Textos alternativos para contenido multimedia
• Capacidad para utilizar el sistema usando el teclado de computadora además del ratón.

Estándares comunes para el cumplimiento

• Americanos con Discapacidad Ley de 1990
• Artículo 508 Enmienda a la Ley de rehabilitación de 1973
• Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C)

Pruebas de seguridad

Las pruebas de seguridad son esenciales para el software que procesa datos confidenciales para evitar la intrusión en el sistema por parte de piratas informáticos.

La Organización Internacional de Normalización (ISO) lo define como un "tipo de prueba realizada para evaluar el grado en que un elemento de prueba y los datos e información asociados están protegidos para que personas o sistemas no autorizados no puedan usar, leerlos o modificarlos, y a las personas o sistemas autorizados no se les niega el acceso a ellos."

Internacionalización y localización

Las pruebas de internacionalización y localización validan que el software se puede usar con diferentes idiomas y regiones geográficas. El proceso de pseudolocalización se utiliza para probar la capacidad de una aplicación para traducirse a otro idioma y facilitar la identificación cuando el proceso de localización puede introducir nuevos errores en el producto.

Las pruebas de globalización verifican que el software esté adaptado a una nueva cultura (como diferentes monedas o zonas horarias).

También se debe probar la traducción real a idiomas humanos. Los posibles errores de localización y globalización incluyen:

• El software se localiza a menudo traduciendo una lista de cadenas fuera de contexto, y el traductor puede elegir la traducción incorrecta para una cadena de fuente ambigua.
• La terminología técnica puede ser inconsistente, si el proyecto es traducido por varias personas sin una coordinación adecuada o si el traductor es imprudente.
• Las traducciones literales de palabra por palabra pueden sonar inapropiado, artificial o demasiado técnico en el idioma objetivo.
• Los mensajes no traducidos en el idioma original pueden quedar codificados en el código fuente.
• Algunos mensajes se pueden crear automáticamente a tiempo de ejecución y la cadena resultante puede ser ungrammatical, funcionalmente incorrecto, engañoso o confuso.
• El software puede utilizar un atajo de teclado que no tiene función en el diseño del teclado del lenguaje fuente, pero se utiliza para escribir caracteres en el diseño del idioma objetivo.
• El software puede carecer de soporte para la codificación de caracteres del lenguaje objetivo.
• Los tamaños de fuentes y fuentes que son apropiados en el idioma de origen pueden ser inapropiados en el idioma de destino; por ejemplo, los caracteres CJK pueden llegar a ser poco legibles, si la fuente es demasiado pequeña.
• Una cadena en el idioma de destino puede ser más larga de lo que el software puede manejar. Esto puede hacer que la cadena parcialmente invisible al usuario o causar que el software se estrelle o desactiva.
• El software puede carecer de apoyo adecuado para leer o escribir texto bidireccional.
• El software puede mostrar imágenes con texto que no se localizó.
• Los sistemas operativos localizados pueden tener archivos de configuración del sistema de diferentes nombres y variables ambientales y diferentes formatos para la fecha y la moneda.

Pruebas de desarrollo

La prueba de desarrollo es un proceso de desarrollo de software que implica la aplicación sincronizada de un amplio espectro de estrategias de prevención y detección de defectos para reducir los riesgos, el tiempo y los costos de desarrollo de software. Lo realiza el desarrollador o ingeniero de software durante la fase de construcción del ciclo de vida del desarrollo de software. Las pruebas de desarrollo tienen como objetivo eliminar los errores de construcción antes de que el código se promueva a otras pruebas; esta estrategia pretende aumentar la calidad del software resultante, así como la eficiencia del proceso de desarrollo general.

Dependiendo de las expectativas de la organización para el desarrollo de software, las pruebas de desarrollo pueden incluir análisis de código estático, análisis de flujo de datos, análisis de métricas, revisiones de código de pares, pruebas unitarias, análisis de cobertura de código, trazabilidad y otras prácticas de prueba de software.

Pruebas A/B

La prueba A/B es un método para ejecutar un experimento controlado para determinar si un cambio propuesto es más efectivo que el enfoque actual. Los clientes son dirigidos a una versión actual (control) de una función oa una versión modificada (tratamiento) y se recopilan datos para determinar qué versión es mejor para lograr el resultado deseado.

Pruebas simultáneas

Las pruebas concurrentes o de concurrencia evalúan el comportamiento y el rendimiento del software y los sistemas que utilizan computación concurrente, generalmente en condiciones normales de uso. Los problemas típicos que expondrá este tipo de prueba son interbloqueos, condiciones de carrera y problemas con el manejo de memoria/recursos compartidos.

Pruebas de conformidad o pruebas de tipo

En las pruebas de software, las pruebas de conformidad verifican que un producto funcione de acuerdo con los estándares especificados. Los compiladores, por ejemplo, se prueban exhaustivamente para determinar si cumplen con el estándar reconocido para ese idioma.

Pruebas de comparación de resultados

La creación de una salida esperada de visualización, ya sea como comparación de datos de texto o capturas de pantalla de la interfaz de usuario, a veces se denomina prueba instantánea o prueba maestra dorada, a diferencia de muchas otras formas de prueba, esto no puede detectar fallas automáticamente y, en cambio, requiere que un humano evalúe el salida por inconsistencias.

Pruebas de propiedad

La prueba de propiedad es una técnica de prueba en la que, en lugar de afirmar que entradas específicas producen resultados esperados específicos, el practicante genera aleatoriamente muchas entradas, ejecuta el programa en todas ellas y afirma la verdad de alguna "propiedad" eso debería ser cierto para cada par de entrada y salida. Por ejemplo, cada entrada de una función de ordenación debe tener la misma longitud que su salida. Cada resultado de una función de clasificación debe ser una lista que aumente monótonamente.

Las bibliotecas de prueba de propiedades permiten al usuario controlar la estrategia mediante la cual se construyen las entradas aleatorias, para garantizar la cobertura de casos degenerados o entradas que presentan patrones específicos que se necesitan para ejercitar completamente los aspectos de la implementación bajo prueba.

Las pruebas de propiedad también se conocen como "pruebas generativas" o "Pruebas QuickCheck" desde que fue presentado y popularizado por la biblioteca Haskell QuickCheck.

Pruebas metamórficas

La prueba metamórfica (MT) es una técnica de prueba de software basada en propiedades, que puede ser un enfoque eficaz para abordar el problema del oráculo de prueba y el problema de generación de casos de prueba. El problema del oráculo de prueba es la dificultad de determinar los resultados esperados de los casos de prueba seleccionados o determinar si los resultados reales concuerdan con los resultados esperados.

Prueba de vídeo

Pruebas de VCR, también conocidas como "pruebas de reproducción" o "grabar/reproducir" testing, es una técnica de prueba para aumentar la confiabilidad y la velocidad de las pruebas de regresión que involucran un componente que es lento o poco confiable para comunicarse, a menudo una API de terceros fuera del control del probador. Implica hacer una grabación ("casete") de las interacciones del sistema con el componente externo, y luego reproducir las interacciones grabadas como sustituto de la comunicación con el sistema externo en ejecuciones posteriores de la prueba.

La técnica fue popularizada en el desarrollo web por la biblioteca Ruby vcr.

Proceso de prueba

Modelo tradicional de desarrollo en cascada

Una práctica común en el desarrollo en cascada es que las pruebas las realice un grupo independiente de evaluadores. Esto puede suceder:

• después de la funcionalidad se desarrolla, pero antes de que se envía al cliente. Esta práctica a menudo resulta en la fase de prueba que se utiliza como un búfer de proyecto para compensar los retrasos del proyecto, lo que compromete el tiempo dedicado a las pruebas.
• al mismo tiempo el proyecto de desarrollo comienza, como un proceso continuo hasta que el proyecto termine.

Sin embargo, incluso en el modelo de desarrollo en cascada, las pruebas unitarias a menudo las realiza el equipo de desarrollo de software, incluso cuando las pruebas adicionales las realiza un equipo independiente.

Modelo de desarrollo ágil o XP

Por el contrario, algunas disciplinas de software emergentes, como la programación extrema y el movimiento de desarrollo de software ágil, se adhieren a un "desarrollo de software basado en pruebas" modelo. En este proceso, los ingenieros de software escriben primero las pruebas unitarias (a menudo con programación en pares en la metodología de programación extrema). Se espera que las pruebas fallen inicialmente. Después de cada prueba fallida, se escribe solo el código suficiente para que pase. Esto significa que los conjuntos de pruebas se actualizan continuamente a medida que se descubren nuevas condiciones de falla y casos de esquina, y se integran con cualquier prueba de regresión que se desarrolle. Las pruebas unitarias se mantienen junto con el resto del código fuente del software y, por lo general, se integran en el proceso de compilación (las pruebas inherentemente interactivas se relegan a un proceso de aceptación de compilación parcialmente manual).

Los objetivos finales de este proceso de prueba son admitir la integración continua y reducir las tasas de defectos.

Esta metodología aumenta el esfuerzo de prueba realizado por el desarrollo, antes de llegar a cualquier equipo de prueba formal. En algunos otros modelos de desarrollo, la mayor parte de la ejecución de la prueba ocurre después de que se hayan definido los requisitos y se haya completado el proceso de codificación.

Un ciclo de prueba de muestra

Aunque existen variaciones entre las organizaciones, existe un ciclo típico para las pruebas. El ejemplo a continuación es común entre las organizaciones que emplean el modelo de desarrollo Waterfall. Las mismas prácticas se encuentran comúnmente en otros modelos de desarrollo, pero pueden no ser tan claras o explícitas.

• Análisis de necesidades: Los exámenes deben comenzar en la fase de requisitos del ciclo de vida de desarrollo de software. Durante la fase de diseño, los probadores trabajan para determinar qué aspectos de un diseño son probados y con qué parámetros funcionan esas pruebas.
• Planificación de pruebas: Estrategia de prueba, plan de prueba, creación de testbed. Dado que muchas actividades se realizarán durante las pruebas, se necesita un plan.
• Desarrollo de pruebas: Procedimientos de prueba, escenarios de prueba, casos de prueba, datasets de prueba, scripts de prueba para usar en software de pruebas.
• Ejecución de pruebas: Los evaluadores ejecutan el software basado en los planes y documentos de prueba y luego reportan cualquier error encontrado al equipo de desarrollo. Esta parte podría ser compleja al realizar pruebas con falta de conocimiento de programación.
• Informe de prueba: Una vez finalizada la prueba, los testadores generan métricas y hacen informes finales sobre su esfuerzo de prueba y si el software probado está listo para su liberación.
• Análisis de resultados de prueba: O Análisis de defectos, es hecho por el equipo de desarrollo generalmente junto con el cliente, con el fin de decidir qué defectos deben ser asignados, fijos, rechazados (es decir, el software encontrado funciona correctamente) o aplazados para ser tratados más adelante.
• Defecto Retesting: Una vez que el equipo de desarrollo ha tratado un defecto, el equipo de pruebas lo prueba.
• Pruebas de regresión: Es común tener un pequeño programa de prueba construido de un subconjunto de pruebas, para cada integración de software nuevo, modificado o fijo, con el fin de asegurar que la última entrega no ha arruinado nada y que el producto de software en su conjunto sigue funcionando correctamente.
• Cierre de prueba: Una vez que la prueba cumple los criterios de salida, las actividades como capturar los productos clave, las lecciones aprendidas, los resultados, los registros, los documentos relacionados con el proyecto son archivados y utilizados como referencia para futuros proyectos.

Pruebas automatizadas

Muchos grupos de programación confían cada vez más en las pruebas automatizadas, especialmente los grupos que utilizan el desarrollo basado en pruebas. Hay muchos marcos para escribir pruebas, y el software de integración continua ejecutará pruebas automáticamente cada vez que el código se registre en un sistema de control de versiones.

Si bien la automatización no puede reproducir todo lo que un ser humano puede hacer (y todas las formas en que piensa hacerlo), puede ser muy útil para las pruebas de regresión. Sin embargo, requiere un conjunto de pruebas bien desarrollado de scripts de prueba para que sea realmente útil.

Herramientas de prueba

Las herramientas de prueba y los depuradores pueden ayudar significativamente a la prueba del programa y la detección de fallas. Las herramientas de prueba/depuración incluyen funciones como:

• Monitores del programa, permitiendo el monitoreo total o parcial del código del programa, incluyendo:
  • Simulador de conjunto de instrucciones, que permite monitorear y rastrear el nivel de instrucción completo
  • Hypervisor, permitiendo el control completo de la ejecución del código del programa incluyendo:-
  • animación del programa, permitiendo la ejecución paso a paso y el punto de ruptura condicional a nivel de fuente o en código de máquina
  • Informes de cobertura del Código
• Depuración formada o depuración simbólica, herramientas que permiten la inspección de variables de programa en error o en puntos escogidos
• Las herramientas de prueba de interfaz gráfica de usuario funcional automatizada (GUI) se utilizan para repetir pruebas a nivel de sistema a través de GUI
• Benchmarks, permitiendo realizar comparaciones de rendimiento de tiempo de ejecución
• Análisis de rendimiento (o herramientas de perfiles) que pueden ayudar a destacar puntos calientes y uso de recursos

Algunas de estas funciones se pueden incorporar en una única herramienta compuesta o en un entorno de desarrollo integrado (IDE).

Capturar y reproducir

pruebas de captura y reproducción consisten en recopilar escenarios de uso de extremo a extremo mientras se interactúa con una aplicación y convertir estos escenarios en casos de prueba. Las posibles aplicaciones de captura y reproducción incluyen la generación de pruebas de regresión. La herramienta SCARPE captura selectivamente un subconjunto de la aplicación bajo estudio mientras se ejecuta. JRapture captura la secuencia de interacciones entre un programa Java en ejecución y componentes en el sistema host, como archivos o eventos en interfaces gráficas de usuario. Estas secuencias luego se pueden reproducir para pruebas basadas en la observación. Saeva et al. Proponga generar pruebas ad-hoc que reproduzcan los rastros de ejecución del usuario registrados para probar los parches candidatos en busca de errores de seguridad críticos. Pankti recopila perfiles de objetos en producción para generar pruebas unitarias diferenciales enfocadas. Esta herramienta mejora la captura y reproducción con la generación sistemática de oráculos de prueba derivados. AutographQL supervisa las solicitudes de los usuarios en las API de GraphQL y genera casos de prueba que pueden detectar fallas de esquema

Medición en pruebas de software

Las medidas de calidad incluyen temas como corrección, integridad, seguridad y requisitos de ISO/IEC 9126 como capacidad, confiabilidad, eficiencia, portabilidad, mantenibilidad, compatibilidad y facilidad de uso.

Hay una serie de métricas o medidas de software que se utilizan con frecuencia para ayudar a determinar el estado del software o la idoneidad de las pruebas.

Jerarquía de dificultad de prueba

Basado en la cantidad de casos de prueba necesarios para construir un conjunto de pruebas completo en cada contexto (es decir, un conjunto de pruebas tal que, si se aplica a la implementación bajo prueba, recopilamos suficiente información para determinar con precisión si el sistema es correcto o incorrecto según alguna especificación), se ha propuesto una jerarquía de dificultad de prueba. Incluye las siguientes clases de comprobabilidad:

• Clase I: existe una suite de prueba completa finita.
• Clase II: cualquier tipo de diferenciación parcial (es decir, cualquier capacidad incompleta para distinguir los sistemas correctos de los sistemas incorrectos) se puede alcanzar con una suite de prueba finita.
• Clase III: existe una suite de prueba completa contable.
• Clase IV: existe una suite de prueba completa.
• Clase V: todos los casos.

Se ha demostrado que cada clase está estrictamente incluida en la siguiente. Por ejemplo, cuando asumimos que el comportamiento de la implementación bajo prueba puede ser denotado por una máquina determinista de estados finitos para algunos conjuntos conocidos finitos de entradas y salidas y con algún número conocido de estados, la prueba pertenece a la Clase I (y todas las clases subsiguientes).). Sin embargo, si no se conoce el número de estados, entonces solo pertenece a todas las clases a partir de la Clase II. Si la implementación bajo prueba debe ser una máquina determinista de estados finitos que falla la especificación para un solo rastro (y sus continuaciones), y se desconoce su número de estados, entonces solo pertenece a las clases de Clase III en adelante. La prueba de máquinas temporales en las que se activan transiciones si las entradas se producen dentro de un intervalo real solo pertenece a las clases a partir de la Clase IV, mientras que la prueba de muchos sistemas no deterministas solo pertenece a la Clase V (pero no todos, y algunos incluso pertenecen a la Clase I). La inclusión en la Clase I no requiere la simplicidad del modelo de cálculo asumido, ya que se ha demostrado que algunos casos de prueba que involucran implementaciones escritas en cualquier lenguaje de programación y pruebas de implementaciones definidas como máquinas que dependen de magnitudes continuas están en la Clase I. Otros elaborados los casos, como el marco de prueba de Matthew Hennessy bajo la semántica obligatoria y las máquinas temporales con tiempos de espera racionales, pertenecen a la Clase II.

Artefactos de prueba

Un proceso de prueba de software puede producir varios artefactos. Los artefactos reales producidos son un factor del modelo de desarrollo de software utilizado, las necesidades de las partes interesadas y de la organización.

Plan de ensayo

Un plan de prueba es un documento que detalla el enfoque que se adoptará para las actividades de prueba previstas. El plan puede incluir aspectos tales como objetivos, alcance, procesos y procedimientos, necesidades de personal y planes de contingencia. El plan de prueba podría venir en la forma de un plan único que incluye todos los tipos de prueba (como un plan de aceptación o de prueba del sistema) y consideraciones de planificación, o puede ser publicado como un plan de prueba maestro que proporciona una visión general de más de un plan de prueba detallado (un plan de un plan). Un plan de prueba puede ser, en algunos casos, parte de una amplia "estrategia de prueba" que documenta enfoques generales de la prueba, que puede ser en sí mismo un plan maestro de pruebas o incluso un artefacto separado.

Matriz de trazabilidad

Una matriz de trazabilidad es una tabla que correlaciona requisitos o documentos de diseño para probar documentos. Se utiliza para cambiar las pruebas cuando se cambian los documentos de origen relacionados, para seleccionar los casos de prueba para la ejecución cuando se planean las pruebas de regresión considerando la cobertura de requisitos.

Caso de prueba

Un caso de prueba normalmente consiste en un identificador único, referencias de requisitos de una especificación de diseño, condiciones previas, eventos, una serie de pasos (también conocidos como acciones) para seguir, entrada, salida, resultado esperado, y el resultado real. Definido clínicamente, un caso de prueba es una entrada y un resultado esperado. Esto puede ser tan terse como 'para la condición x su resultado derivado es y', aunque normalmente los casos de prueba describen con más detalle el escenario de entrada y qué resultados se pueden esperar. Puede ocasionalmente ser una serie de pasos (pero a menudo los pasos están contenidos en un procedimiento de prueba separado que puede ser ejercido contra múltiples casos de prueba, como cuestión de economía) pero con un resultado esperado o resultado esperado. Los campos opcionales son un ID de caso de prueba, paso de prueba o número de orden de ejecución, requisitos relacionados, profundidad, categoría de prueba, autor y casillas de verificación para si la prueba es automatizada y ha sido automatizada. Los casos de prueba más grandes también pueden contener estados o pasos previos y descripciones. Un caso de prueba también debe contener un lugar para el resultado real. Estos pasos se pueden almacenar en un documento de procesador palabra, hoja de cálculo, base de datos u otros repositorios comunes. En un sistema de bases de datos, también puede ser capaz de ver los resultados de las pruebas anteriores, que generaron los resultados, y qué configuración del sistema se utilizó para generar esos resultados. Estos resultados anteriores normalmente se almacenarían en una tabla separada.

Test script

Un script de prueba es un procedimiento o código de programación que replica las acciones del usuario. Inicialmente, el término se deriva del producto del trabajo creado por herramientas automatizadas de prueba de regresión. Un caso de prueba será una base de referencia para crear scripts de prueba usando una herramienta o un programa.

Suite de prueba

El término más común para una colección de casos de prueba es una suite de prueba. La suite de prueba también contiene instrucciones o metas más detalladas para cada colección de casos de prueba. Definitivamente contiene una sección donde el equipo identifica la configuración del sistema utilizada durante las pruebas. Un grupo de casos de prueba también puede contener estados o pasos previos, y descripciones de las siguientes pruebas.

Datos de prueba o prueba

En la mayoría de los casos, se utilizan múltiples conjuntos de valores o datos para probar la misma funcionalidad de una característica particular. Todos los valores de prueba y componentes ambientales cambiantes se recogen en archivos separados y se almacenan como datos de prueba. También es útil proporcionar estos datos al cliente y con el producto o un proyecto. Hay técnicas para generar datos de prueba.

Arnés de ensayo

El software, herramientas, muestras de entrada y salida de datos y configuraciones se denominan colectivamente como un arnés de prueba.

Pruebas

Un informe de los resultados de ejecutar un caso de prueba o una suite de prueba

Certificaciones

Existen varios programas de certificación para respaldar las aspiraciones profesionales de los evaluadores de software y los especialistas en control de calidad. Tenga en cuenta que algunos profesionales argumentan que el campo de pruebas no está listo para la certificación, como se menciona en la sección de controversia.

Controversia

Algunas de las principales controversias sobre las pruebas de software incluyen:

Agile vs. traditional

¿Deberían los testadores aprender a trabajar en condiciones de incertidumbre y cambio constante o deberían apuntar a procesar la "madurez"? El movimiento de pruebas ágiles ha recibido creciente popularidad desde 2006 principalmente en los círculos comerciales, mientras que los proveedores de software gubernamentales y militares utilizan esta metodología, pero también los modelos tradicionales de prueba (por ejemplo, en el modelo Waterfall).

Pruebas automáticas manual vs.

Algunos escritores creen que la automatización de pruebas es tan costosa en relación con su valor que debe ser utilizado escasamente. La automatización de pruebas se puede considerar como una forma de capturar y aplicar los requisitos. Como regla general, cuanto mayor sea el sistema y mayor sea la complejidad, mayor será el ROI en la automatización de pruebas. Además, la inversión en herramientas y experiencia puede amortizarse en múltiples proyectos con el nivel adecuado de intercambio de conocimientos dentro de una organización.

¿Está justificada la existencia del estándar de pruebas de software ISO 29119?

La oposición significativa ha formado parte de las filas de la escuela de pruebas de software impulsada por el contexto sobre la norma ISO 29119. Las asociaciones profesionales de pruebas, como la Sociedad Internacional de Pruebas de Software, han intentado retirar la norma.

Algunos practicantes declaran que el campo de pruebas no está listo para la certificación

Ninguna certificación ofrecida en realidad requiere que el solicitante muestre su capacidad para probar software. Ninguna certificación se basa en un cuerpo de conocimiento ampliamente aceptado. La certificación en sí misma no puede medir la productividad de un individuo, su habilidad o conocimiento práctico, y no puede garantizar su competencia, o profesionalidad como un probador.

Estudios utilizados para mostrar el gasto relativo de los defectos de fijación

Hay opiniones opuestas sobre la aplicabilidad de los estudios utilizados para mostrar el gasto relativo de la fijación de defectos dependiendo de su introducción y detección. Por ejemplo:

Se cree comúnmente que el anterior un defecto se encuentra, el más barato es arreglarlo. La tabla siguiente muestra el costo de fijar el defecto dependiendo de la etapa que se encontró. Por ejemplo, si un problema en los requisitos se encuentra sólo después de la liberación, entonces costaría 10–100 veces más arreglar que si ya se hubiera encontrado en el examen de los requisitos. Con el advenimiento de prácticas modernas de despliegue continuo y servicios basados en la nube, el costo de la redistribución y el mantenimiento puede disminuir con el tiempo.

Costo para arreglar un defecto		Tiempo detectado
		Necesidades	Arquitectura	Construcción	Prueba de sistema	Publicación posterior
Tiempo introducido	Necesidades	1×	3×	5-10×	10×	10-100×
	Arquitectura	–	1×	10×	15×	25-100×
	Construcción	–	–	1×	10×	10–25×

Los datos de los que se extrapola esta tabla son escasos. Laurent Bossavit dice en su análisis:

La curva "proyectos más pequeños" resulta ser de sólo dos equipos de estudiantes de primer año, un tamaño de muestra tan pequeño que extrapolar a "proyectos más pequeños en general" es totalmente indefendible. El estudio GTE no explica sus datos, aparte de decir que provenía de dos proyectos, uno grande y otro pequeño. El documento citado para el proyecto "Safeguard" de Bell Labs niega específicamente haber recogido los datos finos que los puntos de datos de Boehm sugieren. El estudio IBM (documento de Fagan) contiene afirmaciones que parecen contradecir el gráfico de Boehm y no resultados numéricos que claramente corresponden a sus puntos de datos.

Boehm ni siquiera cita un papel para los datos de TRW, excepto cuando escribe para "Making Software" en 2010, y allí citó el artículo original de 1976. Existe un gran estudio realizado en TRW en el momento adecuado para que Boehm lo cite, pero ese documento no contiene el tipo de datos que apoyarían las afirmaciones de Boehm.

Procesos relacionados

Verificación y validación de software

Las pruebas de software se utilizan en asociación con la verificación y validación:

• Verificación: ¿Hemos construido el software bien? (es decir, aplica los requisitos).
• Validación: ¿Hemos construido el software adecuado? (es decir, hacer los entregables satisfacer al cliente).

Los términos verificación y validación suelen usarse indistintamente en la industria; también es común ver estos dos términos definidos con definiciones contradictorias. De acuerdo con el Glosario estándar IEEE de terminología de ingeniería de software:

La verificación es el proceso de evaluación de un sistema o componente para determinar si los productos de una fase de desarrollo determinada satisfacen las condiciones impuestas al comienzo de esa fase.

La validación es el proceso de evaluación de un sistema o componente durante o al final del proceso de desarrollo para determinar si satisface requisitos específicos.

Y, según la norma ISO 9000:

La verificación es confirmación por examen y mediante la provisión de pruebas objetivas que se han cumplido los requisitos específicos.

La validación es confirmación por examen y mediante la provisión de pruebas objetivas de que se han cumplido los requisitos para un uso o aplicación específico previstos.

La contradicción se origina por el uso de los conceptos de requisitos y requisitos especificados pero con diferentes significados.

En el caso de los estándares IEEE, los requisitos especificados, mencionados en la definición de validación, son el conjunto de problemas, necesidades y deseos de las partes interesadas que el software debe resolver y satisfacer. Dichos requisitos se documentan en una Especificación de requisitos de software (SRS). Y, los productos mencionados en la definición de verificación, son los artefactos de salida de cada fase del proceso de desarrollo de software. Estos productos son, de hecho, especificaciones como la Especificación de Diseño Arquitectónico, la Especificación de Diseño Detallado, etc. El SRS también es una especificación, pero no se puede verificar (al menos no en el sentido utilizado aquí, más sobre este tema a continuación).

Pero, para ISO 9000, los requisitos especificados son el conjunto de especificaciones, como se mencionó anteriormente, que deben verificarse. Una especificación, como se explicó anteriormente, es el producto de una fase del proceso de desarrollo de software que recibe otra especificación como entrada. Una especificación se verifica con éxito cuando implementa correctamente su especificación de entrada. Todas las especificaciones se pueden verificar excepto el SRS porque es el primero (aunque se puede validar). Ejemplos: La Especificación de Diseño debe implementar el SRS; y, los artefactos de la fase de Construcción deben implementar la Especificación de Diseño.

Entonces, cuando estas palabras se definen en términos comunes, la aparente contradicción desaparece.

Tanto el SRS como el software deben ser validados. El SRS se puede validar de forma estática consultando a las partes interesadas. Sin embargo, ejecutar alguna implementación parcial del software o un prototipo de cualquier tipo (pruebas dinámicas) y obtener retroalimentación positiva de ellos, puede aumentar aún más la certeza de que el SRS está correctamente formulado. Por otro lado, el software, como producto final y en ejecución (no sus artefactos y documentos, incluido el código fuente) debe validarse dinámicamente con las partes interesadas ejecutando el software y haciéndolos probar.

Algunos podrían argumentar que, para SRS, la entrada son las palabras de las partes interesadas y, por lo tanto, la validación de SRS es lo mismo que la verificación de SRS. Pensar de esta manera no es aconsejable ya que solo causa más confusión. Es mejor pensar en la verificación como un proceso que involucra un documento de entrada formal y técnico.

Control de calidad del software

Las pruebas de software pueden considerarse parte de un proceso de control de calidad del software (SQA). En SQA, los especialistas en procesos de software y los auditores se preocupan por el proceso de desarrollo de software y no solo por los artefactos como la documentación, el código y los sistemas. Examinan y modifican el propio proceso de ingeniería de software para reducir el número de fallos que terminan en el software entregado: la llamada tasa de defectos. Lo que constituye una tasa aceptable de defectos depende de la naturaleza del software; un videojuego de simulador de vuelo tendría una tolerancia a defectos mucho mayor que el software para un avión real. Aunque existen vínculos estrechos con SQA, los departamentos de pruebas a menudo existen de forma independiente y es posible que no exista una función de SQA en algunas empresas.

La prueba de software es una actividad para investigar el software que se está probando con el fin de proporcionar información relacionada con la calidad a las partes interesadas. Por el contrario, QA (garantía de calidad) es la implementación de políticas y procedimientos destinados a evitar que los defectos lleguen a los clientes.