Los principios o reglas -en cualquier disciplina-orientan, estructuran y guían metodologías de trabajo. Es decir, nos ayudan a orientar la práctica profesional.
Les presentamos los 7 principios del testing:
1. El testing pone de manifiesto la presencia -no la ausencia- de defectos
A través de las pruebas es posible encontrar defectos, visibilizarlos y evidenciarlos. Sin embargo, es IMPOSIBLE confirmar la INEXISTENCIA de algún defecto silencioso, no descubierto en pruebas o validaciones. Nunca puede determinarse la “ausencia total de fallos”.
2. El testing exhaustivo es imposible
Mientras usamos un sistema pueden ocurrir diversas situaciones. Algunas serán propias del contexto y/o del espacio en donde vivimos y otras inherentes al software.
Ejemplo:
Estás comprando un pasaje en micro on line. Luego de seleccionar empresa, fechas de viaje, y reserva de asientos debes completar el formulario de pago para abonar con tu tarjeta de crédito. En ese momento suena el teléfono y mantienes una conversación de 20 minutos. Al finalizar vuelves a la página del sitio y decides terminar de completar el formulario-
¿Qué sucederá?
- ¿Se enviará el formulario correctamente al clickear “enviar”?
- ¿El sistema debería esperar media hora o varios días “abierto”?
- ¿El sistema debería timeoutear y pedirme que vuelva a ingresar todos los datos de cero?
¿Es necesario que el equipo de desarrollo dedique esfuerzos en anticipar ese tipo de situaciones excepcionales?
3. El testing temprano ahorra tiempo y dinero
Luego de todo lo analizado, pareciera claro entonces que mientras más temprano comiencen las pruebas de testing, menos costoso será corregir los bugs encontrados.
En ocasiones, si los tester tienen disponible el sistema para la revisión del plan de pruebas pueden encontrar menor cantidad de bugs en el código.
Iniciando las tareas de testing y análisis con anticipación, evitamos que los errores que aparecen en las etapas tempranas del proceso de desarrollo migren a etapas más avanzadas.
4. Defectos agrupados
Es probable que la mayor cantidad de defectos se concentren en algunas áreas del sistema. Quizás en aquellas que revisten mayor complejidad o que fueron modificadas múltiples veces. También puede deberse al trabajo de desarrolladores con menor experiencia (solo por nombrar algunos factores)
Si bien es importante testear las áreas del sistema más conflictivas o que tiendan a tener defectos, esto no implica dejar de lado la ejecución de pruebas sobre otras partes que -a simple vista- parecen menos complejas.
5. Pesticide paradox
¿Conoces la frase que se le atribuye a Albert Einstein: "Si buscas resultados distintos, no hagas siempre lo mismo”?
Trasladamos el espíritu de la misma, a nuestro campo de estudio: repetir una y otra vez las pruebas no servirá para encontrar defectos nuevos.
Las pruebas de regresión tienen por objetivo revisar que los cambios introducidos en el sistema no rompan lo que funcionaba correctamente. Para esto, es necesario revisar estas pruebas y asegurar que sean relevantes para los requerimientos nuevos.
Si el sistema y sus funcionalidades van modificándose con el tiempo, las pruebas deben adaptarse a esos cambios.
6. El testing es dependiente del contexto
Qué tipo de pruebas implementar y cómo llevarlas a cabo dependerá de aquello que se está testeando.
Una aplicación web que permite el ingreso de datos personales requerirá más pruebas y foco en ciertos aspectos que un sitio web que sólo visualiza información.
Un sistema de navegación de un avión va a necesitar pruebas más exhaustivas que los dos sistemas mencionados anteriormente.
7. La ausencia de errores es una falacia
Que no se hayan descubierto errores en un sistema, antes, durante o al finalizar el testeo no implica que el sistema carece de bugs.
El testing busca que el sistema que revisamos alcance niveles de calidad y sea aceptable (según los criterios establecidos) además de cumplir con los requisitos solicitados al inicio del desarrollo del sistema.
0 Comentarios