V&V

Verificación y Validación

La importancia de este tema se viene dando desde hace ya más de 30 años por Michael S.Deutsch [DEUT79] en su estudio de "Verification and Validation" dice que:

"El desarrollo de sistemas de software implica una serie de actividades de producción en las que las posibilidades de que aparezca el fallo humano son enormes. Los errores pueden empezar a darse desde el primer momento del proceso, en el que los objetivos pueden estar especificados de forma errónea o imperfecta, así como en posteriores pasos de diseño y de desarrollo. Debido a la imposibilidad humana de trabajar y comunicar de forma perfecta, el desarrollo de software ha de ir acompañado de una actividad que garantice la calidad."[1]

Los proyectos de desarrollo de software han padecido tradicionalmente problemas de calidad, tanto en el propio proceso de desarrollo como en los productos de entrega. Esta problemática tiene su origen en las habituales desviaciones sobre los plazos y esfuerzos previstos y en la frecuente aparición durante la implantación y operaciones de los productos resultantes.

El proceso de desarrollo adoptado por un proyecto dependerá de los objetivos y metas que tenga el mismo. Para poder alcanzar dichos objetivos se han desarrollado distintos modelos de ciclo de vida, pero en cualquiera de ellos será necesario un proceso que asegure la calidad del producto durante su desarrollo. Para ello, al final de cada fase del ciclo de vida debería comprobarse que el trabajo realizado hasta ese momento cumple con los objetivos previstos. Este es el punto clave, en el que tiene lugar la evaluación del producto, donde se decide si está o no preparado para pasar a la siguiente fase. De esta forma, si hay errores y son detectados, será más eficiente corregirlos que si se descubriesen en etapas avanzadas.[2]

El objetivo final del proceso de verificación y validación es comprobar que el sistema está hecho para un propósito, al cual intenta llegar aplicando técnicas específicas conocidas como: las pruebas y las revisiones.

El proceso de Verificación y Validación es un conjunto de procedimientos, actividades, técnicas y herramientas que se utilizan paralelamente al desarrollo de software, con el fin de asegurar que un producto resuelve el problema inicialmente planteado.

La Verificación
La verificación comprueba la consistencia del software con respecto a especificaciones y requisitos, es decir, si responde a la pregunta: ¿Se ha construido correctamente el software?

• El proceso determina si los productos resultantes de una fase del ciclo de vida del software cumple los requisitos establecidos en la fase anterior. 
• El proceso determina si el producto resultante es completo, consistente y correcto para comenzar la siguiente fase.

La Validación

La validación comprueba si lo que se ha especificado e implementado es lo que el usuario realmente desea, es decir, si responde a la pregunta: ¿Se ha construido el software correcto?

• El proceso determina si el software cumple su especificación.
• El proceso asegura que el software fabricado se comporta como se espera y de acuerdo a las expectativas del cliente.

Las tareas V&V no solo se aplican a productos de software, sino que también a los resultantes del proceso de desarrollo, como el análisis y a la especificación de requisitos, por ejemplo. De esta forma, se comprueba que el proyecto es viable y que las especificaciones documentadas son completas, correctas, precisas, legibles, evaluables, y que, en general, responden a las expectativas del cliente. La V&V del diseño debe garantizar que los requisitos no se encuentran incompletos o incorrectamente diseñados. En el caso de la implementación y la codificación, la V&V del software es comúnmente conocida como las pruebas de software. 

Técnicas de verificación y validación

Existen dos paradigmas principales que permiten la aplicación de estas en un proyecto, las cuales son el análisis estático y el análisis dinámico.

El análisis estático necesita de la ayuda de una herramienta que analice la representación estática del sistema con el propósito de descubrir errores. Trata de la verificación de "productos" obtenidos durante el desarrollo del software.

Por lo contrario, el análisis dinámico implica normalmente la ejecución del código fuente del software con los datos de prueba, con el fin de evaluar en tiempo real los diferentes escenarios soportados por el programa. [2]

Las técnicas son las siguientes:

• Técnicas estáticas: comprende de las revisiones informales que son:
• Revisión del código.
• Programación en parejas.

y revisiones formales:

• Planificación.
• Familiarización.
• Preparación.
• Examen.
• Rehacer.
• Seguimiento.
• Técnicas dinámicas.
• Caja Negra y Caja Blanca.
• Las pruebas del sistema:
• Pruebas de integración.
• Pruebas de entregas.
• Pruebas de rendimiento.
• Las pruebas de componentes:
• Métodos o funciones individuales.
• Clases de objeto.

Referencias

[1] Ton van Schijndel, Dré Robben, “TPI, CMMI and Testing”, Sogeti Nederland B.V.

[2] Hernández, J. Z. (2011). Análisis de los procesos de verificación y validación en las organizaciones software.

Automatización

En las pruebas de software, la automatización de pruebas es una de las actividades que presentan una mayor expectativa. La posibilidad de ejecutar las pruebas de software de manera desatendida, hace que las organizaciones deshagan sus esperanzas en la automatización como la solución ideal para abaratar los costes y acortar los tiempos de pruebas.

Sin embargo, poner en marcha la automatización no es una tarea sencilla. Es necesario salvar numerosas dificultades para poder llevar a cabo una automatización eficiente y que permita retornar la inversión realizada. Es importante fijar un conjunto de prácticas que agilicen las tareas de mantenimiento y construcción que aporten una cierta metodología a nuestro proceso de automatización.

Buenas Prácticas:
Los productos de la Automatización deben mantenerse organizados. Los Scripts, ficheros de datos, aplicaciones de soporte, documentación, ficheros de configuración, etc... Deben almacenarse en un sistema de directorios y carpetas que permitan su direccionamiento rápido.
La organización puede depender de los objetivos. Podemos organizar nuestra infraestructura de directorios por aplicación, por plan de pruebas, por sistema y demás.

En la sección de modularización los casos de prueba automatizados pueden modularizarse en base a librerías que realicen funcionalidades más sencillas, de esa forma se agilizará el mantenimiento de los casos.
También es posible construir librerías de propósito general que apliquen a todos nuestros casos automatizados con indepencia de la aplicación o proceso. Ejemplos de librerías de propósito general son:
* Control de errores.
* Escritura/lectura de ficheros de datos.

Ahora bien, tenemos también el aspecto de robustez que en casi de que se produzca un error no controlado durante la ejecución, la lógica del caso de prueba debe ser capaz de finalizar y dejar el estado del equipo de ejecución estable y listo para continuar con un nuevo caso de prueba.
Una posibilidad es comprobar el estado de la maqueta al comenzar una ejecución, forzando el cierre de aquellas aplicaciones que se encuentren abiertas o elevar para los servicios necesarios.

Para el sistema de trazas la información que debe aportar un caso de prueba debe ser fiable. En caso de fallo debe informar de manera concreta de lo que ha ocurrido.
Completar la construcción de los casos de prueba con un sistema de trazas que aportan toda la información o suministrar la captura de la pantalla en el momento del error, pueden ayudar a ganar confianza en los casos automatizados.

En la flexibilidad los casos de prueba automatizados se deben preparar teniendo en cuenta posibles cambios.
Una opción es parametrizar aquellos datos susceptibles de cambios: rutas de acceso, identificadores de usuarios...

En el mantenimiento de los equipos de ejecución la ejecución de casos automáticos suele ser una tarea estresante para los equipos donde corren los casos. Es recomendable programar tareas de mantenimiento como reinicios periódicos, eliminación de ficheros temporales, desfragmentación de discos, entre otros.




Referencias:
[1] González, J. (2017). Buenas Prácticas en la Automatización de Pruebas. [online] Qatecnico.blogspot.com. Available at: http://qatecnico.blogspot.com/2011/08/buenas-practicas-en-la-automatizacion.html [Accessed 25 Oct. 2017].

Plan de Pruebas en el Desarrollo del Software

Plan de Pruebas

