Pruebas de software

La prueba de software es el acto de verificar si el software satisface las expectativas.

Las pruebas de software pueden proporcionar información objetiva e independiente sobre la calidad del software y el riesgo de que falle para un usuario o patrocinador. ^[1]

Las pruebas de software pueden determinar la corrección del software para escenarios específicos , pero no pueden determinar la corrección para todos los escenarios. ^{[2] [3]} No puede encontrar todos los errores .

Basándose en los criterios de medición de la exactitud de un oráculo , las pruebas de software emplean principios y mecanismos que podrían reconocer un problema. Entre los ejemplos de oráculos se incluyen especificaciones , contratos , ^[4] productos comparables, versiones anteriores del mismo producto, inferencias sobre el propósito previsto o esperado, expectativas del usuario o cliente, estándares relevantes y leyes aplicables.

Las pruebas de software suelen ser de naturaleza dinámica, es decir, ejecutar el software para verificar que el resultado real coincida con lo esperado. También pueden ser de naturaleza estática, es decir, revisar el código y su documentación asociada .

Las pruebas de software se utilizan a menudo para responder a la pregunta: ¿El software hace lo que se supone que debe hacer y lo que necesita hacer?

La información obtenida a partir de las pruebas de software se puede utilizar para mejorar el proceso de desarrollo del software. ^{[5] : 41–43}

Las pruebas de software deben seguir un enfoque de "pirámide" en el que la mayoría de las pruebas deben ser pruebas unitarias , seguidas de pruebas de integración y, finalmente, las pruebas de extremo a extremo (e2e) deben tener la proporción más baja. ^{[6] [7] [8]}

Un estudio realizado por el NIST en 2002 reveló que los errores de software le cuestan a la economía estadounidense 59.500 millones de dólares al año. Más de un tercio de este costo podría evitarse si se realizaran mejores pruebas de software. ^{[9] [ dudoso – discutir ]}

La subcontratación de pruebas de software debido a los costos es muy común, y China, Filipinas e India son los destinos preferidos. ^{[ cita requerida ]}

Glenford J. Myers introdujo inicialmente la separación entre la depuración y las pruebas en 1979. ^[10] Aunque su atención se centraba en las pruebas de fallas ("Un caso de prueba exitoso es aquel que detecta un error aún no descubierto". ^{[10] : 16} ), ilustró el deseo de la comunidad de ingeniería de software de separar las actividades fundamentales de desarrollo, como la depuración, de las de verificación.

Las pruebas de software generalmente están orientadas a objetivos.

Las pruebas de software generalmente incluyen el manejo de errores de software: un defecto en el código que causa un resultado no deseado. ^{[11] : 31} Los errores generalmente ralentizan el progreso de las pruebas e involucran la asistencia del programador para depurarlos y corregirlos.

No todos los defectos provocan un fallo. Por ejemplo, un defecto en un código inactivo no se considerará un fallo.

Un defecto que no causa una falla en un momento dado puede volver a ocurrir debido a cambios ambientales. Algunos ejemplos de cambios ambientales incluyen el uso de un nuevo hardware informático , cambios en los datos e interacción con un software diferente. ^[12]

Un solo defecto puede provocar múltiples síntomas de falla.

Las pruebas de software pueden implicar una brecha de requisitos: la omisión de un requisito en el diseño. ^{[5] : 426} Las brechas de requisitos a menudo pueden ser requisitos no funcionales, como capacidad de prueba , escalabilidad , capacidad de mantenimiento , rendimiento y seguridad .

Una limitación fundamental de las pruebas de software es que no es posible realizar pruebas bajo todas las combinaciones de entradas y precondiciones (estado inicial), ni siquiera con un producto simple. ^{[3] : 17–18  [13]} Los defectos que se manifiestan en condiciones inusuales son difíciles de encontrar en las pruebas. Además, las dimensiones no funcionales de la calidad (cómo se supone que debe ser versus lo que se supone que debe hacer ) – usabilidad , escalabilidad , rendimiento , compatibilidad y confiabilidad – pueden ser subjetivas; algo que constituye un valor suficiente para una persona puede no serlo para otra.

Aunque no es posible realizar pruebas para cada entrada posible, es posible realizar pruebas mediante la combinación de métodos para maximizar la cobertura y minimizar las pruebas. ^[14]

Las pruebas se pueden clasificar de muchas maneras. ^[15]

Las pruebas de software se pueden clasificar en niveles según qué parte del sistema de software es el foco de una prueba. ^{[18] [19] [20] [21]}

Existen muchos enfoques para las pruebas de software. Las revisiones , los recorridos o las 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 . ^{[23] [24]}

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

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

