• Reducen la posibilidad de agregar defectos al software. Si hay que realizar una adición de características requeridas por el cliente y se ve que ya no funcionan bien algunas de las cosas que anteriormente servían, se puede inferir la nueva funcionalidad es la que contiene defectos, por lo que no hay necesidad realizar modificaciones a los componentes realizados anteriormente.
• Reducen la posibilidad de encontrar defectos en funcionalidades ya implementadas.
• Las pruebas son buena documentación. Es preferible ver unas pequeñas líneas de "Código de prueba", que son concisas y realmente son fáciles de entender, a revisar línea por línea de código para poder entender que hace determinado componente de software.
• Reducen el costo del cambio. Ya que evitan que se descubran los defectos hasta el final del desarrollo de software.
• Permiten realizar reimplementación. Se puede llegar a necesitar reimplementar determinada funcionalidad en un sistema, debido a fallos de seguridad, rendimiento, o simplemente por que no reunía lo que el cliente esperaba de éste, entonces dada tal situación, las pruebas que a realizar a dicha funcionalidad van a permitir que se vuelva a desarrollar de manera segura, ya que la prueba encierra el criterio de aceptación sobre la funcionalidad, permitiendo de esta forma que se vuelva a desarrollar algo acorde con la especificación.
• Restringe las características a implementar. Muchas veces los programadores pierden tiempo en detalles que la especificación no pedía. Con las pruebas el programador sabe que tiene que programar dicha funcionalidad y también probarla, por lo que se restringe a lo que los diseñadores de las pruebas hayan realizado.
• Hacen que el desarrollo sea más rápido. Ya que a medida que se agregan características al software, las funcionalidades anteriores pueden fallar, pero si se han hecho las pruebas pertinentes a las funcionalidades anteriores, se puede descartar inmediatamente que existan defectos en éstas, por lo que se puede concentrar tranquilamente en la funcionalidad nueva.

• Analistas, Diseñadores y Programadores: Este grupo de personas poseen un punto de vista creativo, ya que ellos son los que a partir de una necesidad del cliente, diseñan, analizan y codifican una solución informática. Debido a esa situación ellos no alcanzan a divisar los posibles defectos que tiene el software que ellos realizaron.
• Analista de Calidad: Ellos se enfocan en entender las reglas del negocio, requerimientos, casos de uso y todas aquellas cosas que ayuden a comprender el negocio. Este grupo de personas poseen por decirlo de alguna manera un punto de vista destructivo, ya que ellos saben que determinada parte del programa tiene que llevar a cabo ciertas funciones, y ellos en su quehacer tratan de encontrar defectos a la funcionalidad realizada por otra persona.

• Conocer el propósito de la prueba.
• Definir el lugar, fecha y duración de la misma.
• Determinar el hardware y software necesarios para llevarse a cabo.
• Definir el estado del sistema al iniciar la prueba.
• Integrar facilitadores y nivel de participación.
• Definir a los usuarios participantes.
• Especificar las tareas a desarrollar por los usuarios.
• Establecer criterios de terminación de tareas.
• Crear materiales de apoyo para usuarios.
• Especificar métodos de recolección y análisis de datos resultantes.

• Pruebas del camino básico. Propuesta por Tom McCabe, permite al diseñador de casos de prueba que pueda obtener una medida de la complejidad lógica en un diseño procedimental y usar ésta como guía para llegar a definir un conjunto elemental de caminos de ejecución. Los casos de prueba derivados de éste último garantizan que durante la prueba se ejecuta por lo menos una vez cada sentencia de programa.
  
  Un camino independiente es cualquier camino del programa que introduce por lo menos un nuevo conjunto de sentencias de procesamiento o una nueva condición.

• Pruebas de Unidad. Las pruebas unitarias tienen como objetivo verificar la funcionalidad y estructura de cada componente individualmente una vez que ha sido codificado.

1. Caja Negra. Son pruebas que se llevan a cabo directamente en la interfaz del software. Se comprueba el correcto funcionamiento de los componentes del sistema de información, analizando las entradas y salidas y verificando que el resultado es el esperado. Se consideran exclusivamente las entradas y salidas del sistema sin preocuparse por la estructura interna del mismo. Errores que se pretenden detectar: funciones incorrectas o ausentes, errores de interfaz, errores en las estructuras de datos, errores de rendimiento, errores de inicialización y terminación. Algunos tipos son:
   • Partición Equivalente. Es un método que divide el campo de entrada de un programa en clases de datos de los que se pueden derivar casos de prueba. Un caso de prueba correcto descubre de manera inmediata una clase de errores.
     
     Se dirige a la definición de casos de prueba que descubran clases de errores, reduciendo así el número de casos de prueba que hay que desarrollar. El diseño de estos casos se basa en una evaluación de las clases de equivalencia para una condición de entrada. Una clase de equivalencia representa un conjunto de estados válidos o inválidos para condiciones de entrada.
     
   • Análisis de valores límite (AVL). Esta técnica es un complemento para la anterior. En lugar de seleccionar cualquier elemento de una clase de equivalencia, se lleva a la elección de casos de prueba a los extremos de la clase. En lugar de centrarse únicamente en las condiciones de entrada, también se derivan casos de prueba para el campo de salida.
2. Caja Blanca. Se prueban procedimientos del software. Se verifica la estructura interna del componente con independencia de la funcionalidad establecida para el mismo. Por tanto, no se comprueba la corrección de los resultados, sólo si éstos se producen. Algunas clases de pruebas:
   • Pruebas de cubrimiento.
   • Pruebas de condiciones. Es un método de diseño de casos de prueba que ejercita las condiciones lógicas contenidas en un módulo de un programa. Se basa en el criterio de que si un conjunto de pruebas de un programa es efectivo para detectar errores en las condiciones que se encuentran en el programa, es probable que el conjunto de pruebas sea también efectivo para detectar otros errores en el programa.
   • Pruebas de bucles. Los bucles son la parte más importante de la mayoría de los algoritmos implementados en software. Es una técnica que se centra principalmente en la validez de las construcciones de bucles y existen estos tipos de ellos:

