Pruebas de software: estrategia de prueba

El documento de estrategia de prueba es un documento de alto nivel que describe la técnica de prueba utilizada en el ciclo de vida de desarrollo de software y confirma los tipos o niveles de prueba que se realizarán en el producto. No se puede cambiar la estrategia de prueba una vez escrita y aceptada por el Gerente de Proyecto y el equipo de desarrollo.

Además, la estrategia de prueba proporciona los siguientes detalles, que se requieren al escribir el documento de prueba:

  • ¿Qué técnica hay que utilizar además de esta?
  • ¿Cuál de los módulos se examinará?
  • ¿Qué criterios se aplican para la entrada y salida?
  • ¿Qué tipo de prueba es necesaria?

Dicho de otro modo, es un documento que explica el proceso de evaluación del producto. Y los enfoques se pueden desarrollar utilizando los siguientes factores:

  • Si automatizar o no
  • Desde el punto de vista de un recurso.

Sobre la base de los documentos de diseño de desarrollo, podemos escribir la estrategia de prueba.

Los siguientes documentos se incluyen en el documento de diseño del desarrollo:

  • Documentos relacionados con el diseño del sistema: estos documentos se utilizarán principalmente para construir la estrategia de prueba.
  • Documentos de diseño: se utilizan para describir las características del software que se habilitarán en una versión futura.
  • Documentos relacionados con el diseño conceptual: Estos son los documentos que no utilizamos muy a menudo.

Aquí, discutiremos los siguientes puntos:

  1. Componentes de la estrategia de prueba.
  2. Estrategia de prueba vs Plan de prueba.
  3. Tipos de estrategias de prueba.
  4. Selección de estrategia de prueba.
  5. Detalles incluidos en el documento de estrategia de prueba.
  6. Conclusión.

Componentes de una estrategia de prueba

El esfuerzo de prueba, el dominio de prueba, las configuraciones de prueba y las herramientas de prueba utilizadas para verificar y validar un conjunto de funciones se describen en una estrategia de prueba. También incluye horarios, asignaciones de recursos e información sobre la utilización de los empleados. Estos datos son esenciales para que el equipo de prueba (Test) sea lo más estructurado y eficiente posible. Una estrategia de prueba se diferencia de un plan de prueba, que es un documento que recopila y organiza los casos de prueba por áreas funcionales y/o tipos de prueba en un formato que se puede presentar a otros equipos y/o clientes. Ambos son componentes críticos del proceso de Garantía de calidad, ya que ayudan a comunicar la amplitud del método de prueba y garantizan la cobertura de la prueba al tiempo que aumentan la eficiencia del esfuerzo de prueba.

Los siguientes son los componentes de la estrategia de prueba:

  1. Alcance y descripción general.
  2. Metodología de prueba.
  3. Especificaciones del entorno de prueba.
  4. Herramientas de prueba.
  5. Control de liberación.
  6. Análisis de riesgo.
  7. Revisión y Aprobaciones.
Componentes de la estrategia de prueba

Componentes del documento de estrategia de prueba

Vamos a discutir cada uno de estos en detalle.

1. Alcance y descripción general: Alcance y descripción general es la primera sección del documento de estrategia de prueba. La descripción general de cualquier producto incluye información sobre quién debe aprobar, revisar y usar el documento. Las actividades y fases de prueba que deben aprobarse también se describieron en el documento de estrategia de prueba.

  • Una descripción general del proyecto, así como información sobre quién debe utilizar esta página. 
  • Incluya información como quién evaluará y aprobará el documento. 
  • Defina las actividades y fases de prueba que se realizarán, así como los cronogramas que se seguirán en relación con los cronogramas generales del proyecto establecidos en el plan de prueba.

2. Metodología de prueba: la metodología de prueba es el siguiente módulo en el documento de estrategia de prueba y se utiliza para especificar los grados de prueba, los procedimientos de prueba, las funciones y los deberes de todos los miembros del equipo. El proceso de gestión de cambios, que incluye el envío de la solicitud de modificación, el patrón que se utilizará y la actividad para gestionar la solicitud, también se incluye en la estrategia de prueba. Sobre todo, si el documento del plan de prueba no está debidamente establecido, puede dar lugar a futuros errores o metedura de pata. Este módulo se utiliza para especificar la siguiente información:

  • Defina el proceso de prueba, el nivel de prueba, las funciones y los deberes de cada miembro del equipo.
  • Describa por qué se debe realizar cada tipo de prueba definido en el plan de prueba (por ejemplo, prueba de unidad, integración, sistema, regresión, instalación/desinstalación, usabilidad, carga, rendimiento y seguridad), así como detalles como cuándo comenzar , propietario de la prueba, responsabilidades, enfoque de prueba y detalles de la estrategia y la herramienta de automatización (si corresponde).

