O que faz uma pessoa QA?

Por Paulo Caroli e Marcelo Leite*

QA, Quality Analyst em Inglês, ou Analista de Qualidade, em Português. Esse é um dos papéis dos consultores da Thoughtworks mais questionado pelos nossos clientes. Por esse motivo, o Pat Sarnacke escreveu um artigo para responder esta pergunta, originalmente em Inglês. Dada a relevância deste papel para as as equipes que trabalham com produtos digitais, eu decidi traduzi-lo e compartilhá-lo.

Não é um tópico que a maioria das universidades ensina de maneira significativa – e mesmo para aquelas que fazem, muitas vezes não cobrem isso no contexto de equipes ágeis. As pessoas sabem que o “Q” significa “Qualidade” e, geralmente, isso é tudo.

A disciplina e as técnicas de Qualidade de Software evoluíram junto com o desenvolvimento de software e hoje estão alinhadas com as abordagens ágeis e enxutas.

Na abordagem tradicional (desenvolvimento em cascata), a pessoa QA participava do desenvolvimento somente ao final do ciclo, tornando-se o gargalo no fluxo de trabalho e era a única responsável pela “garantia de qualidade”. Esta visão tradicional, onde o desenvolvimento de software era encaixado no sistema industrial de linha de montagem, contrasta com a visão atual, proveniente das abordagens ágeis e enxutas. Uma pessoa QA contemporânea entende que a qualidade é um pacto coletivo e que ela gera mais valor para a equipe quando atua como catalisadora das práticas de qualidade.

Essas práticas de qualidade estão presentes em todo o ciclo de desenvolvimento e, cabe à pessoa QA assessorar os demais membros da equipe, como as pessoas desenvolvedoras, analistas de negócio, DevOps e analistas de experiência de usuário.

Este artigo foi revisado por Marcelo Leite e está dividido em três seções:

1. Práticas de Qualidade ao longo do ciclo de desenvolvimento
2. Tarefas e Responsabilidades de uma pessoa QA
3. O que uma pessoa QA deve aprender?

1. Práticas de Qualidade ao longo do ciclo de desenvolvimento

A imagem abaixo representa uma visão atual do desenvolvimento de software, onde as práticas de operações também se fazem presentes.

Observe que, em cada seção do ciclo, há Práticas de Qualidade. Essa imagem é baseada na abordagem da visão holística da Qualidade, descrita por Lisa Crispin e Janet Gregory.

As Práticas de Qualidade ao longo do ciclo são:

Descoberta (Discover)

Na fase de Descoberta, a equipe foca a sua energia em entender o problema em questão. Essa é uma fase altamente colaborativa, onde a equipe e o cliente realizam várias dinâmicas para entender o que será desenvolvido e qual é o seu valor. Atividades comuns nessa fase são a Lean Inception e o Design Sprint.

Aqui, a pessoa QA trabalha em colaboração com as pessoas analistas de negócio e pessoas-chaves do cliente, com o objetivo de:

• Testar ideias: como definir se a equipe alcançou sucesso se uma dada ideia for implementada?
• Determinar valor: como validar se as soluções propostas entregam valor ao cliente?

Planejamento (Plan)

Na fase de planejamento, a pessoa QA, colabora com analistas de negócio, analistas de experiência de usuário e pessoas desenvolvedoras para definir que as seguintes Práticas de Qualidade:

• Identificar riscos: quais são os riscos presentes nos requisitos e quais são os planos para mitigá-los?
• Testar suposições: como saber rapidamente se as suposições são válidas ou não?
• Criar histórias testáveis: as histórias de usuário são claras o suficiente para que testes possam ser escritos para ela?

Entendimento do Problema (Understand)

Na fase de Entendimento do Problema, o Backlog de Produto é criado, de maneira enxuta e priorizado por valor. Nessa fase, é importante que a pessoa QA trabalhe junto com as pessoas analistas de negócio para uma visão holística do sistema. As Práticas de Qualidade nessa etapa são:

