Pruebas de control de calidad perfeccionadas: un tutorial de flujo de usuario

A medida que los productos y servicios se implementan cada vez más rápido, el control de calidad (QA) tiene que adaptarse al entorno en evolución, a veces logrando el mismo nivel de cobertura en un período de tiempo más corto. ¿Cómo evitamos el error de cantidad sobre calidad ? ¿Cómo cubrimos más, aumentamos la eficiencia y seguimos siendo efectivos en nuestro trabajo?

Todos sabemos que los casos de prueba tardan mucho en crearse. Tenemos que aplicar diferentes técnicas, tipos de pruebas y condiciones previas del documento, pasos y resultados esperados. Además, tenemos que crear un plan de prueba.

Los especialistas en control de calidad a menudo se encuentran sin tiempo, especialmente cuando intentan cumplir con todas las fases del proceso de control de calidad. El mayor dolor de cabeza es la fase de diseño y planificación de la prueba, que gira en torno a la creación de casos de prueba y la documentación de la prueba. Puede tomar horas, a veces incluso días de esfuerzo para hacer todo el trabajo y, por lo general, eligen omitir ciertos entregables y resumir en su lugar, omitiendo información importante que puede hacer que se olvide una prueba. Eso también da como resultado la pérdida del beneficio del intercambio de conocimientos.

Las pruebas de control de calidad tradicionales se encuentran con el flujo de usuarios

Soy un gran admirador de los casos de prueba y los planes de prueba tradicionales. No solo ayudan a identificar toneladas de casos de prueba, sino que también documentan muy bien el producto. Puedes usarlos en el entrenamiento, y cualquier persona del equipo los entiende. No tiene que confiar demasiado en la experiencia para que alguien comience a probar. Los planes de prueba tienen más información, como detallar el alcance, los elementos de prueba, las funciones que está probando y las que no. También hay un análisis de riesgos que se incluye en el plan de prueba. Estos son solo algunos de los beneficios, sin embargo, el tiempo total que lleva es demasiado largo en muchos casos.

El propósito de un plan de prueba es una forma de comunicación y un acuerdo entre las partes interesadas del proyecto. Ayuda a detallar los objetivos, los recursos necesarios y cualquier enfoque o estrategia para probar el producto. El plan ayuda a garantizar que se esté pensando en todo y brinda a las partes interesadas la confianza de que el proceso de control de calidad se invierte estratégicamente. No existe una regla concreta de que este plan debe tener 10 páginas. Podemos redefinirlo para adaptarlo a un equipo de ritmo rápido.

La alternativa es simplificar los casos de prueba tradicionales y el plan de prueba de una manera que reduzca la inversión de tiempo requerida pero brinde la misma, si no más, cobertura y documentación que tenga sentido para todas las partes interesadas. Esto implica una única fuente de verdad, un flujo de usuarios con un giro. Al estructurar y mantener un flujo de usuarios, tendrá la mayor parte del diseño de su caso de prueba ya hecho por usted. Esto se puede aplicar a cualquier producto o equipo y es versátil en su forma de detalle y estructura.

El uso del método de flujo lo ayudará a lograr un tiempo de respuesta más rápido con su documentación de prueba. Esto no es solo para el control de calidad manual, sino también para la automatización. El flujo también puede contribuir a algunas secciones del plan de prueba.

Siguiendo la corriente

Sin más demora, profundicemos en la creación de un flujo de usuarios para un sitio web de mensajería simple.

Primero necesitaremos una herramienta gratuita de mapas mentales. Yo personalmente uso XMind. Siéntase libre de descargar cualquier herramienta con la que se sienta cómodo; solo usaremos funciones básicas como dibujar un diagrama de flujo, agregar "notas" a algunos de los temas, colorear diferentes condiciones y usar etiquetas.

Nuestro primer paso es entender el producto. Por lo general, hará referencia a imágenes de maquetas o estructuras alámbricas. Si ninguno de estos está disponible, una llamada rápida para ponerse al día con un desarrollador arrojará exactamente qué pantallas esperar. Siéntase libre de seguir y practicar a medida que avanzamos. El flujo no solo se limita a una interfaz de usuario y también se puede usar para asignar llamadas de API a API, diagramas de bases de datos, estructuras de dependencia y más. Se aplican los mismos principios.

Condiciones, Estados, Acciones

Restringimos nuestro flujo utilizando solo tres actores. Tendrá una condición , que es como un usuario con un rol particular, un caché borrado o un usuario que inicia sesión por primera vez. En segundo lugar, tenemos State/Page , que es un componente GUI real, como una página de inicio o una ventana de inicio de sesión. Luego viene la Acción , que es una interacción física del usuario que hace que el estado cambie. Veamos esto en acción.

Análisis de los requisitos

Esta es nuestra página de inicio, que es el Estado. Tenemos dos Acciones posibles: Registrarse e Iniciar sesión.

