Automatizador de control de calidad

Automatizador de control de calidad

¿Sabes lo que hace un control de calidad?

QA, Quality Analyst en inglés o Quality Analyst en portugués. Este es uno de los roles de los consultores de Thoughtworks más solicitados por nuestros clientes. Por esta razón, Pat Sarnacke escribió un artículo para responder a esta pregunta, originalmente en inglés. Dada la relevancia de este rol para los equipos que trabajan con productos digitales, decidí traducirlo y compartirlo.

QA debe, ante todo, garantizar la calidad; es decir, la necesidad en cualquier proyecto de asegurar que el software que estamos entregando al cliente es exactamente lo que quiere. Sin embargo, los analistas de calidad son los pensadores que se especializan y se apropian de la calidad del proyecto. Esto es un desafío porque todos en un equipo son responsables de la calidad y, dependiendo de la composición del equipo, diferentes personas pueden manejar diferentes aspectos de la calidad.

Tareas y responsabilidades de control de calidad
  • Análisis de pruebas: incluye análisis de riesgos y diseño de pruebas. El análisis de riesgos consiste en averiguar qué tipos de problemas es probable que ocurran, y dónde, cuándo y cuánto afectan al software. El diseño de pruebas (y el diseño de conjuntos de pruebas) se trata de descubrir cómo cubrir de manera eficiente estas áreas de riesgo por completo, dado el tiempo y los recursos disponibles. El control de calidad realiza análisis de prueba cuando piensa en pruebas exploratorias, cuando escribe casos de prueba de regresión, cuando colabora en criterios de aceptación de historias, cuando implementa o mantiene pruebas automatizadas, o cuando decide qué pruebas de regresión no hacer porque no tendrá tiempo.
  • Estrategia de prueba : los controles de calidad suelen colaborar con los desarrolladores en la estrategia de prueba general del equipo, ya que los desarrolladores realizan muchas pruebas, pruebas funcionales de bajo nivel, pruebas de contrato de servicio y pruebas de interfaz de usuario. Es importante que los esfuerzos de automatización de pruebas entre los QA y los desarrolladores se complementen entre sí, porque de lo contrario puede haber brechas en la cobertura que introduzcan riesgos o duplicaciones que ralenticen al equipo.
  • Análisis empresarial : los controles de calidad pueden (mucho) ayudar a los analistas empresariales a definir criterios de éxito para las historias. Ayudan a los analistas de negocios a pensar en cómo los diferentes usuarios podrían interactuar con una solución propuesta. Además, al preguntar “cómo podemos probar esta historia”, el control de calidad a menudo cambia la forma en que se escriben las historias.
  • Verificación de la historia : a medida que los desarrolladores terminan las historias a lo largo de la iteración, alguien debe probarlas cuidadosamente para asegurarse de que cumplan con los criterios de aceptación y las necesidades del usuario. Si un equipo es lo suficientemente grande como para tener controles de calidad, eso es parte de su función. Confiamos en los QA con sus habilidades de prueba: rigor y conocimiento de técnicas eficientes para encontrar errores.
  • Pruebas manuales : antes de escribir una prueba automatizada, debemos probar las cosas manualmente para tener una idea de cómo funcionan y tener una mejor idea de qué automatizar. Dado que los conjuntos de pruebas automatizados pueden ser costosos de mantener (consulte la sección Mantenimiento y refactorización de pruebas a continuación), podemos o no decidir automatizar las pruebas manuales más adelante.
  • Automatización de pruebas : muchas pruebas (especialmente las pruebas de regresión: consulte Pruebas de regresión a continuación) implican hacer clic repetidamente en el software como lo hace un usuario y asegurarse de que todo funcione. Paradójicamente, esto es propenso a errores Y una pérdida de control de calidad: los controles de calidad son personas inteligentes y creativas, y hacer clic en las mismas páginas una y otra vez no les da muchas oportunidades para ejercitar esa creatividad e inteligencia. Por otro lado, hacer estas tareas rutinarias manualmente deja una alta probabilidad de error. A menudo es mejor si las funciones más importantes se prueban automáticamente.
  • Pruebas exploratorias: aquí es donde brilla el control de calidad. Tratando de encontrar casos y combinaciones que los desarrolladores no pensaron al escribir el código. Tratar de pensar como el usuario final e imaginar cómo usaría el software. Pensando en cosas que no se describieron como requisitos explícitos, pero que obviamente deberían ser parte del software. Pensar en el sistema como un todo y no desde la perspectiva de historias individuales. Los QA probablemente ya hayan pensado algo de esto cuando ayudaron a escribir las historias, pero nada se compara con explorar el software y probar varias cosas.
  • Pruebas de regresión : una regresión es un cambio no deseado en la funcionalidad existente. Cuando algo que antes funcionaba correctamente deja de funcionar disparador, la aplicación “retrocedió” (o retrocedió). Una gran parte del aseguramiento de la calidad tiene que ver con la protección contra las regresiones. En un equipo que está construyendo una nueva aplicación, no hay problema con las pruebas de regresión hasta que se termina la primera historia. Después de eso, a partir del segundo piso, existe un riesgo de regresión que requiere pruebas de regresión. Es un problema constante siempre que la aplicación crezca y cambie. Los desarrolladores a menudo proporcionan una o más capas de pruebas de regresión automatizadas que se ejecutan de manera continua (pruebas unitarias, pruebas funcionales más grandes, pruebas de contrato de servicio, etc.) y el equipo de control de calidad a menudo contribuye con pruebas de IU funcionales automatizadas, pero debido a que el desarrollo a menudo está adelantado de la automatización de pruebas de control de calidad, y debido a que las pruebas automatizadas no pueden anticipar todos los problemas que pueden ocurrir, a menudo hay muchas pruebas de regresión manuales que hacer. Esto implica algo más que seguir pasivamente los guiones de prueba. Gran parte del esfuerzo en las pruebas de regresión manual es la planificación y el diseño de pruebas y conjuntos, y la planificación y coordinación de su ejecución. Las pruebas exploratorias también son clave durante las pruebas de regresión.
  • Pruebas de requisitos de funcionalidad cruzada : muchos proyectos necesitarán elementos como pruebas de estrés, pruebas de inmovilización, pruebas de carga, pruebas de recuperación ante desastres, pruebas de rendimiento, pruebas de penetración y otros formularios de prueba del sistema.
  • Creación y mantenimiento de datos de prueba : todo el mundo necesita datos realistas para probarse a sí mismo y, a menudo, es peligroso o ilegal utilizar datos comerciales reales. El control de calidad puede ayudarlo a encontrar conjuntos de datos realistas o ayudarlo a crearlos y luego ayudarlo a mantenerlos durante el transcurso de un proyecto.
  • DevOps : la mayoría de las pruebas se realizan en un “entorno de prueba”, lo que a menudo significa que el control de calidad es la primera persona que tiene una necesidad real de una aplicación implementada que funcione. Esto a veces significa que el control de calidad se convierte en una persona de DevOps para el equipo a medida que comienzan a solucionar los problemas de las implementaciones por su cuenta.
  • Comunicación de riesgos y defectos : las personas en diferentes roles necesitan información diferente sobre riesgos y problemas, presentados de diferentes maneras. El control de calidad debe ser lo más detallado y preciso posible cuando hable con un desarrollador sobre un defecto, pero es posible que deba ayudar a un gerente de proyecto o gerente de producto a comprender las implicaciones más amplias para el usuario final o el programa de lanzamiento de software. . Y saber cuándo simplemente registrar un problema, cuándo levantar una bandera roja sobre el problema y cuándo detener todo hasta que se resuelva el problema.
  • Liberación de la toma de decisionesEl control de calidad generalmente tiene la responsabilidad de tomar o participar en la toma de decisiones de si o no en inglés para nuevas características y productos.
  • Mantenimiento y refactorización de pruebas : a medida que un proyecto crea un conjunto de pruebas automatizadas, se vuelve cada vez más propenso a romperse debido a pequeños cambios. (Esto se llama “frágil”). Alguien tiene que refactorizar las pruebas para extraer el código de uso común (para que se rompa en un solo lugar en lugar de cientos), y combinar algunas pruebas que están duplicadas y eliminar pruebas antiguas que ya no sirven para su propósito. A medida que crece el tamaño del conjunto de pruebas automatizado, la necesidad de mantener este conjunto de pruebas crece proporcionalmente.

Entrar

Cadastrar

Redefinir senha

Digite o seu nome de usuário ou endereço de e-mail, você receberá um link para criar uma nova senha por e-mail.

Membership

An active membership is required for this action, please click on the button below to view the available plans.

pt_BRPortuguese