• ATDD/BDD: os cenários de teste são criados levando-se em consideração o domínio e o contexto do negócio? Como serão feitos os Testes de Aceite (Acceptance Testing)?
• Mapeamento de Exemplos: é uma técnica para detalhar e obter clareza sobre os critérios de aceitação de uma determinada história de usuário. A pessoa QA deve se preocupar em criar vários exemplos concretos de teste que cubram a funcionalidade
• Prototipação: como validar um protótipo e usar o aprendizado para criar testes futuros na aplicação ou sistema completos?
• Determinar métricas para Monitoração e Observabilidade: ao trabalhar em conjunto com uma pessoa de DevOps para definir as métricas, a pessoa QA deve focar em validar: tempo de resposta, carga no momento de pico de acesso/tráfego, quantas requisições foram servidas, capacidade de CPU, uso de memória, taxas de erro e latência. Essas métricas quantificam o desempenho, alertam a equipe assim que um sistema ou serviço é interrompido e também monitoram eventos em busca de atividades fora do comum, fazendo com que os defeitos em produção sejam reparados mais rapidamente.

Desenvolvimento (Build)

Na fase de desenvolvimento propriamente dita, há várias oportunidades de se realizar Práticas de Qualidade, com a colaboração de pessoas desenvolvedoras e analistas de negócio.

• Automatizar testes: a automatização é essencial para ter um feedback rápido de como o sistema se comporta quando uma nova funcionalidade é implementada. Os testes automatizados vão do nível do código (testes unitários) ao nível de interação com o usuário na interface, passando pela verificação de componentes, banco de dados e integração entre sistemas.
• Instrumentalizar o código: o código está apoiando as métricas de monitoração, definidas anteriormente, para que estas possam ser verificadas em produção?
• Testar histórias e funcionalidades: esta prática é a mais conhecida e mais associada ao trabalho da pessoa QA. Desde os testes exploratórios, quanto os “desk checks”, onde as pessoas QA trabalham em par com a pessoa desenvolvedora em sua própria máquina, quanto à técnica do “three amigos”, onde antes mesmo do desenvolvimento, uma pessoa QA, uma pessoa analista de negócios e uma pessoa desenvolvedora se reúnem para discutir e validar uma história de usuário, a fim de validar o entendimento. Estas e outras Práticas de Qualidade serão descritas na próxima seção, intitulada Tarefas e Responsabilidades de uma pessoa QA.

Implantação (Deploy)

Na fase de implantação, o foco é na infraestrutura que suportará o sistema. Para que haja qualidade nessa etapa, a pessoa QA trabalha em conjunto com a pessoa DevOps e desenvolvedora, nas seguintes Práticas de Qualidade:

• Testar infraestrutura: como são os servidores da aplicação: nas nuvens, físicos? E os bancos de dados? E o sistema de cacheamento? Como é feita a migração de dados? Há uso de contêineres, como Kubernetes?
• Executar testes automatizados: quais são os resultados? Os testes são determinísticos e resilientes?
• Testar a pipeline: como está a saúde da pipeline de integração contínua?
• Testar os atributos de qualidade: como está a confiabilidade do sistema? O que acontece se houver uma falha? O sistema consegue retornar ao estado de perfeito funcionamento? O sistema é escalável? É seguro? É compatível com diferentes versões dos sistemas aos quais se integra?
• Testar o sistema: após os testes de integração, como o sistema se comporta como um todo?

Lançamento (Release)

Após a fase de Implantação, o sistema é “lançado”, ou, como é mais comumente falado, “é colocado em Produção”.

• Testar em produção: quais são os testes rápidos que podem te dizer se o sistema não está funcionando corretamente? Aqui, os testes mais utilizados são os do tipo monitoramento sintético. Um exemplo: um teste que testa a funcionalidade de login de 1 em 1 minuto. Ao falhar, o teste envia um alerta e a equipe fica sabendo deste bug antes de ser reportado pelo usuário final.
• Usar feature toggles: quão rápido e eficaz é possível ligar e desligar uma funcionalidade em Produção através das feature toggles sem comprometer o funcionamento do restante do sistema?
• Método blue/green de deploy: como testar se o sistema pode ser revertido durante o lançamento? Como testar se o lançamento gradual está indo de acordo com o esperado?

Monitoração (Observe)

É na fase de monitoração que temos a oportunidade de aprender o comportamento real dos usuários. Nessa fase, a pessoa QA pode trabalhar em conjunto com a pessoa DevOps para:

• Entender como os usuários usam o produto: os cenários de teste realmente cumpriram a sua função? Quais são as áreas mais problemáticas em termos de bugs? Quais áreas o usuário pode beneficiar de uma melhor experiência?
  Implementação da Monitoração e Observabilidade: a instrumentação foi devidamente implementada?

Aprendizado (Learn)

Esta fase é onde as hipóteses são verificadas e revistas e outras são criadas, iniciando-se novamente o ciclo de desenvolvimento.

• Criação e revisão de hipóteses: quais são as lições aprendidas? O que podemos melhorar no próximo ciclo?

2. Tarefas e Responsabilidades de uma pessoa QA

Seguem algumas das responsabilidades de uma pessoa QA:

• Análise de teste – Isso inclui análise de risco e design de teste. A análise de risco é descobrir quais tipos de problemas são suscetíveis de ocorrer – e onde e quando e quanto eles afetam o software. A atividade de análise de risco mais utilizada hoje em dia segue o método Risk Storming. O design do teste (e o design da suíte de teste) são descobrir como cobrir eficientemente essas áreas de risco completamente, tendo em vista o tempo e os recursos disponíveis. A pessoa QA faz análise de teste quando pensa num teste exploratório, está escrevendo casos de teste de regressão, colaborando nos critérios de aceitação da história, implementando ou mantendo testes automatizados, ou quando está decidindo quais testes de regressão não deve fazer porque não vai ter tempo.
• Estratégia de teste – As pessoas QAs, geralmente, colaboram com os desenvolvedores na estratégia geral de testes da equipe, já que há testes realizados por desenvolvedores também. Usualmente, os desenvolvedores são responsáveis por testes mais próximos da lógica do código da aplicação, como os testes unitários e de contratos de serviço, ao passo que os testes que navegam pela interface são geralmente feitos pelas pessoas QA. É importante que os esforços de automação de teste entre os QAs e os desenvolvedores se complementam, porque, de outra forma, pode haver lacunas de cobertura que introduzem riscos ou duplicações que retardam a equipe.
• Análise de negócios – As pessoas QA podem colaborar com as pessoas analistas de negócio na criação dos critérios de aceitação (também chamados de critérios de sucesso) nas histórias de usuário. O resultado dessa colaboração é um enriquecimento das histórias de usuário, com análises de como as diferentes personas interagem com a aplicação, descrição de riscos e suposições e uma lista dos possíveis cenários através de especificações executáveis, que guiam o desenvolvimento e respondem a pergunta “Como sei quando esta história está pronta?”.
• Verificação da história – Mesmo em times ágeis, até há pouco tempo, era função exclusiva de uma pessoa QA de executar a verificação das histórias e tarefas que se encontram na coluna dedicada à verificação (na maioria dos casos, chamada de “Em Teste” ou “Em QA”). Uma visão mais moderna de como a Qualidade e o Teste são de responsabilidades compartilhadas na equipe, qualquer pessoa da equipe tem o dever de verificar as tarefas e não somente a pessoa QA. Quando é o caso da equipe ter uma pessoa QA em sua formação, esta é responsável por garantir que as tarefas sejam distribuídas e que todos tenham a oportunidade de realizar a verificação. Com isso, a pessoa QA faz com que todos os membros da equipe consigam construir um modelo mental do sistema que está sendo construído, ao mesmo passo que evita se tornar um gargalo no processo de desenvolvimento de software, já que não é somente a única pessoa responsável por mover a tarefa adiante.
• Testes automatizados – a automação de testes é uma ferramenta poderosa para uma pessoa QA. O maior benefício da automação é proporcionar um retorno rápido sobre o estado da aplicação, de maneira não assistida, permitindo que a pessoa QA tenha tempo e espaço suficientes para focar em testes exploratórios. Aqui, o papel da pessoa QA é tanto de participar da automação quanto de ser coach, guiando a equipe e cuidando para que a automação seja feita em todos os níveis (dos testes unitários ao teste de interface, passando pela integração) e que a suíte de testes esteja sempre “saudável”, isto é, que haja um equilíbrio entre a quantidade de testes em cada nível, seguindo o conceito da Pirâmide de Testes, proposta por Mike Cohn. Aqui, há uma grande oportunidade de pareamento com pessoas desenvolvedoras e analistas de negócio. É importante ressaltar que um projeto de automação de testes deve ser tratado como um projeto de produto em si: necessita uma boa arquitetura e revisão periódica para que somente testes relevantes continuem a ser executados.
• Testes exploratórios – O teste exploratório contemporâneo é uma abordagem dinâmica e adaptativa que enfatiza a exploração e a descoberta. Ele se desvia dos métodos tradicionais de teste com script e incentiva os testadores a alavancar suas habilidades, conhecimento e criatividade para descobrir defeitos e obter uma compreensão mais profunda do sistema de software. Os testadores se envolvem ativamente com o software e usam suas habilidades cognitivas para pensar criticamente e analisar o comportamento do sistema. Em vez de depender apenas de scripts de teste pré definidos, essa abordagem permite que os testadores tomem decisões informadas em tempo real, escolhendo quais áreas explorar mais, quais casos de teste executar e quais riscos priorizar.
• Teste de regressão – Um bug de regressão é uma alteração indesejada para a funcionalidade existente. Quando algo que costumava funcionar corretamente deixa de funcionar, o aplicativo “regrediu” (ou foi para trás). Uma grande parte da garantia de qualidade tem a ver com a constante preocupação de manter o produto livre de bugs de regressão. Em uma equipe que está construindo uma nova aplicação, não há nenhum problema de teste de regressão até a primeira história terminar. Depois disso, a partir da segunda história, existe um risco de regressão que exige testes de regressão. É um problema constante, desde que o aplicativo esteja crescendo e mudando. Em uma equipe com uma suíte saudável de testes, encontram-se várias camadas de testes de regressão automatizados, seguindo a Pirâmide de Testes. O teste exploratório contemporâneo é fundamental para revelar bugs de regressão.
• Teste de Atributos de qualidade – Atributos de qualidade de software, também conhecidos como requisitos não funcionais ou características de qualidade, são aspectos importantes do software que são avaliados durante o teste.
  • Confiabilidade: Testar a capacidade do software de executar de forma consistente e precisa sob várias condições, incluindo tratamento de erros, tolerância a falhas e recuperação.
  • Desempenho: avaliação da capacidade de resposta, escalabilidade, taxa de transferência e eficiência do software em termos de velocidade, utilização de recursos e capacidade do sistema.
  • Usabilidade: avaliar a facilidade de uso do software, intuitividade e experiência geral do usuário, incluindo navegação, interfaces de usuário e acessibilidade.
  • Segurança: Testar a resistência do software a acessos não autorizados, vulnerabilidades, violações de dados e garantir a conformidade com os padrões de segurança.
  • Capacidade de manutenção: avaliação da facilidade de manutenção do software, incluindo legibilidade do código, modularidade e capacidade de fazer alterações ou corrigir defeitos sem introduzir novos problemas.
  • Portabilidade: Testar a capacidade do software de rodar em diferentes plataformas, sistemas operacionais e ambientes, garantindo compatibilidade e adaptabilidade.
  • Compatibilidade: avaliar a capacidade do software de interagir e funcionar perfeitamente com outros sistemas, dispositivos e componentes de software, garantindo a interoperabilidade.
  • Testabilidade: avaliar o design e a arquitetura do software para testabilidade, incluindo a facilidade de criar e executar testes, coletar dados de teste e depurar.
  • Escalabilidade: testar a capacidade do software de lidar com o aumento da carga de trabalho, carga do usuário e volume de dados sem sacrificar o desempenho ou a funcionalidade.
  • Disponibilidade: avaliar o tempo de atividade, a confiabilidade e a capacidade do software de permanecer acessível e operacional para os usuários durante interrupções ou manutenções planejadas ou não.
  • Conformidade: Testar a adesão do software aos padrões regulatórios, legais e específicos do setor, garantindo que os requisitos de conformidade sejam atendidos.
  • Eficiência: avaliando a utilização de recursos do software, incluindo memória, CPU e uso de rede, para garantir o desempenho ideal e minimizar o desperdício.
