Pruebas de software

Las pruebas de software normalmente incluyen el manejo de errores de software , un defecto en el código que causa un resultado no deseado. ^{[ 12 ] : 31} Los errores generalmente ralentizan el progreso de las pruebas y requieren la asistencia del programador para depurar y corregir.

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

Un defecto que no causa fallas en un momento dado puede provocar fallas posteriormente debido a cambios en el entorno. Ejemplos de cambios en el entorno incluyen el uso de nuevo hardware informático , cambios en los datos y la interacción con software diferente. ^{[ 13 ]}

Un único defecto puede provocar múltiples síntomas de fallo.

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

Una limitación fundamental de las pruebas de software es que probar bajo todas las combinaciones de entradas y precondiciones (estado inicial) no es factible, incluso con un producto simple. ^{[ 3 ] : 17–18 [ 14 ]} 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 frente a lo que se supone que debe hacer ) – usabilidad , escalabilidad , rendimiento , compatibilidad y fiabilidad – pueden ser subjetivas; algo que constituye un valor suficiente para una persona puede no serlo para otra.

Aunque probar para cada posible entrada no es factible, las pruebas pueden usar combinatoria para maximizar la cobertura y minimizar las pruebas. ^{[ 15 ]}

Las pruebas de software se pueden categorizar en niveles según la cantidad del sistema de software que se analiza. ^{[ 19 ] [ 20 ] [ 21 ] [ 22 ]}

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 dado de casos de prueba se denomina pruebas dinámicas . ^{[ 24 ] [ 25 ]}

Las pruebas estáticas suelen ser implícitas, como la revisión de pruebas, además de cuando las herramientas de programación/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 estático del programa . Las pruebas dinámicas se realizan cuando se ejecuta el programa. Las pruebas dinámicas pueden comenzar antes de que el programa esté completo al 100% para probar secciones particulares del código y se aplican a funciones o módulos discretos. ^{[ 24 ] [ 25 ]} Las técnicas típicas para estas son el uso de stubs /controladores o la ejecución desde un entorno de depuración . ^{[ 25 ]}

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

Las pruebas pasivas consisten en verificar el comportamiento del sistema sin interactuar con el producto de software. A diferencia de las pruebas activas, los evaluadores no proporcionan datos de prueba, sino que analizan los registros y trazas del sistema. Buscan patrones y comportamientos específicos para tomar decisiones. ^{[ 26 ]} Esto se relaciona con la verificación en tiempo de ejecución fuera de línea y el análisis de registros .

El tipo de estrategia de prueba que se debe realizar depende de si las pruebas que se aplicarán a la IUT deben decidirse antes de que comience la ejecución del plan de prueba (pruebas preestablecidas ^{[ 29 ]} ) 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 ^{[ 30 ] [ 31 ]} ).

Las pruebas de software suelen dividirse en pruebas de caja blanca y de caja negra. Estos dos enfoques se utilizan para describir el punto de vista que adopta el evaluador al diseñar los casos de prueba. También se puede aplicar a la metodología de pruebas de software un enfoque híbrido denominado de caja gris, que incluye aspectos de ambos enfoques. ^{[ 32 ] [ 33 ]}

Pruebas de caja blanca

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

Aunque las pruebas de caja blanca pueden aplicarse a nivel de unidad , integración y sistema en el proceso de pruebas de software, generalmente se realizan a nivel de unidad. ^{[ 34 ]} Permiten probar rutas dentro de una unidad, rutas entre unidades durante la integración y entre subsistemas durante una prueba a nivel de sistema. Si bien este método de diseño de pruebas puede revelar muchos errores o problemas, es posible que no detecte partes no implementadas de la especificación ni requisitos faltantes.

Las técnicas utilizadas en las pruebas de caja blanca incluyen: ^{[ 33 ] [ 35 ]}

• Pruebas de API : pruebas de la aplicación utilizando API (interfaces de programación de aplicaciones) públicas y privadas.
• Cobertura de código : creación de pruebas para satisfacer ciertos criterios de cobertura de código (por ejemplo, el diseñador de pruebas puede crear pruebas para que todas las instrucciones del programa se ejecuten al menos una vez).
• Métodos de inyección de fallos : introducción intencionada de fallos para evaluar la eficacia de las estrategias de prueba.
• Métodos de prueba de mutaciones
• Métodos de ensayo estático

Las herramientas de cobertura de código pueden evaluar la completitud 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. ^{[ 36 ]} La cobertura de código como métrica de software se puede informar como un porcentaje para: ^{[ 32 ] [ 36 ] [ 37 ]}

