Sin duda, puede prescindir de una estrategia de prueba si tiene un número infinito de empleados calificados, tiempo y dinero. En una palabra, la capacidad de cortar una versión a lo largo de los años. En tales condiciones ideales hipotéticas, no se necesita ninguna estrategia, porque puede probar su producto de todas las formas existentes durante el tiempo que desee, aplicando las técnicas en cualquier orden, por varios círculos, y tarde o temprano de alguna manera llegará a la calidad de producción lista.

En realidad, el proyecto siempre agota el plazo, la capacidad / habilidades de trabajo del equipo no son elásticas y los requisitos del producto evolucionan constantemente, y aquí no se puede prescindir de un buen plan. Por lo tanto, una estrategia de prueba viene al rescate.

En este artículo, ofreceremos preguntas que deben discutirse para elaborar una estrategia de prueba, y mostraremos con ejemplos cómo se toman las decisiones sobre las herramientas de prueba en un caso particular.

0. Vamos a resolverlo en la orilla

¿Por qué necesitamos una estrategia de prueba?

• Organizar el proceso en condiciones de recursos limitados. Por lo tanto, para empezar, sería bueno darse cuenta de qué recursos tenemos.
• Para que todos los participantes del proyecto comprendan el papel de las pruebas, lo que puede dar, qué beneficios obtendremos de esto. Para que todos tengan las mismas expectativas y comprensión de lo que está sucediendo en el campo del control de calidad. Y también para identificar posibles problemas que inevitablemente se harán evidentes en el proceso de discusión.

¿Quién inventa la estrategia?

En primer lugar, por supuesto, control de calidad y necesariamente un gerente de proyecto.

Por lo tanto, tome de la mano al administrador del proyecto o al administrador del probador, sirva café, tome papel, marcadores, computadoras portátiles y ... ¡vamos!

1. ¿Qué tipos de pruebas usaremos en el proyecto y por qué?

Al principio, ofrecemos recordar todos los tipos de pruebas existentes y decidir sobre cada uno: ¿lo usaremos y por qué? Veamos algunos ejemplos de cómo puede decidir sobre la necesidad de un tipo específico de prueba.

Instalación de la versión de prueba

En cualquier caso, incluso si la aplicación es completamente nueva y se está instalando (implementando) por primera vez, debe verificar cómo despegó: si se inicia, si es posible comenzar a trabajar con ella. Ya sea una aplicación móvil, computadora de escritorio o web.

Para aplicaciones web, es útil analizar cómo verificamos que los datos después de la actualización no se pierdan. Qué tipo de comportamiento esperamos de una sesión activa.

Para las aplicaciones móviles y de escritorio, debe pensar en una forma de entregar la nueva distribución al usuario y el proceso de actualización, que el usuario inicia.

Para todos los proyectos, es útil discutir cosas como calentar el sistema: instalar directorios, configurar usuarios y otros datos que el usuario necesita para comenzar con el sistema.

Pruebas de rendimiento

Tales factores influirán en la decisión: cuántos usuarios trabajarán en el sistema, cuántos datos se procesarán.

Dado	Solución
Sabemos que 10 personas usarán el producto. Y sabemos que entregarán tablas de varios miles de registros.	Tiene sentido planificar pruebas de volumen con grandes cantidades de datos.
Sabemos que en el proceso de uso del producto, los usuarios subirán muchos archivos multimedia al servidor del cliente.	Debe averiguar para qué tipo de carga está diseñado este servidor y tener en cuenta estos datos.
La aplicación es utilizada por varias personas a la semana, la cantidad de datos es mínima.	No se requieren pruebas de rendimiento.

Prueba de regresión

Una verificación completa de todo el sistema siempre lleva mucho tiempo. Por lo tanto, para tomar una decisión, es necesario evaluar la idoneidad: cuánto tiempo se requiere para una regresión completa y los riesgos que pueden ocurrir si no la llevamos a cabo.

Dado	Solución
Lanzamos la primera versión de un producto o módulo de programa.	No se requieren pruebas de regresión.
El proyecto es muy grande y una regresión completa antes del lanzamiento de nuevas características lleva un tiempo comparable al período de desarrollo. La tasa de suministro requerida no lo permite.	Decidimos que no realizamos pruebas de regresión, sino que prestamos más atención a otros tipos de pruebas y monitoreo.
La interacción entre microservicios está cubierta por pruebas de contrato.	Una regresión completa no es práctica. En el marco de las pruebas manuales, realizamos una regresión de la funcionalidad por recomendación del desarrollador.

