O que faz uma pessoa QA?

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. Dado 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.

O QA deve, acima de tudo, garantir a qualidade; ou seja, a necessidade em qualquer projeto de garantir que o software que estamos entregando ao cliente é exatamente o que eles querem. Entretanto, os Analistas de Qualidade são os pensadores que se especializam e se apropriam da qualidade do projeto. Isso é um desafio porque todos em uma equipe são responsáveis ​​pela qualidade e, dependendo da composição da equipe, diferentes aspectos de qualidade podem ser tratadas por pessoas diferentes.

Neste artigo, Pat Sanacke descreve principalmente sobre como um analista de qualidade pode fazer seu trabalho e, como o termo “QA”, realmente deveria ser usado para Analista de Qualidade, Quality Analyst em Inglês, e não para Garantia de Qualidade, Quality Assurance em Inglês (infelizmente também reconhecido pelo acrônimo QA) .

Como Pat menciona, as QAs se especializam na qualidade do software da sua equipe. Há muito envolvido no trabalho de um controle de qualidade. Na verdade, o controle de qualidade pode parecer como o trabalho num estilo camaleão, mudando suas responsabilidades diárias à medida que a equipe aprende e cresce, e o projeto passa por mudanças.

Muitos dos outros papéis da equipe ajudarão o QA com atividades de qualidade, mas o controle de qualidade é, em última instância, responsabilidade do QA, que vai  orquestrar todos para garantir que essas tarefas sejam realizadas pelas pessoas mais adequadas para realizá-las.

O QA é responsável por entender como todas as atividades relacionadas à qualidade da equipe se encaixam. A lista abaixo parece bastante intimidante, mas lembre-se de que ninguém sabe tudo sobre tudo, e que a  equipe ágil vai ajudar o QA a aprender e fomentar os itens dessa lista!

Tarefas e responsabilidades de um QA