Luego, tenemos la ventana Iniciar sesión, otro estado. Las acciones aquí son Atrás e Iniciar sesión. Tenga en cuenta que no clasificamos los campos de entrada como acciones. Eres más que bienvenido a hacer esto. En mi experiencia, descubrí que cuando se trabaja en sistemas complejos que funcionan con algunas décimas de profundidad, se vuelve un poco difícil de mantener, pero para aplicaciones simples, puede ser una excelente opción.

Por último, llegamos al tablero en el que aterrizará el usuario cuando haya iniciado sesión correctamente. Aquí, tenemos tres acciones: podemos crear, editar o eliminar un mensaje.

Ahora tenemos suficiente información para comenzar el flujo de usuarios. Resumamos lo que tenemos. Anotamos los estados del producto. Por lo que podemos ver, hay cuatro páginas:

1. Página principal
2. Ventana de inicio de sesión
3. Ventana de Registro
4. Tablero

Anotamos nuestras acciones en cada página/estado que se puede “interactuar” con:

1. Página principal
   1. Acceso
   2. Registrarse
2. Ventana de inicio de sesión
   1. Registrarse
   2. Cancelar
3. Ventana de Registro
   1. TBD (depende del producto)
4. Tablero
   1. Crear
   2. Editar
   3. Borrar

Comenzamos con el nombre del producto , que se puede cambiar para adaptarse a su entorno, pero se adapta a la mayoría de los equipos y sus productos y también proporciona un buen punto de partida. A continuación, veremos un signo de interrogación junto a Registrarse .

Muchas veces, se encontrará con un componente en Agile que aún no está dentro del alcance o planeado para una versión futura. Toma nota de su existencia, pero déjalo como una incógnita hasta que tengamos más información.

Dibujar el diagrama de flujo

Dibujamos lo anterior en XMind para que se vea así:

Notarás que simplemente estoy codificando por colores lo que es un estado y lo que es una acción. También agregué una línea desde Cancelar acción a la página de inicio para representar ese flujo con precisión. También vemos dos condiciones cuando un usuario selecciona "Iniciar sesión". Aunque ambos van al tablero, todavía queremos probar ambas condiciones posibles.

Lo bueno de XMind es que si trabajamos en una aplicación grande y compleja, podemos crear diferentes niveles del diagrama, por lo que si desea dividir el flujo en varios flujos pero mantenerlos vinculados, es muy fácil hacerlo mediante la vinculación. los temas a hojas separadas. Puede seleccionar insertar un hipervínculo y, desde la ventana emergente del asistente, puede elegir un "Estado" al que conduce la acción. Esto significa que si selecciona "Iniciar sesión" en XMind y tiene un hipervínculo a "Panel de control", el cursor del mouse saltará a "Panel de control", incluso si está en una hoja diferente. Muy genial.

Lo que le falta a nuestro flujo son etiquetas. Le damos al producto una etiqueta de 0, ya que esa es la raíz del flujo. Luego, para cada Estado (azul), agregamos una etiqueta S#, para cada Acción (verde), agregamos una etiqueta A# y, por último, para cada Condición (cian), agregamos una etiqueta C#. Cada etiqueta debe ser única. Terminamos con lo siguiente:

Para rastrear qué número usó por última vez, porque a medida que crece el producto, tratar de encontrar el número más alto puede ser un desafío, guardo esto en el tema raíz del flujo, como se muestra a continuación:

Ahora llegamos a la parte de crear casos de prueba. Nos vamos a centrar en los resultados esperados, que es probablemente la información más importante en un caso de prueba y parte de los criterios de aceptación de la función. Agregaré un título para cada sección o prueba y luego enumeraré los resultados esperados debajo. Haré esto solo para un subconjunto para mantener este artículo conciso:

Luego, la ventana de inicio de sesión:

Luego, la acción de inicio de sesión:

Realmente está tomando forma. Observe las pruebas de límites y seguridad añadidas. Puedes titular esto como quieras, lo que te resulte más fácil de etiquetar. A veces etiqueto el título con un tipo de prueba, como Seguridad - Inyección JS - Campo de correo electrónico, y luego enumero los resultados esperados a continuación.

En la mayoría de los equipos, encontramos que cambiar los requisitos es una molestia para mantener. No más. Supongamos que acabamos de enterarnos de que a todos los usuarios nuevos se les debe presentar la ventana Ts y Cs y tienen que aceptar antes de continuar con su tablero, no hay problema. Podemos agregar el estado y las acciones con relativa facilidad, como a continuación:

Ahora vemos el impacto de agregar un nuevo estado. Tenga en cuenta que la numeración puede ser extraña al principio, pero mientras recordamos, los números son solo para identificar de manera única a cada actor, como una clave principal en una base de datos. No olvide actualizar sus notas de "Último uso" para realizar un seguimiento de los números que utiliza.

Crear los casos de prueba desde el flujo

Después de todo este progreso, ahora llegamos a la parte más fácil: la creación de casos de prueba. Permítanme resaltar algunos puntos importantes. Tenemos etiquetas para cada actor, tenemos títulos para cada prueba y tenemos resultados esperados para cada prueba, con condiciones integradas como parte de nuestro flujo. Esto suena como la receta para un caso de prueba, ¿no le parece?

