Metodologías de prueba de software: modelos de control de calidad
Tomas Hamilton
⚡ Resumen inteligente
La metodología de pruebas de software define las estrategias y los tipos de pruebas que se utilizan para certificar que una aplicación cumple con las expectativas del cliente. Las metodologías en cascada, iterativas, ágiles y de programación extrema determinan cuándo comienzan las pruebas y cómo se recibe la retroalimentación.
¿Qué es la metodología de pruebas de software?
La Metodología de Prueba de Software se define como estrategias y tipos de prueba utilizados para certificar que la Aplicación Bajo Prueba cumple con las expectativas del cliente. Las metodologías de prueba incluyen pruebas funcionales y no funcionales para validar el AUT. Ejemplos de metodologías de prueba son Examen de la unidad, Pruebas de integración, Pruebas del sistema, Test de rendimiento etc. Cada metodología de prueba tiene un objetivo de prueba definido, una estrategia de prueba y entregables.
Nota: : Dado que las pruebas de software son una parte integral de cualquier metodología de desarrollo, muchas empresas utilizan coloquialmente el término Metodologías de desarrollo y metodologías de prueba. Por lo tanto, las metodologías de prueba también podrían referirse a modelos de cascada, ágiles y otros modelos de control de calidad en comparación con la definición anterior de metodologías de prueba. La discusión sobre varios tipos de pruebas no agrega valor a los lectores. Por ello, discutiremos los diferentes modelos de desarrollo.
Metodología de prueba vs. Tipo de prueba vs. Estrategia de prueba
La nota anterior deja entrever una ambigüedad real en el sector. Tres términos se usan indistintamente en una conversación, pero tienen significados diferentes en un documento de proyecto, y confundirlos da lugar a planes de prueba que responden a la pregunta equivocada.
| Término | Pregunta que responde | Decidido por | Ejemplos |
|---|---|---|---|
| Metodología de prueba | ¿Cuándo y cómo encajan las pruebas en el ciclo de desarrollo? | El modelo de desarrollo en uso | Cascada, iterativo, ágil, programación extrema |
| Tipo de prueba | ¿Qué aspecto del producto se está verificando? | Cobertura de riesgos y requisitos | Unidad, integración, sistema, rendimiento, seguridad |
| Nivel de prueba | ¿Con qué nivel de detalle se examina el software? | Posición en la jerarquía de compilación | Componente, integración, sistema, aceptación |
| estrategia de prueba | ¿Cuál es nuestro enfoque organizativo respecto a la calidad? | Liderazgo en control de calidad, aplicable a todos los proyectos | Basado en riesgos, automatización primero, cambio a la izquierda |
| Plan de prueba | ¿Qué es exactamente lo que este proyecto pondrá a prueba, cuándo y quién lo hará? | Gerente de pruebas, específico del proyecto | Alcance, cronograma, recursos, criterios de entrada y salida. |
Una regla práctica útil: la metodología establece el ritmo, el tipo establece el objetivo y el Plan de prueba registra el compromiso. Las secciones siguientes examinan las metodologías.
Modelo de cascada
¿Qué es?
En la sección modelo de cascada, el progreso del desarrollo de software a través de varias fases como análisis de requisitos, diseño, etc. secuencialmente.
En este modelo, la siguiente fase comienza sólo cuando se completa la fase anterior.
¿Cuál es el enfoque de prueba?
La primera fase del modelo en cascada es la fase de requisitos en la que todos los requisitos del proyecto están completamente definidos antes de comenzar las pruebas. Durante esta fase, el equipo de pruebas analiza el alcance de las pruebas, la estrategia de pruebas y redacta un plan de pruebas detallado.
Solo una vez que se complete el diseño del software, el equipo pasará a la ejecución de los casos de prueba para garantizar que el software desarrollado se comporte como se esperaba.
En esta metodología, el equipo de pruebas pasa a la siguiente fase sólo cuando se completa la fase anterior.
| Ventajas | Desventajas |
|---|---|
| Este modelo de Ingeniería de software es muy sencillo de planificar y gestionar. Por lo tanto, los proyectos en los que los requisitos están claramente definidos y establecidos de antemano se pueden probar fácilmente utilizando un modelo en cascada. | En el modelo en cascada, puede comenzar con la siguiente fase sólo una vez que se haya completado la fase anterior. Por lo tanto, este modelo no puede adaptarse a eventos no planificados ni a la incertidumbre. |
| Esta metodología no es adecuada para proyectos donde los requisitos cambian con frecuencia. |
Desarrollo iterativo
¿Qué es?
En este modelo, un proyecto grande se divide en partes más pequeñas, y cada parte se somete a múltiples iteraciones del modelo en cascada. Al final de cada iteración, se desarrolla un nuevo módulo o se mejora uno existente. Este módulo se integra en la arquitectura del software y se prueba todo el sistema en su conjunto.
¿Cuál es el enfoque de prueba?
Tan pronto como se completa la iteración, todo el sistema se somete a pruebas. Los comentarios de las pruebas están disponibles de inmediato y se incorporan en el siguiente ciclo. El tiempo de prueba requerido en iteraciones sucesivas se puede reducir en función de la experiencia adquirida en iteraciones pasadas.
| Ventajas | Desventajas |
|---|---|
| La principal ventaja del desarrollo iterativo es que la retroalimentación de la prueba está disponible inmediatamente al final de cada ciclo. | Este modelo aumenta significativamente los gastos generales de comunicación ya que, al final de cada ciclo, se debe dar retroalimentación sobre los entregables, el esfuerzo, etc. |
Metodología ágil
¿Qué es?
Las metodologías tradicionales de desarrollo de software parten de la premisa de que los requisitos del software se mantienen constantes durante todo el proyecto. Sin embargo, a medida que aumenta la complejidad, los requisitos sufren numerosos cambios y evolucionan continuamente. A veces, el propio cliente no está seguro de lo que quiere. Aunque el modelo iterativo soluciona este problema, sigue basándose en el modelo en cascada.
En la metodología Agile, el software se desarrolla en ciclos rápidos e incrementales. Se enfatizan las interacciones entre clientes, desarrolladores y clientes en lugar de procesos y herramientas. La metodología ágil se centra en responder al cambio en lugar de una planificación exhaustiva.
¿Cuál es el enfoque de prueba?
Las pruebas incrementales se utilizan en métodos de desarrollo ágiles y, por lo tanto, cada versión del proyecto se prueba minuciosamente. Esto garantiza que cualquier error en el sistema se solucione antes de la próxima versión.
| Ventajas | Desventajas |
|---|---|
| Es posible realizar cambios en el proyecto en cualquier momento para cumplir con los requisitos. | La interacción constante con el cliente significa una mayor presión de tiempo para todas las partes interesadas, incluido el propio cliente, el desarrollo de software y los equipos de prueba. |
| Esta prueba incremental minimiza los riesgos. |
Programación extrema
¿Qué es?
La programación extrema es un tipo de metodología ágil que cree en ciclos de desarrollo cortos. Un proyecto se divide en tareas de ingeniería simples. Los programadores codifican una pieza de software simple y se comunican con el cliente para recibir comentarios. RevSe incorporan puntos de vista del cliente y los desarrolladores continúan con la siguiente tarea.
En la programación extrema los desarrolladores suelen trabajar en parejas.
Programación extrema se utiliza en lugares donde los requisitos del cliente cambian constantemente.
¿Cuál es el enfoque de prueba?
La programación extrema sigue un desarrollo basado en pruebas que se describe a continuación:
- Agregue un Caso de prueba al conjunto de pruebas para verificar la nueva funcionalidad que aún está por desarrollarse.
- Ejecute todas las pruebas y, obviamente, el nuevo caso de prueba agregado debe fallar ya que la funcionalidad aún no está codificada.
- Escriba algún código para implementar la característica/funcionalidad.
- Ejecute el conjunto de pruebas nuevamente. Esta vez, el nuevo caso de prueba debería pasar ya que la funcionalidad ha sido codificada.
| Ventajas | Desventajas |
|---|---|
| Los clientes que tengan en mente un diseño de software vago podrían utilizar la programación extrema. | Las reuniones entre el equipo de desarrollo de software y los clientes aumentan los requisitos de tiempo. |
| Las pruebas continuas y la integración continua de versiones pequeñas garantizan que el código de software entregado sea de alta calidad. |
Modelo en V y modelo espiral
En la mayoría de los proyectos aparecen dos modelos adicionales que completan el panorama, ya que cada uno responde de manera diferente a una debilidad del enfoque en cascada.
Modelo V. El modelo V, a menudo denominado verificación y validación, asocia cada fase de desarrollo con su correspondiente fase de prueba, representadas por los dos brazos de una V. Los requisitos se asocian con las pruebas de aceptación, el diseño de alto nivel con las pruebas del sistema, el diseño de bajo nivel con las pruebas de integración y la codificación con las pruebas unitarias. Su ventaja radica en que el diseño de las pruebas comienza junto con cada fase de desarrollo, en lugar de después de la codificación, lo que permite que la persona que escribe las pruebas de aceptación detecte los requisitos ambiguos meses antes de que se produzca un defecto. Su debilidad proviene del modelo en cascada: aún presupone que los requisitos son estables.
Modelo espiral. La espiral integra la iteración en torno a un análisis de riesgos explícito. Cada ciclo consta de cuatro actividades: determinar objetivos, identificar y resolver riesgos, desarrollar y probar, y planificar la siguiente iteración. Por lo tanto, las pruebas se concentran donde el riesgo es mayor, en lugar de distribuirse uniformemente. Es adecuada para programas grandes, costosos y de larga duración, como los sistemas centrales aeroespaciales o bancarios, donde el costo de un descubrimiento tardío es considerable. Para un proyecto web pequeño, el costo adicional de un análisis de riesgos formal en cada ciclo rara vez se justifica.
Ambos modelos se sitúan entre la disciplina en cascada y la capacidad de respuesta ágil. Donde la frecuencia de lanzamiento importa más que cualquiera de los dos, un DevOps El proceso integra las pruebas en la integración continua, de modo que cada confirmación se verifica automáticamente.
¿Qué metodología de software elegir?
Hay toneladas de metodologías disponibles para el desarrollo de software y sus correspondientes pruebas. Cada técnica y metodología de prueba está diseñada para un propósito específico y tiene sus ventajas y desventajas relativas.
La selección de una metodología particular depende de muchos factores, como la naturaleza del proyecto, los requisitos del cliente, el cronograma del proyecto, etc.
Desde una perspectiva de prueba, algunas metodologías presionan para que se prueben los datos en las primeras etapas del ciclo de vida del desarrollo, mientras que otras esperan hasta que esté listo un modelo funcional del sistema.
¿Cómo configurar metodologías de prueba de software?
Las metodologías de prueba de software no deben configurarse simplemente por probar el código del software. Se debe considerar el panorama general y el objetivo principal del proyecto debe satisfacerse con la metodología de prueba. Consulte esta lista de personas acreditadas proveedores de servicios de pruebas de software quienes pueden ayudarlo a establecer estrategias de prueba efectivas adaptadas a los objetivos de su proyecto.
Programación
Una programación realista es la clave para la implementación de una metodología de prueba exitosa y la programación debe satisfacer las necesidades de cada miembro del equipo.
Entregables definidos
Para mantener a todos los miembros del equipo en sintonía, se deben proporcionar resultados bien definidos. Los entregables deben contener contenido directo sin ninguna ambigüedad.
Enfoque de prueba
Una vez que se completa la programación y los entregables definidos están disponibles, el equipo de pruebas debería poder formular el enfoque de prueba correcto. Los documentos de definición y las reuniones de desarrolladores deben indicar al equipo cuál es el mejor enfoque de prueba que se puede utilizar para el proyecto.
Informes
Es muy difícil lograr informes transparentes, pero este paso determina la efectividad del enfoque de prueba utilizado en el proyecto.