3. Especificaciones del entorno de prueba: la especificación del entorno de prueba es otra sección del documento de estrategia de prueba. La especificación de los requisitos de datos de prueba, como bien sabemos, es bastante importante. Como resultado, la especificación del entorno de prueba en el documento de estrategia de prueba incluye instrucciones claras sobre cómo producir datos de prueba. Este módulo contiene información sobre la cantidad de entornos y la configuración requerida. Las estrategias de respaldo y restauración son igualmente importantes.

  • La información sobre la cantidad de entornos y la configuración necesaria para cada entorno debe incluirse en la configuración del entorno de prueba. 
  • Por ejemplo, el equipo de prueba funcional puede tener un entorno de prueba y el equipo UAT puede tener otro. 
  • Defina la cantidad de usuarios admitidos en cada entorno, así como los roles de acceso de cada usuario y los requisitos de software y hardware, como el sistema operativo, la memoria RAM, el espacio libre en disco y la cantidad de sistemas. 
  • Es igualmente crucial definir las necesidades de datos de prueba. 
  • Brinde instrucciones específicas sobre cómo generar datos de prueba (ya sea generar datos o usar datos de producción enmascarando campos por privacidad). 
  • Defina una estrategia de copia de seguridad y restauración para los datos de prueba. 
  • Debido a circunstancias no controladas en el código, la base de datos del entorno de prueba puede tener problemas. 
  • El método de respaldo y restauración debe indicar quién realizará los respaldos, cuándo se deben realizar los respaldos, qué se debe incluir en los respaldos, cuándo se debe restaurar la base de datos, quién la restaurará y qué procedimientos de enmascaramiento de datos se deben implementar si se restaura la base de datos.

4. Herramientas de prueba: las herramientas de prueba son una parte importante del documento de estrategia de prueba, ya que contiene toda la información sobre las herramientas de gestión y automatización de prueba que se requieren para la ejecución de la prueba. Los enfoques y herramientas necesarios para la seguridad, el rendimiento y las pruebas de carga están dictados por los detalles de la herramienta comercial o de código abierto y la cantidad de usuarios que puede admitir.

  • Definir las herramientas para la gestión y automatización de pruebas que se utilizarán para ejecutar las pruebas. 
  • Describir el enfoque de prueba y las herramientas necesarias para las pruebas de rendimiento, carga y seguridad. 
  • Mencione si el producto es de código abierto o comercial, así como la cantidad de personas que puede albergar, y haga la planificación adecuada.

5. Control de versiones: el control de versiones es un componente crucial del documento de estrategia de prueba. Se utiliza para garantizar que las estrategias de ejecución de pruebas y gestión de versiones se establezcan de manera sistemática. Especifica la siguiente información:

  • Diferentes versiones de software en entornos de prueba y UAT pueden ocurrir a partir de ciclos de lanzamiento no planificados. 
  • Todos los ajustes en esa versión se probarán mediante la estrategia de gestión de versiones, que incluye un historial de versiones adecuado. 
  • Configure un proceso de gestión de compilación que responda preguntas como dónde debe estar disponible la nueva compilación, dónde debe implementarse, cuándo recibir la nueva compilación, dónde adquirir la compilación de producción, quién dará la señal de inicio para el lanzamiento de producción y pronto.

6. Análisis de riesgos: el análisis de riesgos es la siguiente sección del documento de estrategia de prueba. Todos los peligros potenciales asociados con el proyecto se describen en el documento de estrategia de prueba y pueden convertirse en un problema durante la ejecución de la prueba. Además, se establece una estrategia definida para la inclinación de estos riesgos con el fin de asegurar su adecuada ejecución. Si el equipo de desarrollo se enfrenta a estos peligros en tiempo real, establecemos un plan de contingencia. Haga una lista de todos los peligros potenciales. Proporcione un plan detallado para gestionar estos riesgos, así como un plan de respaldo en caso de que se materialicen los peligros.

