Desarrollo de software. Testing. La elección de los casos de prueba
Los casos de prueba que permitirían demostrar que funcionalmente un sistema tiene un comportamiento adecuado (otros tipo de casos de prueba son aquellos relacionados con pruebas no funcionales y que deberían verificar el adecuado comportamiento del sistema en situaciones de stress, desde el punto de vista de la seguridad, etc…) dependen de la complejidad y tamaño del sistema.
Es muy costoso plantear un juego de pruebas que reduzca a cero (o mejor dicho que haga que tienda a cero) la probabilidad de error, solo hay que ver la cantidad de casuísticas que se pueden presentar en la utilización de un sistema y darnos cuenta de que cualquiera de ellas podría dar lugar a error si hay algún aspecto en el proceso de programación que se nos ha escapado.
Como no suele haber una práctica del testing en los equipos de desarrollo, ni se suele tener una formación específica, la selección de los casos de prueba en muchas ocasiones no es óptima en el sentido de que el número de errores de tipo funcional que pueden detectar los mismos no es proporcional al esfuerzo que se ha necesitado para diseñar dichos casos de prueba y al que se requiere para ejecutarlos.
Teniendo en cuenta que lo ideal es que cada tipo de sistema tenga su propio itinerario de testing, resulta fundamental que el caso de pruebas elegido esté a la altura de los umbrales definidos en ese itinerario con el menor coste posible.
Teniendo en cuenta que alcanzar ese equilibrio es complicado, por lo menos hay que tender a él e intentar que los casos de prueba elegidos cubran la posibilidad de encontrar el mayor número de errores posible, ya que los errores permanecerán ocultos hasta que se ejecute la porción de código que los provoca y para que dicha porción se ejecute es necesario que el usuario (o el mecanismo automático de testing utilizado) realice las acciones necesarias para provocarlo.
Jummp 