• Cobertura de funciones , que informa sobre las funciones ejecutadas
• Cobertura de sentencias , que informa sobre el número de líneas ejecutadas para completar la prueba.
• Cobertura de decisiones , que informa si se han ejecutado tanto la rama Verdadera como la Falso de una prueba determinada.

La cobertura de sentencias del 100 % 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 asegurar una funcionalidad correcta, pero no suficiente, ya que el mismo código puede procesar diferentes entradas de forma correcta o incorrecta. ^{[ 38 ]}

Pruebas de caja negra

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. ^{[ 39 ]} 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 tablas de decisión , pruebas de fuzzing , pruebas basadas en modelos , pruebas de casos de uso , pruebas exploratorias y pruebas basadas en especificaciones. ^{[ 32 ] [ 33 ] [ 37 ]}

Las pruebas basadas en especificaciones buscan probar la funcionalidad del software de acuerdo con los requisitos aplicables. ^{[ 40 ]} 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) "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 los casos de prueba. Estas pruebas pueden ser funcionales o no funcionales , aunque generalmente son 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. ^{[ 41 ]}

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

Pruebas de interfaz de componentes

Las pruebas de interfaz de componentes son una variación de las pruebas de caja negra , con el enfoque en los valores de datos más allá de las acciones relacionadas de un componente de subsistema. ^{[ 42 ]} La práctica de las pruebas de interfaz de componentes se puede utilizar para verificar el manejo de datos pasados ​​entre varias unidades o componentes de subsistema, más allá de las pruebas de integración completas entre esas unidades. ^{[ 43 ] [ 44 ]} 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 por 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. ^{[ 43 ]} 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 sucedía 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 que dicha información se exprese con claridad. ^{[ 45 ] [ 46 ]}

La esencia de las pruebas visuales radica en la idea de que mostrar un problema (o un fallo en la prueba), en lugar de simplemente describirlo, mejora considerablemente la claridad y la comprensión. Por lo tanto, las pruebas visuales requieren la grabación de todo el proceso, capturando en vídeo todo lo que ocurre en el sistema de prueba. Los vídeos resultantes se complementan con la información del evaluador en tiempo real mediante una cámara web con imagen dentro de imagen y comentarios de audio grabados con micrófonos.

Las pruebas visuales ofrecen numerosas ventajas. La calidad de la comunicación mejora drásticamente, ya que los evaluadores pueden mostrar el problema (y los eventos que lo provocaron) al desarrollador, en lugar de simplemente describirlo. Además, en muchos casos, ya no será necesario replicar los fallos de las pruebas. El desarrollador dispondrá de toda la evidencia necesaria sobre un fallo y podrá centrarse en la causa del problema y en cómo solucionarlo.

Las pruebas ad hoc y las pruebas 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 pueden encontrarse rápidamente. ^{[ 47 ]} En las pruebas ad hoc, donde las pruebas se llevan a cabo de manera improvisada, la capacidad del o los evaluadores para basar las pruebas en métodos documentados y luego improvisar variaciones de esas pruebas puede resultar en un examen más riguroso de las correcciones de defectos. ^{[ 47 ]} Sin embargo, a menos que se mantenga una documentación estricta de los procedimientos, una de las limitaciones de las pruebas ad hoc es la falta de repetibilidad. ^{[ 47 ]}

Una causa común de fallos de software (reales o percibidos) es la falta de compatibilidad con otros programas de aplicación , sistemas operativos (o versiones de sistemas operativos , antiguas o nuevas) o entornos de destino que difieren considerablemente del original (como una aplicación de terminal o GUI diseñada para ejecutarse en el escritorio que ahora debe convertirse en una aplicación web , la cual debe visualizarse en un navegador web ). Por ejemplo, en el caso de la falta de retrocompatibilidad , esto puede ocurrir porque los programadores desarrollan y prueban el software únicamente en la última versión del entorno de destino, que no todos los usuarios pueden estar utilizando. Esto conlleva la consecuencia no deseada de que el trabajo más reciente puede no funcionar en versiones anteriores del entorno de destino, o en hardware antiguo que las versiones anteriores del entorno de destino sí podían utilizar. A veces, estos problemas pueden solucionarse abstraiendo de forma proactiva la funcionalidad del sistema operativo en un módulo o biblioteca de programa independiente .

Las pruebas de viabilidad determinan si es razonable proceder con pruebas adicionales.

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 pueden utilizarse como prueba de verificación de compilación .

