Inicialmente, la prueba se entremezclaba con el debugging y se llevaba a cabo más bien para ganar confianza en que el software sí “corre bien”. G. Myers fue de los primeros en establecer que la labor del Tester es mostrar dónde el sistema no “satisface los requerimientos”.
Myers enunció unos principios que marcan esa filosofía de la prueba de software; algunos de ellos se pueden parafrasear como sigue:
- La prueba tiene como objetivo detectar anomalías. Se lleva a cabo para mostrar dónde un producto tiene defectos, pero no puede utilizarse para demostrar que un producto no tiene defectos.
- Probar todas las posibles combinaciones de entradas es imposible en la práctica. Lo que debe hacerse es distribuir inteligentemente los recursos de prueba y utilizar Heurísticas.
- El equipo que desarrolla el producto no debiera ser el mismo que el que lo prueba (hay una barrera mental que dificulta que encontremos defectos en aquello que construimos con esmero y dedicación).
- Existe un pequeño número de componentes del producto a probar en el que se concentra una gran cantidad de anomalías.
- Existen distintos tipos de anomalías. Dado que cada técnica de prueba solo es capaz de detectar una clase determinada de anomalías, es necesario aplicar distintos tipos de técnicas de prueba.
- Para obtener el mejor beneficio de las pruebas debe buscarse que comiencen tan pronto como sea posible en el proceso de desarrollo.
- Lo anterior muestra que probar es una tarea creativa e intelectualmente demandante.
En la actualidad, la prueba se ve en ocasiones como una parte integrante del Aseguramiento de la Calidad (“QA”). Esta última gira alrededor de los procesos, bajo la hipótesis (heredada del área de la manufactura) de que la calidad del producto está determinada en buena medida por la calidad del proceso, hipótesis que es bastante debatida (pero aún así, debe trabajarse en la calidad de los procesos). Hemos visto que es más útil considerar la prueba de software como una parte complementaria al QA que nos da información concreta acerca de la calidad del producto de software.
Las descripciones de algunos conceptos que expondremos en lo subsiguiente, si bien son generalizables, estarán enunciados desde la perspectiva de la técnica denominada “prueba de caja negra” (consistente en ejecutar el sistema a probar revisando los requerimientos, con la consigna de detectar insatisfacción de los mismos). La razón es que facilita la exposición sin introducir complejidad innecesaria.
En el LNPS vemos la Prueba de Software como…
un proceso en el que se revisa el software a probar (el SUT, System Under Test) bajo condiciones definidas explícitamente, y se le aplica (eventualmente con apoyo de software especializado de tipo CAST, Computer Aided Software Testing) un conjunto de estímulos (los casos de prueba) diseñados de manera sistemática utilizando técnicas apropiadas, con el objetivo de detectar niveles inadecuados de calidad.
Este proceso debe llevarse a cabo disciplinadamente, y respaldarse en métricas bien definidas.
Todas las actividades y los productos de las mismas son documentados, en especial las fallas detectadas.
Precisemos ahora cada uno de los conceptos de esta definición.
Intuitivamente, un proceso puede verse como una secuencia de pasos, cada uno de las cuales genera productos, tiene insumos asociados, e involucra personas (roles) y recursos (v.gr. hardware y software). Cada uno de los pasos puede eventualmente ser refinado.
El SUT (System Under Test) se refiere en general al elemento que será o está siendo probado.
Las herramientas que utiliza el tester para llevar a cabo las actividades anteriores son conocidas bajo el acrónimo CAST (Computer Aided Software Testing).
Los casos de prueba se diseñan aplicando técnicas adecuadas con el objetivo de detectar la mayor cantidad de fallas, lo más nocivas posible, lo antes posible. Para ello, se busca que los casos de prueba presenten las siguientes características: atomicidad (que un caso no incluya otro(s)), ejemplaridad (que “con poco se pruebe mucho”), que evidencien fallas con claridad, y por supuesto que sean efectivos (que detecten fallas).
Con calidad nos referimos a:
- el grado con el que el SUT satisface los requerimientos funcionales y no-funcionales explícitamente establecidos;
- el nivel con el que se siguieron los estándares de desarrollo explícitos y documentados;
- el grado en que el SUT muestra las características implícitas que se espera de todo producto desarrollado profesionalmente.
Finalmente, consideramos una equivocación como una acción incorrecta cometida por un humano (v.gr. no presionar shift) que ocasiona que se genere una falta (sin el shift, queda “<” en vez de “>” en el código fuente); al ser ejecutada, la falta se evidencia en forma de lo que llamamos una falla. En ocasiones se considera error como la magnitud de la diferencia entre el resultado esperado y el obtenido; sin embargo, aquí tomaremos error como sinónimo de equivocación, y consideraremos “bug” y “defecto” como sinónimos de falta.
Síguenos en :
