archivo

Archivo de la etiqueta: verificación

Aplicando prácticas de Scrum y si me apuráis, por puro sentido común, tenemos que tener como objetivo que el resultado de cada sprint sea una versión entregable y por tanto, que se pueda pasar a producción.

Es muy importante desarrollar con intención para reducir el número de iteraciones (o dicho de otra forma para ganar en cantidad de trabajo efectivo por unidad de tiempo o lo que es lo mismo para ganar en productividad), para ello debemos minimizar (siendo el objetivo máximo eliminar), el número de componentes (funcionalidades) defectuosas que llegan al final del sprint (y por extensión a producción).

Para ello cada historia de usuario debe estar completamente terminada. ¿Qué es eso? Desde luego no es programar las tareas en que se descompone la historia y hacer cuatro pruebas, sino de tener la certeza de que efectivamente funciona, lo que implica una buena batería de testing y la verificación de que efectivamente cumple con las expectativas del usuario.

Una primera aproximación a esto último son las medidas para verificar la misma que aparecen en la historia de usuario, en las cuales tenemos que minimizar las ambigüedades para poder dar por bueno o rechazar la misma, ya que no debería haber medias tintas.

Estas medidas pueden estar implícitas en la propia descripción de la historia o separadas en un apartado diferente de la misma.

Otra cosa es que después, el product owner o por extensión los usuarios, se den cuenta de que la especificación realizada no satisface sus expectativas, en este caso el problema está en la especificación y para solucionarlo se requerirá evolucionar (modificar) esa funcionalidad en uno de los siguientes sprints.

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.

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.

La revisión por pares (o revisión comunitaria), del inglés peer review, es una técnica utilizada para la verificación de artefactos en el proceso de desarrollo de desarrollo de software, es decir, para comprobar si cada uno de ellos se ha realizado de la manera adecuada y cumple el propósito para el que ha sido construido.

Sin embargo, es una técnica que va más allá del desarrollo de software y es utilizada en muy diferentes ámbitos, eso sí, compartiendo la misma finalidad: la verificación.

La técnica consiste en someter la verificación de un artefacto al arbitraje de otros técnicos, profesionales o científicos que también son expertos en la temática en cuestión (los cuales deben actuar de manera independendiente al resto que estén realizando esta tarea, por lo que no debería compartir opiniones y conocer los dictámenes de los mismos), los cuales realizan la evaluación correspondiente del artefacto, realizando recomendaciones sobre el mismo (pudiendo indicar aquellos aspectos que consideran necesario corregir o mejorar).

En muchos casos, un tercero, es el que decide finalmente qué hacer con el artefacto, es decir, dejarlo tal cuál, hacer caso o no a las recomendaciones realizadas por terceros, etc…

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).