7. Revisión y Aprobación: Revisión y Aprobación es la última sección del documento de estrategia de Pruebas.

Cuando todas las actividades de prueba están establecidas en el documento de estrategia de prueba, es evaluado por las personas involucradas, tales como:

  • Equipo de administración del sistema.
  • Equipo de gestión de proyectos.
  • Equipo de desarrollo.
  • Equipo de negocios.

Se debe seguir el comienzo del documento con la fecha correcta, el nombre del aprobador, el comentario y el resumen de las modificaciones revisadas.

También debe evaluarse y actualizarse periódicamente a medida que mejora el procedimiento de prueba.

Estrategia de prueba frente a plan de prueba

A continuación se muestran las diferencias entre la estrategia de prueba y el plan de prueba:

No. S. Estrategia de prueba Plan de prueba
1. Se desarrolla a partir de un conjunto de requisitos de software (SRS). Proviene de un documento de requisitos comerciales (BRS).
2. El líder de prueba o gerente es el encargado de prepararlo. El director del proyecto o el analista de negocios lo crea.
3. Los componentes del plan de prueba incluyen la identificación del plan de prueba, las funciones que se probarán, las técnicas de prueba, las tareas de prueba, los criterios de aprobación o falla de las funciones, los resultados de la prueba, las responsabilidades y el cronograma, entre otros. Los componentes de una estrategia de prueba incluyen objetivos y alcance, formatos de documentación, procesos de prueba, estructura de informes del equipo, estrategia de comunicación con el cliente, etc.
4. Una vez aprobados los requisitos, se escribe el plan de prueba. La estrategia de prueba viene primero, seguida por el plan de prueba.
5. El plan de prueba debe ser simple y directo. El enfoque de prueba sirve como una guía general para el proyecto en cuestión.

Tipos de estrategias de prueba

Los siguientes son los diferentes tipos de estrategias de prueba:

  1. Estrategia analítica: por ejemplo, las pruebas basadas en riesgos y las pruebas basadas en requisitos son dos tipos de pruebas. Después de examinar la premisa de prueba, como los riesgos o los requisitos, el equipo de prueba establece las circunstancias de prueba que deben cubrirse. En el caso de pruebas basadas en requisitos, los requisitos se examinan para determinar las circunstancias de la prueba. Luego se crean, implementan y ejecutan pruebas para garantizar que se cumplan los requisitos. Incluso se realiza un seguimiento de los hallazgos en términos de requisitos, como aquellos que se probaron y aprobaron, los que se probaron pero fallaron, los que no se probaron por completo, etc.
  2. Estrategia basada en modelos: el equipo de pruebas selecciona una circunstancia real o anticipada y construye un modelo para ella, teniendo en cuenta las entradas, las salidas, los procesos y el posible comportamiento. Los modelos también se crean en función del software, la tecnología, las velocidades de datos, la infraestructura y otros factores existentes. Veamos un caso en el que está probando una aplicación móvil. Se pueden construir modelos para simular el tráfico saliente y receptor en una red móvil, el número de usuarios activos/inactivos, el crecimiento previsto y otros factores para realizar pruebas de rendimiento.
  3. Estrategia metódica: en este caso, los equipos de prueba se adhieren a un estándar de calidad (como ISO25000), listas de verificación o simplemente un conjunto de circunstancias de prueba. Los tipos específicos de pruebas (como la seguridad) y los dominios de aplicación pueden tener listas de verificación estándar. Por ejemplo, al realizar pruebas de mantenimiento, basta con una lista de verificación que describa las funciones relevantes, sus propiedades, etc.
  4. Estrategia de cumplimiento de estándares o procesos: este método está bien ejemplificado por los sistemas médicos que se adhieren a las pautas de la Administración de Drogas y Alimentos de los EE. UU. (FDA). Los evaluadores siguen los métodos o recomendaciones establecidos por el comité de estándares o un panel de especialistas empresariales para determinar las condiciones de prueba, identificar casos de prueba y reunir el equipo de prueba. En el caso de un programa Agile, los evaluadores crearán una estrategia de prueba completa para cada historia de usuario, comenzando con el establecimiento de criterios de prueba, el desarrollo de casos de prueba, la realización de pruebas, el estado de informes, etc.
  5. Estrategia reactiva: solo cuando se libera el programa real se diseñan e implementan las pruebas. Como resultado, las pruebas se basan en fallas descubiertas en el sistema real. Considere el siguiente escenario: está realizando pruebas exploratorias. Los estatutos de prueba se crean en función de las características y funcionalidades que ya existen. Los resultados de las pruebas realizadas por los probadores se utilizan para actualizar estos estatutos de prueba. Las iniciativas de desarrollo ágil también pueden beneficiarse de las pruebas exploratorias.
  6. Estrategia consultiva: de la misma manera que las pruebas dirigidas por el usuario utilizan los aportes de las partes interesadas clave para establecer el alcance de las condiciones de prueba, esta técnica de prueba también lo hace. Consideremos un escenario en el que se evalúa la compatibilidad del navegador de cualquier aplicación basada en web. En esta sección, el propietario de la aplicación proporcionaría una lista de navegadores y sus versiones en orden de preferencia. También pueden incluir una lista de tipos de conexión, sistemas operativos, software antimalware y otros requisitos para la prueba del programa. Dependiendo de la prioridad de los elementos en las listas proporcionadas, los evaluadores pueden usar varias estrategias, como la división por pares o la equivalencia.
  7. Estrategia de aversión a la regresión: en este caso, los procedimientos de prueba tienen como objetivo reducir el riesgo de regresión para los aspectos funcionales y no funcionales del producto. Utilizando la aplicación web como ejemplo, si es necesario probar el programa para detectar problemas de regresión, el equipo de pruebas puede diseñar la automatización de pruebas para casos de uso comunes e inusuales. También pueden emplear herramientas de automatización basadas en GUI para realizar pruebas cada vez que se actualiza la aplicación. Cualquiera de las estrategias descritas anteriormente no tiene que usarse para ningún trabajo de prueba. Se pueden integrar dos o más estrategias dependiendo de las necesidades del producto y de la organización.