El propósito del plan de pruebas es desarrollar el alcance, el enfoque, los recursos requeridos, calendarios, responsables y el manejo de riesgos de un proceso de pruebas. Es posible manejar un plan global que abarque los distintos tipos de pruebas como lo son la verificación e integración.

El módulo del plan de pruebas es un instrumento muy útil para dar estructura tanto al proceso de pruebas como a la documentación de las mismas es el plan de pruebas.[2]

Algunos aspectos que se deben contemplar para un plan de pruebas son los siguientes:

1) Identificar el plan: se debe permitir relacionar con el alcance. Como todo artefacto del desarrollo, está sujeto a control de configuración, por lo que debe distinguirse adicional-mente la versión y fecha del plan.

2) Alcance: Indica el tipo de prueba y las propiedades o elementos del software a ser probado.

3) Items por probar: Indica la configuración a probar y las condiciones mínimas que debe cumplir para comenzar a aplicarle el plan. Por un lado, es difícil y riesgoso probar una configuración que aún reporta fallas; por otro lado, si esperamos a que todos los módulos estén perfectos, puede que detectemos fallas graves demasiado tarde.

4) Estrategia: Describe la técnica, patrón o herramienta que se pueda utilizar en el diseño de los casos de prueba. Como por ejemplo en el caso de pruebas unitarias de un procedimiento, esta sección podría indicar: "Se aplicará la estrategia caja-negra de fronteras de la pre-condición". En lo posible la estrategia debe precisar el número mínimo de casos de prueba a diseñar. La estrategia también explica el grado de automatización que se exigirá, tanto para la generación de casos de prueba como para su ejecución.

5) Caracterización de la configuración: Hace de forna explícita las condiciones bajo las cuales, el plan debe ser suspendido-repetido-culminado.
En algunas circunstancias el proceso de prueba debe suspenderse en vista de los defectos o fallas que se han detectado. Al corregirse los defectos, el proceso de prueba previsto por el plan puede continuar, pero debe explicarse a partir de qué punto, ya que puede ser tan simples como aprobar el número mínimo de casos de prueba diseñados o tan complejo como tomar en cuenta no sólo el número mínimo, sino también el tiempo previsto para las pruebas y la tasa de detección de fallas.

6) Tangibles: En este caso los documentos a entregarse al culminar el proceso previsto por el plan deben estar de la mayor forma posible bien estructurados.

7) Procedimientos especiales: Identifica el grado de las tareas necesarias para preparar y ejecutar las pruebas, así como cualquier habilidad especial que se requiere.

8) Recursos: Se deben identificar las propiedades necesarias y deseables del ambiente de prueba, incluyendo las características del hardware, el software de sistemas. Cualquier otro software necesario para llevar a cabo las pruebas, así como la colocación específica del software a probar.

9) Calendarios: Esta parte describe los hitos del proceso de prueba y el grafo de dependencia en el tiempo de las tareas a realizar. Se puede realizar con diagramas como el diagrama de Gantt.

10) Manejo de riesgos: Identifica los riesgos en el plan, las acciones que lo solucionan y la contingencia de estos.

11) Responsables: Especifica quién es el responsable de cada una de las tareas previstas en el plan.[1]

Plan de Pruebas - IEEE 829
La estructura de un plan de pruebas en este tipo de estándar es el siguiente:

1- Introducción
2-Items de pruebas
3-Supuestos
4-Características sujetas a pruebas
5-Características No sujetas a pruebas
6-Estrategia de prueba
7-Criterios de éxito/fracaso
8-Criterios de suspensión/devolución
9-Entregables de las pruebas
10-Tareas de la etapa de prueba
11-Recursos:
        Recursos hardware
       Recursos software
       Herramientas de soporte
12) Roles y responsabilidades
13) Riesgos del proyecto de pruebas
14) Dotación de personal y formación
15)Cronograma/Calendario.
16)Aprobación




Referencias:

[1] Obtenido de: http://www.calidadysoftware.com/testing.php
[2] Obtenido de: http://www.pruebasdesoftware.com/plandeprueba.htm

Cero Defectos del Software

En esta nueva entrada les estaré comentado acerca del "Cero Defectos" del software. Todo sobre este.