Todo lo que hacemos ahora es copiar y pegar lo que está en nuestro flujo en cualquier herramienta de gestión de casos de prueba, sitio de Confluence o documento de Excel que desee. Todavía uso el viejo y confiable Excel. Mantengo un registro de todos mis casos de prueba en un archivo llamado "Baseline" - muy original. Una vez que termine de copiar y pegar, termino con lo siguiente:

Siéntase libre de agregar columnas para tipos de prueba, estado de prueba y configuraciones de prueba según sea necesario. Las condiciones pueden estar mejor ubicadas antes de la acción "Iniciar sesión", sin embargo, no hay una forma correcta o incorrecta de hacerlo, depende de las preferencias personales y de cómo te organices.

Hay algunas cosas a destacar. Una es que he combinado celdas que comparten la misma información, no es necesario copiar y pegar repetidamente, es una pérdida de tiempo y es más difícil de mantener. Otro elemento son los Pasos. Notará que dos de las pruebas tienen pasos que incorporan los números de Estado y Acción. Esto se puede usar cuando tiene el flujo como parte del SDLC en su equipo. Luego, todas las partes interesadas contribuyen al flujo al proporcionar información, maquetas, plantear riesgos, etc. Esto significa que al indicar los números de flujo, cualquiera en el equipo sabrá qué hacer, y si hay un nuevo miembro del equipo, es tan fácil como "sigue el rastro, consulta las notas".

Esto también ayuda a la automatización. Puede dar a cada paso o acción una referencia única. Al crear un paquete de automatización que esté estructurado como su flujo, descubrirá que el marco de automatización que puede crear tiene el potencial de ser altamente sólido, modular y compatible en toda la aplicación. Utilizará objetos de paginación a mayor escala, lo que reducirá el tiempo de mantenimiento y le permitirá cambiar las funciones de prueba por otras nuevas.

El flujo puede ser la única fuente de verdad para toda la documentación del producto, incluidas las especificaciones técnicas, las especificaciones funcionales, los casos de prueba, la transición de estado, los flujos de datos, etc.

El enfoque del plan de prueba simplificado

Entonces, ¿qué pasa con los planes de prueba?, debes estar pensando. Esto es simple. Un plan de prueba contiene secciones como:

1. Introducción y alcance
2. Elementos de prueba
3. Características a probar
4. Características que no deben probarse
5. suposiciones
6. Criterio para entrar
7. Criterio de salida
8. EDT
9. Riesgos
10. Requisitos ambientales

La Introducción y alcance será la historia de JIRA o cualquier tarea o historia en otra herramienta. Los elementos de prueba son simplemente las versiones de software o los números de compromiso implementados actualmente en su entorno, que puede vincular al ticket de JIRA o en su ejecución de prueba en Confluence o en la herramienta de administración de pruebas.

Las funciones que se probarán y las funciones que no se probarán son en realidad sus casos de prueba. Los casos de prueba elegidos para ejecutarse en esta historia de JIRA son "Características que se probarán" y cualquier cosa que no esté en la lista es "Características que no se probarán". En pocas palabras, enumere los estados y las acciones que probará en el ticket de la historia.

Las suposiciones, los riesgos e incluso los requisitos ambientales se pueden compilar en un documento o agregar a los comentarios en JIRA, a veces incluso se pueden colocar en Confluence y vincular a la historia.

Una WBS es una estimación que le asigna a la historia en términos de horas o puntos de la historia, según su proyecto. Los criterios de entrada y salida ya serán parte de la historia.

Si desea estar cerca de los planes de prueba "tradicionales", puede pedirle al desarrollador u otras partes interesadas que comenten la historia con un Sí o un No para ver si están de acuerdo con el plan de control de calidad o no. Esto sirve técnicamente como su firma digital. Todo esto puede incluirse en su proceso de control de calidad con bastante facilidad y ayudarlo a optimizar su documentación de control de calidad.

¿Qué hemos aprendido?

El flujo de usuarios con el enfoque anterior y los planes de prueba optimizados para usar las herramientas disponibles en la actualidad nos ayudarán a reducir el trabajo repetitivo y ayudarán al control de calidad a lograr un tiempo de respuesta más rápido sin sacrificar la calidad.

Este enfoque ha sido fundamental para guiarme a mantenerme organizado, cubrir todas las bases y crear documentación que todo el equipo entienda. En Agile, esto será realmente útil, y lo mejor de todo es que seguimos cumpliendo con uno de los enfoques ágiles: "Simplificar la documentación".

Realmente espero que la información haya sido útil. Todo depende de ti como lector. Este no es un conjunto concreto de reglas a seguir, son solo pautas para darle ideas para crecer y mejorar su eficiencia. Ninguna técnica se adaptará a todos los proyectos, equipos o productos, pero puede allanar el camino para otra idea innovadora.