Las pruebas de regresión se centran en encontrar defectos después de un cambio importante en el código. Específicamente, buscan descubrir regresiones de software , como funcionalidades degradadas o perdidas, incluyendo errores antiguos que han reaparecido. Estas regresiones ocurren cuando una funcionalidad del software que antes funcionaba correctamente deja de hacerlo como se esperaba. Por lo general, las regresiones ocurren como consecuencia no deseada de los cambios en el programa, cuando la parte del software recién desarrollada entra en conflicto con el código previamente existente. Las pruebas de regresión suelen ser el mayor esfuerzo de prueba en el desarrollo de software comercial, ^{[ 52 ]} debido a la verificación de numerosos detalles en las funcionalidades de software anteriores, e incluso se puede desarrollar software nuevo utilizando algunos casos de prueba antiguos para probar partes del nuevo diseño y asegurar que la funcionalidad anterior siga siendo compatible.

Los métodos comunes de pruebas de regresión incluyen volver a ejecutar conjuntos de casos de prueba anteriores y verificar si han reaparecido fallos previamente corregidos. La profundidad de las pruebas depende de la fase del proceso de lanzamiento y del riesgo de las nuevas funcionalidades. Pueden ser exhaustivas, para cambios añadidos al final del lanzamiento o considerados arriesgados, o muy superficiales, consistiendo en pruebas positivas para cada funcionalidad, si los cambios se realizan al principio 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. ^{[ 53 ] [ 54 ] [ 55 ] [ 56 ]}

Las pruebas de aceptación pueden realizarse al final o en la mitad de un proyecto, incluso después de cada historia de usuario completada en un proyecto ágil. ^{[ 57 ]}

Las pruebas se agrupan frecuentemente en estos niveles según el lugar del proceso de desarrollo de software en el que se realizan o según el nivel de especificidad de la prueba. ^{[ 56 ]}

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

En ocasiones, las pruebas de aceptación del usuario (UAT, por sus siglas en inglés) las realiza el propio cliente, en su entorno y con su propio hardware.

Las OAT se utilizan para realizar pruebas de preparación operativa (prelanzamiento) de un producto, servicio o sistema como parte de un sistema de gestión de calidad . Las OAT son un tipo común de prueba de software no funcional, utilizada principalmente en proyectos de desarrollo y mantenimiento de software . Este tipo de prueba se centra en la preparación operativa del sistema para su soporte o para su integración en el entorno de producción. Por lo tanto, también se conocen como pruebas de preparación operativa (ORT) o pruebas de preparación y aseguramiento de operaciones (OR&A). Las pruebas funcionales dentro de las OAT se limitan a aquellas necesarias 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. ^{[ 58 ]}

Las pruebas de aceptación contractual se realizan según los criterios de aceptación definidos durante la firma del contrato, mientras que las pruebas de aceptación regulatoria se realizan según la normativa aplicable al producto de software. Ambas pruebas pueden ser realizadas por usuarios o evaluadores independientes. En ocasiones, las pruebas de aceptación regulatoria implican la auditoría de los resultados por parte de los organismos reguladores. ^{[ 56 ]}

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

Las pruebas beta se realizan después de las pruebas alfa y pueden considerarse una forma de prueba de aceptación por parte de usuarios externos . Las versiones del software, conocidas como versiones beta , se lanzan a un público limitado fuera del equipo de programación, denominados beta testers. El software se lanza a grupos de personas para que las pruebas posteriores garanticen que el producto tenga pocos fallos o errores . Las versiones beta pueden ponerse a disposición del público general para ampliar el campo de retroalimentación al mayor número posible de usuarios futuros y ofrecer valor antes, durante un período de tiempo prolongado o incluso indefinido ( beta perpetua ). ^{[ 60 ]}

Las pruebas funcionales se refieren a las actividades que verifican una acción o función específica del código. Estas suelen encontrarse en la documentación de requisitos del código, aunque algunas metodologías de desarrollo trabajan con casos de uso o historias de usuario. Las pruebas funcionales tienden a responder a la pregunta de "¿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 otros aspectos del rendimiento , el comportamiento bajo ciertas restricciones o la seguridad . Las pruebas determinarán el punto crítico, es decir, el punto en el que los extremos de escalabilidad o rendimiento provocan una ejecución inestable. Los requisitos no funcionales suelen reflejar la calidad del producto, especialmente en lo que respecta a la idoneidad para 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 una versión candidata del software. ^{[ 61 ] [ 62 ]} Las pruebas continuas incluyen la validación de los requisitos funcionales y no funcionales ; el alcance de las pruebas se extiende desde la validación de requisitos ascendentes o historias de usuario hasta la evaluación de los requisitos del sistema asociados con los objetivos comerciales generales. ^{[ 63 ] [ 64 ]}