Las pruebas pasivas implican verificar el comportamiento del sistema sin ninguna interacción con el producto de software. A diferencia de las pruebas activas, los evaluadores no proporcionan ningún dato de prueba, sino que observan los registros y rastros del sistema. Extraen patrones y comportamientos específicos para tomar algún tipo de decisión. ^[25] Esto está relacionado con la verificación en tiempo de ejecución sin conexión y el análisis de registros .

El tipo de estrategia de pruebas a realizar depende de si las pruebas que se aplicarán a la IUT deben decidirse antes de que comience a ejecutarse el plan de pruebas (pruebas preestablecidas ^[28] ) o si cada entrada que se aplicará a la IUT puede depender dinámicamente de las salidas obtenidas durante la aplicación de las pruebas anteriores (pruebas adaptativas ^{[29] [30]} ).

Las pruebas de software a menudo se pueden dividir en caja blanca y caja negra. Estos dos enfoques se utilizan para describir el punto de vista que adopta el evaluador al diseñar casos de prueba. También se puede aplicar a la metodología de pruebas de software un enfoque híbrido llamado caja gris que incluye aspectos de ambas cajas. ^{[31] [32]}

Las pruebas de caja blanca (también conocidas como pruebas de caja transparente, pruebas de caja de vidrio, pruebas de caja transparente y pruebas estructurales) verifican las estructuras internas o el funcionamiento de un programa, en contraposición a 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 habilidades de programación para diseñar casos de prueba. El evaluador elige entradas para ejercitar rutas a través del código y determina las salidas apropiadas. ^{[31] [32]} Esto es análogo a probar nodos en un circuito, por ejemplo, pruebas en circuito (ICT).

Si bien las pruebas de caja blanca se pueden aplicar en los niveles de unidad , integración y sistema del proceso de prueba de software, generalmente se realizan en el nivel de unidad. ^[33] 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 pruebas 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: ^{[32] [34]}

• Pruebas de API : pruebas de la aplicación utilizando API públicas y privadas (interfaces de programación de aplicaciones)
• Cobertura de código : creación de pruebas para satisfacer algunos criterios de cobertura de 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 de fallas : introducción intencional de fallas para medir la eficacia de las estrategias de prueba
• Métodos de prueba de mutaciones
• Métodos de prueba estática

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 al equipo de software examinar partes de un sistema que rara vez se prueban y garantiza que se hayan probado los puntos de función más importantes. ^[35] La cobertura de código como métrica de software se puede informar como un porcentaje para: ^{[31] [35] [36]}

• Cobertura de funciones , que informa sobre las funciones ejecutadas
• Cobertura de declaración , que informa sobre la cantidad de líneas ejecutadas para completar la prueba.
• Cobertura de decisión , que informa si se han ejecutado tanto la rama Verdadera como la Falso de una prueba determinada.

La cobertura del 100 % de las declaraciones garantiza que todas las rutas o ramas del código (en términos de flujo de control ) se ejecuten al menos una vez. Esto es útil para garantizar una funcionalidad correcta, pero no es suficiente, ya que el mismo código puede procesar diferentes entradas de manera correcta o incorrecta. ^[37]

Las pruebas de caja negra (también conocidas como pruebas funcionales) describen el diseño de casos de prueba sin conocimiento de la implementación, sin leer el código fuente. Los evaluadores solo saben lo que se supone que debe hacer el software, no cómo lo hace. ^[38] Los métodos de prueba de caja negra incluyen: partición de equivalencia , análisis de valores límite , pruebas de todos los pares , tablas de transición de estados , pruebas de tabla de decisión , pruebas difusas , pruebas basadas en modelos , pruebas de casos de uso , pruebas exploratorias y pruebas basadas en especificaciones. ^{[31] [32] [36]}

Las pruebas basadas en especificaciones tienen como objetivo probar la funcionalidad del software de acuerdo con los requisitos aplicables. ^[39] Este nivel de pruebas generalmente requiere que se proporcionen casos de prueba exhaustivos al evaluador, quien luego puede simplemente verificar que para una entrada dada, el valor de salida (o comportamiento), ya sea "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 generalmente funcionales. Las pruebas basadas en especificaciones pueden ser necesarias para asegurar la funcionalidad correcta, pero son insuficientes para protegerse contra situaciones complejas o de alto riesgo. ^[40]

Las pruebas de caja negra se pueden utilizar en cualquier nivel de prueba, aunque normalmente no a nivel de unidad. ^[33]

Prueba de interfaz de componentes

Las pruebas de interfaz de componentes son una variación de las pruebas de caja negra , con el foco en los valores de los datos más allá de las acciones relacionadas de un componente del subsistema. ^[41] La práctica de las pruebas de interfaz de componentes se puede utilizar para verificar el manejo de los datos que pasan entre varias unidades o componentes del subsistema, más allá de las pruebas de integración completa entre esas unidades. ^{[42] [43]} Los datos que se pasan pueden considerarse como "paquetes de mensajes" y se puede verificar el rango o los tipos de datos para los datos generados desde una unidad y probar su validez antes de pasarlos 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 pasados ​​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. ^[42] Los valores de datos inusuales en una interfaz pueden ayudar a explicar el rendimiento inesperado en la siguiente unidad.