Selección de estrategia de prueba

Los siguientes factores pueden influir en la selección del enfoque de prueba:

  • La estrategia de prueba elegida está determinada por la naturaleza y el tamaño de la organización.
  • Uno puede elegir una estrategia de prueba basada en las necesidades del proyecto; por ejemplo, las aplicaciones de seguridad y protección requieren una técnica más rigurosa.
  • La estrategia de prueba se puede elegir en función del modelo de desarrollo del producto.
  • ¿Es esta una estrategia a corto o largo plazo?
  • Tipo y tamaño de la organización.
  • Requisitos del proyecto: las aplicaciones de seguridad y protección requieren una estrategia bien pensada.
  • Modelo de desarrollo de productos.

Detalles incluidos en el documento de estrategia de prueba

El documento de estrategia de prueba incluye los siguientes detalles importantes:

  • Resumen y alcance.
  • Software y productos de trabajo de prueba que se pueden reutilizar.
  • Detalles sobre los distintos niveles de prueba, sus relaciones y la técnica para integrar los distintos niveles de prueba.
  • Técnicas de ensayo del entorno.
  • Nivel de automatización de pruebas.
  • Varias herramientas de prueba.
  • Evaluación de riesgos.
  • Para cada nivel de la prueba Condiciones tanto de entrada como de salida.
  • Informes sobre los resultados de las pruebas.
  • El grado de independencia de cada prueba.
  • Durante las pruebas, se analizarán las métricas y las medidas.
  • Pruebas de regresión y confirmación.
  • Atender los defectos descubiertos.
  • Configuración y gestión de herramientas e infraestructura de prueba.
  • Funciones y responsabilidades de los miembros del equipo de pruebas.

Conclusión

El documento de estrategia de prueba presenta una visión brillante de lo que hará el equipo de prueba para todo el proyecto. Debido a que el documento de estrategia de prueba impulsará a todo el equipo, solo deben prepararse personas con amplia experiencia en el área del producto. Debido a que es un documento estático, no se puede editar ni cambiar durante el ciclo de vida del proyecto. El documento de estrategia de prueba se puede enviar al equipo de prueba completo antes de que comiencen las operaciones de prueba. Si el documento de estrategia de prueba se crea correctamente, dará como resultado el desarrollo de un sistema de alta calidad y la expansión de todo el proceso de prueba.

Publicación traducida automáticamente

Artículo escrito por akashmomale19 y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *