En esta ocasión vamos a revisar los tipos de pruebas, por ejemplo
dependiendo del tipo de defecto que verifican las pruebas cada especialización
tiene su nombre, pero todos los tipos de pruebas en general se pueden clasificar
como pruebas de Caja Negra o Caja Blanca.
Pruebas de Caja Negra
Toda la arquitectura interna del sistema es oculta a quien lo prueba. Es decir
el usuario de prueba solo conoce lo que el producto se supone que tiene que hacer
pero no cómo lo hace. Los usuarios de prueba solo observa los resultados
o el comportamiento del producto y no necesitan ser programadores. Generalmente
estas pruebas las realizan los usuarios finales o personas que no son parte del
proceso de desarrollo.
Pruebas de Caja Blanca
Es lo opuesto a las anteriores, es decir que quien prueba conce la estructura
interna del software. Estos usuarios de prueba evaluan la lógica de los programas
a travéz de casos de prueba específicos. Al auditar el flujo de las entradas
de prueba, el usuario puede verificar que todos los casos han sido manejados
correctamente.
Otra clasificación general para los métodos de pruebas es pruebas manuales versus
pruebas automatizadas. Muchas tipos de pruebas se pueden hacer tanto manualmente
como de forma automatizada. Esta distinción indica como la prueba es completada.
Pruebas Manuales
Una persona como probador toma el rol de un usuario final del software y chequea
casos de prueba uno por uno. Es una forma tradicional de verificar el software
y en algunos casos es necesario porque puede detectar cosas que no pueden las
pruebas automatizadas como apariencia visual de un sitio. Pero esta forma de
ejecutar pruebas no escala, cuando el software es muy grande y complejo
no se puede volver a probar todo el sistema.
Pruebas Automatizadas
Es el proceso de usar software denominado un framework de pruebas para
crear casos de pruebas que se ejecutan y comparan el resultado del programa
con el resultado esperado. Algunos ejemplos de este tipo de frameworks son
selenium, codeception, cucumber.
Ahora revisaremos las metodologías de pruebas clasificadas entre funcionales y no
funcionales, la diferencia está en si la prueba se enfoca en el comportamiento
del software o su operación interna.
Pruebas Funcionales
Son un tipo de pruebas de caja negra que generan los casos de prueba usando
los requerimientos y especificaciones del software.
Algunas de estas metodologías incluyen:
- Pruebas unitarias (Unit testing)
- Pruebas de integración (Integration testing)
- Pruebas de sistema (System testing)
- Pruebas de aceptación de usuario (Acceptance testing)
- Pruebas de regresión (Regression testing)
- Pruebas de humo (Smoke testing)
Un proceso funcional común tiene 4 etapas, abriendo el alcance
del test en cada paso. El proceso inicia con:
1. Pruebas unitarias
Verifica el correcto funcionamiento de un componente individual del software,
en el caso de orientación a objetos puede verificarse clases individuales.
Este tipo de pruebas las realiza el programador como parte de su trabajo.
Y casi siempre están automatizadas para obtener resultados muy rápidamente.
2. Pruebas de integración
Estas son usadas para verificar cómo varios componentes conectados del software
funcionan juntos. Esto se hace luego de verificar que cada componente funciona
individualmente, luego se valida que funcionen bien juntos. Al igual
que las unitarias estas las hace el desarrollador de forma automatizada.
3. Pruebas de sistema
Prueban el producto completo, con todos los componentes ensamblados. Verifica
que modulos completos funcionen unos con otros. Generalmente este tipo
de pruebas las realiza un equipo de QA.
4. Pruebas de aceptación
Verifica si el producto final satisface los requerimientos originales. Estas
pruebas pueden ser realizadas por usuarios internos (pruebas alpha) o externos (pruebas beta)
que revisan cómo funciona el producto al usarlo.
Existen metodologías especialiazadas que verifican aspectos específicos de un programa
que van más allá del proceso anterior. Por ejemplo las pruebas de regresión
que sirven para verificar la integridad del producto luego de un cambio o upgrade
verifican la salida del nuevo programa con la salida de versiones anteriores del mismo.
Pruebas de humo sirven para verificar rápidamente que las funciones más esenciales de un producto
sigan estables, cosas como el programa se abre, una página muestra datos.
Pruebas No Funcionales
Son un tipo de pruebas que verifican cómo un programa opera en lugar de si un comportamiento
es correcto. Por ejemplo un test no funcional prueba que tan bien un programa
se ejecuta con una carga alta de transacciones, o mientras funciona por un largo tiempo.
Las pruebas no funcionales más usadas son:
- Pruebas de desempeño (Performance testing)
- Pruebas de seguridad (Security testing)
- Pruebas de usabilidad (Usability testing)
- Pruebas de compatibilidad (Compatibility testing)
- Pruebas de estres (Stress or load testing)
Pruebas de desempeño
Validan la velocidad, responsividad y fiabilidad en que un sistema cumple una función. Si una
función funciona pero se demora mucho o a veces funciona y otra no, este test va a fallar
y debe regresar a desarrollo.
Pruebas de seguridad
Son usadas para encontrar debilidades en la seguridad de la información, hay pruebas por ejemplo
de pentesting o escaner de vulnerabilidades. Pero todas buscan que se mantenga la confidencialidad, integridad, autenticación, autorización, disponibilidad y no repudiación.
Pruebas de usabilidad
Usadas para verificar si una característica del software no produce confusión o dificultad
al usuario final. Generalmente se verifica por un investigador que observa cómo un
usuario final realiza las tareas en el sistema. Se pide a los usuarios hacer una tarea
pero sin indicarles cómo realizarlas.
Pruebas de compatibilidad
Verifican que tan bien un software se desempeña en diferentes ambientes, por ejemplo si
se tuvieran el mismo software para mac, linux y pc.
Pruebas de estres
Los desarrolladores verifican hasta cuánto un sistema puede seguir trabajando aumentando
la cantidad de usuarios o transacciones simultáneas. La idea es tratar de encontrar
los cuellos de botella o puntos débiles que pueden hacer que un sistema en vivo colapse
cuando hay muchos usuarios a la vez.
Top comments (0)