Las pruebas destructivas buscan provocar fallos en el software o en un subsistema. Verifican si el software funciona correctamente al recibir entradas no válidas o inesperadas, evaluando así la robustez de las rutinas de validación de entrada y gestión de errores. ^{[ 65 ]} La inyección de fallos de software , en forma de fuzzing , es un ejemplo de prueba de fallos. En la página de inyección de fallos de software se incluyen enlaces a diversas herramientas comerciales de pruebas no funcionales ; también existen numerosas herramientas de software libre y de código abierto que realizan pruebas destructivas.

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

Las pruebas de carga se centran principalmente en comprobar que el sistema puede seguir funcionando bajo una carga específica, ya sean grandes cantidades de datos o un gran número de usuarios . Esto se conoce generalmente como escalabilidad del software . La actividad relacionada de pruebas de carga, cuando se realiza como una actividad no funcional, se suele denominar 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 fiabilidad bajo cargas de trabajo inesperadas o poco frecuentes. Las pruebas de estabilidad (a menudo denominadas pruebas de carga o de resistencia) comprueban si el software puede funcionar correctamente de forma continua durante un período aceptable o superior.

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 se utilizan a menudo indistintamente.

Los sistemas de software en tiempo real tienen estrictas restricciones de temporización. Para comprobar si se cumplen dichas restricciones, se utilizan pruebas en tiempo real .

Las pruebas de usabilidad consisten en comprobar si la interfaz de usuario es fácil de usar y comprender. Se centran principalmente en el uso de la aplicación. Este tipo de prueba no se puede automatizar; se necesitan usuarios reales, supervisados ​​por diseñadores de interfaz de usuario cualificados . Las pruebas de usabilidad pueden utilizar modelos estructurados para comprobar el buen funcionamiento de una interfaz. El modelo de Stanton, Theofanos y Joshi (2015) analiza la experiencia del usuario, y el modelo de Al-Sharafat y Qadoumi (2016) se utiliza para la evaluación de expertos, ayudando a evaluar la usabilidad en aplicaciones digitales. ^{[ 66 ]}

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 contenido multimedia
• Capacidad para utilizar el sistema mediante el teclado del ordenador, además del ratón.

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

La Organización Internacional de Normalización (ISO) lo define como un "tipo de ensayo realizado para evaluar el grado en que un elemento de ensayo, y los datos e información asociados, están protegidos de manera que personas o sistemas no autorizados no puedan utilizarlos, leerlos o modificarlos, y a las personas o sistemas autorizados no se les niegue el acceso a ellos". ^{[ 67 ]}

Las pruebas de internacionalización y localización validan que el software pueda utilizarse en diferentes idiomas y regiones geográficas. El proceso de pseudolocalización se utiliza para probar la capacidad de una aplicación para ser traducida a otro idioma y facilita la identificación de posibles errores que puedan surgir durante el proceso de localización.

Las pruebas de globalización verifican que el software esté adaptado a una nueva cultura, como diferentes monedas o zonas horarias. ^{[ 68 ]}

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

• Es posible que algunos mensajes no estén traducidos.
• A menudo, el software se localiza traduciendo una lista de cadenas de texto 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 debida 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 sin traducir en el idioma original pueden estar codificados directamente en el código fuente y, por lo tanto, ser intraducibles.
• Es posible que algunos mensajes se generen automáticamente durante la ejecución y que la cadena resultante sea agramatical, funcionalmente incorrecta, engañosa o confusa.
• Es posible que el software utilice una combinación de teclas que no tenga ninguna función en la distribución del teclado del idioma de origen , pero que se utilice para escribir caracteres en la distribución del teclado 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 los 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 de texto 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 falle o funcione incorrectamente.
• Es posible que el software no ofrezca el soporte adecuado para leer o escribir texto bidireccional .
• Es posible que el software muestre imágenes con texto que no ha sido localizado.
• Los sistemas operativos localizados pueden tener archivos de configuración del sistema y variables de entorno con nombres diferentes , así como formatos distintos 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 para reducir los riesgos, el tiempo y los costos del desarrollo. Las realiza el desarrollador o ingeniero de software durante la fase de construcción del ciclo de vida del desarrollo. El objetivo de las pruebas de desarrollo es eliminar los errores de construcción antes de que el código pase a otras fases de prueba; esta estrategia busca aumentar la calidad del software resultante, así como la eficiencia del proceso de desarrollo en general.

