Saltar la navegación

1.4.- Limitaciones del proceso.

Caso práctico

Juan no puede evitar pensar que el proceso de pruebas va a llevarles un tiempo precioso, tiempo que podría emplear para avanzar en otras fases del proyecto… ¿Por lo menos nos servirá para encontrar todos los errores?

Imagen de Juan, uno de los protagonistas de nuestros casos prácticos.
Ministerio de Educación y Formación Profesional (Elaboración propia)



Resulta que, por su propia naturaleza, no es posible probar completamente los productos software, tanto por su complejidad como por su coste.

Por tanto, el propósito más importante es el de reducir, mediante la detección temprana de problemas, los riesgos derivados de la aparición de los posibles defectos en los procesos de implantación y explotación.

En la práctica se considera que, en software, el conjunto completo de casos de prueba es teóricamente infinito. El número de pruebas a realizar implicará un equilibrio entre recursos y tiempo.
Imagen que muestra a una chica sentada, trabajando con un ordenador.
Ministerio de Educación y Formación Profesional (Elaboración propia)



Según los datos y tal como demuestra la experiencia, resulta que por muy cuidadosos que hayamos sido en la estrategia de pruebas siempre habrá una serie de errores que sólo aparecen cuando el cliente comienza a usarlo.

Debemos tener claro que "el cliente siempre lleva la razón" y, por esta razón, después de un cierto tiempo en el que el cliente haya estado usando nuestra aplicación y descubra defectos, o que el programa no realice lo que se esperaba (o en la forma en que se esperaba), debemos revisar la aplicación y corregir esas taras.

Es por ello que las pruebas de aceptación, como veremos más adelante, tienen gran importancia y pueden llevarse a cabo durante incluso semanas después de haber entregado el proyecto al cliente.

Las empresas se sorprenden de que no se pueda estimar de forma realista el coste de sus proyectos. El coste asociado al proceso de pruebas no es fácilmente estimable, puesto que no hay dos proyectos iguales.

El software no puede ser 100 % libre de errores. La cuestión más difícil en la realización de pruebas es estimar el momento en que debemos parar.

Por propia definición, un proyecto de software siempre tendrá defectos y nuestra principal finalidad es minimizarlos. Para conseguirlo, hay que tener en cuenta una serie de principios:

  1. Siempre hay falta de conocimiento del estado real de las aplicaciones durante el desarrollo de los proyectos. (Este es el motivo principal por el que nunca sabremos el coste asociado a la estrategia de pruebas).
  2. Tener buenos conocimientos técnicos no son una garantía de éxito de un proyecto.
  3. Hay que seguir procedimientos y actividades estandarizadas que nos guíen durante el desarrollo del proyecto y nos permitan realizar los mismos de forma repetitiva.