• Criação e manutenção de dados de teste – Todo mundo precisa de dados realistas para se testar e, muitas vezes, é perigoso ou ilegal usar dados comerciais reais. A pessoa QA pode ajudar a encontrar conjuntos de dados realistas ou ajudar a criá-los e, em seguida, ajudá-los a mantê-los no decorrer de um projeto.
• DevOps – Como foi mostrado na seção sobre as Práticas de Qualidade, há várias oportunidades da pessoa QA trabalhar em atividades de operações, como teste de pipeline de desenvolvimento, monitoração e observabilidade.
• Comunicação de Riscos e Defeitos – Pessoas em diferentes papéis precisam de informações diferentes sobre riscos e problemas, apresentadas de diferentes maneiras. A pessoa QA pode ajudar a mitigar os riscos com a aplicação do Risk Storming.
• Manutenção da suíte de testes automatizados – Assim como o código do projeto principal, o código da suíte de testes também demanda manutenção. A pessoa QA pode liderar essa iniciativa.

Como você pode ver, há muito o que se fazer sendo uma pessoa QA. Conforme foi dito anteriormente, a qualidade é um pacto coletivo. Embora seja responsabilidade da pessoa QA garantir que as coisas aconteçam, não é necessariamente responsabilidade dela fazer todo o trabalho!