Dependiendo de las expectativas de la organización en cuanto al 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 prueba de software.

Las pruebas A/B son un método para realizar un experimento controlado y determinar si un cambio propuesto es más efectivo que el enfoque actual. Los clientes son dirigidos a la versión actual (control) de una función o a una versión modificada (tratamiento), y se recopilan datos para determinar qué versión logra mejor el resultado deseado.

Las pruebas 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 revela son los interbloqueos, las condiciones de carrera y los problemas con la gestión de la memoria/recursos compartidos.

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 someten a pruebas exhaustivas para determinar si cumplen con el estándar reconocido para ese lenguaje.

La creación de una visualización de la salida esperada, 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ánea o prueba Golden Master. A diferencia de muchas otras formas de prueba, esta no puede detectar fallas automáticamente y, en cambio, requiere que un humano evalúe la salida en busca de inconsistencias.

Las pruebas de propiedades son una técnica de prueba en la que, en lugar de afirmar que entradas específicas producen salidas esperadas específicas, el usuario genera aleatoriamente múltiples entradas, ejecuta el programa con todas ellas y verifica la veracidad de alguna "propiedad" que debería cumplirse 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 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 presenten patrones específicos 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 . ^{[ 69 ]}

Las pruebas metamórficas (MT) son 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 la generación de casos de prueba. El problema del oráculo de prueba radica en 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.

Las pruebas de reproducción (también conocidas como pruebas de grabación/reproducción) son una técnica para aumentar la fiabilidad y la velocidad de las pruebas de regresión que involucran un componente con el que la comunicación es lenta o poco fiable, a menudo una API de terceros ajena al control del evaluador. Consisten en grabar las interacciones del sistema con el componente externo y, posteriormente, reproducir dichas interacciones como sustituto de la comunicación con el sistema externo en ejecuciones posteriores de la prueba.

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

Las pruebas de contrato , que no deben confundirse con las pruebas de aceptación contractual con motivación legal mencionadas anteriormente, son una metodología que consiste en probar el punto de integración entre dos servicios de software cualesquiera, verificando si las solicitudes y respuestas enviadas entre ellos se ajustan a un conjunto compartido de expectativas, comúnmente denominado contrato. Se utilizan frecuentemente en el contexto de sistemas distribuidos , arquitecturas de software orientadas a servicios y microservicios . ^{[ 70 ] [ 71 ]}

Desde principios de la década de 2020, la inteligencia artificial se ha integrado cada vez más en los flujos de trabajo de pruebas de software. Los métodos de prueba basados ​​en IA automatizan la creación de casos de prueba, se adaptan dinámicamente a los cambios y aprovechan el aprendizaje automático para identificar áreas de alto riesgo en el código fuente; un enfoque que mejora la eficiencia de las pruebas de regresión al tiempo que amplía la cobertura general de las pruebas. ^{[ 72 ]}

Un avance clave es la automatización de pruebas autorreparables , en la que las pruebas automatizadas detectan y se adaptan automáticamente a los cambios en una interfaz de usuario sin intervención humana. Estudios sobre la automatización de pruebas impulsada por IA en más de 3600 fuentes de literatura gris identificaron los scripts de prueba autorreparables como una de las soluciones de IA más comunes en la práctica. ^{[ 73 ]}

Un estudio terciario publicado en ACM Computing Surveys (2023) encontró que los métodos de IA se han aplicado ampliamente en todas las fases principales del ciclo de vida del desarrollo de software, e identificó la generación de casos de prueba, la predicción de fallas y la reparación automatizada como las tres áreas más activas de investigación de pruebas asistidas por IA. ^{[ 74 ]}

Las pruebas de inicio temprano (shift-left testing) consisten en integrar las actividades de prueba lo antes posible en el ciclo de vida del desarrollo de software, de modo que los defectos se detecten cuando su corrección sea menos costosa. El término se describió por primera vez en la literatura académica en la revista Dr. Dobb's Journal y se formalizó en investigaciones posteriores de ACM / IEEE . ^{[ 75 ]}

