archivo

Archivo de la etiqueta: validación

Realmente podemos llevarnos horas, días, semanas, meses, discutiendo sobre si la aplicación de una determinada estrategia, enfoque o práctica es adecuada, pero solo se tratará de especulación, muchas hipótesis e ideas.

¿Es humo? Para mi el humo tiene mucho más que ver con hipótesis que solo han tenido en cuenta aspectos teóricos u opiniones personales que no se han contrastado, al menos, con la realidad del contexto en el que se quieren aplicar. Si, por lo menos, las ideas se sustentan en un análisis objetivo, yo no lo llamaría humo, pero no dejan de ser hipótesis sin validar.

Lo queramos llamar humo o no, se trata de mucho tiempo invertido en establecer un conjunto de ideas que lo mismo la realidad se encarga de demostrar que son equivocadas.

Ese tiempo invertido puede suponer dinero (siempre lo es aunque no te suponga un gasto directo), pérdida de oportunidad y/o dificultad de adaptación al cambio si has desarrollado un producto prácticamente finalista.

Mientras que el negative testing se centraba en la localización de incidencias y errores en los artefactos que se producen en el proceso de desarrollo de software (entre ellos el propio software), el positive testing es la forma más habitual de testing ya que se centra la detección de incidencias en la verificación y validación de los objetivos reales que persigue el artefacto construido y su adecuación al proyecto que se está realizando y las entradas que reciba de artefactos anteriores o del mismo si para su obtención se está siguiendo un proceso iterativo e incremental.

Por tanto, las incidencias se encuentran cuando el artefacto no tiene el contenido o el comportamiento adecuado.

Es un concepto sobre el que hay muchísima bibliografía y en cierto modo es algo curioso, ya que el negative testing es el proceso de buscar incidencias en el artefacto que se verifica o se valida, es decir, la diferencia con el testing ordinario es que este encuentra los errores mediante la comprobación de si un artefacto cumple las expectativas, si tomamos por ejemplo en el propio producto software, el testing ordinario se centraría en validar si se cumplen o no los requisitos funcionales y no funcionales y las incidencias se encontrarían mediante ese proceso.

El negative testing busca errores y no se centra (por lo menos no es su objetivo principal) en comprobar si el producto funciona.

¿Dónde podemos aplicar negative testing? En muchas áreas, por ejemplo, cuando se detecta una incidencia en una funcionalidad o módulo del sistema que sospechamos que se puede extender a otros, cuando hacemos testing exploratorio, etc…

El testing tiene diferentes objetivos, pero el principal es ayudar a conseguir que el producto final sea de calidad. Eso no se consigue participando exclusivamente antes de la entrega del software o antes de su puesta en producción, se requiere aplicar los procesos de verificación y validación desde las etapas iniciales del proyecto (algo que sugiere los modelos de testing en V o de testing en W).

En esta línea se encuentra el experto en calidad del software y testing, David Coward, cuando indica que: “El principal objetivo del testing del software es dar confianza al software”.

Es interesante el uso de la palabra confianza, algo fundamental en sistemas críticos donde es necesario tener seguridad de que los requisitos funcionales y no funcionales se han llevado a cabo de manera adecuada y también importante en sistemas no críticos donde un sistema de información puede fracasar y costar mucho esfuerzo (y dinero) darle la vuelta.

Que un proveedor de servicios de desarrollo de software no tenga entre sus procesos una mínima metodología de verificación y validación de los artefactos que se van generando en los proyectos de desarrollo de software me parece una temeridad y eso que es algo con lo que me encuentro con demasiada frecuencia.

Es decir, se deja al buen o mal hacer del equipo de desarrollo la responsabilidad da revisar los artefactos (entre ellos, el más importante, el software) sin que exista unos procedimientos establecidos para ello. ¿Cuál es la consecuencia de todo esto? La organización no tiene una estrategia para garantizar unos mínimos de calidad en los desarrollos y eso es malo a corto plazo pero todavía peor a largo plazo ya que en un entorno tan competitivo como este negocio, la calidad puede ser aquello que te haga distinto de la competencia porque al final muy pocos se atreven a trabajar con quienes han tenido malas experiencias o tienen malas referencias por muy barato que sean sus precios o por muy maravilloso que sea lo que te vendan.

Que el cliente tenga sus propios mecanismos para intentar conseguir unos umbrales de calidad aceptables no debe eximir a que el proveedor los tenga ya que no es algo que deba depender del cliente con el que se trabaja sino que tiene que formar parte de la cultura de la organización.

Existe un cierto grado de confusión entre lo que es smoke testing y sanity testing, sin embargo, las diferencias entre ambas técnicas son significativas, ya que sanity testing consiste en realizar pruebas de regresión tras un cambio menor que se realizan sobre una funcionalidad o un conjunto de funcionalidades concretas del sistema (constituye por tanto, un subconjunto del total de pruebas de regresión que se pueden definir o realizar sobre la aplicación).

Este testing se debe realizar con detalle pero sin salirse de lo que es el nivel de validación funcional.

Cuando traté sobre el área de proceso de verificación, comenté su estrecha relación con este área de proceso del nivel 3 de CMMI.

La verificación comprueba que cada artefacto se ha obtenido/construido como debe y en la validación se comprueba si es correcto, por ejemplo, si un artefacto son las historias de usuario o los casos de uso, la verificación constata si se ha seguido el procedimiento y técnica definida para la obtención de los mismos, lo cual no quiere decir que sean correctos o que realmente vayan alineados con las expectativas del usuario en el sistema que se está construyendo.

Por tanto en este proceso se define, qué se valida, cómo realizar las validaciones, dónde se realizan, qué técnicas aplicar, quienes participan y qué hacer con los resultados obtenidos de la misma.