A desvantagem de tudo isso é que é difícil dizer a alguém exatamente o que eles devem aprender em sua jornada como QA. Algumas pessoas serão colocadas em uma equipe com analistas de negócio muito experientes, uma equipe DevOps completa e Devs que escrevem testes funcionais automatizados como parte do desenvolvimento de sua história. Esses QAs podem gastar mais tempo na análise de testes, testes exploratórios e manutenção de testes.

Outros começarão em uma pequena equipe como o único QA e terão de automatizar alguns testes, enquanto ainda fazem muitos testes manualmente para garantir a qualidade do software. Algumas pessoas estarão em um projeto onde só há testes de interface e as outras camadas da Pirâmide de Testes estão faltando. Outras pessoas estarão em uma equipe de teste de API de back-end.

3. O que uma pessoa QA deve aprender?

Depois de descrever todas essas tarefas e responsabilidades de uma pessoa QA, vou propor um caminho de aprendizagem com base nos relatos de várias pessoas QAs da Thoughtworks e suas jornadas.

1. Aprenda sobre o domínio – entender os diferentes tipos de usuários, entender o que é construído e o porquê, entender como a coisa que está sendo construída é dividida em pedaços menores (épicos e histórias).
2. Compreenda os princípios básicos do teste – quais são os diferentes tipos de testes, como deve ser um testador, como aplicar testes diferentes às histórias e Critérios de Aceitação.
3. Saiba documentar um defeito – aprendendo quais informações precisam ser incluídas, como funcionam as ferramentas padrão de rastreamento de erros.
4. Aprenda mais sobre o sistema operacional – muitos dos scripts, implantação e solução de problemas mais recentes que você precisa fazer dependem da sua capacidade de entender e navegar em torno do seu sistema operacional. Você precisará entender os conceitos básicos de como os sistemas operacionais funcionam – Windows, Linux, OS X, Android, iOS – e você precisará estar confortável trabalhando na linha de comando.
5. Utilize as ferramentas para desenvolvedores dos navegadores – os navegadores mais modernos possuem ferramentas que auxiliam no desenvolvimento de produtos Web, que podem ser usadas pelas pessoas QA, tais como o Chrome Dev Tools e o Firefox Developer Tools.
6. Desenvolva habilidades básicas em planilhas (Excel e Google Sheets) – Para testar aplicativos, eles precisam ser preenchidos com dados de teste e tanto o Excel quanto o Google Sheets são ferramentas utilizadas para criar, editar e gerenciar dados de teste.
7. Compreenda como funciona Integração Contínua – Compreenda os princípios por trás da Integração Contínua. Saiba como funciona e o que é testado em que fase do pipeline.
8. Saiba usar SSH – SSH é a maneira mais comum de acessar servidores remotos e, se o aplicativo que você está testando estiver em um servidor, você precisará entender como usar SSH para ajustar as configurações e, mais importante, para examinar os arquivos de log. Saiba como lidar com keyfiles e tunelamento SSH.
9. Conheça ferramentas de Monitoração e Observabilidade – Quando você está investigando erros, você terá que descobrir quais logs procurar, como encontrar coisas nesses logs (como abrir, pesquisar, navegar), como encontrar códigos de erro e quando é apropriado trazer algo que você encontrar para um desenvolvedor. Da mesma maneira, ferramentas de Observabilidade te permitem inferir conhecimento a partir dos dados coletados.
10. Entenda os fundamentos da Web – seletores HTTP e HTML / DOM / CSS. A interação HTTP e navegador / servidor através de solicitações e respostas que são “assíncronas” ajudará qualquer pessoa que tenha algo a ver com um aplicativo da Web. Eles fornecem a base da maioria dos sistemas com os quais eles terão que trabalhar, bem como os ambientes de desenvolvimento e teste em que estarão. Isso é absolutamente crítico para a sua capacidade de interações do navegador de script.
11. Conheça alguns drivers do navegador (por exemplo, WebDriver / Selenium / Watir) – Os drivers do navegador são a maneira principal de testar automaticamente as interfaces de usuário baseadas na web.
12. Saiba os fundamentos de testes móveis – Além de emuladores e implantação de pacotes construídos para vários dispositivos, esta área fornece uma introdução natural à análise de combinações e permutações. Saiba quando repetir absolutamente tudo em cada navegador em cada dispositivo.
13. Utilize BDD – Behavior Driven Development é um estilo de desenvolvimento introduzido pelo antigo ThoughtWorker Dan North (e você achará que muitos dos frameworks mais populares para isso são criados por ThoughtWorkers atuais e anteriores!) O BDD envolve um alto grau de colaboração via Testes automatizados.
14. Ajude o time a entregar com eficiência – A pessoa QA também deve entender e auxiliar na eficiência do processo que o time utiliza para fazer as entregas. Uma pessoa QA deve compreender e ajudar a equipe com Lean Delivery.
15. Fomente workshops colaborativos – A pessoa QA também deve participar ativamente (muitas vezes ela assume o papel de facilitadora) das sessões de Lean Inception e PBB.
16. Aprenda sobre contêineres – Saber como testar Kubernetes e Docker é crucial, pois eles são essenciais para o desenvolvimento de software moderno. Docker permite a conteinerização, empacotando aplicativos com dependências para portabilidade, ao passo que Kubernetes automatiza o gerenciamento, dimensionamento e implantação de contêineres. Testar essas tecnologias garante confiabilidade, escalabilidade e desempenho. Envolve validação de conteinerização, configuração, implantação, dimensionamento, rede e segurança.
17. Conheça as tecnologias de nuvem – Organizações dependem cada vez mais de serviços de nuvem para suas necessidades de infraestrutura. AWS, Google Cloud e Microsoft Azure oferecem uma ampla variedade de serviços em nuvem, incluindo poder de computação, armazenamento, rede e várias outras ferramentas e serviços que permitem que as empresas criem, implantem e gerenciem aplicativos e serviços na nuvem.
    Testar plataformas em nuvem envolve verificar a funcionalidade dos serviços em nuvem, validar a integridade e disponibilidade dos dados, realizar testes de desempenho e escalabilidade, garantir que medidas de segurança estejam em vigor e validar integrações com outros sistemas e serviços.

Espero que tenha gostado da versão atualizada deste artigo. Talvez possamos compartilhar outras questões, ideias e recursos de aprendizagem nos comentários e possamos continuar a evoluir este conhecimento.

Marcelo Leite é consultor de Qualidade na Thoughtworks, com 18 anos de experiência. Acredita que a Qualidade é um pacto coletivo e foca o seu trabalho em ajudar as equipes a construírem produtos com qualidade, com forte ênfase em colaboração. Tem experiência em projetos em setores variados, como Petróleo, Automotivo, Siderurgia, Rede, Transporte Público, Varejo, Mídia, Jogos, Aplicativos Corporativos e Web.