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.

En el nivel 3 de CMMI estamos analizando diferentes áreas de proceso que lo que hacen es especificar un marco de trabajo para la realización de determinadas tareas dentro del proceso de desarrollo de software.

Esta estrategia a nivel organizativo para la obtención de productos software requiere de procesos que se encarguen de verificar la calidad y adecuación a su finalidad de los diferentes artefactos intermedios que se vayan obteniendo así como el resultado final, es decir, no se trata solo de definir los caminos que se pueden elegir a la hora realizar el desarrollo, sino también de determinar los controles a realizar para comprobar si las diferentes piezas utilizadas en el proceso de ingeniería del software y de construcción (al fin y al cabo una parte más del mismo proceso de ingeniería) cumplen su propósito y los requisitos establecidos.

Los citados en el anterior párrafo, son los objetivos fundamentales de este área de proceso. La diferencia respecto al área de proceso de validación, que trataremos más adelante, es que en la verificación comprobamos si el estamos desarrollando (construyendo) el producto de manera adecuada (es decir, este artefacto, ¿está construido cómo debe?) y en la validación se comprueba si se está desarrollando el producto correcto (que no es lo mismo). Ambas áreas de proceso van de la mano, aunque tengan finalidades distintas.

Una organización es madura si es capaz de detectar desviaciones lo más cerca posible de la causa o causas que lo provocan, ya que cuanto más nos alejemos del foco y/o más tardemos en realizar acciones correctoras, más esfuerzo se requerirá para invertir esta tendencia.

En este área de proceso se debe establecer:

– Los artefactos que se deben verificar, pudiendo llegar a definirse (como en las otras areas de proceso) diferentes escenarios en función del tipo de proyecto o incluso establecer las condiciones que debe cumplir un artefacto para ser verificado.

– El entorno de verificación, es decir, dónde y qué medios se van a aplicar para realizar las diferentes verificaciones.

– Los procedimientos de verificación, es decir, cómo y que criterios se van a seguir para determinar si un artefacto cumple con su finalidad. La metodología determina que el procedimiento debe basarse en un mecanismo de revisión por pares en cual se suele incluir el análisis de los resultados de la verificación y la determinación de las acciones correctoras.

El modelo en V se suele entender como una metodología de testing, sin embargo, se trata en realidad de una adaptación del ciclo de vida clásico o en cascada realizado por el gobierno federal alemán (aunque también existen versiones de esta metodología que se desarrollaron en paralelo o independientemente a la misma) en la cual se pretende aliviar algunos de sus problemas, como por ejemplo la validación tardía que se realizaba del producto (generalmente en el momento de la entrega), realizando validaciones y verificaciones en paralelo al proceso de desarrollo, las cuales están adaptadas a la fase del proyecto en la que nos encontremos.

Desde mi punto de vista se trataba de normalizar ciertas buenas prácticas que ya se venían llevando a cabo en desarrollos en cascada como la revisión por etapas de los entregables de las mismas, así como la definición de los casos de prueba específicos en cada una de ellas (se rompía en cierto modo con lo que era estrictamente una cascada pero resultaba totalmente razonable no dejar toda la “suerte” del desarrollo a las etapas finales del ciclo de vida).

Por tanto, se trata de un modelo en cascada con vitaminas, mejorado, pero que arrastra las principales carencias del modelo.

La V del modelo representa a dos secuencias de fases, la primera se corresponde con la secuencia de fases de desarrollo del proyecto y la segunda con la secuencia de fases de testing del proyecto. Las fases de un mismo nivel se realizan en paralelo. Estas dos cascadas se muestran más alejadas cuanto más abstracta es la visión del producto, es decir, en las etapas más tempranas y se acercan hasta tener como punto de unión la codificación o punto más concreto del desarrollo de software.

La V también se puede considerar como la metáfora de una vuelta atrás cuando en el proceso de testing de una fase no se cumple con las expectativas de la misma (si bien, se considera que la representación gráfica del modelo no deja bien claro este hecho, lo que entre otras causas, como por ejemplo que tampoco deja claro que hito software es el que verifica, lo que originó la aparición del modelo en W).

¿Qué defectos presenta este modelo? Al igual que la cascada la diferencia de tiempo existente entre el inicio del proyecto y la puesta en producción, existiendo una ventana de tiempo lo suficientemente importante como para que se produzcan contingencias en el proyecto (cambio en las especificaciones, cambios en los procesos, cambios organizativos, cambios de interlocutores, cambio de prioridades, etc…) que puedan afectar gravemente al proceso de desarrollo.

Además, al igual que la cascada es un modelo predictivo en el que se da por supuesto de que la diferencia entre lo que se entiende que quiere el usuario, el usuario cree que quiere y el producto final es muy pequeña, cuando la realidad indica que por regla general esa diferencia es importante y que cuando antes se ataje, menores serán los costes necesarios para obtener un producto acorde a las expectativas del usuario. Para evitar esto interesa obtener el feedback del usuario cuanto antes, lo que obliga a ir liberando versiones del producto periódicamente (en periodos cortos aunque acordes con las características del proyecto).

Dentro del libro blanco de desarrollo de una organización o de las normas de calidad del software resulta de mucha utilidad contar con un catálogo de validaciones.

Este catálogo define de manera única cómo validar determinados tipos de atributos como por ejemplo un NIF.

Cuando se esté especificando un requisito funcional (o cualquier otra técnica que se utilice para representar lo que quiere el usuario) y se quiera indicar cómo validar esos atributos, bastará con referenciar al código de validación que le corresponda a cada uno (no teniendo que volver a repetir en qué consiste la validación lo cual a su vez puede ser fuente de errores si no se expresa con las mismas palabras lo que ya está definido en el catálogo de validaciones).