Seguem algumas das responsabilidades de um 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 susceptíveis de ocorrer – e onde e quando e quanto eles afetam o software. 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.  O QA faz análise de teste quando pensa num teste exploratório, quando está escrevendo casos de teste de regressão, quando está colaborando nos critérios de aceitação da história, quando está 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 – Os QAs geralmente colaboram com os desenvolvedores na estratégia geral de testes da equipe, já que muitos testes, testes funcionais de baixo nível, testes de contrato de serviço, testes de UI são feitos por desenvolvedores. É importante que os esforços de automação de teste entre os QAs e os desenvolvedores se complementem, porque, de outra forma, pode haver lacunas de cobertura que introduzam riscos ou duplicações que retardam a equipe.
  • Análise de negócios – os QAs podem ajudar (e muito) os analistas de negócios a definir critérios de sucesso para as histórias. Eles ajudam os analistas de negócio a pensar sobre como diferentes usuários podem interagir com uma solução proposta. Além disso, perguntando “como podemos testar essa história”, o QA geralmente muda a maneira como as histórias são escritas.
  • Verificação da história – Como os desenvolvedores terminam as histórias ao longo da iteração, alguém precisa testá-las cuidadosamente para garantir que elas atendam aos critérios de aceitação e às necessidades dos usuários. Se uma equipe é grande o suficiente para ter QAs, isso faz parte de seu papel. Confiamos em QAs com suas habilidades de teste: rigor e conhecimento de técnicas eficientes para encontrar erros.
  • Teste manual – Antes de escrever um teste automatizado, precisamos testar as coisas manualmente para ter uma idéia de como elas funcionam e para ter uma idéia melhor do que automatizar. Uma vez que os conjuntos de teste automatizados podem ser caros de manter (consulte a seção Manutenção de testes e Refatoração abaixo), podemos ou não decidir automatizar os testes manuais mais tarde.
  • Automação de teste – Muitos testes (especialmente testes de regressão: ver Teste de Regressão abaixo) envolvem repetidamente o clique no software como um usuário faz, e certificando-se de que tudo funciona. Isso é paradoxalmente propenso a erros E um desperdício de QA: os QAs são pessoas inteligentes e criativas e clicando nas mesmas páginas repetidas vezes não lhes dão muita oportunidade de exercer essa criatividade e inteligência. Por outro lado, fazer essas tarefas de rotina manualmente deixa uma grande chance de erro. Muitas vezes, é melhor se a maioria das funcionalidades importantes forem testadas automaticamente.
  • Testes exploratórios – é aqui que uma QA brilha. Tentando descobrir casos e combinações que os desenvolvedores não imaginaram ao escrever o código. Tentando pensar como o usuário final, e imaginar como eles usariam o software. Pensando em coisas que não estavam descritas como requisitos explícitos, mas obviamente, deveria ser parte do software. Pensando no sistema como um todo em vez de na perspectiva das histórias individuais. Os QAs provavelmente já fizeram algum desse pensamento ao ajudar a escrever as histórias, mas nada se compara em explorar o software e tentar várias coisas.
  • Teste de regressão – Uma 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 guarda contra as regressões. 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. Os desenvolvedores geralmente fornecem uma ou mais camadas de testes de regressão automatizados que são executados de forma contínua (testes de unidade, testes funcionais maiores, testes de contrato de serviço, etc.) e a equipe de QA frequentemente contribui com testes funcionais automáticos da IU, mas porque o desenvolvimento está muitas vezes à frente Automação de teste de QA, e porque testes automatizados não podem antecipar todos os problemas que podem ocorrer, geralmente há muitos testes de regressão manual para fazer. Isso envolve mais do que apenas passivamente seguindo scripts de teste. Grande parte do esforço dos testes de regressão manual é o planejamento e o design de testes e suítes, e o planejamento e coordenação de sua execução. O teste exploratório também é chave durante os testes de regressão.
  • Teste de Requisitos de Funcionalidade Cruzada – Muitos projetos precisarão de coisas como Testes de Estresse, Testes de imobilização, Teste de carga, Teste de recuperação de desastres, Teste de desempenho, Teste de penetração e outras formas de teste do sistema.
  • 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. O 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 – a maioria dos testes acontece em um “Ambiente de Teste”, o que muitas vezes significa que o QA é a primeira pessoa que tem uma necessidade real de um aplicativo implantado em funcionamento. Isso às vezes significa que o QA se torna uma pessoa DevOps para a equipe, pois eles começam a solucionar as falhas de implantação por conta própria.
  • Comunicação de Riscos e Defeitos – Pessoas em diferentes papéis precisam de informações diferentes sobre riscos e problemas, apresentadas de diferentes maneiras. O QA precisa ser o mais detalhista e preciso possível quando conversar com um desenvolvedor sobre um defeito, mas talvez seja necessário ajudar um gerente de projeto ou gerente de produto a compreender as implicações mais amplas para o usuário final ou para o cronograma de lançamento do software. E saber quando apenas registar um problema, quando levantar uma bandeira vermelha sobre o problema, e quando parar tudo até resolver o problema.
  • Liberação de tomada de decisão – O QA geralmente tem a responsabilidade de fazer, ou participar na tomada de decisões, go / no-go em Inglês, para novas funcionalidades e produtos.
  • Teste de manutenção e refatoração – como um projeto cria um conjunto de testes automátizados, este torna-se cada vez mais propenso a quebrar devido a pequenas mudanças. (Isto é chamado de “frágil”). Alguém tem que refatorar os testes para extrair código comumente usado (de modo que ele quebre em apenas um lugar em vez de centenas), e para combinar alguns testes que são duplicados e deletar testes antigos que não estão mais atendendo à sua finalidade. À medida que o tamanho do conjunto de testes automatizado cresce, a necessidade da manutenção deste conjunto de testes cresce, proporcionalmente.

Como você pode ver, é uma tonelada de coisas! Tentando fazer tudo é impossível, mas, por sorte, a qualidade é uma atividade de toda a equipe. Embora seja responsabilidade do QA garantir que as coisas aconteçam, não é necessariamente a responsabilidade deles fazer todo o trabalho!

Qualidade é uma atividade de toda a equipe!

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 Ruby com uma GUI e um bom conjunto de testes Selenium. Outras pessoas estarão em uma equipe de teste de API de back-end.

O que um QA deve aprender?

Depois de descrever todas essas tarefas e responsabilidades de um QA, vou propor um caminho de aprendizagem com base nos relatos de vários 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 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) Aprenda tudo sobre o browser – (cookies, preferências de localização, browser strings, etc.)

6) Desenvolva habilidades básicas no Excel – Para testar aplicativos, eles precisam ser preenchidos com dados de teste, e o Excel é uma ferramenta extremamente comum para criar, editar e gerenciar dados de teste. Você precisará trabalhar com grandes conjuntos sem fazer alterações um por um, então aprenda as fórmulas para fazer a edição em lote. Muitas empresas usam excel para gerenciar casos de teste também, então, quanto mais confortável você estiver com ele, mais eficiente voce será nas suas tarefas.

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 os logs – 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.

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. Conheça a técnica de teste “parwise”.

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.

Espero que isso lhe dê uma boa lista para começar. Talvez possamos compartilhar outras questões, ideias e recursos de aprendizagem nos comentários, e possamos continuar a evoluir este conhecimento (favor criar novos artigos e postagens e linkar para este).

 

Comentários no LinkedIn.

 

UA-3488176-1