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.