La investigación empírica ha demostrado que las pruebas tempranas (shift-left testing) reducen entre un 40 % y un 60 % el tiempo necesario para detectar defectos, y entre un 75 % y un 85 % el coste de eliminarlos cuando se identifican en las primeras etapas del desarrollo, en comparación con los enfoques tradicionales en los que las pruebas se posponen hasta etapas posteriores. ^{[ 76 ]}

Un estudio de caso presentado en la Conferencia Internacional sobre Gestión y Tecnología de la Información (ICIMTech) de 2023 reveló que la integración de las pruebas de desplazamiento a la izquierda en una metodología de desarrollo ágil durante un año redujo notablemente el número de errores que llegaban a producción. ^{[ 77 ]}

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

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

Entre los roles y títulos notables en las pruebas de software se incluyen: ^{[ 78 ]} gerente de pruebas , líder de pruebas , analista de pruebas , diseñador de pruebas , probador , desarrollador de automatización y administrador de pruebas . ^{[ 79 ]}

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

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

• Verificación: ¿Hemos desarrollado el software correctamente? (es decir, ¿cumple con los requisitos?).
• Validación: ¿Hemos desarrollado el software adecuado? (Es decir, ¿los entregables satisfacen al cliente?).

Los términos verificación y validación se utilizan comúnmente de forma indistinta en la industria; también es común encontrar definiciones contradictorias de estos dos términos. Según el Glosario estándar de terminología de ingeniería de software del IEEE : ^{[ 12 ] : 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 cumplen las condiciones impuestas al inicio de dicha fase.

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

Y, según la norma ISO 9000:

La verificación consiste en la confirmación, mediante examen y aportación de pruebas objetivas, de que se han cumplido los requisitos especificados.

La validación consiste en la confirmación, mediante examen y 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 específicos, pero con significados diferentes.

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). Por otro lado, los productos mencionados en la definición de verificación son los artefactos resultantes 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 utiliza aquí; se abordará este tema más adelante).

Sin embargo, para la norma ISO 9000, los requisitos especificados son el conjunto de especificaciones, como se mencionó anteriormente, que deben verificarse. Una especificación, como se explicó previamente, 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 la especificación de entrada. Todas las especificaciones pueden verificarse, excepto la SRS, ya que es la primera (aunque puede validarse). Un ejemplo sería que 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í pues, cuando estas palabras se definen en términos comunes, la aparente contradicción desaparece.

Tanto la especificación de requisitos de software (SRS) como el software deben validarse. La SRS puede validarse de forma estática consultando con las partes interesadas. Sin embargo, ejecutar una implementación parcial del software o un prototipo (pruebas dinámicas) y obtener retroalimentación positiva puede aumentar la certeza de que la SRS está correctamente formulada. Por otro lado, el software, como producto final y en funcionamiento (no sus artefactos ni documentos, incluido el código fuente), debe validarse dinámicamente con las partes interesadas, ejecutándolo y permitiéndoles probarlo.

Algunos podrían argumentar que, para los SRS, la información de entrada son las palabras de las partes interesadas y, por lo tanto, la validación de los SRS es lo mismo que la verificación de los mismos. Pensar así no es recomendable, ya que solo genera más confusión. Es mejor concebir la verificación como un proceso que incluye un documento de entrada formal y técnico.

En algunas organizaciones, las pruebas de software forman parte de un proceso de aseguramiento de la calidad del software (SQA). ^{[ 3 ] : 347} En SQA, los especialistas en procesos de software y los auditores se ocupan del proceso de desarrollo de software en lugar de solo de 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 de defectos aceptable depende de la naturaleza del software; un videojuego de simulación 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 funcionan de forma independiente, y puede que no exista una función de SQA en algunas empresas.

Las pruebas de software consisten en investigar el software que se está probando para proporcionar información sobre su calidad a las partes interesadas. Por el contrario, el control de calidad (CC ) 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 la corrección , la integridad, la seguridad y los requisitos de la norma ISO/IEC 9126 , tales como capacidad, fiabilidad , eficiencia , portabilidad , mantenibilidad , compatibilidad y usabilidad .

Existen diversas métricas o medidas de software de uso frecuente que ayudan a determinar el estado del software o la adecuación de las pruebas.

Un proceso de prueba de software puede generar diversos artefactos . Los artefactos generados dependen del modelo de desarrollo de software utilizado, las necesidades de las partes interesadas y de la organización.

Existen varios programas de certificación para apoyar las aspiraciones profesionales de los probadores de software y los especialistas en control de calidad. Algunos profesionales sostienen que el campo de las pruebas aún no está preparado para la certificación, como se menciona en la sección de controversias .