Conozca a los autores del artículo de julio para el "Calendario del probador " Andrei Marchenko y Marina Tretyakova, probadores y analistas de Kontur. Este mes, los chicos hablarán sobre modelos de flujo de trabajo para probar análisis y cómo comenzaron a probar análisis antes de la etapa de desarrollo. La experiencia de los chicos será útil para los gerentes, evaluadores y analistas de equipos de productos medianos que no viven dentro de una startup y para quienes la calidad es más importante que la velocidad .

Modelos de flujo de trabajo de pruebas analíticas

Modelo 1

El probador trabaja con análisis después de que se le dio la tarea finalizada. Valida la tarea leyendo análisis como documentación de lo que hizo el desarrollador. Todo está equivocado, independientemente del nivel de profesionalismo. Los defectos pueden estar en análisis o en código de desarrollador.

Contras:

• los defectos en el análisis no se detectarán antes de la etapa de prueba,
• existe el riesgo de que la tarea de la prueba regrese a análisis para su revisión. Como resultado, la tarea TimeToMarket aumenta significativamente.

Los errores de análisis identificados durante las pruebas son caros o muy caros.

Pros:

• el tiempo del evaluador se reduce para tareas donde no se requiere un analista (infraestructura, refactorización).

Modelo 2

El probador está conectado a la tarea incluso antes de que se transfiriera al desarrollo. Él mira prototipos en una tarea o simplemente lee la documentación. El probador le hace al analista todas las preguntas sobre la tarea. El analista corrige rápidamente los comentarios. El probador realiza pruebas de aceptación.

Contras:

• el probador tendrá que estudiar un campo adyacente (diseño de análisis y conocimientos tradicionales),
• Cambiando a este modelo, el probador primero tendrá que pasar más tiempo probando, porque el proceso "llegó la tarea terminada - leo análisis - estoy probando" se extiende a "llega la descripción de la tarea futura - leo análisis - estoy analizando análisis - llegó la tarea terminada - estoy probando".

Pros:

• la probabilidad de encontrar errores analíticos después de que la tarea se transfiere al desarrollo se reduce
• el probador ya está en el contexto de la tarea, cuando llega a él para la prueba, por lo tanto, lo verifica más rápido
• las pruebas analíticas amplían perfectamente los horizontes, brindando al especialista la oportunidad de una futura transición a la analítica,
• el desarrollador mejora la calidad de su código y el producto en su conjunto, porque antes de pasar su solución para la prueba, pasa las pruebas de aceptación.

Si el equipo de desarrollo no tiene una revisión del trabajo de los analistas, las pruebas analíticas mejoran la calidad del producto y reducen el riesgo de transferir tareas al desarrollo con errores en los ToR.

Cuando recomendamos el segundo modelo a los evaluadores que trabajan en el primer modelo, a menudo escuchamos:

• "Tenemos en línea y tenemos suficientes tareas actuales para tomar más".
• "Habla con el gerente".

Rediseñar el proceso de desarrollo es una tarea administrativa seria.

Implemente pruebas analíticas antes del desarrollo

Durante casi un año, como en el proyecto Kontur , el estándar en el proceso de desarrollo es una etapa obligatoria de "prueba analítica". El equipo no llegó a esto de inmediato. El ímpetu fue el aumento en el número de retornos de tareas de las pruebas a la etapa de análisis y un mayor refinamiento.

Fue especialmente doloroso para tareas grandes con nueva funcionalidad. Las tareas de front-end transferidas a la fase de prueba fueron crudas, a menudo se rompieron en los escenarios más simples, implementadas de manera diferente en vista de la "doble" de definiciones y términos en análisis.

El proceso de prueba de análisis no aparece con el clic de un dedo ni con ningún tipo de magia. Este es un trabajo minucioso, pero se puede dividir en etapas.

Etapa 0. Vende al equipo la idea de probar análisis

Puede imaginar fácilmente una situación en la que de repente recibe comentarios de su trabajo con comentarios, sugerencias y correcciones. El primer pensamiento de una persona normal sería: “¿Por qué decidiste ponerme a prueba? ¿No confían en mí? ¿Monitorean la calidad de mi trabajo? En esta etapa, es muy importante que el analista no tenga la sensación de que se le está verificando la calidad y, en caso de una prueba fallida, serán despedidos.

Se pueden eliminar una serie de preguntas si la información se presenta en la clave: "esto nos dará la oportunidad de aprender sobre nuevas funcionalidades antes, acelerar la fase de prueba y evitar la introducción de incluso pequeños defectos en el código".

Cuando se completa la etapa 0, puede seguir adelante.

Etapa 1. Implementación de pruebas analíticas en el proceso de desarrollo.

Después de convencer al equipo, comenzamos a introducir pruebas analíticas en el flujo de trabajo diario. Si inicialmente el flujo de trabajo se veía así:

Que después de la implementación:

