No eres tú; una gran parte de ser un control de calidad ES la localización de defectos

Una gran parte del trabajo de control de calidad es la localización de defectos.

Por supuesto, las técnicas de diseño de pruebas nos ayudan a elegir escenarios de prueba y a hacer que las cosas sean más eficientes, pero ¿qué es exactamente la localización de defectos y cómo podemos hacerla menos dolorosa?

Empecemos con lo básico

La localización es como jugar a ser detective: “¿Dónde y cuándo salieron mal las cosas?” Sin una localización adecuada, un defecto puede convertirse en un problema candente que se debate entre el frontend, el backend y cualquier equipo de desarrollo. Se pierde tiempo y, potencialmente, incluso contexto.

Piense en la localización de defectos como si estuviera navegando por un laberinto, con las solicitudes y los registros de la aplicación como su ovillo de lana. Pero ¿no sería más fácil tener un mapa de este laberinto, aunque sea un bosquejo, en lugar de simplemente dar tumbos con el hilo? Ahí es donde entra en juego la arquitectura de la aplicación.

¿Qué es la arquitectura de aplicaciones?

Se trata de cómo funcionan juntas las distintas partes del sistema. En términos de nuestra metáfora del laberinto, se trata de cómo se conecta una sección con otra, qué pasadizos conducen a dónde.

Distingo dos arquitecturas principales: cliente-servidor y backend.

• La arquitectura cliente-servidor nos muestra cómo interactúan el cliente y el servidor.
• La arquitectura del backend determina cómo el backend maneja las solicitudes de los clientes.

Algunas palabras sobre la arquitectura cliente-servidor

Generalmente existen dos tipos:

• Cliente ligero
• Cliente pesado

El tipo afecta la cantidad de información que el cliente conserva y procesa por sí solo. Hay otras formas de configurar esto, pero me ceñiré a lo que realmente he trabajado.

La mayoría de las aplicaciones móviles y web son clientes ligeros. Toda la información se almacena en el servidor y la aplicación cliente solicita datos o solicita que se procesen. Registrarse, iniciar sesión, suscribirse a notificaciones: todo esto son llamadas al servidor. Todo el procesamiento en el servidor está oculto para el cliente. En respuesta a la solicitud, el cliente recibe información recopilada y procesada de la base de datos o una confirmación de que la solicitud se completó correctamente.

En las aplicaciones de cliente pesado, el cliente realiza la mayor parte del procesamiento por sí mismo: agrega datos a la base de datos, genera informes, calcula sumas y crea documentos. A menudo se instalan localmente, pero no siempre. Algunos ejemplos de clientes pesados incluyen juegos sin conexión, AutoCAD y algunas versiones de 1C.

Ahora, exploremos la arquitectura del backend.

Dos enfoques comunes son:

• Monolítico
• Microservicios

Cuando casi todo se procesa en un solo lugar, es un monolito.

Si se envían solicitudes de procesamiento a otros servicios dentro del sistema, es probable que se trate de una arquitectura de microservicios.

En una arquitectura monolítica, identificar el origen de un defecto puede ser complicado, ya que distintos equipos y servicios suelen compartir la misma base de código, lo que significa que los cambios pueden tener consecuencias inesperadas.

En el segundo caso, los servicios están separados, cada uno con su propia base de código, lo que significa que los cambios en un servicio tienen poco impacto en los demás.

Estructura organizativa y áreas de responsabilidad

El título suena aterrador, pero simplemente te dice quién hace qué y quién es responsable de qué parte del laberinto (aplicación). Imaginemos que tenemos una gran empresa: un banco, un mercado, un servicio de entrega de alimentos, lo que sea. Cuanto más grande y compleja sea nuestra aplicación, más personas trabajarán en ella. Y cuantas más personas haya, más necesitarás dividirlas en equipos, cada uno responsable de su propia área de desarrollo.

Por ejemplo, un equipo puede encargarse de las promociones, mientras que otro es responsable de los pagos. Si nuestra aplicación ofrece diferentes servicios, los equipos pueden ser responsables de servicios individuales, como la gestión electrónica de documentos, la contabilidad o las compras gubernamentales.

No es necesario saberlo todo ni saberlo de todos, pero si hay documentación que describe qué equipo es responsable de qué área, es mejor mantenerla en favoritos.

Poniéndolo todo junto

Mapa en mano, hilo en mano, adentrémonos en nuestro laberinto y busquemos la fuente de un defecto. Imaginemos algunos escenarios.

