Parte 2: Tipos De Pruebas de Software
Esta es la seguna parte de la serie de Pruebas de Software, si aún no has leído la primera parte puedes hacerlo ahora.
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.
Si quieres recibir una notificación en tu correo cuando salga la parte 3, suscríbete.