Pruebas de integración

Para determinar la necesidad de pruebas de integración, es útil enumerar todos los sistemas externos con los que interactúa el producto e indicar qué datos recibimos y transmitimos.

Dado	Solución
Los datos de ventas del portal se transfieren al sistema analítico.	Es importante no solo verificar que las ventas se hayan ido, en el formato correcto, sino también que vinieron en el formato correcto: no se perdió nada en el camino.

Pruebas de localización

Es importante responder preguntas sobre el proyecto:

• qué idiomas deben ser compatibles
• ¿Proporcionamos la conexión de ubicaciones adicionales durante la operación de la solución?
• En qué países trabajarán nuestros usuarios,
• habrá ventas y en qué monedas
• ¿Necesitas trabajar con zonas horarias?

Dado	Solución
El sistema tiene 2 idiomas: ruso e inglés.	Tiene sentido discutir cómo entenderemos la interfaz en qué idioma mostrarle al usuario.
El cliente solicita que la aplicación sea multilingüe.	Vale la pena contestarse las preguntas de cómo verificaremos los textos, de dónde obtendremos los textos en árabe, cómo se adaptará la pantalla al texto que se escribe de derecha a izquierda.

Cross-browser y multiplataforma

No podemos verificar el funcionamiento correcto de la aplicación móvil en todos los dispositivos en general. En el caso de una aplicación web, la pregunta surge de inmediato: ¿admitiremos IE9? Antes de ingresar este tipo de prueba en la estrategia, analizamos (si la solución ya está funcionando) o asumimos (si aún no funciona) para qué la usarán.

Dado	Solución
Los usuarios de aplicaciones móviles son empleados en todo el país.	Observamos las estadísticas existentes sobre el uso de las plataformas de nuestra aplicación y tomamos una decisión sobre cuál de ellas probaremos.
Nuestra aplicación tiene usuarios corporativos en máquinas estacionarias.	Lo más probable es que podamos recomendar el uso de un solo navegador. Y, por lo tanto, reduce el tiempo de prueba y soporte para la compatibilidad entre navegadores.

Del mismo modo, debe analizar todos los demás tipos de pruebas:

• Funcional (conducido o no),
• Aceptación (quién lo conduce y cómo)
• UX / UI (cuáles son los criterios objetivos para una buena interfaz)
• Modular y unitario (quién escribe pruebas de contrato, quién escribe pruebas unitarias y si las escribimos)
• Pruebas de seguridad (quién garantiza la seguridad de los datos y qué tan resistente es el sistema a la piratería),
• Falla y recuperación (cómo se comportará el sistema en una emergencia)

y otros

2. Prioridades en las pruebas

La fuerza mayor ocurre en todos los proyectos, por lo que es útil tener una hoja de trucos con un plan bien pensado, en lugar de agarrar botones al azar.



En modo normal, las prioridades significativas también son importantes. Por ejemplo, el desarrollo de las pruebas automáticas debe planificarse teniendo en cuenta las prioridades: en primer lugar, los escenarios más críticos son automatizados (prueba de humo).

Dado	Solución
Nuestro programa se utiliza en los aeropuertos para vender servicios a los pasajeros al abordar un avión. Y si en este momento ocurre algún tipo de error, entonces no tendremos tiempo para una solución rápida. Por lo tanto, no debe haber errores!	En primer lugar, verificamos el escenario de uso en el aeropuerto.

3. Entorno para el trabajo.

Es necesario pensar y coordinar con el equipo qué entornos se requieren para el trabajo y quién los usará. Como regla, 2-3 entornos y ventas son suficientes.

Dado	Solución
En el proyecto CD / CI, se escribieron pruebas de humo para la prueba inicial de funcionalidad.	Necesitamos un entorno para el ensamblaje primario de código en una rama, la ejecución de pruebas de humo, donde los sistemas externos están cerrados por trozos. También necesita un entorno para pruebas manuales y de integración con servicios al cliente (QA).
Las sesiones de prueba beta se llevan a cabo regularmente.	Necesitamos un entorno que sea visible "afuera", más estable que el entorno QA.

4. Trabajo del probador en el proyecto.

Tiene sentido discutir por adelantado todas las actividades que esperamos del probador en el proyecto, porque no son necesariamente las mismas en todos los proyectos. Puede ser una sorpresa para alguien en el equipo que el probador esté haciendo algo o no haciendo algo.

