QA&V Tipos de pruebas
(QA&V Test types)
Como continuación a la introducción publicada anteriormente les dejo los tipos de prueba existentes.
Dependiendo la complejidad y los requerimientos
del cliente se deben tomar en cuenta diferentes tipos de pruebas, a
continuación se hace mención de los más relevantes:
- Caja negra:
Estas
pruebas se concentran en lo que se espera de un módulo, es decir pretenden
encontrar casos, en los que el módulo no se ocupa de su especificación. Este tipo de pruebas no está basado en el
conocimiento o diseño interno, se encarga de verificar la correcta
funcionalidad del sistema.
- Caja blanca:
En este tipo
de prueba siempre se está examinando el código, están basadas en la lógica
interna de la aplicación, con estas pruebas se desea “probarlo todo”, hace una cobertura de declaraciones del
código, ramas, caminos y condiciones.
- Unitaria:
Este tipo de
prueba se utiliza para probar la correcta funcionalidad de los módulos del
programa, como funciones, procedimientos, módulos de clase. En ciertos sistemas
también se verifican o se prueban los drivers y el diseño de la arquitectura,
esto sirve para asegurar que cada uno de los módulos funcione correctamente por
separado.
- Integración incremental:
Cuando
nuevas funciones son ingresadas al sistema se hace la prueba basándose en la
funcionalidad, la dependencia con otros módulos y la integración con el
programa completo.
- Prueba de integración:
Se llevan a
cabo durante el desarrollo del sistema. Se
basan en las pruebas de conexiones y comunicaciones entre diferentes
módulos. Estas pruebas terminan probando el sistema en conjunto.
- Prueba funcional:
En
este proceso se pretende encontrar desigualdades entre el sistema y su
especificación funcional. La prueba funcional generalmente es una actividad de
caja negra, para realizar esta prueba, las especificaciones del sistema se
analizan, desarrollando casos de prueba
y mediante diferentes técnicas de caja negra. (Oré B, 2009)
- Prueba de sistema:
Este proceso
es parte de las pruebas de caja negra en el cual se prueban todos los
componentes del sistema desde el hardware a la documentación.
- Prueba de fin a fin:
Esta prueba
es semejante a la prueba de sistema pero esta implica la interacción con otro
hardware, bases de datos y redes.
- Prueba de sanidad:
Con base en
esta prueba se determina si la nueva versión de un software está bien
desarrollada y si requiere un nuevo esfuerzo en la prueba de software.
Por ejemplo la nueva versión de un sistema satisface casi todas las
especificaciones pero destruye la base de datos al leerla, por lo tanto se dice
que este software no está en una condición sana.
- Prueba de regresión:
Es una nueva
revisión en las pruebas del programa una vez realizado algún cambio sobre un
componente del sistema, para comprobar que dicho cambio no haya introducido un
comportamiento o errores adicionales en
otros componentes no modificados.
- Prueba de aceptación:
Es la prueba
final, su objetivo es validar que un programa cumple con las especificaciones y
con el funcionamiento correcto. Esta prueba está basada en el uso del programa
por el usuario final luego de un periodo de tiempo.
- Prueba de carga:
Se realiza generalmente para observar el
comportamiento en las aplicaciones bajo cargas pesadas, esta carga puede ser el
número esperado de usuarios concurrentes utilizando el sistema y que realizan
diferentes transacciones durante el tiempo que dura la ejecución de los datos a
probar, generalmente usadas en sitios web y en servidores con gran cantidad de
datos donde se determina en cuáles puntos existen atenuación del sistema
- Prueba de estrés:
Una prueba
de carga y performance es utilizada generalmente para colapsar el sistema, está
basada en la funcionalidad del sistema bajo cargas pesadas, doblando el número
de usuarios que se agregan a la aplicación, así como también un gran número de
repeticiones, manejo de grandes volúmenes de datos y demasiadas preguntas a
bases de datos grandes hasta que el sistema colapsa.
- Prueba de performance:
Este
procedimiento permitirá asegurar el rendimiento y capacidad de la solución
tecnológica empleada en sus sistemas, es una de las pruebas finales y sirve
para validar los requerimientos y la calidad del software, con base en las
pruebas de carga y estrés.
- Prueba de instalación y desinstalación:
Este proceso determina la eficiencia de los procedimientos que instalan y
desinstalan las aplicaciones del sistema.
- Prueba de recuperación:
En esta
prueba se fuerza al fallo del sistema para verificar la recuperación del sistema después de bloqueos, fallas del
hardware u otros problemas catastróficos.
- Prueba de seguridad:
La prueba de
seguridad evalúa que los mecanismo de protección integrados al sistema protejan
de interrupciones inapropiadas, contra accesos, internos o externos, no
autorizados, esta prueba requiere sofisticadas técnicas y herramientas.
- Prueba de compatibilidad:
Son
utilizadas para evaluar si el sistema funcionará correctamente en diferente
hardware, sistema operativo y redes.
- Pruebas exploratorias:
Son pruebas
informales que se le aplican al sistema, no están basadas en ningún plan o caja
de prueba y se aplican con base en la experiencia del ingeniero de pruebas. (Bec, 2007)
- Prueba de anuncio:
Es semejante
a la prueba de exploración pero los testers deben tener suficiente
conocimiento sobre las especificaciones y el funcionamiento del programa antes
de llevar a cabo esta prueba, por lo que requiere una previa reunión con
analistas y programadores.
- Prueba de usuario:
Se basa en
evaluar si el usuario se desenvuelve satisfactoriamente en el entorno del
programa y que esté satisfecho con el funcionamiento del mismo. (Testing, 2013)
- Prueba de comparación:
En esta
prueba se comparan los pros y los contras del programa con los programas
creados con la competencia.
- Prueba alfa:
Se lleva a
cabo cuando la aplicación está cerca de la entrega al usuario. Se utiliza el
programa de forma natural con el desarrollador observando cómo el usuario
interactúa con el sistema y registrando los posibles errores y problemas de uso;
generalmente se hacen pequeños cambios en el diseño de interfaces.
- Prueba beta:
Esta prueba
se lleva a cabo por los usuarios finales del sistema, a diferencia de la alfa
el desarrollador no está presente, así se puede decir que esta prueba es la
aplicación real del software en un entorno que no es controlado por el
programador, el usuario es quien registra los errores y problemas de la
aplicación. (Pressman, 2002)
(Mañas, 1994).
- Caja gris:
El concepto de testing de caja gris es simple, se basa en la realización de testing de caja negra basado
en casos de prueba realizados por personas que conocen el programa por dentro.
Se entiende que de esta forma las pruebas realizadas son más efectivas porque
se conocen las partes del código que pueden resultar más conflictivas: por su
complejidad, por su acoplamiento con
otras clases, etc. (Pressman, 2002)
Gracias.