1. Bucles simples
2. Bucles anidados
3. Bucles concatenados
4. Bucles no estructurados

3. Trayectoria.

• Pruebas de Integración. El objetivo de las pruebas de integración es verificar el correcto ensamblaje entre los distintos componentes una vez que han sido probados unitariamente con el fin de comprobar que interactúan correctamente a través de sus interfaces, tanto internas como externas, cubren la funcionalidad establecida y se ajustan a los requisitos no funcionales. En las pruebas de integración se examinan las interfaces entre grupos de componentes o subsistemas para asegurar que son llamados cuando es necesario y que los datos que se transmiten son los requeridos.

1. Ascendente. Es la estrategia tradicional empleada para integrar los componentes de un sistema de software en un todo funcionando. Consiste en pruebas de unidad, seguidas por pruebas de subsistemas y luego por pruebas del sistema completo. Las primeras tienen el objetivo de descubrir errores en los módulos individuales del sistema. Las pruebas de unidad deben ser tan exhaustivas como sea posible para garantizar que se ha probado cada caso representativo manejado por cada módulo. dichas pruebas se facilitan por una estructura que se componga de módulos pequeños y débilmente acoplados.
2. Descendente. Empieza con la rutina principal y una o dos rutinas inmediatamente subordinadas en la estructura del sistema. después de que el esqueleto de alto nivel ha sido probado con detenimiento, se convierte en el arreo de prueba para sus subrutinas inmediatamente subordinadas. La integración de alto nivel requiere el uso de troncos de programa para simular el efecto de rutinas de más bajo nivel que son llamadas rutinas en prueba.
3. Regresión. Son una estrategia de prueba en la cual las pruebas que se han ejecutado anteriormente se vuelven a realizar en la nueva versión modificada, para asegurar la calidad después de añadir la nueva funcionalidad. El propósito de estas pruebas es asegurar que:
   
   
   • Los defectos identificados en la ejecución anterior de la prueba se ha corregido.
   • Los cambios realizados no han introducido nuevos defectos o reintroducido defectos anteriores.
   La prueba de regresión puede implicar la re-ejecución de cualquier tipo de prueba. Normalmente, las pruebas de regresión se llevan a cabo durante cada iteración, ejecutando otra vez las pruebas de la iteración anterior.
   

• Pruebas de Validación. La validación se logra cuando se logran cumplir las expectativas que tiene el cliente al cual se esta desarrollando el producto y se lleva a cabo mediante algunas pruebas como:

1. Alfa. Es una prueba que es llevada a cabo por un cliente en el mismo lugar en el que se desarrollo el producto. Se usa el software de manera normal pero con algún encargado del desarrollo checando el uso que le da el usuario y registrando errores y problemas con su uso. Este tipo de pruebas se llevan a cabo en un entrono controlado.
   
2. Beta. Esta prueba se lleva a cabo, en uno o más lugares, por los que serán los usuarios finales del software. A diferencia de la anterior prueba, el encargado del desarrollo, regularmente, no se encuentra presente. La prueba es una aplicación del software en un entorno que no puede ser controlado por el equipo de desarrollo, para poder darle más realismo al funcionamiento del software o sistema. El cliente registra todos los fallos y/o problemas (reales o imaginarios) que llegue a encontrar y los informa regularmente. Con base en éstos, el equipo de desarrollo lleva a cabo modificaciones y así prepara una versión mejorada del producto.

• Pruebas del Sistema. Las pruebas del sistema implican dos clases de actividades: pruebas de integración y pruebas de aceptación. Las estrategias para integrar los componentes del software en un producto que funcione incluyen las estrategias ascendente, descendente y de emparedado. Se requiere de una cuidadosa planeación y programación a tiempo para asegurar que los módulos estarán disponibles para su integración dentro del producto de software en desarrollo, cuando se necesiten. La estrategia de integración dicta el orden en que los módulos deben estar disponibles, por lo que ejerce gran influencia en el orden en que se escriben, depuran y hacen las pruebas de unidad de los módulos.
  

Las pruebas de aceptación implican la planeación y ejecución de pruebas funcionales, de desempeño y de tensión para verificar que el sistema realizado satisfaga sus requisitos. Las pruebas de aceptación suelen realizarlas las organizaciones de control de calidad, los clientes o ambos. Dependiendo de las circunstancias, locales, el grupo de desarrollo puede o no estar relacionado con las pruebas de aceptación. Algunas son:

• Prueba de validación: Proporciona una seguridad final de que el software satisface todos los requerimientos funcionales y de rendimiento. Además, valida los requerimientos establecidos comparándolos con el sistema que ha sido construido. Durante la validación se usan exclusivamente técnicas de prueba de caja negra.
• Prueba de recuperación: Fuerza un fallo del software y verifica que la recuperación se lleva a cabo apropiadamente.
• Prueba de seguridad: Verificar los mecanismos de protección y es una herramienta técnica al análisis de riesgos que proporciona una clara visión referente al nivel de vulnerabilidad y exposición de la plataforma tecnológica.
• Prueba de resistencia: Enfrenta a los programas a situaciones anormales.
• Prueba de rendimiento: Prueba el rendimiento del software en tiempo de ejecución.
• Prueba de instalación: Se centra en asegurar que el sistema software desarrollado se puede instalar en diferentes configuraciones hardware y software y bajo condiciones excepciones, por ejemplo con espacio de disco insuficiente o continuas interrupciones.