He identificado 7 etapas clave en la evolución de las pruebas para ilustrar cómo están cambiando los enfoques para el aseguramiento de la calidad en las empresas. Durante el curso de la lectura del artículo, podrá rastrear la evolución de las pruebas, determinar su etapa actual y averiguar qué debe hacerse para mejorar el proceso y la calidad de las pruebas.
El artículo fue escrito originalmente para la revista CIS, pero creo que también será interesante para los usuarios de Habr.
Entonces, las etapas.
- No hay probador. Sus funciones son realizadas por el desarrollador o gerente.
- Aparecen los probadores, pero solo prueban proyectos en la etapa de finalización.
- Los probadores verifican todas las tareas de los desarrolladores para ver si el resultado cumple con la declaración original del problema.
- Los probadores participan en el diseño de pruebas.
- Se está introduciendo un sistema de gestión de pruebas.
- Prueba de automatización aparece.
- La jerarquía se vuelve más compleja, aparecen nuevos roles en el equipo de prueba.
Ahora sobre cada etapa con más detalle.
Etapa 1. La prueba es realizada por el desarrollador y / o gerente
"Lo comprobó usted mismo": el enfoque más simple e "instintivo" para las pruebas. Una cosa común en pequeñas empresas. Cuando no es posible contratar a un evaluador profesional o no se comprende la necesidad de la prueba, este frente de trabajo se realiza por sí solo. Probarse es el enfoque más irracional y problemático. Por eso
- El desarrollador mismo prueba solo aquellos escenarios que implementó con los datos que utilizó en el proceso de desarrollo. Con tales pruebas "en el vacío", se omiten escenarios alternativos. Como resultado, la vida realiza ajustes y, por regla general, se producen errores a los usuarios finales.
- Si el gerente está probando, entonces lo hace como una carga adicional, sin poseer experiencia y sin tener el tiempo y la fuerza moral para participar de cerca en las pruebas. Por lo tanto, puede encontrar errores graves, pero se pasan por alto muchos matices.
- La actitud subjetiva hacia el proyecto, el deseo de aprobarlo rápidamente lleva a la tentación de cerrar los ojos a una serie de problemas aparentemente "insignificantes".
Un caso extremo cuando la empresa no realiza pruebas en absoluto, y un informe de error trae ... al cliente. Recibió el lanzamiento, todo ya está en el campo de batalla, informó el desarrollador sobre el lanzamiento. El cliente abre el proyecto y ve algún error común en la base de datos o error del servidor. Luego más y más errores. El cliente se convierte en un probador por su propio dinero.
Etapa 2. El probador verifica el proyecto al final
Verificar todo el proyecto en la etapa de prelanzamiento es un método clásico cuando se trabaja en el modelo Waterfall. El proyecto se divide en etapas globales (a veces todo el proyecto es una etapa). En cada etapa, primero se hace el software, y solo luego se prueba. Las pruebas ya están ahí, y eso es bueno. Pero también hay problemas, y muy específicos.
Primero, cuando probamos al final, los errores graves a nivel de arquitectura se encontrarán demasiado tarde. Será necesario rehacer una gran parte, o incluso todo el proyecto. Esto no es beneficioso para nadie.
En segundo lugar, en ausencia de documentación, solo podemos realizar pruebas de superficie utilizando el método de búsqueda gratuito. Esto inmediatamente apaga algunos de los escenarios alternativos. Sucede que hay documentación, pero en el proceso, las tareas cambian y el producto final difiere de la imagen en papel. Nuevamente, existen dificultades para probar y analizar informes de errores.
En tercer lugar, casi todo el tiempo un proyecto se suele desarrollar como una tarea prioritaria. Deja algo de tiempo para revisar. Pero no hay tiempo para corregir errores, como resultado, a veces las mejoras impresionantes ralentizan el proyecto e interrumpen los plazos.
La prueba separada de los pasos plantea otro problema. Entre etapas, el probador olvida los detalles del proyecto y cada vez que tiene que profundizar en lo que está sucediendo. Esto también es una pérdida de horas de trabajo.
En general, verificar el proyecto al final es lógico y aparentemente correcto, pero este método no tiene en cuenta el riesgo de detectar errores globales. Por lo tanto, las pruebas evolucionan aún más.
Etapa 3. Se verifica que todas las tareas cumplan el resultado con la tarea original.
Además, la compañía entiende que es mejor detectar errores a medida que se acumulan. Por lo tanto, estamos cambiando del modelo Waterfall a la metodología Agile. En este punto, los evaluadores están más integrados en el proceso de desarrollo. Todas las tareas comienzan a probarse repetidamente secuencialmente: por separado, como parte del lanzamiento, en un entorno de combate.
En esta etapa, se verifica que las tareas cumplan con los requisitos establecidos. Agile ayuda a trabajar mejor, pero no todos los evaluadores, y especialmente sus líderes, están listos para relacionarse con las pruebas de una manera nueva.
El jefe espera velocidad y calidad de los probadores, pero no se comprende la necesidad de documentación de prueba y la realización de pruebas de regresión. De ahí los problemas típicos de esta etapa de la evolución.
Las pruebas son más intuitivas que estructuradas. El principio de "lo que veo es lo que estoy probando" domina. En cada iteración, se realizan diferentes comprobaciones y en una secuencia diferente. Como resultado, al menos puede omitir el error en una de las etapas de prueba o no verlo en absoluto. Escenarios alternativos y cambios en la funcionalidad relacionada también pueden pasar desapercibidos.
Además, el problema es con las pruebas de regresión, que, si se llevan a cabo, no son sistemáticas. De hecho, el probador verifica lo que considera necesario o lo que el desarrollador / gerente le aconsejó que verifique.
Etapa 4. Los probadores participan en el diseño de la prueba.
En esta etapa, el diseño de prueba entra en escena. Los probadores comienzan a prestar atención conscientemente al análisis de requisitos. La funcionalidad se divide en bloques lógicos, que están cubiertos por listas de verificación o casos de prueba.
Lista de verificación: una lista de comprobaciones necesarias para probar la funcionalidad. Las listas de verificación son más comunes ya que son más fáciles de mantener actualizadas, especialmente como parte de un proyecto grande y dinámico.
Un caso de prueba es una secuencia de pasos que se deben seguir para verificar la funcionalidad. Una descripción de cada paso se acompaña de una indicación del comportamiento esperado del sistema.
Aparece la
documentación de prueba completa, según la cual puede realizar un seguimiento de cómo se verifica un funcional en particular. La documentación de la prueba es útil no solo para las pruebas iniciales, sino también en las pruebas de regresión.
Todo esto se llama diseño de prueba. Se puede decir que las pruebas profesionales significativas comienzan en esta etapa. Esto es más que una montaña de tareas que deben verificarse, sino un proceso estructurado para analizar requisitos, generar documentación de prueba y pruebas directas. Incluyendo cambiar el enfoque de los datos de prueba. Los datos ya no se inventan espontáneamente en el proceso, sino que se toman de conjuntos preparados previamente.
No hay inconvenientes obvios en la etapa de diseño de la prueba. En general, este es un nivel de prueba decente. Para sitios de producción de streaming o proyectos similares, el diseño de prueba es más que suficiente. Lo principal es abordar el proceso de prueba correctamente: analizar el producto, redactar documentación y realizar pruebas en él.
Etapa 5. Se está introduciendo un sistema de gestión de pruebas.
Además, la compañía crece a la necesidad de utilizar sistemas especializados para almacenar casos de prueba (listas de verificación) y realizar ejecuciones de prueba.
Tal sistema permite:
- requisitos de la tienda y casos de prueba;
- Requisitos asociados con casos de prueba
- analizar la cobertura de la prueba;
- almacenar diferentes versiones de casos de prueba;
- Realizar ejecuciones de prueba
- realizar un análisis comparativo de las pruebas de funcionamiento;
- mantener informes de prueba;
- Rastree las cargas de trabajo del equipo para ajustar las tareas y los recursos.
Un sistema es siempre un nuevo paso en la evolución. En nuestro caso, en primer lugar, se mejora el control sobre el proceso de prueba. Gestionamos mejor las pruebas y obtenemos un nuevo nivel de calidad del producto.
En las etapas posteriores del desarrollo del proyecto, dicho sistema ayuda a todos los participantes a recordar cómo algo debería funcionar y cómo verificarlo. El sistema acelera la introducción de nuevos participantes en el proyecto.
Etapa 6. Los controles regulares son automatizados
En el proceso de desarrollo a largo plazo de proyectos, existe la necesidad de automatizar las inspecciones individuales. Para esto, los desarrolladores y evaluadores escriben pruebas automáticas. Los desarrolladores suelen hacer pruebas unitarias, los probadores hacen pruebas ui. Comienzan cubriendo con autotest los escenarios positivos del uso de la funcionalidad clave: autorización, registro, publicación de registros y similares.
Las pruebas automáticas desarrolladas se incluyen en el proceso de integración continua (
CI / CD ), que permite al equipo conocer los errores inmediatamente en el momento de la confirmación.
Las pruebas automáticas reducen significativamente los costos de las pruebas de regresión y mejoran la calidad del producto final. Pero para hacerlos, necesitas un cierto nivel de probador. También vale la pena saber que las pruebas automáticas no tienen sentido en las primeras etapas de un proyecto. El sistema cambia rápidamente, por lo tanto, para evitar errores fantasmas, también es necesario cambiar las pruebas automáticas, lo que lleva tiempo.
Etapa 7. La jerarquía se vuelve más compleja, aparecen nuevos roles
Hemos llegado a la etapa más alta de la evolución, cuando la jerarquía en el departamento de pruebas es significativamente complicada y aparecen especialistas limitados: un gerente de pruebas, un líder de pruebas, un analista de pruebas, un diseñador de pruebas, etc.
El equipo está creciendo, las tareas se están volviendo más complicadas. Por ejemplo, un
administrador de pruebas sabe más sobre un producto y organiza las pruebas a un nivel superior. Se comunica más a menudo y más de cerca con los clientes y el desarrollo que con el equipo de prueba.
El líder de prueba organiza pruebas en el proyecto y distribuye tareas dentro del equipo.
El analista de pruebas se dedica al análisis de requisitos, su descomposición y priorización, prepara el material para el diseño de la prueba y las pruebas posteriores. Y el
diseñador de pruebas transforma los requisitos en listas de verificación y casos de prueba.
Se necesitan nuevos roles en grandes proyectos donde trabaja todo un equipo de evaluadores. La aparición de tales roles conduce a un proceso de prueba aún más estructurado, sin el cual es imposible trabajar en proyectos de TI grandes y complejos.
Conclusiones
Examinamos las etapas clave en la evolución de las pruebas en una empresa. Las pruebas profesionales conscientes comienzan desde la etapa de diseño de la prueba. El diseño de prueba proporciona una mejora constante en la calidad del producto.
El proceso de desarrollo de pruebas no siempre es lineal. Puede omitir, combinar, mezclar ciertas etapas o ir inmediatamente a un nivel superior. Por ejemplo, en Qualitica tenemos un sistema de gestión de pruebas, es decir, estamos en la etapa 5. Ahora, casi simultáneamente, tenemos especialistas limitados (nuevas funciones, etapa 7) y automatización (etapa 6).
No todos necesitan el sistema de gestión de pruebas, las pruebas automáticas y, más aún, un diseñador de pruebas. Pero, permaneciendo en la etapa de pruebas instintivas o limitándonos a los controles finales, es poco probable que realice proyectos complejos a largo plazo. Por lo tanto, deseo que encuentre el punto correcto en el desarrollo de las pruebas y que lo haga para mejorar la calidad de las pruebas y ofrecer a los clientes un producto de alta calidad.