¿Qué es V-Model?
V-Model, también conocido como modelo de validación o verificación, es un estándar de pruebas que aplica a conseguir calidad en los sistemas.
Este modelo apareció por primera vez en los años 80 en la empresa aeroespacial y de defensa Hughes Aircraft (adquirida por General Motors en 1985) como parte del esfuerzo previo a la propuesta para el programa Federal Aviation Administration (FAA) Advanced Automation System (AAS).
El V-Model se utiliza para describir las actividades de prueba como parte del proceso de desarrollo de software, puede interpretarse como una extensión del modelo de desarrollo en cascada (Waterfall), que describe las actividades de prueba como uno de los últimos pasos de un proceso de desarrollo secuencial. Sin embargo, a diferencia del modelo en cascada, el V-Model muestra la relación entre cada fase de desarrollo y su correspondiente actividad de prueba. Consiguiendo la calidad de forma interactiva y escalonada, validando y verificando cada uno de los pasos del desarrollo del software.
Se le ha criticado mucho por simplificar el proceso de desarrollo y por no ajustarse completamente a la metodología ágil, sin embargo es muy útil como modelo para cada iteración de un proyecto ágil. Además incluye términos y conceptos esenciales para las pruebas de software que pueden aprovecharse para encontrar una estructura adecuada para los esfuerzos de prueba.
Introducción al V-Model
La idea principal del V-Model es que las actividades de desarrollo y de prueba se corresponden entre sí. Cada fase de desarrollo debe completarse con su propia actividad de prueba, cubriendo cada una de ellas un nivel de abstracción diferente: los componentes de software, la integración de componentes, el sistema de software completo y la aceptación del usuario. Es un modelo muy disciplinado y cada fase comienza solo después de completar la fase anterior.
El V-Model describe las fases de desarrollo como la rama izquierda de una «V», mientras que la rama derecha representa las actividades de prueba.
1.- Estudio de los requisitos
A través de reuniones con las partes interesadas, se definen los requisitos estableciendo qué es lo que tiene que hacer el sistema.
Se definen:
2.- Diseño del sistema
Es la solución tecnológica que nos va a permitir dar solución a esos requisitos que nos están pidiendo. Se define cuál es la tecnología sobre la que se va a implantar la solución final. Se diseña a nivel funcional, estableciendo: las funciones, los elementos de la interfaz de usuario, los flujos de trabajo y las estructuras de los datos.
Se preparan los documentos para las pruebas del sistema.
3.- Diseño de la arquitectura
A lo largo de esta fase se especifica la funcionalidad general de los componentes del sistema, las interfaces y las dependencias. El diseño de la arquitectura nos permite definir de qué forma van a interactuar cada una de las soluciones técnicas. Para ello se suelen utilizar lenguajes de modelado, como UML.
Se preparan las pruebas de integración.
Recomendado por LinkedIn
4.- Diseño modular
Se describe en detalle cada módulo, incluyendo la lógica interna que se va a implementar, una especificación detallada de la interfaz que describe la API y las tablas de la base de datos, si las hay. Este diseño nos va a permitir más tarde ejecutar su programación y llegar hasta el punto final que es el Software.
Se preparan las pruebas de los módulos, dado que existen la especificación de la interfaz y la descripción funcional de los módulos o componentes.
5.- Programación
La fase de programación es el trabajo de codificación utilizando un lenguaje de programación específico. Sigue las especificaciones que se han determinado en las fases de desarrollo anteriores.
Verificación y Validación.
Una vez que tengamos el Software, vamos a ir incrementando para ir verificando y validando que se van cumpliendo cada una de las fases.
La verificación es una revisión realizada sin ejecutar código, evaluando la fase de desarrollo del producto para determinar si se cumplen los requisitos especificados.
La validación es el proceso para evaluar el software después de la finalización de la fase de desarrollo para determinar si el software cumple con las expectativas y los requisitos del cliente. Se realizan pruebas ejecutando código.
Las fases de verificación y validación se unen mediante la fase de programación en forma de V. De ahí el nombre “V-Model”, donde las fases de verificación están en el lado izquierdo de la v y las fases de validación en el lado derecho de la v.
Según el V-Model, un tester tiene que verificar si se cumplen los requisitos de una fase de desarrollo específica. Además, tiene que validar que el sistema satisface las necesidades del usuario, el cliente u otras partes interesadas. En la práctica, las pruebas incluyen tanto verificaciones como validaciones.
Etapas de prueba
Según el V-Model, las actividades de prueba se dividen en diferentes fases, vinculadas con cada fase del desarrollo:
Hace unos meses publicamos un post sobre los tipos de pruebas. En él encontrarás toda la información sobre cada tipo de pruebas, su definición y explicación con ejemplos reales.
Para más información, contacta sin ningún tipo de compromiso con SIPSA.
Sentimos disentir de una manera tan tajante, y no pretendemos dudar de las ventajas que el V-model pueda aportar a equipos concretos en circunstancias concretas, pero, como bien indicáis se trata de un modelo de validación o verificación del estado del código, en ningún caso se debe relacionar plenamente esto con el aseguramiento de la calidad, sin duda un término mucho más amplio y que va más allá del testing aglutinando un buen número de buenas prácticas que nos permitan trabajar de una forma más proactiva en busca de la mejor calidad posible de nuestro software, por tanto aseverar que este modelo es uno de los estándares de aseguramiento de la calidad puede resultar confuso.