Escenario 1

Imagínese lo siguiente: estamos probando un sitio web para un club de conversación.

Estamos revisando el horario de clases, leyendo sobre las próximas sesiones, cuando en algún momento detectamos un error tipográfico.

Ahora bien, ¿cómo podemos averiguar cuál es su origen? ¡Que comience la aventura!

Abrimos devTools, actualizamos la página y observamos las solicitudes y respuestas. Como tenemos un cliente ligero, encontramos nuestro error tipográfico en una de las respuestas: provenía del backend.

Ahora, abrimos los registros y buscamos el procesamiento de la solicitud o respuesta del backend: este es nuestro hilo de la bola mágica. Podemos buscar en los registros utilizando cualquier información de la solicitud y la respuesta, pero es mejor utilizar valores únicos: xiid de la solicitud, ID de la solicitud, número de teléfono, etc.

Encontramos la entrada y verificamos: ¿obtuvimos la información de la clase de la base de datos o de otro servicio?

Si la información proviene de la base de datos, podemos pasar el problema al soporte técnico para corregir el error tipográfico en la base de datos.

Si la información proviene de otro servicio, podemos pasarles el defecto.

¡Enhorabuena! Hemos superado nuestro primer laberinto: el defecto está localizado y notificado.

Escenario 2

Ahora imagina que estamos probando un formulario de registro.

Introducimos un correo electrónico, unos datos y una contraseña inventada. Hacemos clic en el botón de registro y, de repente, nos aparece un error.

¡Es hora de desentrañar nuestra bola mágica! Nos dirigimos a nuestra querida pestaña Red en devTools y vemos qué salió mal: repetimos todos los pasos y verificamos la respuesta del servidor.

En respuesta a la solicitud, recibimos un código 400 con un cuerpo de respuesta vacío. ¿Deberíamos salir corriendo y registrar un defecto en el frontend? Pero aún no sabemos qué salió mal exactamente y qué se debe solucionar. A menudo, un error 400 ocurre cuando hay una discrepancia entre lo que el cliente envió y lo que el servidor esperaba. Puede haber muchas razones para esto, entre ellas:

• Documentación obsoleta en la tarea
• Cambios realizados sin documentación
• Errores tipográficos

Revisemos la solicitud del cliente.

Si tenemos documentación, escrita manualmente o generada en Swagger o OpenAPI, usémosla para verificar que:

• Estamos enviando todos los parámetros requeridos
• Los valores de los parámetros tienen tipos de datos correctos (por ejemplo, valores numéricos para parámetros int)

¿De qué otra manera podemos comprobar la solicitud?

Incluso si no tenemos documentación, podemos verificar:

• Cumplimiento de sintaxis (por ejemplo, si la solicitud se envía en formato JSON, debe seguir la sintaxis JSON)
• Errores tipográficos en los nombres de los parámetros (por ejemplo, “mony” en lugar de “money”, “doby” en lugar de “body”)
• Caracteres cirílicos entre caracteres latinos (por ejemplo, “nombre” escrito con una “e” cirílica)

¿Está todo en orden? Entonces es hora de continuar nuestro viaje a través del laberinto para encontrar la respuesta. Tomamos nuestro mapa y “descendemos” hacia los troncos.

Análisis de registros

Aquí son posibles dos escenarios:

• Se registra un error durante el procesamiento de la solicitud.
• No se registra ningún error, pero se registran las solicitudes.

En el último caso, tendremos que continuar nuestro viaje por el laberinto de microservicios y buscar el lugar donde se procesó nuestra solicitud.

Al localizar el registro de errores, sabremos exactamente qué salió mal, lo que significa que nuestra localización y nuestro viaje están completos. Solo queda recopilar la siguiente información para el informe de defectos:

• Solicitud de backend
• Registro de errores
• Solución recomendada

Conclusión

La localización de defectos puede ser un desafío. A veces te toparás con un muro: el registro que estabas siguiendo no conduce al error o hace que las cosas sean más confusas. En tales situaciones, suelo dar un par de pasos atrás o empezar desde el principio.

Explorar el laberinto puede llevar mucho tiempo. El viaje puede ser difícil y estar plagado de peligros: el procesamiento de algunas solicitudes puede ser complicado y enviar solicitudes a varios servicios diferentes. A veces tiene sentido simplificar la tarea y ponerse en contacto con los arquitectos del laberinto, los desarrolladores.