El objetivo de las pruebas visuales es proporcionar a los desarrolladores la capacidad de examinar lo que estaba sucediendo en el momento de la falla del software presentando los datos de tal manera que el desarrollador pueda encontrar fácilmente la información que necesita y la información se exprese claramente. ^{[44] [45]}

En el centro de las pruebas visuales está la idea de que mostrarle a alguien un problema (o un fallo de prueba), en lugar de simplemente describirlo, aumenta enormemente la claridad y la comprensión. Por lo tanto, las pruebas visuales requieren la grabación de todo el proceso de prueba, es decir, capturar todo lo que ocurre en el sistema de prueba en formato de video. Los videos de salida se complementan con la entrada en tiempo real del evaluador a través de una cámara web con imagen en 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 evaluadores pueden mostrar el problema (y los eventos que lo provocaron) al desarrollador en lugar de simplemente describirlo, y la necesidad de replicar los fallos de las pruebas dejará de existir en muchos casos. El desarrollador tendrá todas las pruebas que necesita de un fallo de prueba y, en cambio, puede centrarse en la causa del fallo y en cómo solucionarlo.

Las pruebas ad hoc y exploratorias son metodologías importantes para verificar la integridad del software porque requieren menos tiempo de preparación para su implementación, mientras que los errores importantes se pueden encontrar rápidamente. ^[46] En las pruebas ad hoc, donde las pruebas se realizan de manera improvisada, la capacidad del o los evaluadores de 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. ^[46] 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. ^[46]

Las pruebas de caja gris (en inglés, gray-box testing) implican el uso de los conocimientos sobre las estructuras de datos internas y los algoritmos con el fin de diseñar pruebas mientras se ejecutan esas pruebas en el nivel de usuario o de caja negra. El evaluador a menudo tendrá acceso tanto al "código fuente como al binario ejecutable". ^[47] Las pruebas de caja gris también pueden incluir ingeniería inversa (utilizando análisis de código dinámico) para determinar, por ejemplo, valores límite o mensajes de error. ^[47] La ​​manipulación de los datos de entrada y el formateo de la salida no se califican como pruebas de caja gris, ya que la entrada y la salida están claramente fuera de la "caja negra" que llamamos 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 las interfaces están expuestas para la prueba.

Al conocer los conceptos subyacentes de cómo funciona el software, el evaluador 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 sentencias SQL contra 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. ^[48]

Con el concepto de pruebas de caja gris, esta "distinción arbitraria" entre pruebas de caja negra y pruebas de caja blanca se ha desvanecido un poco. ^[33]