El Cero Defectos es un programa de la mejora de la calidad que tiene como objetivo principal que las cosas se hagan bien desde la primera vez. Este toma en cuanta la participación del operador, así como la forma de involucrarse con el producto y el proceso, y mediante una evaluación comprender las consecuencias que puede traer algún error.

Philip Crosby nació en Wheeling, Virginia Occidental el 18 de junio de 1926. Fue un empresario estadounidense, autor que contribuyó a la Teoría Gerencial y a las prácticas de la gestión de la calidad. Hasta su muerte se dedicó a la calidad.
Un dato muy importante es que fundó Philip Crosby Associates (PCA) con sede en Winter Park, Florida, y durante los diez años seguidos la convirtió en una organización con 300 empleados alrededor del mundo y con $80 millones con ganancias. P.C.A. enseñó a la gerencia cómo establecer una cultura preventiva para lograr realizar las cosas bien y a la primera. GM, Chrysler, Motorola, Xerox, muchos hospitales, y cientos de corporaciones alrededor del mundo vinieron a P.C.A. para entender la Administración de la calidad. Todavía enseña en 16 lenguajes alrededor del mundo.[1]

Componentes Básicos para la resolución de problemas y mejoramiento de la calidad:

1. Cuatro Fundamentos:
1. Pleno involucra-miento de la dirección.
2. Administración profesional de la calidad.
3. Programas originales.
4. Reconocimiento.
2. Los 5 principios de la dirección de calidad.
1. La calidad significa cumplir los requisitos del funcionamiento del producto.
2. No existen problemas de calidad.
3. No existen ahorros al sacrificar la calidad.
4. La calidad medida de desempeño es el costo de la calidad. 
5. El único estándar de desempeño es el cero defectos.
3. Los 14 pasos de Crosby los cuales son:
1. Asegúrese de que la dirección esté comprometida con la calidad.
2. Forme equipos para el mejoramiento de la calidad con representantes de cada departamento.
3. Determine como analizar dónde se presentan los problemas de calidad actuales y potenciales.
4. Evalúe el coste de la calidad y explique su utilización como una herramienta de administración.
5. Incremente la información acerca de la calidad y el interés personal de todos los empleados.
6. Tome medidas formales para corregir los problemas identificados a lo largo de los pasos previos.
7. Instituya una comisión para el programa "Cero Defectos".
8. Instruya a todos los empleados para que cumplan con su parte en el programa de mejoramiento de la calidad.
9. Organice una "jornada de los Cero Defectos" para que todos los empleados se den cuenta de que ha habido un cambio.
10. Aliente a los individuos para que se fijen metas de mejoramiento para sí mismos y para sus grupos.
11. Aliente al personal para que comunique a la dirección los obstáculos que enfrenta en la persecución de sus metas de mejoramiento.
12. Reconozca y valore a aquellos que participan activamente en el programa.
13. Establezca consejos de calidad a fin de mantener informado al personal en forma regular.
14. Repita todo para enfatizar que el programa de mejoramiento de la calidad no finaliza jamás. 

Ventajas: 

• Se concentra el esfuerzo en ámbitos administrativos y de procedimientos competitivos.
• Consiguen mejoras en un corto plazo y resultados meramente visibles.
• Si existe reducción de productos defectuosos por consecuencia hay una reducción de los costos.
• Incrementa la productividad y dirige a la organización hacia la hacia la competitividad.
• Contribuye a la adaptación en los procesos a los avances tecnológicos y permite alinear procesos repetitivos.

Desventajas:

• Se pierde la perspectiva de la interdependencia entre los miembros de la empresa. 
• El mejoramiento continuo se hace a un proceso muy largo.
• Requiere de un cambio en toda la organización y hay que hacer inversiones importantes

Una aplicación es el sistema "jidoka", que es la automatización  con la mano humana de que el sistema permita tener su propio auto-control de oportunidad.

Referencias:

[1] Obtenido de: http://www.pablogiugni.com.ar/httpwwwpablogiugnicomarp106/