archivo

Archivo de la etiqueta: pruebas funcionales

Uno de los aspectos más complicados del testing consiste en definir hasta dónde se va a llegar, es decir, qué tipo de pruebas realizar y con qué intensidad, ya que todo el software no tiene la misma criticidad, los mismos recursos para su desarrollo, los mismos plazos, etc…

Es un error aplicar el mismo nivel de testing a todos los productos, ya que podemos pecar por exceso o por defecto (siempre mejor, como es lógico el exceso) y además hay que tener en cuenta que el testing se debería medir más por su efectividad y por su calidad que por el tiempo dedicado al mismo, si bien, se entiende que un equipo formado, aplicando una serie de metodologías y utilizando una serie de herramientas, mantendrá un nivel de efectividad más o menos regular por unidad de tiempo.

A lo anterior hay que añadir que el testing se debe realizar en todo el proceso de desarrollo y no solo al final y que el mismo equipo de proyecto debe participar en el mismo mediante la aplicación de pruebas unitarias, integración continua, pruebas funcionales, verificaciones continuas con el usuario y obtención e implementación del feedback, etc…, independientemente de que existan una serie de profesionales que sean especialistas en realizar este tipo de trabajo.

El testing es muy importante y no una disciplina secundaria, no es algo que se debiera infravalorar, como en el mundo de la programación hay programadores buenos, malos y regulares, lo mismo pasa con los testers. Un producto que llega a producción con errores graves va a costar dinero, de una u otra forma. En algunos casos estos errores serán críticos y el coste será elevadísimo en otros casos provocará un parón en el servicio que no es poco.

Resulta muy interesante la siguiente cita de Weinberg porque refleja bien a las claras lo crítico que resulta en muchas ocasiones el proceso de testing y lo complicado que resulta establecer sus límites (traducción libre): “En septiembre de 1962, saltó a la luz una noticia que indicaba que un cohete de 18 millones de dolares había sido destruido en pleno vuelo debido a un simple guión que faltaba en un programa. La naturaleza de la programación es así, ya que no existe relación entre el tamaño del error y los problemas que causa. Por tanto, es difícil definir cualquier objetivo en el proceso de testing, sin llegar a la eliminación de todos los errores, algo que resulta imposible”.

Que yo diga que los productos son entregados sin la realización de unas pruebas funcionales rigurosas por parte de la mayoría de los proveedores de servicios de desarrollo de software no cogerá de sorpresa a la mayoría de sus responsables. Sé que algunos dirán: “pues en mi equipo de trabajo sí que se prueba todo o yo personalmente pruebo todo”. Y yo responderé que seguro que hay excepciones y que también que este tipo de generalizaciones, como toda generalización, es injusta.

Cuando digo que no cogerá de sorpresa es debido a que esa conciencia de que no se prueban las entregas lo que se debía probar existe y no sólo por nosotros los clientes, sino que los proveedores lo saben y eso suele ser provocado porque no existen unos procesos de prueba y de control de calidad rigurosos en los desarrollos y por tanto, al no existir se deja al libre albedrío de los equipos de proyecto y de sus técnicos la realización de estas tareas, por lo que difícilmente se podrá ser determinista en cuanto a la calidad, al menos funcional, del producto que se entrega.

La entrega de desarrollos con problemas funcionales, ocasiona pérdidas en el cliente, se detecten en la fase de pruebas del producto o en producción. Para empezar porque hace necesario la realización de varias veces las mismas tareas: tratar la entraga, desplegarla en el servidor de pruebas, probar, comunicarse con el proveedor, con la dirección del proyecto, etc… ¿quién paga esas horas?, ¿quién sufre por el colapso que se produce en área de desarrollo, calidad y sistemas por el hecho tener que repetirse estas tareas, cuando hay otras muchas esperando a ser tratadas? por regla general el cliente. También hay que tener en cuenta los costes directos e indirectos que tiene el hecho de que se retrase la puesta en producción de una aplicación o de un parche que corrija defectos en la misma.

Además de todo lo anterior, se crea desconfianza, lo que hace que se tenga que dedicar más atención por parte de los responsables del proyecto a todo el proceso que gira alrededor de la entrega del producto, lo que supone que tengan que dedicar menos tiempo a otras tareas que lo mismo resultan de una mayor importancia e interés para la organización.

A mi personalmente me parece un hecho diferencial para las empresas la consecución de un buen porcentaje de entregas limpias, convenientemente acompañadas por guías detalladas y correctas de instalación, así como por sus correspondientes casos de prueba. Después entrarán a considerarse también otros aspectos como la calidad de la codificación, de la arquitectura, etc… que para mi también marcan la diferencia por su repercusión en la deuda técnica del producto.