Una causa común de falla de software (real o percibida) es la falta de compatibilidad con otro software de aplicación , sistemas operativos (o versiones de sistemas operativos , antiguas o nuevas) o entornos de destino que difieren en gran medida del original (como una aplicación de terminal o GUI destinada a ejecutarse en el escritorio que ahora se requiere que se convierta en una aplicación web , que debe mostrarse 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 software solo en la última versión del entorno de destino, que puede que no todos los usuarios estén ejecutando. Esto da como resultado la consecuencia no deseada de que el último trabajo puede no funcionar en versiones anteriores del entorno de destino o en hardware más antiguo que las versiones anteriores del entorno de destino eran capaces de usar. A veces, estos problemas se pueden solucionar abstrayendo de manera proactiva la funcionalidad del sistema operativo en un módulo o biblioteca de programa independiente .

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

Las pruebas de humo consisten en intentos mínimos de operar el software, diseñados para determinar si existen problemas básicos que impidan su funcionamiento. Estas pruebas se pueden utilizar como prueba de verificación de la compilació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, buscan descubrir regresiones de software , como características degradadas o perdidas, incluidos errores antiguos que han regresado. Tales regresiones ocurren siempre que la funcionalidad del software que anteriormente funcionaba correctamente, deja de funcionar como se esperaba. Por lo general, las regresiones ocurren como una consecuencia no deseada de los cambios del programa, cuando la parte recién desarrollada del software colisiona con el código previamente existente. Las pruebas de regresión suelen ser el mayor esfuerzo de prueba en el desarrollo de software comercial, ^[50] debido a la verificación de numerosos detalles en las características del software anterior, e incluso se puede desarrollar software nuevo mientras se utilizan algunos casos de prueba antiguos para probar partes del nuevo diseño para garantizar que la funcionalidad anterior aún se admita.

Los métodos habituales de pruebas de regresión incluyen volver a ejecutar conjuntos de casos de prueba anteriores y comprobar si han vuelto a aparecer los fallos corregidos anteriormente. La profundidad de las pruebas depende de la fase del proceso de lanzamiento y del riesgo de las características añadidas. Pueden ser completas, en el caso de los cambios añadidos en una fase avanzada del lanzamiento o que se consideren arriesgados, o muy superficiales, consistentes en pruebas positivas de cada característica, si los cambios se realizan en una fase temprana del lanzamiento o se consideran de bajo riesgo.

Las pruebas de aceptación son pruebas a nivel de sistema para garantizar que el software cumpla con las expectativas del cliente. ^{[51] [52] [53] [54]}

Las pruebas de aceptación se pueden realizar como parte del proceso de transferencia entre dos fases de desarrollo. ^{[ cita requerida ]}

Las pruebas se agrupan frecuentemente en estos niveles según dónde se realizan en el proceso de desarrollo de software o según el nivel de especificidad de la prueba. ^[54]

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

A veces, la UAT la realiza el cliente, en su entorno y en su propio hardware.

La OAT 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 . La 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 que se va a respaldar o que se va a convertir 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 la 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 o corrompa parcialmente su entorno operativo ni provoque que otros procesos dentro de ese entorno dejen de funcionar. ^[55]

Las pruebas de aceptación contractual se realizan en función de los criterios de aceptación del contrato definidos durante el acuerdo del contrato, mientras que las pruebas de aceptación regulatorias se realizan en función de las regulaciones pertinentes al producto de software. Ambas pruebas pueden ser realizadas por usuarios o evaluadores independientes. Las pruebas de aceptación regulatorias a veces implican que las agencias regulatorias auditen los resultados de las pruebas. ^[54]

Las pruebas alfa son pruebas operativas simuladas o reales que realizan usuarios/clientes potenciales o un equipo de pruebas independiente en las instalaciones de los desarrolladores. Las pruebas alfa se emplean a menudo para software comercial como una forma de prueba de aceptación interna antes de que el software pase a la fase de prueba beta. ^[56]

Las pruebas beta se realizan 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, conocida como probadores beta. El software se lanza a grupos de personas para que las pruebas posteriores 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 retroalimentación a un número máximo de futuros usuarios y para entregar valor antes, durante un período de tiempo extendido o incluso indefinido ( beta perpetua ). ^[57]

Las pruebas funcionales se refieren a actividades que verifican una acción o función específica del código. Por lo general, 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 usuario. Las pruebas funcionales tienden a responder a la pregunta "¿puede el usuario hacer esto?" o "¿funciona esta característica en particular?".

Las pruebas no funcionales se refieren a aspectos del software que pueden no estar relacionados con una función específica o una 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.

Las pruebas continuas son el proceso de ejecutar pruebas automatizadas como parte del proceso de entrega de software para obtener retroalimentación inmediata sobre los riesgos comerciales asociados con un candidato a lanzamiento de software. ^{[58] [59]} Las pruebas continuas incluyen la validación tanto de los requisitos funcionales como de los no funcionales ; el alcance de las pruebas se extiende desde la validación de los requisitos de abajo hacia arriba o las historias de usuario hasta la evaluación de los requisitos del sistema asociados con los objetivos comerciales generales. ^{[60] [61]}

Las pruebas destructivas intentan provocar que el software o un subsistema falle. Verifican 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. ^{[ cita requerida ]} La inyección de fallas de software , en forma de fuzzing , es un ejemplo de prueba de fallas. Varias herramientas comerciales de prueba no funcional 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.

Las pruebas de rendimiento se realizan generalmente para determinar el rendimiento de un sistema o subsistema en términos de capacidad de respuesta y estabilidad bajo una carga de trabajo particular. También pueden servir para investigar, medir, validar o verificar otros atributos de calidad del sistema, como la escalabilidad, la confiabilidad y el uso de recursos.

Las pruebas de carga se ocupan principalmente de probar que el sistema puede seguir funcionando bajo una carga específica, ya sea grandes cantidades de datos o una gran cantidad de usuarios . Esto generalmente se conoce como escalabilidad del software . La actividad de prueba de carga relacionada, cuando se realiza como una actividad no funcional, a menudo se conoce como 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 poco frecuentes. Las pruebas de estabilidad (a menudo denominadas pruebas de carga o resistencia) verifican si el software puede funcionar bien de manera continua durante un período aceptable o por encima de él.

Existe poco consenso sobre cuáles son los objetivos específicos de las pruebas de rendimiento. Los términos pruebas de carga, pruebas de rendimiento, pruebas de escalabilidad y pruebas de volumen suelen usarse indistintamente.

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

Las pruebas de usabilidad sirven para comprobar si la interfaz de usuario es fácil de usar y comprender. Se centran principalmente en el uso de la aplicación. No se trata de un tipo de prueba que se pueda automatizar; se necesitan usuarios humanos reales supervisados ​​por diseñadores de interfaz de usuario expertos .

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

• Asegurarse de que el contraste de color entre la fuente y el color de fondo sea apropiado
• Tamaño de fuente
• Textos alternativos para contenidos multimedia
• Capacidad de utilizar el sistema utilizando el teclado de la computadora además del mouse.

• Ley de Estadounidenses con Discapacidades de 1990
• Enmienda de la Sección 508 a la Ley de Rehabilitación de 1973
• Iniciativa de Accesibilidad Web (WAI) del Consorcio World Wide Web (W3C)

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

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

Las pruebas de internacionalización y localización validan que el software se puede utilizar en 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 de 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. ^[63]

También es necesario probar la traducción real a los idiomas humanos. Entre los posibles errores de localización y globalización se incluyen los siguientes:

• Es posible que algunos mensajes no estén traducidos.
• El software a menudo se localiza traduciendo una lista de cadenas fuera de contexto, y el traductor puede elegir la traducción incorrecta para una cadena de origen ambigua.
• La terminología técnica puede volverse inconsistente si el proyecto es traducido por varias personas sin la adecuada coordinación o si el traductor es imprudente.
• Las traducciones literales palabra por palabra pueden sonar inapropiadas, artificiales o demasiado técnicas en el idioma de destino.
• Los mensajes no traducidos en el idioma original pueden estar codificados en el código fuente y, por lo tanto, ser intraducibles.
• Algunos mensajes pueden crearse automáticamente en tiempo de ejecución y la cadena resultante puede ser gramaticalmente incorrecta, funcionalmente incorrecta, engañosa o confusa.
• El software puede utilizar un atajo de teclado que no tiene ninguna función en el diseño del teclado del idioma de origen , pero se utiliza para escribir caracteres en el diseño del idioma de destino.
• Es posible que el software no sea compatible con la codificación de caracteres del idioma de destino.
• Las fuentes y tamaños de fuente que son apropiados en el idioma de origen pueden ser inapropiados en el idioma de destino; por ejemplo, los caracteres CJK pueden volverse ilegibles 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 procesar. Esto puede hacer que la cadena sea parcialmente invisible para el usuario o provocar que el software se bloquee o funcione mal.
• Es posible que el software carezca de soporte adecuado para leer o escribir texto bidireccional .
• El software puede mostrar imágenes con texto no localizado.
• Los sistemas operativos localizados pueden tener archivos de configuración del sistema y variables de entorno con nombres diferentes , y diferentes formatos para la fecha y la moneda .

Las pruebas de desarrollo son 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 con el fin de reducir los riesgos, el tiempo y los costos del desarrollo de software. Las 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 promocione para otras pruebas; esta estrategia tiene como objetivo 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 por pares, pruebas unitarias, análisis de cobertura de código, trazabilidad y otras prácticas de pruebas de software.

Las pruebas A/B son un método para ejecutar un experimento controlado para determinar si un cambio propuesto es más eficaz que el enfoque actual. Se dirige a los clientes a una versión actual (control) de una función o a una versión modificada (tratamiento) y se recopilan datos para determinar qué versión es mejor para lograr el resultado deseado.

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 de uso normales. Los problemas típicos que este tipo de pruebas expondrá son bloqueos, condiciones de carrera y problemas con el manejo de recursos/memoria compartida.

En las pruebas de software, las pruebas de conformidad verifican que un producto funciona de acuerdo con los estándares especificados. Los compiladores, por ejemplo, se someten a pruebas exhaustivas para determinar si cumplen con el estándar reconocido para ese lenguaje.

La creación de una pantalla con el resultado esperado, ya sea como comparación de datos de texto o capturas de pantalla de la interfaz de usuario, ^{[3] : 195} a veces se denomina prueba de instantáneas o prueba maestra dorada; a diferencia de muchas otras formas de prueba, esta no puede detectar fallas automáticamente y, en cambio, requiere que un humano evalúe el resultado en busca de inconsistencias.

La prueba de propiedades es una técnica de prueba en la que, en lugar de afirmar que determinadas entradas producen determinadas salidas esperadas, el profesional genera aleatoriamente muchas entradas, ejecuta el programa en todas ellas y afirma la veracidad de alguna "propiedad" que debería ser cierta para cada par de entrada y salida. Por ejemplo, cada salida de una función de serialización debería ser aceptada por la función de deserialización correspondiente, y cada salida de una función de ordenación debería ser una lista monótonamente creciente que contenga exactamente los mismos elementos que su entrada.

Las bibliotecas de pruebas 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 son necesarios para ejercitar completamente aspectos de la implementación bajo prueba.

Las pruebas de propiedades también se conocen a veces como "pruebas generativas" o "pruebas QuickCheck", ya que fueron introducidas y popularizadas por la biblioteca Haskell QuickCheck . ^[64]

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

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

La técnica se popularizó en el desarrollo web gracias a la biblioteca Ruby vcr.

En una organización, los evaluadores pueden estar en un equipo separado del resto del equipo de desarrollo de software o pueden estar integrados en un equipo. Las pruebas de software también pueden ser realizadas por evaluadores de software no especializados.

En la década de 1980, el término probador de software comenzó a usarse para designar una profesión separada.

Los roles y títulos notables en pruebas de software incluyen: ^[65] gerente de pruebas , líder de pruebas , analista de pruebas , diseñador de pruebas , probador , desarrollador de automatización y administrador de pruebas . ^[66]

Las organizaciones que desarrollan software realizan pruebas de manera diferente, pero existen patrones comunes. ^[2]

En el desarrollo en cascada , las pruebas se realizan generalmente después de que se completa el código, pero antes de que el producto se envíe al cliente. ^[67] Esta práctica a menudo da como resultado que la fase de prueba se use como un amortiguador del proyecto para compensar los retrasos del proyecto, comprometiendo así el tiempo dedicado a las pruebas. ^{[10] : 145–146}

Algunos sostienen que el proceso en cascada permite que las pruebas comiencen cuando se inicia el proyecto de desarrollo y que sean un proceso continuo hasta que el proyecto finalice. ^[68]

El desarrollo de software ágil generalmente implica realizar pruebas mientras se escribe el código y organizar equipos con programadores y evaluadores y con miembros del equipo que realizan tanto la programación como las pruebas.

Una práctica ágil, el desarrollo de software basado en pruebas (TDD), es una forma de realizar pruebas unitarias en las que se realizan pruebas a nivel de unidad mientras se escribe el código del producto. ^[69] El código de prueba se actualiza a medida que se agregan nuevas características y se descubren condiciones de falla (se corrigen errores). Por lo general, el código de prueba unitaria se mantiene con el código del proyecto, se integra en el proceso de compilación y se ejecuta en cada compilación y como parte de las pruebas de regresión. Los objetivos de esta integración continua son respaldar el desarrollo y reducir los defectos. ^{[70] [69]}

Incluso en organizaciones que separan los equipos por funciones de programación y prueba, muchas veces hacen que los programadores realicen pruebas unitarias . ^[71]

El ejemplo que se muestra a continuación es común para el desarrollo en cascada. Las mismas actividades se encuentran comúnmente en otros modelos de desarrollo, pero podrían describirse de manera diferente.

• Análisis de requisitos : las pruebas deben comenzar en la fase de requisitos del ciclo de vida del desarrollo de software . Durante la fase de diseño, los evaluadores trabajan para determinar qué aspectos de un diseño se pueden probar y con qué parámetros funcionan esas pruebas.
• Planificación de pruebas: estrategia de pruebas , plan de pruebas , creación de un banco de pruebas . Dado que durante las pruebas se realizarán muchas actividades, es necesario contar con un plan.
• Desarrollo de pruebas: procedimientos de prueba, escenarios de prueba , casos de prueba , conjuntos de datos de prueba, scripts de prueba para usar en la prueba de software.
• Ejecución de pruebas: los evaluadores ejecutan el software según los planes y los documentos de prueba y luego informan al equipo de desarrollo sobre los errores que encuentren. Esta parte puede resultar compleja cuando se ejecutan pruebas sin conocimientos de programación.
• Informes de pruebas: una vez finalizadas las pruebas, los evaluadores generan métricas y elaboran informes finales sobre su esfuerzo de prueba y si el software probado está listo o no para su lanzamiento.
• Análisis de resultados de pruebas: o análisis de defectos , lo realiza el equipo de desarrollo generalmente junto con el cliente, para decidir qué defectos se deben asignar, reparar, rechazar (es decir, encontrar que el software funciona correctamente) o posponer para tratarlos más adelante.
• Nueva prueba de defectos: una vez que el equipo de desarrollo ha solucionado un defecto, el equipo de pruebas lo vuelve a probar.
• Pruebas de regresión : es común tener un pequeño programa de pruebas construido a partir de un subconjunto de pruebas, para cada integración de software nuevo, modificado o reparado, con el fin de garantizar que la última entrega no haya arruinado nada y que el producto de software en su conjunto todavía esté funcionando correctamente.
• Cierre de la prueba: una vez que la prueba cumple con los criterios de salida, las actividades como la captura de los resultados clave, lecciones aprendidas, resultados, registros, documentos relacionados con el proyecto se archivan y se utilizan como referencia para proyectos futuros.

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

• Verificación: ¿Hemos construido correctamente el software? (es decir, ¿implementa los requisitos?)
• Validación: ¿Hemos construido el software correcto? (es decir, ¿los resultados satisfacen al cliente?)

Los términos verificación y validación se utilizan comúnmente de manera intercambiable en la industria; también es común ver estos dos términos definidos con definiciones contradictorias. Según el Glosario estándar IEEE de terminología de ingeniería de software : ^{[11] : 80–81}

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

La validación es el proceso de evaluar un sistema o componente durante o al final del proceso de desarrollo para determinar si satisface los requisitos especificados.

Y, según la norma ISO 9000:

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

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

La contradicción se debe al uso de los conceptos de requisitos y requisitos especificados pero con significados diferentes.

En el caso de las normas 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. La SRS también es una especificación, pero no se puede verificar (al menos no en el sentido que se le da aquí, más sobre este tema a continuación).

Pero, para la ISO 9000, los requisitos especificados son el conjunto de especificaciones, como se acaba de mencionar, que deben ser verificadas. 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 la SRS porque es la primera (aunque se puede validar). Ejemplos: La Especificación de Diseño debe implementar la SRS; y, los artefactos de la fase de Construcción deben implementar la Especificación de Diseño.

Así, 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 puede ser validado estáticamente consultando a las partes interesadas. Sin embargo, ejecutar una implementación parcial del software o un prototipo de cualquier tipo (prueba dinámica) 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 funcionamiento (no sus artefactos y documentos, incluido el código fuente) debe ser validado dinámicamente con las partes interesadas ejecutando el software y pidiéndoles que lo prueben.

Algunos podrían argumentar que, en el caso de los sistemas de información estadística, el insumo son las palabras de las partes interesadas y, por lo tanto, la validación de los sistemas de información estadística es lo mismo que la verificación de los sistemas de información estadística. Pensar de esta manera no es aconsejable, ya que solo genera más confusión. Es mejor pensar en la verificación como un proceso que implica un documento de insumo formal y técnico.

En algunas organizaciones, las pruebas de software forman parte de un proceso de aseguramiento de la calidad del software (SQA, por sus siglas en inglés). ^{[3] : 347} En SQA, los especialistas en procesos de software y los auditores se ocupan del proceso de desarrollo de software, más que solo de los artefactos como la documentación, el código y los sistemas. Examinan y modifican el proceso de ingeniería de software en sí para reducir la cantidad de fallas que terminan en el software entregado: la llamada tasa de defectos. Lo que constituye una tasa de defectos aceptable depende de la naturaleza del software; un videojuego de simulación de vuelo tendría una tolerancia a los 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 puede que no exista una función de SQA en algunas empresas. ^{[ cita requerida ]}

La prueba de software es una actividad que se realiza 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, el control de calidad (QA ) es la implementación de políticas y procedimientos destinados a evitar que los defectos lleguen a los clientes.

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

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.

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

Un plan de pruebas es un documento que detalla el enfoque que se adoptará para las actividades de prueba previstas. El plan puede incluir aspectos como objetivos, alcance, procesos y procedimientos, requisitos de personal y planes de contingencia. ^[51] El plan de pruebas puede presentarse en forma de un único plan que incluya todos los tipos de pruebas (como un plan de pruebas de aceptación o de sistema) y consideraciones de planificación, o puede emitirse como un plan de pruebas maestro que proporcione una descripción general de más de un plan de pruebas detallado (un plan de un plan). ^[51] Un plan de pruebas puede ser, en algunos casos, parte de una amplia " estrategia de pruebas " que documenta los enfoques generales de las pruebas, que puede ser en sí misma un plan de pruebas maestro o incluso un artefacto separado.

Un caso de prueba normalmente consta de un identificador único, referencias de requisitos de una especificación de diseño, precondiciones, eventos, una serie de pasos (también conocidos como acciones) a seguir, entrada, salida, resultado esperado y el resultado real. Clínicamente definido, un caso de prueba es una entrada y un resultado esperado. ^[74] Esto puede ser tan conciso 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 podrían esperarse. Ocasionalmente puede ser una serie de pasos (pero a menudo los pasos están contenidos en un procedimiento de prueba separado que puede ejercerse contra múltiples casos de prueba, como una 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, requisito(s) relacionado(s), profundidad, categoría de prueba, autor y casillas de verificación para si la prueba es automatizable y ha sido automatizada. Los casos de prueba más grandes también pueden contener estados o pasos de prerrequisitos 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 de texto, una hoja de cálculo, una base de datos u otros repositorios comunes. En un sistema de base de datos, también es posible ver los resultados de pruebas anteriores, quién generó los resultados y qué configuración del sistema se utilizó para generar esos resultados. Estos resultados anteriores normalmente se almacenan en una tabla separada.

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

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

El software, las herramientas, las muestras de entrada y salida de datos y las configuraciones se denominan colectivamente " arnés de pruebas" .

Una ejecución de prueba es una colección de casos de prueba o conjuntos de pruebas que el usuario ejecuta y compara los resultados esperados con los reales. Una vez finalizada, se puede generar un informe de todas las pruebas ejecutadas.

Existen varios programas de certificación para respaldar las aspiraciones profesionales de los evaluadores de software y los especialistas en control de calidad. Algunos profesionales sostienen que el campo de las pruebas no está listo para la certificación, como se mencionó en la sección de controversias.

Algunas de las principales controversias en materia de pruebas de software incluyen:

Ágil vs. tradicional

¿Los testers deberían aprender a trabajar en condiciones de incertidumbre y cambio constante o deberían apuntar a la "madurez" del proceso ? El movimiento de pruebas ágiles ha ganado popularidad desde principios de los años 2000, principalmente en círculos comerciales ^{[76] [77],} mientras que los proveedores de software gubernamentales y militares ^[78] utilizan esta metodología, pero también los modelos tradicionales de prueba final (por ejemplo, en el modelo Waterfall ). ^{[ cita requerida ]}

Pruebas manuales vs. pruebas automatizadas

Algunos autores creen que la automatización de pruebas es tan cara en relación con su valor que debería utilizarse con moderación. ^[79] La automatización de pruebas puede considerarse entonces como una forma de capturar e implementar los requisitos. Como regla general, cuanto mayor sea el sistema y mayor la complejidad, mayor será el retorno de la inversión en la automatización de pruebas. Además, la inversión en herramientas y experiencia puede amortizarse en varios proyectos con el nivel adecuado de intercambio de conocimientos dentro de una organización.

¿Está justificada la existencia de la norma ISO 29119 de pruebas de software?

Se ha formado una oposición significativa en las filas de la escuela de pruebas de software basada en el contexto con respecto a la norma ISO 29119. Las asociaciones de pruebas profesionales, como la Sociedad Internacional de Pruebas de Software, han intentado que se retire la norma. ^{[80] [81]}

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

^[82] Actualmente, ninguna certificación que se ofrece exige que el solicitante demuestre su capacidad para probar software. Ninguna certificación se basa en un conjunto de conocimientos ampliamente aceptado. La certificación en sí no puede medir la productividad de un individuo, su habilidad o su conocimiento práctico, y no puede garantizar su competencia o profesionalismo como evaluador. ^[83]

Estudios utilizados para mostrar el gasto relativo de reparar defectos

Existen opiniones encontradas sobre la aplicabilidad de los estudios utilizados para mostrar el costo relativo de la reparación de defectos en función de su introducción y detección. Por ejemplo:

Se cree comúnmente que cuanto antes se encuentre un defecto, más barato será solucionarlo. La siguiente tabla muestra el costo de solucionar el defecto dependiendo de la etapa en la que se encontró. ^[84] Por ejemplo, si un problema en los requisitos se encuentra recién después de la publicación, entonces costaría entre 10 y 100 veces más solucionarlo que si ya se hubiera encontrado en la revisión de requisitos. Con la llegada de las prácticas modernas de implementación continua y los servicios basados ​​en la nube, el costo de la reimplementación y el mantenimiento puede disminuir con el tiempo.

Costo de reparar un defecto		Tiempo detectado
		Requisitos	Arquitectura	Construcción	Prueba del sistema	Post-lanzamiento
Tiempo introducido	Requisitos	1×	3×	5–10×	10×	10–100×
	Arquitectura	–	1×	10×	15×	25–100×
	Construcción	–	–	1×	10×	10–25×

Los datos a partir de los cuales se extrapola esta tabla son escasos. Laurent Bossavit afirma en su análisis:

La curva de "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 la extrapolación a "proyectos más pequeños en general" es totalmente indefendible. El estudio de GTE no explica sus datos, más allá de decir que provienen de dos proyectos, uno grande y otro pequeño. El artículo citado para el proyecto "Safeguard" de Bell Labs niega específicamente haber recopilado los datos de grano fino que sugieren los puntos de datos de Boehm. El estudio de IBM (el artículo de Fagan) contiene afirmaciones que parecen contradecir el gráfico de Boehm y ningún resultado numérico que corresponda claramente a sus puntos de datos.

Boehm ni siquiera cita un artículo que apoye los datos de TRW, excepto cuando escribió para "Making Software" en 2010, y allí citó el artículo original de 1976. Existe un estudio de gran tamaño realizado en TRW en el momento adecuado para que Boehm lo cite, pero ese artículo no contiene el tipo de datos que respaldarían las afirmaciones de Boehm. ^[85]

• Meyer, Bertrand (agosto de 2008). "Siete principios de las pruebas de software" (PDF) . Computer . Vol. 41, núm. 8. págs. 99–101. doi :10.1109/MC.2008.306 . Consultado el 21 de noviembre de 2017 .

Wikimedia Commons tiene medios relacionados con Pruebas de software .

En Wikiversidad , puedes aprender más y enseñar a otros sobre pruebas de software en el Departamento de Pruebas de Software.

• "Software que hace que el software sea mejor" Economist.com