Pues la respuesta general a esa pregunta suele ser muy sencilla: "testear es ejecutar pruebas". Y efectivamente, la ejecución de las pruebas forma parte del testing, pero sin embargo hay muchas más actividades que se suelen dejar de lado.
La actividad de "testear" tiene que existir antes y después de la ejecución de las pruebas, y esto implica:
- Llevar a cabo tareas de planificación y control
- Seleccionar las condiciones de las pruebas
- Diseñar los casos de pruebas y los resultados esperados
- Gestionar los casos de prueba
- Generar informes
- Finalizar y cerrar los ciclos de pruebas
Además "testear" incluye también la revisión de documentos e incluso puede incluir técnicas de análisis estático.
El estándar ISO/IEC 29119, cuya elaboración comenzó en 2007, tiene como objetivo cubrir todo el ciclo de vida de las pruebas de software incluyendo los aspectos relativos a la organización, gestión, diseño y ejecución de las pruebas, para remplazar varios estándares IEEE y BSI sobre pruebas de software, pero hasta que llegue, podemos emplear la siguiente definición:
Testear es obtener la información necesaria para mejorar el sistema que se está probando, pero también para mejorar los propios procesos de desarrollo y de pruebas.
Hay diferentes objetivos en el testing:
- Buscar los defectos
- Ganar confianza respecto al nivel de calidad
- Prevenir los defectos
Pero eso sí, es muy importante que a los defectos siempre los tratemos bien, también tienen sentimientos :-)
Y para alcanzar los objetivos, hemos de tener en cuenta los siguientes principios:
1. El testing muestra la presencia de defectos.
El testing puede mostrar que defectos están presentes, pero nunca podrá probar que no hay defectos. El testing reduce la probabilidad de que aparezcan defectos ocultos en el software pero, incluso si no se encuentra ningún defecto, nunca será una garantía de su corrección.
2. Es imposible probarlo todo.
Probar todo (todas las combinaciones de entradas y precondiciones) es inabordable excepto para los casos triviales. En lugar de probarlo todo, hay que centrar los esfuerzos en analizar los riesgos y priorizar los casos.
3. Probar desde el principio.
Las actividades de testeo tienen que empezar tan pronto como sea posible en el ciclo de vida del desarrollo, y se deben centrar en objetivos claramente definidos
4. Regla del 20/80
El 20 % del proyecto contiene el 80 % de los defectos que se pueden descubrir en fases tempranas de las pruebas.
5. La paradoja del pesticida
Si se repiten las mismas pruebas una y otra vez, llegará un momento en el que el mismo conjunto de casos de prueba nunca encontrará nuevos defectos. Para evitar esa paradoja, los casos de prueba tienen que ser revisados, y deben crearse nuevos y diferentes casos que puedan evaluar otras partes del software y encontrar nuevos defectos potenciales.
6. Las pruebas son dependientes del contexto
Por ejemplo, no es lo mismo probar un software crítico que se ejecuta en tiempo real que un sitio web de comercio electrónico.
7. La falacia de la ausencia de errores
Encontrar y solucionar defectos no sirve de nada si el sistema no cumple con los requisitos establecidos y las necesidades y expectativas de los usuarios.
La clave para llevar a cabo con éxito los procesos de pruebas de software es tener siempre en mente estos principios. Estos principios son de sentido común, sin embargo lo que suele ocurrir es que la tensión de las entregas, las fechas, costes, o la falta de experiencia, acaban llevándolos al olvido, lo que provoca un efecto perverso en las pruebas de software, y es que dejan de tener sentido y se ejecutan simplemente para no tener errores, pero no para detectarlos.
Un proceso de pruebas de software sólo tiene éxito cuando se encuentren defectos. Si no es así el equipo de pruebas nunca habrá alcanzado sus objetivos.
Recuerda: "testear es mejorar".
Todas las imágenes están extraídas de Cartoon Tester