Este elemento ayudará a los gerentes a comprender qué grado de competencia se requiere del probador y qué carga de tiempo se espera. Para los proyectos existentes, también es importante indicar que nosotros (QA) somos capaces de que el gerente comprenda lo que significa.

Por ejemplo, podría ser:

• evaluación de objetivos de sprint para completar y consistencia,
• evaluación de costos laborales para pruebas,
• preparación de listas de verificación para pruebas (o casos de prueba),
• revisión de script de autotest
• escribir autotests funcionales,
• prueba manual directa,
• despliegue de cambios en el medio ambiente,
• actualizar estrategias de prueba, etc.

5. Documentación de prueba sobre el proyecto.

Es necesario llegar a un acuerdo sobre la costa, y posiblemente revisar más y regularmente el formato de la documentación de la prueba:

• qué documentación de prueba realizaremos en el proyecto,
• vamos a escribir casos de prueba
• hacer listas de verificación
• y con qué frecuencia actualizar esta documentación.

Dado	Solución
Ya se han escrito unos 300 casos de prueba para aproximadamente un tercio de la funcionalidad del sistema. No solo deben revisarse periódicamente, sino también actualizarse periódicamente.	En condiciones de recursos limitados, decidimos no trabajar con casos de prueba, sino restringirnos a las listas de verificación para cada tarea específica. Y como resultado, ahorramos tiempo en la documentación de respaldo sin perder la calidad de las pruebas.

6. Cómo se generan los casos de prueba

Las condiciones de operación y los escenarios dependen de la solución específica, así que asegúrese de discutir:

• qué técnicas de diseño de prueba tiene sentido usar. Como parte de este párrafo, es útil hacer una lista de objetos con los que trabaja la aplicación y sus clases de equivalencia.
• qué heurística y experiencia de vida banal ayudan a crear scripts de prueba para un proyecto específico. Para aplicaciones móviles, es conveniente utilizar heurística estándar, por ejemplo, "DIVERTIRÉ LA DIVERSIÓN".

Dado	Solución
En el proyecto de seguro, el usuario (agente) debe inspeccionar la máquina, durante la cual es necesario tomar fotografías y subirlas al servidor. El sentido común dicta que apenas hay wifi en los garajes. Y a veces, no hay conexión móvil.	Por lo tanto, debe verificar la aplicación no solo cuando trabaja con 3G, sino también en ausencia de comunicación como tal.
Cualquier acción del usuario en la aplicación móvil de la aerolínea es parte de un escenario. Por ejemplo, no puede emitir un boleto sin crear primero una reserva.	Por lo tanto, es lógico utilizar la técnica del "caso de uso".

7. El procedimiento para trabajar con el rastreador

En diferentes rastreadores, las posibilidades y tipos de tareas difieren. En función de las capacidades del rastreador, le recomendamos que acuerde quién y por qué principio determina la prioridad de las tareas, en qué tipo de tareas organizar los errores y las tareas.

Habla los puntos clave con el equipo:

• ¿Cómo distinguiremos entre los errores encontrados por nosotros y los errores encontrados por los clientes (y si necesitamos distinguirlos)?
• Cómo hacer mejoras
• ¿Es necesario distinguir las mejoras que inventamos de las que solicitó el cliente? Como?
• ¿Qué estado debería cometer un error si no vuelve a suceder,
• Qué estado se considera final.

Dado	Solución
El probador crea un error. El desarrollador no puede reproducirlo, lo traduce al estado rechazado.	El probador vuelve a comprobar la tarea y establece el estado en Cerrado (final), si el error realmente desaparece, o refina la descripción y vuelve a Nuevo.
El cliente establece la tarea para su revisión. El desarrollador comprende que no tiene suficientes datos para implementar.	El desarrollador coloca la tarea en el estado Comentarios.

(Escribimos más sobre formas de describir errores y la historia de usuario en este artículo ).

8. Criterios para comenzar y finalizar las pruebas

Si el probador realiza alguna tarea en cualquier momento, esto no es orden, sino caos. Porque la tarea puede no estar lista. O listo, pero no gratis. O listo, desplegado, pero depende de otras tareas que aún no están listas. Como resultado, el probador pasa tiempo y nervios buscando y reparando errores, pero de hecho solo tiene que esperar. Por lo tanto, estamos de acuerdo en qué punto comienza y termina el área de responsabilidad de control de calidad sobre la tarea.