Si su equipo tiene varios analistas que se revisan entre sí antes de asignar la tarea al desarrollo, entonces procederemos a probar un texto mejor. Queremos decir que la revisión analítica no lo está probando, sino solo una parte.

Etapa 2. Analítica de prueba

Hay tareas cuando los prototipos reemplazan la versión de texto de análisis.

En este caso, el prototipo también se verifica como texto. Si los prototipos complementan el análisis, es útil mirar los diseños de diseño de la funcionalidad futura antes de leer la documentación. Esta es su única oportunidad de ver la tarea como un usuario que no ha leído los TOR y no sabe cómo funciona todo y debería funcionar.

Lo que se puede verificar en análisis:

1. La solución propuesta cumple con los objetivos de la tarea.

Por ejemplo, si el objetivo de la tarea es recopilar comentarios de los usuarios, la solución debe incluir el registro y el almacenamiento de las respuestas de los usuarios.

2. Singularidad de la interpretación.

Por ejemplo, la frase "mostrar información para el día actual" se puede interpretar de manera diferente. Puede comprender cómo "mostrar información para el día seleccionado en la configuración" o como "mostrar información para el día igual hoy".

3. Viabilidad de la decisión.

La viabilidad es la capacidad de implementar los requisitos escritos en análisis bajo las limitaciones bien conocidas del entorno de desarrollo, lenguaje de programación y complejidad algorítmica. Los buenos analistas pueden tener en cuenta el algoritmo mediante el cual pueden resolver el problema que escribieron. No es un hecho que los desarrolladores lo hagan de acuerdo con este algoritmo (tienen más conocimiento, encontrarán formas de hacer que el algoritmo sea óptimo, etc.), pero su sola presencia indica la viabilidad de la tarea.

4. Estabilidad.

No está claro cómo verificar que se cumple la condición "mejorar los resultados de búsqueda". Pero si reescribimos la condición en "los resultados de la búsqueda deben mostrarse al usuario dentro de 1 segundo después de presionar el control" Buscar ", está claro.

5. La disponibilidad de escenarios alternativos.

En la frase "Si se indica el número y la fecha, imprimimos el número y la fecha. Si no se especifica la fecha, imprimimos solo el número "no hay suficientes scripts:

• no hay número, pero hay una fecha,
• sin datos

6. Manejo de excepciones.

En la redacción "Puede descargar un documento solo en formato Excel" no está claro qué debería suceder si cargamos archivos de otros formatos, y qué error veremos al descargarlos.

Artefactos al probar análisis

Qué artefactos pueden quedar después de probar el análisis:

• casos de prueba compilados
• listas de verificación para desarrolladores.

Lista de verificación para el desarrollador: las comprobaciones necesarias, integrales y básicas de los escenarios principales que deberían funcionar para ser probados. También es una herramienta para mejorar la calidad del código. Antes de enviar la tarea para la prueba, el desarrollador pasa la lista de verificación, identificando rápidamente los errores por su cuenta.

Se debe persuadir al desarrollador para que revise la lista de verificación del probador, eliminando las preocupaciones internas del desarrollador "me prueban", enfocándose en "acelerar el proceso, acelerar las pruebas, mejorar la calidad". Como resultado, nuestro desarrollador revisa estas listas de verificación y se alegra de que no haya sido el probador quien encontró los errores, sino él mismo ("nadie sabrá lo que arruiné en un escenario de mierda").

Cual es el resultado

A primera vista, parece que introducir una nueva etapa en el proceso de desarrollo solo aumentará TimeToMarket, pero esto es una ilusión. Al principio, por supuesto, el proceso de prueba de análisis será nuevo y no probado, y el probador pasará más tiempo en él. En el futuro, ganando experiencia, podrá conducirlo más rápido. Y los resultados obtenidos en la etapa de análisis analítico reducirán el tiempo en la etapa de prueba directa y reducirán al mínimo la cantidad de retornos.

Este proceso de prueba analítica se ha implementado en varios equipos de Contour. Los equipos de desarrollo recibieron una serie de ventajas innegables:

• Ahorro de tiempo en la etapa de prueba: no hay costo para el diseño de la prueba y el análisis de la prueba, ya que todo ya se ha hecho de antemano
• acelerar la retroalimentación al desarrollador a través de la lista de verificación, antes de encontrar errores críticos,
• todas las partes interesadas pueden verificar previamente las listas de verificación y agregar algunas verificaciones (en la etapa de prueba, esta acción es "más costosa").

Creemos que podrá obtener estas ventajas al implementar la fase de prueba analítica en su proyecto.

Lista de artículos del calendario:
Prueba un enfoque diferente
Prueba de par razonable
Comentarios: cómo sucede
Optimizar pruebas
Leer un libro
Pruebas analíticas
El probador debe atrapar el error, leer a Caner y organizar el movimiento.
Servicio de carga
Métricas del servicio de control de calidad
Prueba de seguridad
Conozca a su cliente
Tomar registro