Guia Completo para Analistas de Qualidade

Prévia do material em texto

Guia Completo para Analistas de
Qualidade (QA)
Índice Completo
Introdução ao Quality Assurance (QA)
O que é QA: definição detalhada e seu papel no desenvolvimento de software
Por que QA é essencial: impacto na qualidade, custo e satisfação do usuário
Diferenças entre QA, QC e Testes: explicação clara com exemplos práticos
Papéis e Responsabilidades do Analista de Qualidade
Expectativas do QA: garantir qualidade, identificar defeitos e atender requisitos
Competências técnicas: ferramentas, metodologias e tipos de testes
Competências comportamentais: comunicação, atenção aos detalhes,
colaboração
Relacionamento com stakeholders: devs, POs e usuários finais
Fundamentos de Testes de Software
Definição de teste: verificação e validação detalhadas
Diferença entre erro, defeito e falha: explicação com exemplos reais
Tipos de testes: funcionais, não funcionais, regressão, exploratórios,
automatizados — com descrição e aplicação de cada um
Os Sete Princípios do Teste
Explicação individual e detalhada de cada princípio
Exemplos práticos para cada princípio, baseados em cenários reais
Níveis de Teste
Teste de Unidade: verificar componentes individuais, com exemplos de código
Teste de Integração: verificar interações, com cenários práticos
Teste de Sistema: validar o sistema completo, com casos reais
Teste de Aceitação: confirmar requisitos do usuário, com exemplos
Onde e quando aplicar cada nível: contexto e critérios
Ciclo de Vida de Teste (STLC)
Etapas detalhadas: Planejamento, Design, Execução, Registro, Reteste e
Encerramento
Artefatos de cada etapa: plano de teste, casos de teste, relatórios — com
exemplos
Técnicas de Design de Testes
Técnicas estáticas (revisões) e dinâmicas (execução): explicação e uso
Partição de equivalência: como dividir dados em classes, com exemplos
Valor limite: testando extremos, com cenários práticos
Tabela de decisão e transição de estado: aplicação detalhada
Abordagens de Testes
Manual vs Automatizado: vantagens, desvantagens e exemplos reais
Exploratório, baseado em risco, baseado em requisitos: quando e como usar
cada um
Ferramentas populares: Selenium, JUnit, Postman — com casos de uso
Boas Práticas de QA
Escrever casos de teste claros: estrutura, exemplos e dicas
Documentação e rastreabilidade: como organizar e conectar requisitos e testes
Comunicação eficaz com stakeholders: exemplos de interações
Métricas e Indicadores de Qualidade
Tipos de métricas: defeitos abertos x fechados, cobertura de testes, tempo de
resolução
Como interpretar e usar dados para melhoria contínua, com exemplos
Mentalidade e Cultura de Qualidade
Qualidade desde o início: importância e exemplos práticos
QA como agente de mudança: cases de melhoria contínua
Checklist para Onboarding de Novos QAs
Primeira semana: ferramentas, ambientes, padrões internos — com detalhes
Passo a passo para novos QAs: exemplos de tarefas iniciais
EXTRAS OPCIONAIS
Glossário de Termos Técnicos
Dúvidas Frequentes (FAQ)
Links e Recursos Úteis
Tabela de Comparação entre Ferramentas de Teste
Modelos Prontos
Curadoria de Conteúdos Recomendados
Resumo Visual
Checklist do Ciclo de Vida de Teste (STLC)
Tabela Resumo dos Tipos de Testes
Introdução ao Quality Assurance (QA)
O que é QA: definição detalhada e seu papel no desenvolvimento de
software
Quality Assurance (QA), ou Garantia de Qualidade, é um conjunto de atividades e
processos sistemáticos que garantem que um produto ou serviço atenda aos requisitos de
qualidade definidos. No contexto do desenvolvimento de software, o QA não se limita
apenas a encontrar bugs, mas abrange todo o ciclo de vida do desenvolvimento, desde a
concepção da ideia até a entrega e manutenção do produto. Seu papel principal é prevenir
defeitos, estabelecer padrões de qualidade e assegurar que o software seja robusto,
confiável e atenda às expectativas do usuário final.
Por que QA é essencial: impacto na qualidade, custo e satisfação do
usuário
A importância do QA é multifacetada. Primeiramente, ele impacta diretamente a qualidade
do produto, garantindo que o software funcione conforme o esperado, sem falhas ou
comportamentos inesperados. Em segundo lugar, o QA contribui significativamente para a
redução de custos a longo prazo. Identificar e corrigir defeitos nas fases iniciais do
desenvolvimento é exponencialmente mais barato do que fazê-lo após o lançamento do
produto, quando os custos de retrabalho e o impacto na reputação da empresa podem ser
enormes. Por fim, e talvez o mais crucial, o QA eleva a satisfação do usuário. Um software
de alta qualidade, que funciona sem problemas e atende às necessidades do usuário, gera
confiança, fidelidade e uma experiência positiva, o que é vital para o sucesso de qualquer
produto digital.
Diferenças entre QA, QC e Testes: explicação clara com exemplos práticos
É comum haver confusão entre os termos QA (Quality Assurance), QC (Quality Control) e
Testes. Embora interligados, eles representam conceitos distintos:
Quality Assurance (QA - Garantia de Qualidade): Foca na prevenção de defeitos. É
um processo proativo que estabelece e mantém os padrões de qualidade em todo o
ciclo de desenvolvimento. O QA define as metodologias, processos e ferramentas que
serão utilizados para garantir a qualidade. Por exemplo, um analista de QA pode
definir que todas as novas funcionalidades devem passar por uma revisão de código
por pares antes de serem integradas ao sistema principal.
Quality Control (QC - Controle de Qualidade): Foca na identificação de defeitos. É
um processo reativo que verifica se o produto final atende aos padrões de qualidade
definidos pelo QA. O QC é a parte do processo que inspeciona o produto para
encontrar falhas. Por exemplo, um analista de QC pode realizar uma inspeção final
em um lote de produtos manufaturados para garantir que não haja defeitos visíveis
antes do envio.
Testes: É uma atividade dentro do QC que visa encontrar defeitos no software. Os
testes envolvem a execução do software com o objetivo de identificar se ele se
comporta de maneira diferente do esperado. Por exemplo, um testador pode
executar um conjunto de casos de teste para verificar se uma funcionalidade de login
está funcionando corretamente, inserindo credenciais válidas e inválidas.
Analogia: "QA é como a rotina de manutenção preventiva de um carro — evita que os
problemas apareçam mais tarde. QC é como a inspeção veicular anual que verifica se o
carro ainda está seguro para rodar. E os Testes são como dirigir o carro em diferentes
condições para ver se ele apresenta algum problema antes da inspeção."
Papéis e Responsabilidades do Analista de Qualidade
Expectativas do QA: garantir qualidade, identificar defeitos e atender
requisitos
O analista de qualidade, ou QA, desempenha um papel crucial no ciclo de vida do
desenvolvimento de software, atuando como um defensor da qualidade em todas as
etapas. Suas principais expectativas e responsabilidades incluem:
Garantir a Qualidade do Produto: O objetivo primordial é assegurar que o software
entregue atenda aos mais altos padrões de qualidade, funcionando de forma
confiável, eficiente e segura.
Identificar Defeitos e Vulnerabilidades: Através de testes rigorosos e análises
detalhadas, o QA deve ser capaz de descobrir bugs, falhas e potenciais
vulnerabilidades antes que o produto chegue aos usuários finais.
Validar o Atendimento aos Requisitos: É responsabilidade do QA verificar se o
software foi construído de acordo com as especificações e requisitos definidos,
garantindo que as funcionalidades implementadas correspondam às necessidades
do negócio e dos usuários.
Contribuir para a Melhoria Contínua: Além de encontrar problemas, o QA deve
propor melhorias nos processos de desenvolvimento e teste, visando a otimização e
a prevenção de futuros defeitos.
Competências técnicas: ferramentas, metodologias e tipos de testes
Para cumprir suas responsabilidades, um analista de QA precisa de um conjunto robusto
de competências técnicas:
Conhecimento em Metodologias de Teste:Aceitação
(UAT)
Confirmar requisitos do
usuário
Antes do lançamento,
com usuários/POs
N/A (foco no
usuário)
Funcional Validar funcionalidades Todas as fases Selenium, Postman
Não Funcional
Avaliar desempenho,
segurança, usabilidade
Após funcionalidade
básica
JMeter, Burp Suite
Regressão
Garantir que novas mudanças
não quebraram o existente
Após cada alteração de
código
Automação
(Selenium,
Cypress)
Exploratório
Encontrar defeitos
inesperados, sem roteiro
Complementar a testes
roteirizados
N/A (abordagem
manual)
Automatizado
Executar testes repetitivos via
script
Para testes de
regressão, performance
Selenium, Cypress,
Playwright
Manual
Testar cenários complexos,
usabilidade
Para testes
exploratórios,
usabilidade
N/A (abordagem
humana)Dominar diferentes tipos de testes
(funcionais, não funcionais, regressão, exploratórios, automatizados, etc.) e saber
quando e como aplicá-los.
Ferramentas de Teste: Proficiência no uso de ferramentas para gerenciamento de
casos de teste (ex: TestLink, Zephyr), automação de testes (ex: Selenium, Cypress,
Playwright), gerenciamento de bugs (ex: Jira, Azure DevOps) e testes de API (ex:
Postman, SoapUI).
Noções de Programação: Embora não seja um desenvolvedor, ter conhecimento
básico em linguagens de programação (ex: Python, Java, JavaScript) é fundamental
para entender o código, escrever scripts de automação e colaborar efetivamente com
a equipe de desenvolvimento.
Banco de Dados: Capacidade de escrever consultas SQL para validar dados,
configurar ambientes de teste e analisar o comportamento do sistema.
Sistemas Operacionais e Redes: Compreensão de como os sistemas operacionais
funcionam e noções básicas de redes para diagnosticar problemas de conectividade
e desempenho.
Competências comportamentais: comunicação, atenção aos detalhes,
colaboração
Além das habilidades técnicas, as competências comportamentais são igualmente
importantes para um QA de sucesso:
Comunicação Eficaz: Habilidade de comunicar claramente os problemas
encontrados, o progresso dos testes e os riscos identificados, tanto para a equipe
técnica quanto para stakeholders não técnicos. Isso inclui a capacidade de escrever
relatórios de bugs concisos e compreensíveis.
Atenção aos Detalhes: Uma característica essencial para identificar pequenas
inconsistências ou falhas que podem passar despercebidas por outros.
Colaboração e Trabalho em Equipe: O QA atua como uma ponte entre diferentes
equipes (desenvolvimento, produto, negócios), sendo fundamental a capacidade de
colaborar, negociar e construir relacionamentos positivos.
Pensamento Crítico e Analítico: Habilidade de analisar situações complexas,
identificar a causa raiz dos problemas e propor soluções eficazes.
Proatividade e Curiosidade: Buscar constantemente novas formas de testar,
aprender sobre novas tecnologias e antecipar possíveis problemas.
Relacionamento com stakeholders: devs, POs e usuários finais
O analista de QA interage com diversos stakeholders ao longo do projeto:
Desenvolvedores (Devs): Colaboração próxima para entender o código, discutir a
implementação de funcionalidades, reportar e acompanhar a correção de bugs. O QA
atua como um parceiro que ajuda a equipe de desenvolvimento a entregar um
produto de maior qualidade.
Product Owners (POs) / Gerentes de Produto: Entendimento dos requisitos de
negócio, validação das funcionalidades desenvolvidas e alinhamento das
expectativas de qualidade. O QA ajuda o PO a garantir que o produto final atenda à
visão e aos objetivos do negócio.
Usuários Finais: Embora a interação direta seja menos frequente, o QA deve ter uma
mentalidade centrada no usuário, buscando entender suas necessidades e dores
para garantir que o software entregue uma experiência positiva.
Gerentes de Projeto: Fornecer atualizações sobre o status dos testes, riscos
identificados e progresso geral da qualidade do projeto.
Analogia: "O QA é o guardião da confiança — como o revisor de um livro antes da
publicação. Ele não apenas corrige erros de gramática (bugs), mas também garante que a
história faça sentido (requisitos atendidos) e que a leitura seja agradável (experiência do
usuário), trabalhando em conjunto com o autor (desenvolvedor) e o editor (PO) para
entregar a melhor obra possível aos leitores (usuários finais)."
Fundamentos de Testes de Software
Definição de teste: verificação e validação detalhadas
No universo do software, o teste é um processo investigativo que busca avaliar a
qualidade de um produto. Ele se divide em duas atividades complementares e cruciais:
verificação e validação.
Verificação: Responde à pergunta: "Estamos construindo o produto certo?". É um
processo que garante que o software atende às especificações e requisitos definidos.
A verificação é um processo mais estático, que envolve revisões de documentos,
análise de código e inspeções para garantir que o produto está sendo desenvolvido
de acordo com o planejado. Por exemplo, um analista de QA pode revisar a
documentação de requisitos para garantir que todos os critérios de aceitação de uma
nova funcionalidade estão claros e testáveis.
Validação: Responde à pergunta: "Construímos o produto certo?". É um processo
que garante que o software atende às necessidades e expectativas do usuário final. A
validação é um processo mais dinâmico, que envolve a execução do software para
verificar se ele se comporta como o esperado em um ambiente real. Por exemplo, um
testador pode executar um conjunto de casos de teste em um ambiente de
homologação para validar se a funcionalidade de carrinho de compras de um e-
commerce está funcionando corretamente do ponto de vista do usuário.
Diferença entre erro, defeito e falha: explicação com exemplos reais
Embora frequentemente usados como sinônimos, esses termos possuem significados
distintos no contexto de testes de software:
Erro: É uma ação humana que produz um resultado incorreto. Um erro é a causa raiz
de um defeito. Por exemplo, um desenvolvedor pode cometer um erro de lógica ao
escrever um algoritmo de cálculo de juros, o que pode levar a um defeito no sistema.
Defeito (ou Bug): É uma imperfeição ou deficiência em um produto de software que
faz com que ele se comporte de maneira inesperada ou contrária aos requisitos. Um
defeito é o resultado de um erro. Por exemplo, o erro de lógica do desenvolvedor
pode resultar em um defeito que faz com que o sistema calcule os juros de forma
incorreta.
Falha: É a manifestação de um defeito. Uma falha ocorre quando o software não
consegue executar uma função necessária dentro dos limites de desempenho
especificados. Por exemplo, a falha ocorre quando um cliente de um banco utiliza o
sistema e percebe que o cálculo de juros de seu empréstimo está incorreto, o que foi
causado pelo defeito no algoritmo.
Tipos de testes: funcionais, não funcionais, regressão, exploratórios,
automatizados — com descrição e aplicação de cada um
Existem diversos tipos de testes, cada um com um objetivo específico:
Testes Funcionais: Verificam se o software executa suas funções conforme
especificado nos requisitos. Eles se concentram no "o que" o sistema faz. Exemplos
incluem testes de unidade, testes de integração, testes de sistema e testes de
aceitação.
Testes Não Funcionais: Avaliam características do software que não estão
relacionadas à sua funcionalidade, como desempenho, usabilidade, segurança e
confiabilidade. Eles se concentram no "como" o sistema funciona. Exemplos incluem
testes de carga, testes de estresse, testes de usabilidade e testes de segurança.
Testes de Regressão: Garantem que as alterações recentes no código não
introduziram novos defeitos ou quebraram funcionalidades existentes. São
executados sempre que há uma modificação no software.
Testes Exploratórios: Uma abordagem de teste mais livre e criativa, onde o testador
explora o software sem um roteiro pré-definido, buscando encontrar defeitos que
não seriam descobertos por testes roteirizados. É baseado na experiência e intuição
do testador.
Testes Automatizados: Utilizam ferramentas e scripts para executar testes de forma
automática, o que é ideal para testes repetitivos, como os de regressão. A automação
aumenta a eficiência, a cobertura e a velocidade dos testes.
Analogia: "Testar um sistema é como testar um avião antes de permitir que passageiros
embarquem. Os testes funcionais garantem que os motores, os freios e os controles
funcionam como deveriam. Os testes não funcionais verificam se o avião é confortável,
seguro e consegue voar na altitude e velocidade corretas. Os testes de regressão garantem
que a troca de um pneu não afetou o sistema de freios. Os testes exploratórios são como
um piloto experiente que, além do checklist, faz uma inspeção visual extra em busca de
qualquer anomalia. E os testes automatizadossão como o piloto automático, que executa
uma série de verificações de rotina de forma rápida e precisa."
Os Sete Princípios do Teste
Os sete princípios do teste são diretrizes fundamentais que ajudam os profissionais de QA
a entender a natureza e os limites dos testes de software. Eles foram estabelecidos pelo
ISTQB (International Software Testing Qualifications Board) e são essenciais para uma
abordagem eficaz de testes.
Explicação individual e detalhada de cada princípio
�. Testes mostram a presença de defeitos, não a ausência: Este é o princípio mais
fundamental. Testar um software pode revelar que existem defeitos, mas nunca pode
provar que não há nenhum. Mesmo após testes exaustivos, sempre pode haver
defeitos não descobertos. O objetivo dos testes é reduzir a probabilidade de defeitos
não descobertos no software.
�. Testes exaustivos são impossíveis: Testar todas as combinações de entradas e pré-
condições (testes exaustivos) é inviável, exceto para os sistemas mais triviais. Em vez
disso, é necessário usar riscos e prioridades para focar os esforços de teste. A
estratégia de teste deve ser baseada em uma análise de risco do produto.
�. Testar cedo economiza tempo e dinheiro: Conhecido como o "paradoxo do teste
precoce" ou "shift-left testing", este princípio afirma que quanto mais cedo os
defeitos são encontrados no ciclo de vida do desenvolvimento, mais baratos e fáceis
eles são de corrigir. Encontrar um bug na fase de requisitos é muito mais barato do
que encontrá-lo em produção.
�. Defeitos se agrupam: Uma pequena quantidade de módulos ou funcionalidades em
um sistema geralmente contém a maioria dos defeitos descobertos. Isso é conhecido
como o "Princípio de Pareto" aplicado aos testes (��% dos defeitos são encontrados
em ��% dos módulos). Os esforços de teste devem ser concentrados nessas áreas de
maior risco.
�. Paradoxo do pesticida: Se os mesmos testes forem repetidos várias vezes, eles se
tornam ineficazes para encontrar novos defeitos. Assim como os pesticidas perdem
sua eficácia com o tempo, os testes precisam ser revisados e atualizados
regularmente, e novos testes devem ser criados para encontrar novos tipos de
defeitos.
�. Testes são dependentes do contexto: A forma como testamos um software
depende do seu contexto. Um software de controle de voo de avião será testado de
forma muito diferente de um aplicativo de e-commerce ou de um jogo mobile.
Diferentes metodologias, técnicas e tipos de teste são apropriados para diferentes
contextos.
�. A ilusão da ausência de erros: Se um sistema for testado exaustivamente e nenhum
defeito for encontrado, mas ele não atende às necessidades e expectativas do
usuário, ele ainda não é um sistema de qualidade. Encontrar e corrigir defeitos não
ajuda se o sistema for inutilizável ou não atender aos requisitos do negócio. É crucial
testar o software para garantir que ele seja útil e atenda ao propósito para o qual foi
construído.
Exemplos práticos para cada princípio, baseados em cenários reais
�. Testes mostram a presença de defeitos, não a ausência: Uma equipe de QA testou
exaustivamente um novo recurso de pagamento online e não encontrou nenhum
bug. No entanto, após o lançamento, um usuário descobriu um cenário raro onde o
pagamento falhava se ele usasse um cartão de crédito internacional específico e uma
moeda não padrão. Isso demonstra que, mesmo com testes rigorosos, a ausência
total de defeitos não pode ser garantida.
�. Testes exaustivos são impossíveis: Um aplicativo de e-commerce tem um
formulário de cadastro com �� campos, cada um com � opções de entrada. Testar
todas as combinações possíveis de entrada seria astronomicamente impossível. Em
vez disso, a equipe de QA foca nos cenários mais críticos e prováveis, como entradas
válidas, inválidas, vazias e limites.
�. Testar cedo economiza tempo e dinheiro: Durante a fase de revisão de requisitos
de um novo sistema de agendamento, o QA identificou uma ambiguidade na regra de
cancelamento de agendamentos. Corrigir essa ambiguidade neste estágio custou
apenas algumas horas de discussão. Se fosse descoberto durante os testes de
sistema, exigiria mudanças no código e nos testes, custando dias. Se fosse
descoberto em produção, poderia gerar insatisfação do cliente e perdas financeiras.
�. Defeitos se agrupam: Em um sistema bancário, a maioria dos bugs críticos foi
encontrada no módulo de transações financeiras e no módulo de integração com
sistemas externos, enquanto o módulo de relatórios teve poucos bugs. A equipe de
QA, ao perceber esse padrão, direcionou mais esforços e recursos para testar os
módulos de transações e integração nas próximas releases.
�. Paradoxo do pesticida: Uma suíte de testes automatizados para a funcionalidade de
login de um aplicativo sempre passava. No entanto, novos bugs relacionados a
sessões de usuário começaram a aparecer. A equipe de QA percebeu que os testes
existentes eram muito básicos e não cobriam cenários mais complexos, como login
simultâneo ou expiração de sessão. Eles precisaram criar novos testes e variar as
abordagens para encontrar esses novos defeitos.
�. Testes são dependentes do contexto: Uma empresa desenvolve um software para
controle de tráfego aéreo e outro para um aplicativo de delivery de comida. O
software de controle de tráfego aéreo exigirá testes de segurança e desempenho
extremamente rigorosos, com certificações e regulamentações específicas, enquanto
o aplicativo de delivery terá um foco maior em usabilidade e experiência do usuário,
com testes exploratórios e de interface.
�. A ilusão da ausência de erros: Uma equipe de desenvolvimento entregou um
sistema de gerenciamento de estoque sem nenhum bug conhecido, e todos os testes
passaram. No entanto, os usuários reclamaram que o sistema era extremamente
lento e a interface era confusa, tornando-o impraticável para o uso diário. Apesar de
não ter defeitos técnicos, o sistema falhou em atender às necessidades de
usabilidade e desempenho dos usuários, resultando em um produto de baixa
qualidade.
Analogia para cada princípio:
Testes mostram a presença de defeitos, não a ausência: "Como uma rede de pesca
que pega peixes, mas não garante que não haja mais no mar. Ela prova que há peixes,
mas não que o mar está vazio."
Testes exaustivos são impossíveis: "Como tentar ler todos os livros de uma
biblioteca infinita. Você precisa escolher os mais importantes para ler."
Testar cedo economiza tempo e dinheiro: "Como consertar um vazamento na
torneira antes que inunde a casa. É muito mais fácil e barato do que lidar com os
estragos depois."
Defeitos se agrupam: "Como em uma cidade, onde a maioria dos crimes acontece
em algumas poucas áreas. A polícia concentra seus esforços nessas áreas."
Paradoxo do pesticida: "Como um fazendeiro que usa o mesmo pesticida
repetidamente. As pragas se tornam resistentes, e ele precisa de um novo tipo de
pesticida para combatê-las."
Testes são dependentes do contexto: "Como escolher o calçado certo. Você não
usaria chuteiras para ir a um casamento, nem sapatos sociais para jogar futebol. O
calçado depende da atividade."
A ilusão da ausência de erros: "Como construir uma ponte perfeitamente sólida,
sem rachaduras ou falhas, mas que leva a lugar nenhum. A ponte é perfeita, mas
inútil."
Níveis de Teste
Os testes de software são organizados em diferentes níveis, cada um com um escopo e
objetivo específicos. Essa abordagem em camadas permite uma cobertura mais
abrangente e a identificação de defeitos em diferentes estágios do desenvolvimento.
Teste de Unidade: verificar componentes individuais, com exemplos de
código
Definição: O teste de unidade é o menor nível de teste, focado em verificar
componentes individuais do software, como funções, métodos ou classes. O objetivo
é garantir que cada unidade de código funcione corretamente de forma isolada.
Quem faz: Geralmente, os próprios desenvolvedores escrevem e executam os testes
de unidade, utilizando frameworks de teste específicos para a linguagem de
programação (ex: JUnit para Java, Pytestpara Python, Jest para JavaScript).
Exemplo de Código (Python com Pytest):
```python
arquivo: calculadora.py
def somar(a, b): return a + b
def subtrair(a, b): return a - b
arquivo: test_calculadora.py
def test_somar(): assert somar(�, �) == � assert somar(-�, �) == � assert somar(�, �) ==
�
def test_subtrair(): assert subtrair(�, �) == � assert subtrair(��, ��) == � assert
subtrair(�, �) == -� ```
Teste de Integração: verificar interações, com cenários práticos
Definição: O teste de integração verifica a interação entre diferentes unidades ou
módulos do software. O objetivo é identificar problemas que surgem quando os
componentes são combinados, como interfaces incorretas, fluxo de dados
inadequado ou falhas na comunicação entre módulos.
Quem faz: Pode ser feito por desenvolvedores ou QAs, dependendo da
complexidade e do tipo de integração (ex: integração entre frontend e backend,
integração com APIs externas).
Cenário Prático: Testar o fluxo de um aplicativo de e-commerce onde o usuário
adiciona um item ao carrinho (módulo A), o sistema calcula o frete (módulo B) e
processa o pagamento (módulo C). O teste de integração verificaria se esses módulos
se comunicam corretamente e se o fluxo completo funciona sem interrupções.
Teste de Sistema: validar o sistema completo, com casos reais
Definição: O teste de sistema avalia o sistema de software completo e integrado para
verificar se ele atende aos requisitos funcionais e não funcionais especificados. É um
teste de ponta a ponta, realizado em um ambiente que simula a produção.
Quem faz: Principalmente analistas de QA.
Casos Reais: Testar um sistema de gerenciamento de hospital, verificando se o
cadastro de pacientes, agendamento de consultas, emissão de prontuários e
faturamento funcionam em conjunto, e se o sistema é seguro e performático sob
carga.
Teste de Aceitação: confirmar requisitos do usuário, com exemplos
Definição: O teste de aceitação (UAT - User Acceptance Testing) é o nível final de teste
antes do lançamento. Ele verifica se o sistema atende às necessidades e expectativas
do usuário final e se está pronto para ser implantado em um ambiente de produção.
É focado na perspectiva do negócio.
Quem faz: Geralmente, os usuários finais, Product Owners (POs) ou stakeholders do
negócio.
Exemplos: Em um sistema bancário, os gerentes de conta testam a funcionalidade
de abertura de novas contas para garantir que o processo seja intuitivo e que todas
as regras de negócio sejam aplicadas corretamente. Em um aplicativo de delivery, os
entregadores testam o fluxo de recebimento de pedidos e atualização de status para
garantir que atenda às suas necessidades operacionais.
Onde e quando aplicar cada nível: contexto e critérios
Teste de Unidade: Realizado continuamente pelos desenvolvedores durante a fase
de codificação. É o primeiro nível de teste e deve ser executado antes de qualquer
integração.
Teste de Integração: Realizado após a conclusão dos testes de unidade, quando os
módulos são combinados. Pode ser feito de forma incremental (integrando um
módulo por vez) ou big-bang (integrando todos os módulos de uma vez).
Teste de Sistema: Realizado após a conclusão dos testes de integração, quando o
sistema está completo e estável. É feito em um ambiente que se assemelha ao
ambiente de produção.
Teste de Aceitação: Realizado após o teste de sistema, geralmente em um ambiente
de homologação, com a participação dos usuários finais ou representantes do
negócio. É a última validação antes da implantação.
Analogia: "Como construir uma casa — tijolo por tijolo (unidade), depois a estrutura
(integração), e por fim a vistoria final (aceitação). O teste de unidade é como verificar a
qualidade de cada tijolo individualmente. O teste de integração é como garantir que as
paredes e o telhado se encaixam perfeitamente. O teste de sistema é como inspecionar a
casa completa, verificando se a encanação, a eletricidade e todos os sistemas funcionam
em conjunto. E o teste de aceitação é como o futuro morador visitando a casa para
garantir que ela atende a todas as suas expectativas e necessidades antes de se mudar."
Ciclo de Vida de Teste (STLC)
O Ciclo de Vida de Teste de Software (STLC - Software Testing Life Cycle) é uma sequência
de atividades bem definidas que são executadas durante o processo de teste de software.
Ele é uma parte integrante do Ciclo de Vida de Desenvolvimento de Software (SDLC) e
garante que o processo de teste seja sistemático, eficiente e eficaz.
Etapas detalhadas: Planejamento, Design, Execução, Registro, Reteste e
Encerramento
O STLC geralmente compreende as seguintes fases:
�. Análise de Requisitos de Teste: Nesta fase, a equipe de QA analisa os requisitos do
software do ponto de vista de teste para identificar os requisitos testáveis. Isso
envolve a compreensão detalhada das funcionalidades, requisitos não funcionais e a
identificação de quaisquer ambiguidades ou lacunas. O resultado desta fase é a
criação de um documento de requisitos de teste.
�. Planejamento de Teste: Esta é a fase mais crucial do STLC. Envolve a definição da
estratégia de teste, estimativa de esforço, planejamento de recursos, definição de
cronogramas e identificação de ferramentas de teste. O plano de teste é o principal
artefato desta fase, detalhando o escopo, os objetivos, os tipos de teste a serem
realizados, os critérios de entrada e saída, e os riscos envolvidos.
�. Design de Casos de Teste: Nesta fase, os casos de teste são criados com base nos
requisitos e no plano de teste. Isso inclui a identificação de cenários de teste, a
escrita de passos detalhados para cada caso de teste, a definição de dados de teste e
a especificação dos resultados esperados. Técnicas de design de teste (como
partição de equivalência e análise de valor limite) são aplicadas aqui para criar casos
de teste eficazes e otimizados.
�. Configuração do Ambiente de Teste: Esta fase envolve a preparação do ambiente
de hardware e software onde os testes serão executados. Isso pode incluir a
instalação de sistemas operacionais, bancos de dados, servidores de aplicação e a
configuração de dados de teste. É fundamental que o ambiente de teste seja o mais
próximo possível do ambiente de produção para garantir a validade dos resultados.
�. Execução de Teste: Nesta fase, os casos de teste projetados são executados no
ambiente de teste configurado. Os testadores registram os resultados da execução
(passou, falhou, bloqueado), documentam quaisquer defeitos encontrados e os
reportam à equipe de desenvolvimento. Ferramentas de gerenciamento de teste são
frequentemente usadas para rastrear o progresso da execução.
�. Registro e Relatório de Defeitos: Quando um defeito é encontrado durante a
execução do teste, ele é registrado em um sistema de gerenciamento de defeitos (ex:
Jira, Bugzilla). O relatório de defeitos deve ser detalhado, incluindo passos para
reproduzir o bug, resultados esperados e reais, e informações sobre o ambiente de
teste. O defeito é então atribuído a um desenvolvedor para correção.
�. Reteste e Teste de Regressão: Após a correção de um defeito pelo desenvolvedor, o
QA realiza um reteste para verificar se o defeito foi realmente corrigido. Além disso,
testes de regressão são executados para garantir que a correção do defeito não
introduziu novos problemas ou afetou funcionalidades existentes.
�. Encerramento do Ciclo de Teste: Esta é a fase final do STLC. Envolve a análise dos
resultados dos testes, a preparação de relatórios de resumo de teste, a
documentação das lições aprendidas e a avaliação dos critérios de saída. O objetivo
é garantir que todos os testes planejados foram concluídos e que o software está
pronto para ser liberado.
Artefatos de cada etapa: plano de teste, casos de teste, relatórios — com
exemplos
Cada fase do STLC gera artefatos importantes que documentam o processo de teste:
Análise de Requisitos de Teste: Documento de Requisitos de Teste, Matriz de
Rastreabilidade de Requisitos.
Planejamento de Teste: Plano de Teste (documentoque descreve o escopo,
abordagem, recursos e cronograma do teste).
Design de Casos de Teste: Casos de Teste (documentos detalhados com passos,
dados de entrada e resultados esperados), Cenários de Teste.
Configuração do Ambiente de Teste: Relatório de Configuração do Ambiente de
Teste, Dados de Teste.
Execução de Teste: Relatórios de Execução de Teste, Logs de Teste.
Registro e Relatório de Defeitos: Relatórios de Defeitos (Bug Reports).
Reteste e Teste de Regressão: Relatórios de Reteste, Relatórios de Teste de
Regressão.
Encerramento do Ciclo de Teste: Relatório de Resumo de Teste, Lições Aprendidas,
Métricas de Teste.
Analogia: "Como o preparo de um prato em um restaurante — da receita (planejamento) à
entrega final ao cliente (encerramento). A análise de requisitos é como entender o que o
cliente quer comer. O planejamento é como o chef decidindo os ingredientes, o tempo de
preparo e quem vai cozinhar. O design de casos de teste é como escrever a receita
detalhada. A configuração do ambiente é como preparar a cozinha e os utensílios. A
execução é como cozinhar o prato. O registro de defeitos é como notar que o tempero está
errado e pedir para o ajudante corrigir. O reteste é como provar o prato novamente para
ver se o tempero está certo. E o encerramento é como o chef avaliando o prato final antes
de enviá-lo ao cliente e aprendendo com a experiência para futuras receitas."
Técnicas de Design de Testes
As técnicas de design de testes são métodos sistemáticos usados para criar casos de teste
eficazes e eficientes. Elas ajudam a reduzir o número de testes necessários, mantendo
uma boa cobertura e aumentando a probabilidade de encontrar defeitos.
Técnicas estáticas (revisões) e dinâmicas (execução): explicação e uso
As técnicas de teste podem ser classificadas em estáticas e dinâmicas:
Técnicas Estáticas: São métodos de teste que não envolvem a execução do código.
Elas são realizadas em artefatos de trabalho, como requisitos, design, código-fonte e
documentação. O objetivo é encontrar defeitos nas fases iniciais do ciclo de vida do
desenvolvimento. Exemplos incluem:
Revisões: Análise manual de documentos por um ou mais indivíduos para
identificar defeitos. Podem ser informais (revisão por pares) ou formais
(inspeções).
Análise Estática: Uso de ferramentas para analisar o código-fonte sem executá-
lo, buscando por vulnerabilidades, violações de padrões de codificação,
complexidade de código e outros problemas. (Ex: SonarQube).
Técnicas Dinâmicas: Envolvem a execução do software para encontrar defeitos. São
os testes que a maioria das pessoas associa ao QA. Exemplos incluem:
Testes Funcionais: Verificam se o software atende aos requisitos funcionais.
Testes Não Funcionais: Avaliam características como desempenho, segurança
e usabilidade.
Testes de Caixa Branca: Baseados na estrutura interna do código, exigindo
conhecimento da implementação.
Testes de Caixa Preta: Baseados nos requisitos e funcionalidades, sem
conhecimento da estrutura interna.
Partição de equivalência: como dividir dados em classes, com exemplos
Definição: A partição de equivalência é uma técnica de teste de caixa preta que
divide os dados de entrada em partições (classes de equivalência) onde se espera
que o comportamento do software seja o mesmo. Se um teste é válido para um valor
em uma partição, ele é considerado válido para todos os outros valores nessa mesma
partição.
Uso: Reduz o número de casos de teste, pois não é necessário testar todos os valores
possíveis. Basta selecionar um valor representativo de cada partição.
Exemplo: Um campo de idade aceita valores entre �� e �� anos.
Partições Válidas: [��-��] (ex: ��)
Partições Inválidas: (��) (ex: ��)
Casos de Teste: Testar com ��, �� e ��.
Valor limite: testando extremos, com cenários práticos
Definição: A análise de valor limite é uma técnica de teste de caixa preta que
complementa a partição de equivalência. Ela foca nos valores nas fronteiras das
partições de equivalência, pois é onde a maioria dos defeitos tende a ocorrer.
Uso: Aumenta a probabilidade de encontrar defeitos relacionados a condições de
limite.
Cenário Prático: Para o campo de idade (��-�� anos):
Valores Limite Válidos: ��, ��
Valores Limite Inválidos: �� (abaixo do mínimo), �� (acima do máximo)
Casos de Teste: Testar com ��, ��, ��, ��.
Tabela de decisão e transição de estado: aplicação detalhada
Tabela de Decisão:
Definição: Uma tabela de decisão é uma técnica que representa logicamente as
condições e as ações correspondentes de um sistema. É útil para testar
funcionalidades complexas com múltiplas condições e regras de negócio.
Aplicação Detalhada: Considere um sistema de empréstimo onde as condições
são: (�) Cliente tem bom histórico de crédito, (�) Cliente tem renda suficiente,
(�) Valor do empréstimo é menor que R$ ��.���. As ações são: (A) Aprovar
empréstimo, (B) Rejeitar empréstimo, (C) Encaminhar para análise manual.
Regra
Condição �
(Histórico
Bom)
Condição �
(Renda
Suficiente)
Condição �
(Valor Processando -> Enviado -> Entregue ou Cancelado .
Estados: Novo, Processando, Enviado, Entregue, Cancelado.
Eventos/Transições: Fazer Pedido, Processar Pagamento, Enviar Produto,
Confirmar Entrega, Cancelar Pedido.
Casos de Teste: Testar transições válidas (ex: de Novo para Processando
após pagamento) e inválidas (ex: tentar ir de Enviado para Novo ).
Analogia: "Como verificar todas as rotas possíveis em um GPS antes de escolher a melhor.
A partição de equivalência é como agrupar as ruas em categorias (ruas principais, ruas
secundárias). O valor limite é como verificar as entradas e saídas de cada rua. A tabela de
decisão é como um fluxograma que te diz qual caminho seguir com base em várias
condições de tráfego. E a transição de estado é como o GPS mudando de 'navegando' para
'chegou ao destino' com base em eventos como a sua localização."
Abordagens de Testes
As abordagens de teste referem-se às estratégias e filosofias que guiam o processo de
teste. A escolha da abordagem depende de diversos fatores, como o tipo de projeto, os
recursos disponíveis, o cronograma e os riscos envolvidos.
Manual vs Automatizado: vantagens, desvantagens e exemplos reais
Teste Manual:
Vantagens: Flexibilidade para testar cenários complexos e inesperados; ideal
para testes exploratórios e de usabilidade, onde a intuição humana é crucial;
baixo custo inicial.
Desvantagens: Demorado e propenso a erros humanos; não escalável para
grandes volumes de testes; difícil de repetir consistentemente; alto custo a
longo prazo para testes de regressão.
Exemplo Real: Um QA testa manualmente um novo fluxo de checkout em um
site de e-commerce, clicando em botões, preenchendo formulários e
verificando a experiência do usuário em diferentes navegadores.
Teste Automatizado:
Vantagens: Rapidez na execução de testes repetitivos; alta precisão e
consistência; escalabilidade para grandes suítes de testes; detecção precoce de
regressões; economia de tempo e custo a longo prazo.
Desvantagens: Alto custo inicial de implementação e manutenção; requer
habilidades de programação; menos flexível para testes exploratórios; pode
não ser adequado para todos os tipos de testes (ex: usabilidade).
Exemplo Real: Uma equipe de QA desenvolve scripts automatizados usando
Selenium para verificar se a funcionalidade de login de um aplicativo web
continua funcionando corretamente após cada nova implantação de código.
Exploratório, baseado emrisco, baseado em requisitos: quando e como
usar cada um
Teste Exploratório:
Quando usar: Quando os requisitos não são totalmente claros, em projetos
ágeis, para complementar testes roteirizados, ou para encontrar defeitos
inesperados.
Como usar: O testador explora o software em tempo real, projetando e
executando testes simultaneamente, usando sua intuição e experiência para
descobrir falhas. Não há roteiros de teste pré-definidos.
Teste Baseado em Risco:
Quando usar: Em projetos com tempo e recursos limitados, onde é preciso
priorizar os testes. Foca nas áreas do sistema que têm maior probabilidade de
falhar ou que teriam o maior impacto se falhassem.
Como usar: Identificar os riscos do projeto e do produto, avaliar a
probabilidade e o impacto de cada risco, e então priorizar os testes nas áreas de
maior risco. Por exemplo, em um sistema bancário, o módulo de transações
financeiras teria maior prioridade de teste do que o módulo de relatórios.
Teste Baseado em Requisitos:
Quando usar: Quando os requisitos são bem definidos e documentados.
Garante que cada requisito funcional e não funcional seja testado e validado.
Como usar: Criar casos de teste diretamente a partir dos requisitos, utilizando
uma matriz de rastreabilidade para garantir que todos os requisitos sejam
cobertos. É uma abordagem mais formal e estruturada.
Ferramentas populares: Selenium, JUnit, Postman — com casos de uso
Selenium: Uma suíte de ferramentas para automação de testes de aplicações web.
Permite simular interações do usuário com o navegador (cliques, preenchimento de
formulários, navegação).
Caso de Uso: Automatizar testes de regressão para um portal de notícias,
verificando se a navegação, busca e exibição de artigos funcionam
corretamente em diferentes navegadores.
JUnit (e similares como Pytest, NUnit, TestNG): Frameworks de teste de unidade
para diversas linguagens de programação. Permitem que os desenvolvedores
escrevam e executem testes automatizados para unidades de código.
Caso de Uso: Um desenvolvedor usa JUnit para testar se um método que
calcula o imposto sobre vendas está retornando o valor correto para diferentes
entradas.
Postman: Uma ferramenta popular para testar APIs (Application Programming
Interfaces). Permite enviar requisições HTTP/S e inspecionar as respostas.
Caso de Uso: Um QA usa Postman para testar a API de um serviço de
autenticação, verificando se o endpoint de login retorna um token de acesso
válido para credenciais corretas e um erro para credenciais inválidas.
Analogia: "Manual é como costurar à mão, automatizado é como usar uma máquina de
costura industrial. A costura à mão é flexível e permite detalhes únicos (exploratório), mas
é lenta para grandes volumes. A máquina industrial é rápida e consistente para produção
em massa (regressão automatizada), mas menos adaptável a designs complexos. A
escolha depende do que você precisa costurar."
Boas Práticas de QA
Adotar boas práticas é fundamental para a eficácia do trabalho de um analista de QA,
garantindo não apenas a qualidade do produto, mas também a eficiência do processo de
desenvolvimento como um todo.
Escrever casos de teste claros: estrutura, exemplos e dicas
Casos de teste bem escritos são a espinha dorsal de um processo de teste eficaz. Eles
devem ser claros, concisos e fáceis de entender e executar por qualquer pessoa da equipe.
Estrutura de um Caso de Teste:
ID do Caso de Teste: Identificador único (ex: TC_LOGIN_���).
Título/Nome: Descrição breve e clara do que está sendo testado (ex: "Verificar
login com credenciais válidas").
Pré-condições: Condições que devem ser atendidas antes da execução do teste
(ex: "Usuário cadastrado e com conta ativa").
Passos de Execução: Sequência detalhada de ações a serem realizadas (ex: "�.
Abrir navegador e acessar URL de login; �. Inserir 'usuario@teste.com' no
campo de e-mail; �. Inserir 'senha���' no campo de senha; �. Clicar no botão
'Entrar'").
Resultado Esperado: O que o sistema deve fazer ou exibir após a execução dos
passos (ex: "Usuário é redirecionado para a página inicial e exibe mensagem de
boas-vindas").
Pós-condições (Opcional): Estado do sistema após a execução do teste (ex:
"Usuário logado").
Dicas para Escrever Casos de Teste Claros:
Seja Específico: Evite termos vagos. Em vez de "verificar se funciona", diga
"verificar se o botão X redireciona para a página Y".
Um Objetivo por Caso de Teste: Cada caso de teste deve focar em testar uma
única funcionalidade ou cenário.
Linguagem Simples e Direta: Use verbos de ação e evite jargões
desnecessários.
Dados de Teste Claros: Especifique quais dados devem ser usados (ex:
"usuário: admin, senha: ���").
Revisão: Peça para outro QA revisar seus casos de teste para garantir clareza e
cobertura.
Documentação e rastreabilidade: como organizar e conectar requisitos e
testes
A documentação adequada e a rastreabilidade são cruciais para manter a organização,
facilitar a manutenção e garantir que todos os requisitos sejam cobertos pelos testes.
Matriz de Rastreabilidade de Requisitos (RTM - Requirements Traceability
Matrix): Uma ferramenta que mapeia os requisitos do sistema para os casos de teste
correspondentes. Isso garante que cada requisito tenha pelo menos um caso de teste
associado e ajuda a identificar lacunas na cobertura.
ID
Requisito
Descrição Requisito
ID Caso de
Teste
Status do
Teste
REQ_���
O sistema deve permitir o login de usuários
cadastrados.
TC_LOGIN_��� Passou
REQ_���
O sistema deve exibir uma mensagem de
erro para credenciais inválidas.
TC_LOGIN_��� Passou
Gerenciamento de Casos de Teste: Utilizar ferramentas (ex: TestLink, Zephyr, Azure
Test Plans) para organizar, armazenar e gerenciar os casos de teste, facilitando a
execução, o acompanhamento e a geração de relatórios.
Relatórios de Bugs Detalhados: Ao encontrar um defeito, o relatório de bug deve
ser o mais completo possível, incluindo:
Título claro e conciso.
Passos para reproduzir o bug.
Resultado esperado vs. Resultado real.
Evidências (screenshots, logs).
Informações do ambiente (navegador, SO, versão do software).
Prioridade e severidade.
Comunicação eficaz com stakeholders: exemplos de interações
A comunicação é uma das habilidades mais importantes para um QA. Ser capaz de
transmitir informações de forma clara e construtiva para diferentes públicos é essencial.
Com Desenvolvedores:
Ao reportar um bug: "Olá [Nome do Dev], encontrei um bug no módulo de
cadastro de usuários. Ao tentar cadastrar um usuário com e-mail já existente, o
sistema não exibe a mensagem de erro esperada e permite o cadastro. Os
passos para reproduzir estão no Jira [link do bug]. Poderia verificar, por favor?"
Ao discutir uma funcionalidade: "[Nome do Dev], sobre a nova funcionalidade
de busca, pensei em um cenário onde o usuário digita caracteres especiais.
Como o sistema deve se comportar nesse caso? Isso está coberto na
implementação?"
Com Product Owners (POs):
Ao esclarecer um requisito: "[Nome do PO], sobre o requisito de cálculo de
frete, para entregas internacionais, o valor deve ser fixo ou variável por região?
Precisamos definir isso para criar os casos de teste."
Ao apresentar o status dos testes: "[Nome do PO], concluímos ��% dos testes
funcionais da nova release. Encontramos � bugs críticos que estão sendo
corrigidos. A funcionalidade X está com ���% de cobertura e funcionando
conforme o esperado."
Com Gerentes de Projeto:
Ao reportar riscos: "[Nome do Gerente], identificamos um alto risco de atraso
na entrega do módulo de relatórios devido à complexidade das integrações e à
quantidade de bugs encontrados. Sugiro realocar mais recursos para essa área
ou ajustar o cronograma."
Analogia: "Como seguir uma receita passo a passo para que qualquer pessoa consiga
repetir o prato. Os casos de teste são a receita. A documentação e rastreabilidade são o
livro de receitas organizado, com índice e referências cruzadas. E a comunicação eficaz é
como o chef explicando a receita para a equipe da cozinha e para o cliente, garantindoque
todos entendam o que está sendo feito e o que esperar."
Métricas e Indicadores de Qualidade
Métricas e indicadores de qualidade são ferramentas essenciais para que os analistas de
QA possam medir, monitorar e melhorar o processo de teste e a qualidade do produto.
Eles fornecem dados objetivos para tomadas de decisão e comunicação com stakeholders.
Tipos de métricas: defeitos abertos x fechados, cobertura de testes,
tempo de resolução
Existem diversas métricas que podem ser utilizadas, cada uma fornecendo uma
perspectiva diferente sobre a qualidade:
Métricas de Defeitos:
Número Total de Defeitos Encontrados: Quantidade bruta de bugs
identificados.
Defeitos Abertos vs. Fechados: Proporção de bugs que ainda precisam ser
corrigidos versus os que já foram resolvidos e verificados. Um alto número de
defeitos abertos pode indicar gargalos no processo de desenvolvimento ou
problemas de qualidade.
Densidade de Defeitos: Número de defeitos por unidade de tamanho do
software (ex: defeitos por mil linhas de código, defeitos por ponto de função).
Ajuda a identificar módulos mais problemáticos.
Severidade e Prioridade dos Defeitos: Classificação dos bugs com base no
impacto (severidade: crítico, maior, médio, menor) e na urgência de correção
(prioridade: alta, média, baixa). Permite focar nos problemas mais importantes.
Métricas de Cobertura:
Cobertura de Testes: Percentual de código, requisitos ou funcionalidades que
foram cobertos pelos testes. Pode ser cobertura de código (linhas, branches,
funções), cobertura de requisitos (quantos requisitos foram testados) ou
cobertura de casos de teste (quantos casos de teste foram executados).
Cobertura de Automação: Percentual de casos de teste que são
automatizados. Indica a maturidade da automação de testes.
Métricas de Eficiência do Teste:
Tempo Médio para Encontrar um Defeito (MTTD - Mean Time To Detect):
Tempo médio que leva para um defeito ser identificado após sua introdução.
Um MTTD baixo indica um processo de teste eficiente.
Tempo Médio para Resolver um Defeito (MTTR - Mean Time To Resolve):
Tempo médio que leva para um defeito ser corrigido e verificado após ser
encontrado. Um MTTR baixo indica eficiência na correção de bugs.
Produtividade do Teste: Número de casos de teste executados por
dia/semana, ou número de defeitos encontrados por testador.
Como interpretar e usar dados para melhoria contínua, com exemplos
As métricas não são apenas números; elas devem ser interpretadas e usadas para
impulsionar a melhoria contínua:
Identificar Tendências: Monitorar as métricas ao longo do tempo para identificar
padrões. Por exemplo, se o número de defeitos abertos está constantemente alto,
pode indicar que a equipe de desenvolvimento está sobrecarregada ou que há
problemas na qualidade do código.
Tomada de Decisão: Usar os dados para tomar decisões informadas. Se a cobertura
de testes está baixa em um módulo crítico, pode ser necessário alocar mais recursos
para testes nessa área.
Comunicação com Stakeholders: Apresentar as métricas de forma clara e visual
para gerentes e outras equipes. Por exemplo, um gráfico mostrando a evolução de
defeitos abertos e fechados pode demonstrar o progresso da qualidade do produto.
Otimização de Processos: Se o MTTR for alto, pode indicar que o processo de
comunicação entre QA e desenvolvimento precisa ser otimizado, ou que as correções
estão demorando muito.
Previsão de Qualidade: Com base em dados históricos, é possível prever a
qualidade futura do software e identificar riscos potenciais.
Exemplo Prático: Se o gráfico de defeitos abertos mostra um pico após uma nova
funcionalidade ser implementada, isso pode indicar que a funcionalidade foi mal
desenvolvida ou que os testes iniciais foram insuficientes. A equipe pode então investigar
a causa raiz e implementar ações corretivas, como revisões de código mais rigorosas ou
mais testes de unidade para futuras funcionalidades.
Analogia: "Assim como um velocímetro mostra se o carro está rápido demais, as métricas
mostram se o processo está sob controle. O nível de combustível indica se você precisa
abastecer (cobertura de testes), e a luz de advertência do motor indica um problema sério
que precisa ser resolvido (defeitos críticos)."
Mentalidade e Cultura de Qualidade
A qualidade de um produto de software não é responsabilidade exclusiva da equipe de QA;
ela é o resultado de uma mentalidade e cultura que permeiam toda a organização.
Promover uma cultura de qualidade significa que todos os envolvidos no ciclo de vida do
desenvolvimento de software são responsáveis por garantir que o produto final atenda
aos mais altos padrões.
Qualidade desde o início: importância e exemplos práticos
O conceito de "qualidade desde o início" (Quality by Design ou Shift-Left Testing) enfatiza a
importância de incorporar a qualidade em todas as fases do desenvolvimento, desde a
concepção da ideia até a entrega. Isso contrasta com a abordagem tradicional de "testar a
qualidade no final", que geralmente resulta em custos mais altos e maior dificuldade para
corrigir defeitos.
Importância:
Redução de Custos: Encontrar e corrigir defeitos nas fases iniciais é
significativamente mais barato do que fazê-lo em estágios avançados ou após o
lançamento.
Melhoria da Eficiência: Evita retrabalho e otimiza o fluxo de trabalho,
permitindo que as equipes se concentrem em novas funcionalidades em vez de
corrigir problemas antigos.
Maior Satisfação do Cliente: Produtos de maior qualidade resultam em
usuários mais satisfeitos e leais.
Aumento da Confiança: A equipe se sente mais confiante no produto que está
entregando.
Exemplos Práticos:
Revisão de Requisitos: QAs e desenvolvedores participam ativamente da
revisão dos requisitos para identificar ambiguidades, inconsistências ou
lacunas antes que o código seja escrito.
Testes de Unidade e Integração Contínuos: Desenvolvedores escrevem testes
de unidade para seu próprio código e os executam continuamente. Testes de
integração são realizados assim que os módulos são combinados.
Pair Programming e Code Review: Desenvolvedores trabalham em pares ou
revisam o código uns dos outros para identificar defeitos e garantir a
conformidade com os padrões de codificação.
Automação de Testes: Implementar automação de testes desde o início para
garantir que as funcionalidades existentes não sejam quebradas por novas
alterações (testes de regressão automatizados).
Ambientes de Desenvolvimento e Teste Consistentes: Garantir que os
ambientes de desenvolvimento, teste e produção sejam o mais semelhantes
possível para evitar problemas de "funciona na minha máquina".
QA como agente de mudança: cases de melhoria contínua
O analista de QA não deve ser apenas um "caçador de bugs", mas um agente de mudança
que impulsiona a melhoria contínua dos processos e da qualidade do produto. Isso
envolve uma postura proativa, colaborativa e analítica.
Cases de Melhoria Contínua:
Implementação de Automação: Um QA identifica que a execução manual de
testes de regressão está consumindo muito tempo e propondo a
implementação de uma suíte de testes automatizados, demonstrando o ROI
(Retorno sobre Investimento) e liderando a iniciativa.
Otimização do Processo de Reporte de Bugs: Percebendo que os bugs estão
sendo reportados de forma inconsistente, o QA propõe um novo template de
reporte, treina a equipe e monitora a adesão, resultando em relatórios mais
claros e um ciclo de correção mais rápido.
Sessões de Teste Exploratório: Organizar sessões regulares de teste
exploratório com a equipe de desenvolvimento para que todos entendam
melhor o produto e contribuam para a identificação de problemas.
Feedback Contínuo: Fornecer feedback construtivo aos desenvolvedores sobre
a qualidade do código e as práticas de desenvolvimento, ajudando-os a
escrever um código mais testável e robusto.
Definição de Critérios de Aceitação: Trabalhar em conjunto com o Product
Owner para definir critérios de aceitação claros e testáveis para cada
funcionalidade, garantindo que todos tenhama mesma compreensão do que
significa "pronto".
Analogia: "Como um jardineiro que cuida das plantas todos os dias, não só quando elas
adoecem. Ele prepara o solo (requisitos), planta as sementes (desenvolvimento), rega e
aduba (testes contínuos), e poda quando necessário (correção de bugs), garantindo que o
jardim (software) floresça de forma saudável e sustentável."
Checklist para Onboarding de Novos QAs
Um processo de onboarding bem estruturado é fundamental para integrar novos analistas
de QA à equipe de forma eficiente, garantindo que eles se tornem produtivos rapidamente
e compreendam a cultura e os processos da empresa.
Primeira semana: ferramentas, ambientes, padrões internos — com
detalhes
Durante a primeira semana, o foco deve ser na familiarização com o ambiente de trabalho,
as ferramentas e os processos básicos:
Dia �: Boas-vindas e Introdução Geral
Apresentação à equipe (desenvolvedores, POs, outros QAs).
Visão geral da empresa, sua missão, valores e cultura.
Explicação do papel do QA na organização e como ele se encaixa no ciclo de
desenvolvimento.
Configuração do ambiente de trabalho (computador, acessos, e-mail,
ferramentas de comunicação).
Dia �: Ferramentas Essenciais
Introdução às ferramentas de gerenciamento de projetos (ex: Jira, Trello) e
como a equipe as utiliza.
Apresentação da ferramenta de gerenciamento de casos de teste (ex: TestLink,
Zephyr) e como os casos de teste são estruturados e executados.
Explicação do sistema de controle de versão (ex: Git) e como acessar o código-
fonte (mesmo que não vá codificar, é importante saber onde está).
Configuração de ferramentas de comunicação (ex: Slack, Microsoft Teams).
Dia �: Ambientes de Teste e Documentação
Visão geral dos diferentes ambientes de teste (desenvolvimento, homologação,
produção) e seus propósitos.
Como acessar e configurar o ambiente de teste local (se aplicável).
Onde encontrar a documentação do projeto (requisitos, especificações,
diagramas de arquitetura).
Explicação dos padrões de documentação de bugs e casos de teste da equipe.
Dia �: Processos de Teste e Ciclo de Vida
Revisão detalhada do Ciclo de Vida de Teste de Software (STLC) da empresa.
Explicação do fluxo de trabalho de bugs: como reportar, acompanhar e verificar
correções.
Participação em uma reunião de planejamento ou daily stand-up para entender
a dinâmica da equipe.
Introdução às métricas de qualidade que a equipe acompanha.
Dia �: Primeiro Teste e Feedback
Atribuição de uma tarefa de teste simples e guiada (ex: testar uma
funcionalidade pequena e estável).
Acompanhamento e feedback sobre o primeiro reporte de bug ou execução de
caso de teste.
Sessão de perguntas e respostas para esclarecer dúvidas da semana.
Passo a passo para novos QAs: exemplos de tarefas iniciais
Após a primeira semana, o novo QA pode começar a assumir tarefas mais independentes,
sempre com acompanhamento:
�. Familiarização com o Produto: Passar um tempo explorando o software como um
usuário final, entendendo suas funcionalidades principais e fluxos de uso.
�. Execução de Casos de Teste Existentes: Começar executando casos de teste já
documentados para funcionalidades conhecidas. Isso ajuda a entender o
comportamento esperado do sistema e a familiarizar-se com a ferramenta de
gerenciamento de testes.
�. Reporte de Bugs: Praticar o reporte de bugs, garantindo que todas as informações
necessárias (passos para reproduzir, evidências, ambiente) estejam presentes.
�. Participação em Code Reviews (Opcional, mas Recomendado): Mesmo sem
conhecimento aprofundado em código, participar de code reviews pode ajudar a
entender a arquitetura do sistema e a lógica de negócio.
�. Testes Exploratórios Guiados: Realizar sessões de teste exploratório em
funcionalidades específicas, com um objetivo claro (ex: "explorar a funcionalidade de
busca por �� minutos, focando em cenários de erro").
�. Criação de Casos de Teste Simples: Começar a escrever casos de teste para
funcionalidades pequenas ou para cenários de erro, aplicando as técnicas de design
de teste aprendidas.
�. Participação Ativa em Reuniões: Contribuir com perguntas e insights nas reuniões
de equipe, demonstrando interesse e proatividade.
Analogia: "Como preparar um novo piloto para voar com segurança. A primeira semana é
como o treinamento em simulador, onde ele aprende os controles e os procedimentos
básicos. Os passos a passo são como os primeiros voos supervisionados, onde ele aplica o
que aprendeu em cenários reais, ganhando confiança e experiência sob a orientação de
um instrutor experiente."
EXTRAS OPCIONAIS
Para complementar este guia, apresentamos seções adicionais que podem enriquecer
ainda mais o conhecimento e a prática de analistas de QA.
Glossário de Termos Técnicos
Bug: Um erro, falha ou defeito em um programa de computador que causa um
resultado incorreto ou inesperado, ou faz com que ele se comporte de maneira
diferente do que foi planejado.
Defeito: Sinônimo de bug. Uma imperfeição ou deficiência em um componente ou
sistema que pode causar uma falha.
Falha: A manifestação de um defeito. Ocorre quando um componente ou sistema
não consegue executar sua função requerida dentro dos limites de desempenho
especificados.
Erro: Uma ação humana que produz um resultado incorreto. É a causa raiz de um
defeito.
Regressão: O reaparecimento de um defeito que havia sido corrigido anteriormente,
ou o surgimento de novos defeitos em funcionalidades existentes devido a
alterações no código.
Caso de Teste: Um conjunto de condições e variáveis sob as quais um testador
determinará se um sistema de software está funcionando corretamente ou não.
Inclui passos de execução, dados de teste e resultado esperado.
Plano de Teste: Um documento que descreve o escopo, a abordagem, os recursos e
o cronograma das atividades de teste pretendidas. Ele identifica os itens a serem
testados, os recursos a serem empregados, as tarefas de teste a serem executadas e
os riscos associados.
Ambiente de Teste: O hardware e software configurados com dados de teste para
permitir a execução de testes.
Critérios de Aceitação: Um conjunto de condições que um sistema de software deve
satisfazer para ser aceito pelos usuários, clientes ou outras partes interessadas.
Matriz de Rastreabilidade: Um documento que mapeia e rastreia os requisitos do
usuário com os casos de teste. Ajuda a garantir que todos os requisitos sejam
cobertos pelos testes.
Automação de Testes: O uso de software para controlar a execução de testes, a
comparação de resultados reais com resultados esperados, a configuração de pré-
condições de teste e outras funções de controle de teste e relatório de teste.
Exploratório: Uma abordagem de teste onde o testador projeta e executa testes
simultaneamente, usando sua intuição e experiência para encontrar defeitos.
Mock/Stub: Objetos simulados que imitam o comportamento de objetos reais de
forma controlada, usados em testes de unidade e integração para isolar o
componente sendo testado.
API (Application Programming Interface): Um conjunto de definições e protocolos
para construir e integrar software de aplicação. Permite que diferentes sistemas se
comuniquem entre si.
CI/CD (Continuous Integration/Continuous Delivery): Um conjunto de práticas que
visa automatizar e melhorar o processo de desenvolvimento de software, desde a
integração de código até a entrega contínua em produção.
Dúvidas Frequentes (FAQ)
P: Preciso saber programar para ser um QA? R: Não é estritamente obrigatório para
todos os papéis de QA, especialmente para testes manuais. No entanto, ter noções de
programação é um diferencial enorme, especialmente para QAs que desejam atuar com
automação de testes, entender o código, ou mesmo para uma melhor comunicação com
os desenvolvedores. Conhecimentos básicos em SQL e alguma linguagem de script
(Python, JavaScript) são altamente recomendados.
P: Qual a diferença entre QA e Tester? R: O Tester (Testador) é o profissional que executa
os testes para encontrar defeitos. O QA (Quality Assurance)tem um papel mais
abrangente, focado na prevenção de defeitos e na melhoria contínua dos processos de
qualidade em todo o ciclo de desenvolvimento. O teste é uma atividade dentro do escopo
do QA.
P: Como posso me manter atualizado na área de QA? R: A área de QA está em constante
evolução. Mantenha-se atualizado lendo blogs especializados, participando de
comunidades online (fóruns, grupos de LinkedIn), seguindo influenciadores da área,
participando de webinars e conferências, e realizando cursos e certificações (como ISTQB).
P: Qual a importância dos testes não funcionais? R: Os testes não funcionais são
cruciais porque avaliam aspectos que impactam diretamente a experiência do usuário e a
viabilidade do sistema a longo prazo, como desempenho, segurança, usabilidade e
confiabilidade. Um sistema funcional, mas lento ou inseguro, não será bem-sucedido.
P: Devo automatizar todos os testes? R: Não. Nem todos os testes são bons candidatos
para automação. Testes exploratórios, testes de usabilidade e testes que mudam com
muita frequência são geralmente mais eficazes quando realizados manualmente. A
automação é ideal para testes repetitivos, de regressão e de alto volume.
Links e Recursos Úteis
Comunidades e Fóruns:
Ministry of Testing: https://www.ministryoftesting.com/ (Conteúdo, eventos e
comunidade global de testes)
Testing Community Brasil: Grupos no LinkedIn e Telegram (busque por
"Testing Community Brasil")
Blogs e Sites:
Software Testing Help: https://www.softwaretestinghelp.com/ (Artigos e
tutoriais abrangentes)
https://www.ministryoftesting.com/
https://www.softwaretestinghelp.com/
DevMedia (Seção de Testes): https://www.devmedia.com.br/cursos/testes/
(Conteúdo em português)
Certificações:
ISTQB (International Software Testing Qualifications Board):
https://www.istqb.org/ (Certificações reconhecidas globalmente)
Ferramentas:
Selenium: https://www.selenium.dev/ (Automação web)
Postman: https://www.postman.com/ (Testes de API)
Jira: https://www.atlassian.com/software/jira (Gerenciamento de projetos e
bugs)
Tabela de Comparação entre Ferramentas de Teste
Característica Selenium Cypress Playwright Postman JMeter
Tipo de Teste Web UI Web UI Web UI, API API Performance
Linguagens
Suportadas
Múltiplas
(Java,
Python, C#,
JS, etc.)
JavaScript/TypeScript
Múltiplas
(JS,
Python,
Java, C#)
N/A (GUI) N/A (GUI)
Curva de
Aprendizagem
Média/Alta Média Média Baixa Média/Alta
Execução em
Navegador
Sim (via
WebDriver)
Sim (direta)
Sim
(direta)
N/A N/A
Relatórios
Via
frameworks
de terceiros
Integrado Integrado Integrado Integrado
Integração
CI/CD
Excelente Excelente Excelente Boa Excelente
Principais
Usos
Testes de
regressão
web, cross-
browser
Testes E�E web,
testes de
componentes
Testes E�E
web, API,
mobile
web
Testes
funcionais
de API,
automação
de API
Testes de
carga,
estresse, API
https://www.devmedia.com.br/cursos/testes/
https://www.istqb.org/
https://www.selenium.dev/
https://www.postman.com/
https://www.atlassian.com/software/jira
Modelos Prontos
Para facilitar o dia a dia do QA, apresentamos exemplos simplificados de modelos que
podem ser adaptados e utilizados.
Modelo de Caso de Teste
ID do Caso de Teste: TC_LOGIN_001
Título: Verificar login de usuário com credenciais válidas
Prioridade: Alta
Severidade: Média
Pré-condições:
 - Usuário 'teste@exemplo.com' cadastrado e ativo com senha 'senha123'.
Passos de Execução:
 1. Abrir o navegador e navegar para a URL de login: [URL do Sistema]
 2. No campo 'E-mail', inserir 'teste@exemplo.com'.
 3. No campo 'Senha', inserir 'senha123'.
 4. Clicar no botão 'Entrar'.
Resultado Esperado:
 - O usuário deve ser redirecionado para a página inicial do sistema.
 - Uma mensagem de boas-vindas (ex: 'Bem-vindo, Teste!') deve ser exibida.
 - O status de login deve ser 'logado'.
Modelo de Relatório de Bug
ID do Bug: BUG-001
Título: Erro ao adicionar produto ao carrinho com quantidade zero
Status: Aberto
Prioridade: Alta
Severidade: Média
Reportado por: [Seu Nome/ID]
Data de Reporte: YYYY-MM-DD
Componente Afetado: Módulo de Carrinho de Compras
Versão do Software: 1.0.0
Ambiente: Homologação (Chrome, Windows 10)
Passos para Reproduzir:
 1. Acessar a página de detalhes de qualquer produto.
 2. No campo de quantidade, inserir '0'.
 3. Clicar no botão 'Adicionar ao Carrinho'.
Resultado Esperado:
 - O sistema deve exibir uma mensagem de erro informando que a quantidade mínima é 
1.
 - O produto NÃO deve ser adicionado ao carrinho.
Resultado Real:
 - O sistema não exibe nenhuma mensagem de erro.
 - O produto é adicionado ao carrinho com quantidade zero, causando inconsistência 
no total do pedido.
Evidências:
 - Screenshot da tela do carrinho com o produto de quantidade zero.
 - Log do console do navegador (se houver erros).
Notas:
 - Este bug pode levar a inconsistências no estoque e problemas no processamento 
de pedidos.
Modelo de Plano de Teste (Estrutura)
1. Introdução
 1.1. Propósito
 1.2. Escopo do Teste (funcionalidades a serem testadas e não testadas)
 1.3. Objetivos do Teste
2. Itens a Serem Testados
 2.1. Módulos/Funcionalidades
 2.2. Versão do Software
3. Itens a Não Serem Testados
4. Estratégia de Teste
 4.1. Tipos de Teste (funcional, não funcional, regressão, etc.)
 4.2. Abordagens de Teste (manual, automatizado, exploratório)
 4.3. Níveis de Teste (unidade, integração, sistema, aceitação)
5. Critérios de Entrada e Saída
 5.1. Critérios de Entrada (quando o teste pode começar)
 5.2. Critérios de Saída (quando o teste pode terminar)
6. Suspensão e Retomada do Teste
7. Recursos
 7.1. Pessoal (equipe de teste)
 7.2. Ferramentas (gerenciamento de teste, automação, bugs)
 7.3. Ambiente de Teste
8. Cronograma e Estimativas
9. Entregáveis do Teste
10. Riscos e Contingências
11. Aprovações
Curadoria de Conteúdos Recomendados
Livros:
"Lessons Learned in Software Testing" por Cem Kaner, James Bach, Bret
Pettichord: Um clássico que oferece insights práticos e valiosos sobre testes de
software.
"Software Testing: A Craftsman's Approach" por Paul C. Jorgensen: Aborda
técnicas de design de teste e estratégias de forma aprofundada.
"Agile Testing: A Practical Guide for Testers and Agile Teams" por Lisa
Crispin e Janet Gregory: Essencial para QAs que trabalham em ambientes ágeis.
"Testes de Software" por Ron Patton: Um guia prático e acessível para
iniciantes e profissionais experientes.
Cursos Online (Plataformas):
Udemy, Coursera, Alura, DIO: Oferecem uma vasta gama de cursos sobre
testes de software, automação, performance e segurança.
Canais do YouTube:
The Testing Show: Podcasts e discussões sobre diversos tópicos de testes.
QA Lead: Conteúdo focado em liderança e carreira em QA.
Resumo Visual
Para facilitar a fixação do conteúdo e servir como uma referência rápida, apresentamos
um resumo visual dos principais tópicos abordados neste guia.
Checklist do Ciclo de Vida de Teste (STLC)
Este checklist resume as etapas essenciais do STLC, garantindo que nenhum passo
importante seja esquecido:
[ ] Análise de Requisitos de Teste: Entender o que precisa ser testado.
[ ] Planejamento de Teste: Definir a estratégia, escopo e recursos.
[ ] Design de Casos de Teste: Criar os passos detalhados para os testes.
[ ] Configuração do Ambiente de Teste: Preparar o local para a execução dos testes.
[ ] Execução de Teste: Rodar os testes e registrar os resultados.
[ ] Registro e Relatório de Defeitos: Documentar e comunicar os bugs encontrados.
[ ] Reteste e Teste de Regressão: Verificar correções e garantir que nada foi
quebrado.
[ ] Encerramento do Ciclo de Teste: Finalizar o processo e documentar as lições
aprendidas.
Tabela Resumo dos Tipos de Testes
Tipo de Teste Objetivo Principal Quando Aplicar
Exemplo de
Ferramenta
Unidade
Verificar componentes
individuais
Durante a codificação JUnit, Pytest
Integração
Verificar interação entre
módulos
Após testes de unidade
Postman,
RestAssured
Sistema Validar o sistema completo
Após integração, antes
da aceitação
Selenium, Cypress