En las primeras etapas del desarrollo del proyecto, la preparación de la tarea / versión se determina a simple vista.
Con el crecimiento de la autoconciencia, entendemos que necesitamos criterios claros de que la tarea / versión esté lista. Para que esta decisión sea transparente para todos y no "el probador siente el botín de que todo es normal". Por ejemplo, en el contexto de un CD sintonizado, creemos que la tarea está lista para probarse tan pronto como se implemente en el entorno de control de calidad y tenga el estado Resuelto.

Dado	Solución
Se ha establecido un proceso en el proyecto en el que se compila una lista de verificación para las pruebas para cada revisión.	Consideramos la tarea verificada si hemos pasado todos los puntos en la lista de verificación.
El proyecto está trabajando en sprints.	Sprint se considera listo si todas las mejoras están en estado Cerrado y no hay errores con la prioridad Normal y superior.
El proyecto compiló una lista de funcionalidades por prioridad.	Creemos que la versión está lista para su lanzamiento si la funcionalidad de los primeros puntos de la lista funciona correctamente.
El proyecto ha escrito casos de prueba y llevado a cabo pruebas de regresión antes del lanzamiento.	Una versión se considera lista para su lanzamiento si, según los resultados de las pruebas de regresión, no se encontraron errores con prioridad Normal o superior (o el porcentaje de escenarios fallidos no fue superior a 5).

9. Herramientas para el trabajo.

La sección es útil para establecer las tareas responsables (para el administrador y el gerente) ya en la etapa de planificación de la prueba y para obtener todas las herramientas necesarias al comienzo del trabajo.

Vale la pena discutir estos temas:

• ¿Qué herramientas necesitamos para realizar la documentación de la prueba?
• Qué herramientas pueden preparar los datos de prueba,
• Qué herramientas se necesitan para la automatización.

Dado	Solución
Para describir la funcionalidad implementada, decidimos usar mapas mentales.	Los chicos del equipo trabajan en diferentes plataformas, por lo que debe elegir un formato de archivo de mapa mental con el que pueda trabajar en Windows, Linux y Mac.
Acordamos que necesitamos automatización en el proyecto.	Por lo tanto, necesitamos herramientas que nos permitan preparar datos de prueba (por ejemplo, para rodar scripts en la base de datos), que nos permitan ejecutar dentro de la tubería (por ejemplo, newman) y que nos permitan crear apéndices (por ejemplo, WireMock).

10. Evaluación de la calidad del proyecto y herramientas de monitoreo.

En esta sección, proponemos acordar qué KPI son para evaluar el estado de la aplicación (además del cálculo obvio de la cobertura de la prueba). Este indicador debe ser medible y alcanzable. En particular, comprenda y responda las siguientes preguntas:

• Cómo rastrearemos los errores en el producto
• ¿Cómo recopilaremos los comentarios de los usuarios?
• ¿Cómo recopilaremos estadísticas sobre el uso de nuestras funciones?

Dado	Solución
Después del lanzamiento de una nueva característica del sistema, se configura el monitoreo de uso (por ejemplo, el número de ventas de servicios).	La disminución es un detonante para la investigación. Quizás la función no funciona como se esperaba o no implementamos parte del script.
Hemos configurado el programa para monitorear la velocidad de realizar operaciones básicas.	El criterio para la calidad del trabajo será que con la afluencia de usuarios, la velocidad de ejecución no disminuye.

Conclusión

No existe una estrategia de prueba única y universal que sea adecuada para todos. Está diseñado individualmente para cada proyecto.

• Es importante comprender que la estrategia no debe ser un fin en sí misma, es solo una herramienta que nos permite alcanzar nuestros objetivos.
• Es bastante normal que no siempre sea posible responder de inmediato a todas las preguntas planteadas. Esta es una ocasión para volver a hablar con el cliente o los usuarios del producto.
• El proyecto está creciendo, y si ayer era demasiado temprano para preocuparse por la productividad, mañana probablemente sea el momento. Por lo tanto, después de elaborar una estrategia, es importante actualizarla y reponerla regularmente y aportar cambios al equipo.
• Después de escribir una estrategia, generalmente queda claro dónde están las fallas en las pruebas y qué debe hacerse. Esta es una ocasión para establecer objetivos, observar la dinámica y ... actualizar la estrategia después de un tiempo.