Guia Completo: Testes de Software

Prévia do material em texto

Guia Completo: Fundamentos de Testes
de Software e Atuação do QA
Introdução
Bem-vindo(a) ao guia completo sobre os fundamentos de testes de software e a
atuação do Quality Assurance (QA). Este material foi desenvolvido para ser um recurso
claro, prático e progressivo, ideal para quem está começando do zero na área de
qualidade de software. Nosso objetivo é proporcionar um entendimento real do papel
do QA, dos conceitos essenciais e das ferramentas utilizadas, capacitando você a atuar
com confiança e eficácia neste campo dinâmico.
No cenário atual do desenvolvimento de software, a qualidade não é apenas um
diferencial, mas uma necessidade intrínseca. Softwares bem testados garantem a
satisfação do usuário, a reputação da empresa e a minimização de custos com
correções pós-lançamento. É nesse contexto que a figura do profissional de QA se
torna indispensável, atuando como um guardião da qualidade em todas as etapas do
ciclo de vida do software.
Ao longo deste guia, exploraremos desde os conceitos mais básicos até as técnicas e
abordagens mais avançadas, sempre com exemplos práticos e analogias didáticas
para facilitar a compreensão. Prepare-se para desvendar o universo dos testes de
software e descobrir como você pode contribuir significativamente para a entrega de
produtos digitais de excelência.
�. Fundamentos de Teste ‒ Entendendo a base da
qualidade no software
Para iniciar nossa jornada, é fundamental compreender o que são os testes de
software e por que eles são tão cruciais no processo de desenvolvimento. Mais do que
apenas encontrar erros, os testes são uma atividade sistemática que visa garantir que
um produto de software atenda aos requisitos, funcione conforme o esperado e
entregue valor aos seus usuários.
O que é teste de software?
Teste de software é o processo de avaliar e verificar se um produto ou aplicativo de
software faz o que deveria fazer [�]. É uma investigação para fornecer informações
sobre a qualidade do software em relação ao contexto em que ele deve operar [�]. Em
outras palavras, é a validação de que o software está funcionando corretamente e
atendendo às expectativas e especificações definidas. Este processo envolve a
execução de um sistema ou componente sob condições controladas, observando os
resultados e comparando-os com os resultados esperados para identificar quaisquer
desvios ou falhas.
Os testes não se limitam a uma única etapa; eles são uma atividade contínua que
idealmente começa durante a fase de design e se estende até a implementação e até
mesmo após o software ser implantado em produção [�]. O objetivo principal é
identificar defeitos, falhas e erros o mais cedo possível no ciclo de desenvolvimento,
quando são mais fáceis e baratos de corrigir.
Por que o teste é necessário?
A necessidade do teste de software é inegável e multifacetada. Atrasos na entrega ou
defeitos no software podem prejudicar a reputação de uma marca, levando a clientes
frustrados e perdidos [�]. Em casos extremos, um bug ou defeito pode degradar
sistemas interconectados ou causar mau funcionamento grave, com consequências
financeiras e até mesmo de segurança [�].
Alguns dos principais motivos pelos quais o teste é necessário incluem:
Redução de riscos: Testar ajuda a identificar e mitigar riscos associados a falhas
de software, garantindo que o produto seja robusto e confiável [�].
Garantia de qualidade: O teste é um componente chave da garantia de
qualidade, assegurando que o software atenda aos padrões de desempenho,
segurança, usabilidade e funcionalidade [�].
Satisfação do cliente: Um software que funciona corretamente e atende às
expectativas do usuário resulta em maior satisfação e lealdade do cliente.
Economia de custos: Embora os testes em si custem dinheiro, as empresas
podem economizar milhões por ano em desenvolvimento e suporte se tiverem
uma boa técnica de testes e processos de controle de qualidade em vigor [�].
Quanto mais cedo os problemas são descobertos, mais barato é corrigi-los.
Melhora da reputação: A entrega consistente de software de alta qualidade
constrói uma reputação positiva para a empresa e seus produtos.
Diferença entre erro, defeito e falha
No universo dos testes de software, é comum encontrar termos como erro, defeito e
falha sendo usados de forma intercambiável. No entanto, eles possuem significados
distintos e é crucial compreendê-los para uma comunicação eficaz e uma análise
precisa dos problemas:
Erro (Mistake): Um erro é uma ação humana incorreta [�]. É uma falha cometida
por um desenvolvedor, testador ou qualquer pessoa envolvida no processo de
desenvolvimento de software. Por exemplo, um erro de lógica na codificação, um
requisito mal interpretado ou um design falho.
Defeito (Defect/Bug): Um defeito, também conhecido como bug, é a
manifestação de um erro no código ou na lógica do software [�]. É uma
imperfeição ou anomalia no sistema que pode causar um comportamento
inesperado. O defeito é a causa raiz de uma falha [�]. Por exemplo, uma linha de
código incorreta que impede uma função de operar como deveria.
Falha (Failure): Uma falha ocorre quando o software apresenta um
comportamento ou resposta diferente do esperado e especificado em seu
desenvolvimento [�]. É o resultado visível de um defeito sendo ativado durante a
execução do software. Uma falha é a manifestação externa de um erro [�]. Por
exemplo, um aplicativo que trava, uma função que não retorna o resultado
correto ou uma tela que não carrega.
Em resumo, um erro leva a um defeito, que por sua vez pode causar uma falha
durante a execução do software. A relação pode ser entendida como: Erro (causa) →
Defeito (sintoma interno) → Falha (sintoma externo).
Os � princípios dos testes de software
Os testes de software são guiados por um conjunto de princípios fundamentais que
ajudam a otimizar o processo e a maximizar a eficácia. Conhecer e aplicar esses
princípios é essencial para qualquer profissional de QA:
�. Teste demonstra a presença de defeitos, não a ausência: Os testes podem
revelar que existem defeitos no software, mas não podem provar que não há
defeitos [�]. Mesmo após testes exaustivos, é impossível garantir um software
���% livre de defeitos.
�. Teste exaustivo é impossível: Testar todas as combinações de entradas e pré-
condições é inviável, exceto para os sistemas mais triviais [�]. É necessário
priorizar e focar os esforços de teste nas áreas de maior risco.
�. Teste antecipado: As atividades de teste devem começar o mais cedo possível
no ciclo de vida do desenvolvimento de software [�]. Quanto mais cedo um
defeito é encontrado, mais barato e fácil é corrigi-lo.
�. Agrupamento de defeitos: Um pequeno número de módulos contém a maioria
dos defeitos descobertos [�]. Isso é conhecido como o Princípio de Pareto
(��/��), onde ��% dos problemas são encontrados em ��% do código. 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 na descoberta de novos defeitos [�]. É necessário revisar e
atualizar os casos de teste regularmente, adicionando novos testes para
encontrar diferentes tipos de defeitos.
�. Teste é dependente do contexto: A forma como o teste é realizado depende do
contexto do software [�]. Por exemplo, o teste de um software de segurança
crítica será diferente do teste de um aplicativo de e-commerce.
�. Ausência de erros é uma falácia: Encontrar e corrigir muitos defeitos não ajuda
se o sistema construído for inutilizável e não atender às necessidades e
expectativas do usuário [�]. Um software sem bugs, mas que não serve ao
propósito, é um fracasso.
Analogia didática: Testar software é como revisar um texto antes de
imprimir em grande escala
Imagine que você escreveu um livro e pretende imprimi-lo em milhares de cópias.
Antes de enviar para a gráfica, você não apenas lê o texto uma vez, mas o revisa
cuidadosamente várias vezes. Você verifica a gramática, a ortografia, a pontuação, a
coerência das ideias e se a mensagemdesenvolvimento-de-software/. Acesso em: � jul. ����.
[��] Accurate. Automação de Testes: O que é, por que fazer e como começar.
Disponível em: https://blog.accurate.com.br/automacao-de-testes/. Acesso em: � jul.
����.
Ciclo de Vida do Teste de Software (STLC)
O Ciclo de Vida do Teste de Software (STLC - Software Testing Life Cycle) é uma
sequência de atividades específicas executadas durante o processo de teste para
garantir a qualidade do software. Embora possa haver variações, as fases típicas do
STLC incluem:
�. Análise de Requisitos: Entender os requisitos do software do ponto de vista do
teste. Identificar os requisitos testáveis e não testáveis.
�. Planejamento de Teste: Definir a estratégia de teste, estimar o esforço, os
recursos e o cronograma. Selecionar as ferramentas de teste.
�. Desenvolvimento de Casos de Teste: Criar casos de teste detalhados, scripts de
teste e dados de teste.
�. Configuração do Ambiente de Teste: Preparar o ambiente de hardware e
software para a execução dos testes.
https://www.objective.com.br/insights/testes-funcionais/
https://www.zaptest.com/pt-br/testes-nao-funcionais-o-que-e-isso-tipos-abordagens-ferramentas-mais
https://www.zaptest.com/pt-br/testes-nao-funcionais-o-que-e-isso-tipos-abordagens-ferramentas-mais
https://www.ibm.com/br-pt/topics/test-management
https://www.ibm.com/br-pt/topics/test-management
https://www.atlassian.com/br/devops/testing-tutorials/jira-xray-integration-manage-test-cases
https://www.atlassian.com/br/devops/testing-tutorials/jira-xray-integration-manage-test-cases
https://monday.com/blog/pt/desenvolvimento/metodologias-de-desenvolvimento-de-software/
https://monday.com/blog/pt/desenvolvimento/metodologias-de-desenvolvimento-de-software/
https://blog.accurate.com.br/automacao-de-testes/
�. Execução de Teste: Executar os casos de teste, registrar os resultados e reportar
os defeitos encontrados.
�. Fechamento do Ciclo de Teste: Avaliar os critérios de saída, preparar relatórios
de teste e analisar as lições aprendidas.
Pirâmide de Testes
A Pirâmide de Testes é um conceito visual que ajuda a guiar a estratégia de teste,
sugerindo a proporção ideal de diferentes tipos de testes. A ideia principal é ter mais
testes de baixo nível (unidade) e menos testes de alto nível (interface do usuário),
devido ao custo, velocidade e feedback.está clara. Você pode até pedir para outras
pessoas lerem e darem feedback.
O que é teste de software? É essa revisão minuciosa do seu livro. Você está
verificando se o conteúdo está correto, se não há erros e se ele cumpre o
propósito de comunicar sua história ou informação de forma eficaz.
Por que é necessário? Porque se você imprimir milhares de cópias com erros, o
custo para corrigi-los será enorme (reimprimir tudo), sua reputação como autor
será prejudicada e os leitores ficarão frustrados. No software, um bug pode
custar milhões, danificar a marca e irritar os usuários.
Erro, Defeito e Falha: Se você digitou
uma palavra errada (erro), essa palavra errada é o defeito no seu texto. Se, ao ler,
alguém não entender a frase por causa dessa palavra (falha), é a manifestação do
defeito. * Os � princípios: São as melhores práticas para revisar seu livro. Por
exemplo, você não vai ler o livro inteiro de uma vez só (teste exaustivo é impossível),
mas vai focar nos capítulos mais importantes (agrupamento de defeitos) e sempre
buscar novas formas de revisar para não deixar passar nada (paradoxo do pesticida).
Assim como a revisão de um texto é vital antes da impressão em massa, o teste de
software é fundamental para garantir que o produto final seja de alta qualidade,
confiável e atenda às expectativas dos usuários.
�. O que é Quality Assurance (QA)? ‒ O guardião da
qualidade
Enquanto o teste de software se concentra na identificação de defeitos, o Quality
Assurance (QA) abrange uma perspectiva muito mais ampla. O QA é o guardião da
qualidade, um conjunto de práticas e processos que visam garantir que o produto ou
serviço atenda aos padrões de qualidade estabelecidos em todas as etapas do seu
desenvolvimento [�, �]. Não se trata apenas de encontrar bugs, mas de prevenir que
eles aconteçam.
Diferença entre teste e QA
É comum confundir os termos "teste" e "QA", mas eles representam conceitos
distintos, embora complementares:
Teste (Testing): É uma atividade específica focada na execução do software para
identificar defeitos. O testador executa casos de teste, compara os resultados
com o esperado e reporta quaisquer desvios. É uma atividade reativa, que busca
encontrar problemas no produto já desenvolvido [�, �].
Quality Assurance (QA): É um processo proativo e abrangente que visa prevenir
defeitos. O QA atua em todas as fases do ciclo de vida do desenvolvimento de
software, desde a definição dos requisitos até a entrega e manutenção. Ele
estabelece e monitora os processos, padrões e metodologias para garantir que a
qualidade seja construída no produto, e não apenas verificada ao final [�, �, �].
Em resumo, o teste é uma parte do QA. O QA define "como" a qualidade será
garantida (processos, padrões), enquanto o teste é uma das ferramentas "o que" é
feito para verificar essa qualidade (execução de casos de teste).
O que exatamente faz um QA?
O papel de um profissional de QA é multifacetado e estratégico. Ele vai muito além da
simples execução de testes. As responsabilidades de um QA podem incluir:
Definição de processos e padrões de qualidade: Estabelecer as diretrizes e
metodologias que a equipe seguirá para garantir a qualidade do software [�].
Análise de requisitos: Trabalhar com as equipes de produto e desenvolvimento
para garantir que os requisitos sejam claros, completos e testáveis, identificando
possíveis ambiguidades ou falhas desde o início [�].
Planejamento de testes: Desenvolver estratégias e planos de teste abrangentes,
definindo o escopo, os recursos necessários, os tipos de teste a serem
executados e os critérios de aceitação [�].
Criação e execução de casos de teste: Projetar, escrever e executar casos de
teste detalhados para validar as funcionalidades do software [�].
Reporte e rastreamento de defeitos: Documentar, priorizar e acompanhar os
defeitos encontrados, trabalhando em conjunto com os desenvolvedores para
garantir que sejam corrigidos [�].
Automação de testes: Desenvolver e manter scripts de automação para testes
repetitivos, aumentando a eficiência e a cobertura dos testes [�].
Monitoramento e melhoria contínua: Analisar métricas de qualidade,
identificar gargalos no processo e propor melhorias para otimizar o ciclo de
desenvolvimento e a entrega de software [�].
Comunicação e colaboração: Atuar como um elo entre as diferentes equipes
(desenvolvimento, produto, negócios), garantindo que todos estejam alinhados
com os objetivos de qualidade [�].
Papel do QA em equipes ágeis e tradicionais
O papel do QA evoluiu significativamente com a ascensão das metodologias ágeis.
Embora o objetivo final de garantir a qualidade permaneça o mesmo, a forma como o
QA atua difere em ambientes tradicionais (como o modelo Cascata) e ágeis (como
Scrum ou Kanban):
Em equipes tradicionais (Cascata):
No modelo Cascata, o QA geralmente atua em fases mais tardias do ciclo de
desenvolvimento. O processo é sequencial e linear, com fases bem definidas
(requisitos, design, desenvolvimento, teste, implantação). O QA recebe o software para
testar após a fase de desenvolvimento estar "completa".
Foco: Principalmente na detecção de defeitos no final do ciclo.
Atuação: Mais isolada, com pouca interação com desenvolvedores durante as
fases iniciais. O QA é visto como um "gatekeeper" que aprova ou rejeita o
produto antes do lançamento.
Desafios: Identificação tardia de defeitos, o que torna a correção mais cara e
demorada. Menos oportunidades para influenciar a qualidade desde o início do
projeto.
Em equipes ágeis (Scrum, Kanban):
Nas metodologias ágeis, o QA é parte integrante da equipe desde o início do projeto. A
qualidade é uma responsabilidade compartilhada por todos, e o QA atua de forma
colaborativa e contínua em ciclos curtos (sprints).
Foco: Prevenção de defeitos e garantia de qualidade contínua ao longo de todo o
ciclo de desenvolvimento.
Atuação: Colaborativa e integrada. O QA participa de reuniões de planejamento,
revisão de requisitos, discussões de design e desenvolvimento. Ele fornece
feedback contínuo e ajuda a equipe a construir a qualidade no produto desde o
primeiro dia [�].
Atividades: Além dos testes, o QA ágil atua na automação, na definição de
critérios de aceitação, na revisão de código, na exploração de funcionalidades e
na disseminação da cultura de qualidade dentro da equipe [�].
Benefícios: Detecção precoce de defeitos, redução de custos, maior agilidade na
entrega de valor e melhoria contínua do processo.
Habilidades essenciais de um bom QA
Para ser um profissional de QA de sucesso, é necessário um conjunto de habilidades
técnicas (hard skills) e comportamentais (soft skills) que vão além do conhecimento
em ferramentas de teste:
Hard Skills:
Conhecimento em metodologias de teste: Dominar diferentes tipos, níveis e
técnicas de teste.
Automação de testes: Habilidade para escrever e manter scripts de automação
utilizando ferramentas e frameworks (Selenium, Cypress, Playwright, etc.) [��].
Conhecimento em linguagens de programação: Entender o básico de
linguagens como Python, Java, JavaScript para automação e análise de código.
Banco de dados: Capacidade de escrever queries SQL para validar dados e testar
a integridade do banco de dados [��].
Ferramentas de gerenciamento de testes e bugs: Proficiência em ferramentas
como Jira, Azure DevOps, TestRail, Xray para planejar, executar e rastrear testes e
defeitos [�].
Conhecimento em APIs: Habilidade para testar APIs utilizando ferramentas
como Postman, SoapUI.
Soft Skills:
Pensamento crítico e analítico: Capacidade de analisar problemas complexos,
identificar a causa raiz e propor soluções eficazes [��].
Atenção aos detalhes: Ser minucioso na identificação de pequenas
inconsistências ou falhas que podem passar despercebidas [��].
Comunicação eficaz: Habilidade para se comunicar claramente com
desenvolvedores, gerentes de produto e outras partes interessadas, tanto na
escrita (relatórios de bugs) quanto na fala (discussões em equipe) [��].
Colaboração e trabalho em equipe: Ser capaz de trabalharde forma integrada
com a equipe de desenvolvimento, fornecendo feedback construtivo e
colaborando para a melhoria contínua.
Proatividade: Buscar ativamente por problemas, propor melhorias e antecipar
riscos.
Curiosidade e vontade de aprender: O cenário tecnológico muda rapidamente,
e um bom QA está sempre atualizado com novas ferramentas, técnicas e
tendências.
Empatia: Entender a perspectiva do usuário final para garantir que o software
atenda às suas necessidades e expectativas [��].
Analogia: QA é como o revisor de uma linha de produção, que garante
que tudo saia dentro do padrão de qualidade.
Pense em uma fábrica que produz carros. O "teste" seria o engenheiro que, ao final da
linha de montagem, liga o carro, verifica se as portas fecham, se o motor funciona, se
os faróis acendem. Ele está procurando por defeitos no produto final.
O QA, por outro lado, é o time que atua em todas as etapas da produção. Eles
garantem que:
Os materiais usados (chapa de metal, parafusos) são de alta qualidade
(prevenção de defeitos nos requisitos).
As máquinas estão calibradas corretamente (garantia de qualidade no processo
de design e desenvolvimento).
Os trabalhadores seguem os procedimentos padrão para montar cada peça
(garantia de qualidade na codificação).
Há inspeções em cada estação da linha de montagem, não apenas no final
(testes contínuos e shift-left).
Se um problema é encontrado, a causa raiz é investigada e o processo é ajustado
para que o mesmo problema não ocorra novamente (melhoria contínua).
O QA não apenas encontra o carro com defeito, mas garante que o processo de
fabricação seja tão robusto que a chance de um carro com defeito sair da linha seja
mínima. Ele é o responsável por manter o padrão de excelência em toda a linha de
produção, assegurando que o produto final não só funcione, mas seja construído com
qualidade desde o início.
�. Níveis de Teste ‒ As camadas onde o QA atua
Para garantir a qualidade de um software, os testes são realizados em diferentes
níveis, cada um com um objetivo específico e um escopo de atuação. Esses níveis
formam uma hierarquia, geralmente representados pela "Pirâmide de Testes", onde a
base é composta por testes mais granulares e a parte superior por testes mais
abrangentes. Compreender esses níveis é fundamental para planejar uma estratégia
de teste eficaz.
Teste de Unidade
O que é: O Teste de Unidade (Unit Test) é o nível mais baixo e granular de teste.
Ele se concentra em testar componentes individuais ou "unidades" do código-
fonte de forma isolada [��]. Uma unidade pode ser uma função, um método,
uma classe ou um módulo. O objetivo é verificar se cada unidade de código
funciona conforme o esperado, de acordo com sua especificação [��].
Quem faz: Geralmente, os próprios desenvolvedores são responsáveis por
escrever e executar testes de unidade, muitas vezes utilizando frameworks de
teste unitário específicos para a linguagem de programação (JUnit para Java,
Pytest para Python, Jest para JavaScript, etc.).
Quando usar: É o primeiro nível de teste a ser executado, idealmente durante o
desenvolvimento do código. Quanto mais cedo os defeitos são encontrados,
mais fácil e barato é corrigi-los.
Exemplo prático: Imagine uma função que calcula o valor total de um carrinho
de compras, somando o preço de todos os itens. Um teste de unidade verificaria
se essa função retorna o valor correto para diferentes cenários: carrinho vazio,
carrinho com um item, carrinho com vários itens, itens com desconto, etc.
Teste de Integração
O que é: O Teste de Integração (Integration Test) verifica a interação entre
diferentes módulos ou componentes do software que foram testados
individualmente no nível de unidade [��]. O objetivo é identificar falhas que
surgem da comunicação ou interface entre esses módulos, garantindo que eles
funcionem corretamente quando combinados [��].
Quem faz: Pode ser realizado por desenvolvedores ou QAs, dependendo da
complexidade e da abordagem da equipe.
Quando usar: Após os testes de unidade, quando os módulos individuais já
foram verificados e estão prontos para serem combinados.
Exemplo prático: Continuando o exemplo do carrinho de compras, o teste de
integração verificaria se a função de cálculo do total (unidade A) se comunica
corretamente com o módulo de gerenciamento de estoque (unidade B) e com o
módulo de processamento de pagamento (unidade C). Por exemplo, ao adicionar
um item ao carrinho, o estoque é atualizado? Ao finalizar a compra, o pagamento
é processado e o estoque é debitado corretamente?
Teste de Sistema
O que é: O Teste de Sistema (System Test) avalia o sistema de software completo
e integrado, verificando se ele atende aos requisitos funcionais e não funcionais
especificados [��]. Neste nível, o software é testado como um todo, em um
ambiente que simula o ambiente de produção, para garantir que todas as partes
funcionem juntas harmoniosamente e que o sistema se comporte conforme o
esperado do ponto de vista do usuário final.
Quem faz: Geralmente, equipes de QA ou testadores dedicados.
Quando usar: Após os testes de integração, quando todos os módulos foram
integrados e o sistema está funcionalmente completo.
Exemplo prático: Testar o sistema de e-commerce completo. Isso incluiria o
fluxo de ponta a ponta: desde o login do usuário, navegação pelos produtos,
adição ao carrinho, finalização da compra, processamento do pagamento, até a
confirmação do pedido e o envio de e-mails. Também seriam testados aspectos
não funcionais como desempenho (o site é rápido?), segurança (os dados do
usuário estão protegidos?) e usabilidade (é fácil navegar e comprar?).
Teste de Aceitação
O que é: O Teste de Aceitação (Acceptance Test), muitas vezes chamado de Teste
de Aceitação do Usuário (UAT - User Acceptance Testing), é a etapa final do
processo de teste antes do lançamento do software [��]. O objetivo principal é
validar se o software atende às necessidades e expectativas do cliente ou usuário
final e se está pronto para ser implantado em um ambiente de produção [��]. É
um teste de caixa-preta, onde o foco é no comportamento externo do sistema,
sem se preocupar com a estrutura interna do código.
Quem faz: Clientes, usuários finais ou representantes de negócios.
Quando usar: Após o teste de sistema, quando o software é considerado estável
e funcionalmente completo pela equipe de desenvolvimento e QA.
Exemplo prático: Os stakeholders do e-commerce (gerentes de produto, equipe
de vendas, etc.) utilizariam o sistema para realizar transações reais, simular
cenários de uso diário e verificar se o software resolve os problemas de negócio e
atende aos objetivos definidos. Eles validariam se o fluxo de compra é intuitivo,
se os relatórios de vendas estão corretos e se o sistema é fácil de usar para o
público-alvo.
Analogia: níveis de teste são como checagens em uma fábrica ‒ cada
etapa valida algo antes do produto final.
Imagine que você está construindo uma casa. Cada nível de teste representa uma fase
de verificação da qualidade:
Teste de Unidade: É como testar cada tijolo individualmente antes de começar a
construir. Você verifica se o tijolo é sólido, se tem o tamanho certo, se não está
quebrado. É a menor parte da construção.
Teste de Integração: É como verificar se as paredes (feitas de tijolos) se
encaixam corretamente com o telhado, se as tubulações se conectam com as
torneiras. Você está testando como as partes individuais interagem entre si.
Teste de Sistema: É como inspecionar a casa inteira depois de pronta. Você
verifica se a eletricidade funciona em todos os cômodos, se a água chega em
todos os banheiros, se a estrutura é segura. Você está testando a casa como um
todo, em seu funcionamento completo.
Teste de Aceitação: É como o futuro morador visitando a casa antes de se
mudar. Ele verifica se a casa atende às suas necessidades, se os quartos são do
tamanho certo, se a cozinha é funcional, se a vista é boa. Ele está validando se a
casa está pronta para ser habitada e se corresponde às suas expectativas.Cada nível de teste é crucial para garantir que a casa (ou o software) seja construída
com qualidade, desde o menor componente até o produto final, e que atenda
plenamente às necessidades de quem irá utilizá-la.
�. Abordagens de Teste ‒ Entendendo o que se
conhece (ou não) do sistema
As abordagens de teste referem-se à perspectiva que o testador adota ao realizar os
testes, especialmente em relação ao conhecimento que ele tem sobre a estrutura
interna do software. As três principais abordagens são Caixa Branca, Caixa Preta e
Caixa Cinza.
Caixa Branca (White-box)
O que é: O Teste de Caixa Branca, também conhecido como teste de caixa clara,
teste estrutural ou teste de vidro, é uma técnica que se concentra na estrutura
interna e no funcionamento do código do software [��]. O testador tem
conhecimento completo do código-fonte, da arquitetura interna, dos algoritmos
e das estruturas de dados. O objetivo é verificar o fluxo de controle, os caminhos
de execução, as condições lógicas e a cobertura do código.
Quando usar: É ideal para testes de unidade e integração, onde o acesso ao
código é fundamental. É usado para garantir que todas as partes do código sejam
executadas e que a lógica interna esteja correta.
Vantagens: Permite identificar defeitos em níveis mais baixos do código, como
erros de lógica, falhas de segurança em implementações e caminhos de código
não testados. Oferece alta cobertura de código.
Desvantagens: Requer conhecimento de programação e acesso ao código-fonte.
Pode ser demorado e caro para sistemas grandes e complexos.
Exemplo prático: Um desenvolvedor escreve testes para uma função específica,
verificando se todas as linhas de código são executadas, se os loops funcionam
corretamente para diferentes iterações e se as condições if/else cobrem todos
os cenários possíveis.
Caixa Preta (Black-box)
O que é: O Teste de Caixa Preta, também conhecido como teste funcional, é uma
técnica que se concentra no comportamento externo do software, sem qualquer
conhecimento da sua estrutura interna ou código-fonte [��]. O testador interage
com o software como um usuário final, fornecendo entradas e verificando as
saídas, com base nos requisitos e especificações. É como testar uma "caixa
preta" ‒ você não sabe o que está dentro, mas espera um comportamento
específico para determinadas entradas.
Quando usar: É amplamente utilizado em testes de sistema e aceitação, onde o
foco é validar se o software atende aos requisitos funcionais e não funcionais do
ponto de vista do usuário.
Vantagens: Não requer conhecimento de programação, pode ser realizado por
testadores não técnicos. Simula o uso real do usuário. Ajuda a identificar
problemas de usabilidade e requisitos não atendidos.
Desvantagens: Não garante a cobertura de todos os caminhos de código. Pode
deixar passar defeitos internos se o comportamento externo for o esperado.
Exemplo prático: Um testador verifica se, ao clicar no botão "Comprar" em um
site de e-commerce, o item é adicionado ao carrinho e o valor total é atualizado
corretamente, sem se preocupar com o código que executa essas ações. Ele
apenas valida a funcionalidade do ponto de vista do usuário.
Caixa Cinza (Gray-box)
O que é: O Teste de Caixa Cinza é uma combinação das abordagens de Caixa
Branca e Caixa Preta [��]. O testador possui um conhecimento parcial da
estrutura interna do software, como acesso à arquitetura de alto nível, diagramas
de fluxo de dados ou acesso a bancos de dados, mas não necessariamente ao
código-fonte completo. Esse conhecimento intermediário permite que o testador
projete casos de teste mais eficazes, focando em áreas de maior risco ou
complexidade.
Quando usar: É frequentemente utilizado em testes de integração e sistema,
onde é benéfico ter alguma visibilidade interna para otimizar os testes, mas sem
a necessidade de uma análise de código exaustiva.
Vantagens: Combina os benefícios das abordagens de caixa branca e preta.
Permite testes mais inteligentes e focados, aumentando a eficácia na detecção
de defeitos. Reduz o tempo de teste em comparação com o teste de caixa branca
puro.
Desvantagens: Requer um nível intermediário de conhecimento técnico. Pode
ser mais complexo de configurar e executar do que o teste de caixa preta.
Exemplo prático: Um testador de caixa cinza pode ter acesso aos logs do sistema
ou ao banco de dados para verificar se os dados estão sendo armazenados
corretamente após uma transação, mesmo que ele não tenha acesso ao código-
fonte que realiza a inserção dos dados. Ele usa esse conhecimento parcial para
investigar o comportamento do sistema de forma mais aprofundada.
Analogia: como investigar um problema com base no que você vê, no
que você sabe, ou nos dois.
Imagine que seu carro está com um problema e você precisa investigá-lo:
Caixa Preta: Você não sabe nada sobre mecânica. Você apenas tenta ligar o
carro, acelerar, frear e observa o que acontece. Se ele não liga, você sabe que há
um problema, mas não sabe a causa. Você está testando o carro como um
usuário final.
Caixa Branca: Você é um mecânico experiente. Você abre o capô, verifica o
motor, os fios, os fluidos, usa ferramentas de diagnóstico para analisar cada
componente interno. Você sabe exatamente como o carro funciona por dentro e
pode identificar a causa raiz do problema no nível do componente.
Caixa Cinza: Você tem um conhecimento básico de mecânica. Você pode não
saber todos os detalhes do motor, mas sabe onde fica a bateria, o óleo, os pneus.
Você pode verificar o nível do óleo, a pressão dos pneus e se a bateria está
carregada. Esse conhecimento parcial te ajuda a direcionar sua investigação e a
fazer perguntas mais inteligentes ao mecânico.
No teste de software, a escolha da abordagem depende do objetivo do teste, do nível
de acesso ao código e do conhecimento técnico disponível. Cada abordagem tem seu
valor e é utilizada em diferentes fases do ciclo de vida do software para garantir uma
cobertura abrangente e eficaz.
�. Técnicas e Estratégias de Teste ‒ Como planejar e
executar com inteligência
Para tornar o processo de teste mais eficiente e eficaz, os profissionais de QA utilizam
diversas técnicas e estratégias. Essas abordagens ajudam a projetar casos de teste que
maximizam a probabilidade de encontrar defeitos com o menor número de testes
possível, especialmente quando o teste exaustivo é inviável.
Partição de Equivalência
O que é: A Partição de Equivalência é uma técnica de teste de caixa preta que
divide os dados de entrada de um software em partições (ou classes) de
equivalência [��]. A premissa é que, se um teste encontrar um defeito em um
valor dentro de uma partição, é provável que outros valores dentro da mesma
partição também causem o mesmo defeito. Da mesma forma, se um valor não
causar um defeito, outros valores na mesma partição também não o farão.
Como funciona: Para cada condição de entrada, identificam-se as partições
válidas (dados que o sistema deve aceitar) e inválidas (dados que o sistema deve
rejeitar). Em seguida, seleciona-se apenas um valor representativo de cada
partição para criar os casos de teste, reduzindo significativamente o número
total de testes necessários.
Exemplo prático: Considere um campo de idade que aceita valores entre �� e ��
anos. As partições de equivalência seriam:
Válida: ��-�� (ex: ��)
Inválida (abaixo do limite): �� (ex: ��) Ao invés de testar todas as idades
possíveis, você testaria apenas um valor de cada partição (��, ��, ��),
cobrindo os cenários essenciais.
Análise de Valor Limite
O que é: A Análise de Valor Limite (Boundary Value Analysis - BVA) é uma técnica
de teste de caixa preta que complementa a Partição de Equivalência [��]. Ela se
baseia na observação de que os defeitos são frequentemente encontrados nos
limites das partições de equivalência. Portanto, o BVA foca em testar os valores
nos extremos de cada partição, incluindo os valores imediatamente acima e
abaixo dos limites.
Como funciona: Para cada limite de uma partição,são selecionados três valores
para teste: o valor no limite, o valor imediatamente abaixo do limite e o valor
imediatamente acima do limite.
Exemplo prático: Usando o mesmo campo de idade (�� a �� anos) do exemplo
anterior, a Análise de Valor Limite geraria os seguintes casos de teste:
Limite inferior: �� (inválido), �� (válido), �� (válido)
Limite superior: �� (válido), �� (válido), �� (inválido) Essa técnica aumenta
a probabilidade de encontrar defeitos que podem ocorrer nas transições
entre as partições.
Tabela de decisão
O que é: A Tabela de Decisão é uma técnica de teste de caixa preta que é
particularmente útil para testar sistemas com lógica complexa, onde o
comportamento do software depende de múltiplas condições [��]. Ela organiza
as condições de entrada e as ações resultantes em um formato tabular,
garantindo que todas as combinações de condições sejam consideradas e
testadas.
Como funciona: A tabela é dividida em quatro partes principais:
Condições: As diferentes entradas ou estados que afetam o
comportamento do sistema.
Regras: As combinações únicas das condições.
Ações: Os resultados ou comportamentos esperados para cada
combinação de regras.
Casos de Teste: Os cenários de teste derivados de cada regra.
Exemplo prático: Considere um sistema de login com as seguintes condições:
Usuário Válido, Senha Válida. As ações seriam: Acesso Concedido, Mensagem de
Erro.
Condição/Ação Regra � Regra � Regra � Regra �
Usuário Válido V V F F
Senha Válida V F V F
------------------- --------- --------- --------- ---------
Acesso Concedido X
Mensagem de Erro X X X
Esta tabela garante que todos os quatro cenários (Usuário Válido/Senha Válida,
Usuário Válido/Senha Inválida, Usuário Inválido/Senha Válida, Usuário Inválido/Senha
Inválida) sejam testados.
Técnica do Estado-Transição
O que é: A Técnica do Estado-Transição é uma técnica de teste de caixa preta que
modela o comportamento de um sistema em termos de seus estados e as
transições entre eles [��]. É útil para sistemas que possuem um comportamento
dinâmico, onde a saída depende não apenas da entrada atual, mas também do
estado anterior do sistema. O objetivo é testar se o sistema se move
corretamente entre os estados e se as transições são válidas.
Como funciona: Um diagrama de estados é criado para representar os diferentes
estados do sistema, os eventos que causam transições entre esses estados e as
ações que ocorrem durante as transições. Os casos de teste são então projetados
para cobrir todas as transições, sequências de estados e estados inválidos.
Exemplo prático: Considere um aplicativo de caixa eletrônico. Os estados
podem ser: "Logado", "Não Logado", "Aguardando Senha", "Transação em
Andamento". Os eventos seriam: "Inserir Cartão", "Digitar Senha", "Selecionar
Saque", "Confirmar Transação". O teste de estado-transição verificaria se, por
exemplo, após "Inserir Cartão" e "Digitar Senha" corretas, o sistema transita para
o estado "Logado" e não para um estado inválido.
Teste Exploratório
O que é: O Teste Exploratório é uma abordagem de teste simultânea de
aprendizado, design de teste e execução de teste [��]. Ao contrário dos testes
roteirizados (onde os casos de teste são pré-definidos), o teste exploratório é
mais livre e intuitivo. O testador explora o software em tempo real, usando sua
experiência e intuição para descobrir novas funcionalidades, identificar áreas de
risco e encontrar defeitos inesperados.
Quando usar: É particularmente útil quando os requisitos são incompletos, o
tempo é limitado, ou para complementar testes roteirizados, buscando cenários
que não foram previstos. É eficaz para encontrar bugs difíceis de reproduzir ou
falhas de usabilidade.
Vantagens: Flexível e adaptável. Permite a descoberta rápida de defeitos.
Estimula a criatividade do testador. Ajuda a construir um conhecimento mais
profundo do software.
Desvantagens: Pode ser difícil de documentar e reproduzir. A cobertura pode ser
inconsistente se não for bem gerenciada. Depende muito da experiência e
habilidade do testador.
Exemplo prático: Um testador recebe um novo módulo de um aplicativo e, sem
um roteiro de teste pré-definido, começa a interagir com ele, clicando em
diferentes botões, inserindo dados variados, tentando quebrar o sistema de
formas inesperadas, e registrando suas descobertas e os bugs encontrados.
Analogia: como montar um bom roteiro de viagem que prevê todos os
caminhos possíveis.
Pense em planejar uma viagem de carro para um destino desconhecido:
Partição de Equivalência: Você sabe que precisa de gasolina para a viagem. Ao
invés de encher o tanque e testar a cada litro, você pensa: "Se o tanque está
entre �/� e cheio, eu consigo chegar. Se está abaixo de �/�, não". Você testa um
valor no meio da "partição cheia" e um na "partição vazia".
Análise de Valor Limite: Você sabe que a autonomia do seu carro é de ���km.
Você testaria dirigir ���km, ���km e ���km para ver como o carro se comporta
nos limites da sua autonomia.
Tabela de Decisão: Você está decidindo qual rota pegar com base em várias
condições: "Há trânsito?", "Está chovendo?", "Há pedágios?". Você criaria uma
tabela com todas as combinações dessas condições e as ações (rotas) a serem
tomadas para cada uma.
Técnica do Estado-Transição: Seu GPS tem diferentes estados: "Procurando
Sinal", "Navegando", "Perdeu Sinal". Você testaria se, ao entrar em um túnel
(evento), o GPS muda de "Navegando" para "Perdeu Sinal" e se, ao sair, ele volta
para "Navegando".
Teste Exploratório: Você decide desviar da rota principal para explorar uma
pequena cidade que viu no mapa. Você não tem um plano detalhado, mas está
curioso para ver o que encontra. Você pode descobrir uma paisagem linda
(funcionalidade inesperada) ou uma estrada sem saída (bug).
Essas técnicas e estratégias são como ferramentas no seu kit de planejamento de
viagem. Elas permitem que você planeje sua jornada de forma inteligente, cobrindo os
cenários mais importantes e estando preparado para o inesperado, garantindo que
você chegue ao seu destino com segurança e eficiência.
�. Tipos de Teste ‒ A lente certa para cada problema
Além dos níveis e abordagens, os testes de software podem ser classificados em
diferentes tipos, cada um focado em verificar um aspecto específico do sistema. Essa
categorização ajuda a garantir que todas as dimensões da qualidade sejam
abordadas.
Testes funcionais (o que o sistema faz)
Os testes funcionais são aqueles que verificam se o software atende aos requisitos
funcionais especificados, ou seja, se ele faz o que deveria fazer [��]. Eles se
concentram nas funcionalidades do sistema, testando as ações que o usuário pode
realizar e as saídas esperadas. São testes de caixa preta, pois não se preocupam com a
estrutura interna do código, mas sim com o comportamento externo do software.
Exemplos de Testes Funcionais:
Teste de Unidade: (Já abordado) Verifica a menor parte testável do código.
Teste de Integração: (Já abordado) Verifica a comunicação entre módulos.
Teste de Sistema: (Já abordado) Verifica o sistema completo.
Teste de Aceitação: (Já abordado) Valida o software com o usuário final.
Teste de Regressão: Garante que novas alterações no código (correções de bugs,
novas funcionalidades) não introduzam novos defeitos ou causem o
reaparecimento de defeitos antigos em funcionalidades existentes [�]. É crucial
para manter a estabilidade do software ao longo do tempo.
Teste de Sanidade: Um subconjunto de testes de regressão, rápido e superficial,
para verificar se uma nova compilação do software é estável o suficiente para
prosseguir com testes mais aprofundados [�].
Teste de Fumaça (Smoke Test): Um tipo de teste de sanidade que verifica as
funcionalidades mais críticas do software para garantir que as funções básicas
funcionam. É como verificar se "há fumaça" (se o sistema está funcionando
minimamente) antes de investir em testes mais detalhados.
Testes não funcionais (como o sistema se comporta)
Os testes não funcionais avaliam como o sistema se comportasob diferentes
condições, focando em aspectos como desempenho, segurança, usabilidade,
confiabilidade, etc. [��]. Eles não se preocupam com o "o quê" o sistema faz, mas sim
com o "como" ele faz. São cruciais para garantir a experiência do usuário e a robustez
do sistema.
Exemplos de Testes Não Funcionais:
Teste de Desempenho: Avalia a velocidade, capacidade de resposta e
estabilidade de um software sob uma carga de trabalho específica. Inclui:
Teste de Carga: Mede o comportamento do sistema sob uma carga de
trabalho esperada (número de usuários, transações) para determinar se ele
pode lidar com o uso normal [�].
Teste de Estresse: Avalia a robustez do sistema testando-o além de seus
limites normais de operação, com cargas de trabalho extremas, para
verificar como ele se recupera de falhas [�].
Teste de Escalabilidade: Verifica a capacidade do sistema de lidar com um
aumento no número de usuários ou na quantidade de dados.
Teste de Segurança: Identifica vulnerabilidades no software que podem ser
exploradas por ataques maliciosos [�]. O objetivo é proteger os dados e a
funcionalidade do sistema contra acessos não autorizados, fraudes ou outros
riscos de segurança.
Teste de Usabilidade: Avalia a facilidade com que os usuários podem aprender e
operar o software para atingir seus objetivos [�]. Foca na experiência do usuário,
na intuitividade da interface e na eficiência das tarefas.
Teste de Acessibilidade: Garante que o software possa ser utilizado por pessoas
com deficiência (visuais, auditivas, motoras, cognitivas), seguindo padrões e
diretrizes de acessibilidade (WCAG).
Teste de Compatibilidade: Verifica se o software funciona corretamente em
diferentes ambientes (sistemas operacionais, navegadores, dispositivos, versões
de hardware/software).
Teste de Confiabilidade: Avalia a capacidade do software de manter seu nível de
desempenho sob condições específicas por um período de tempo. Inclui testes
de recuperação (como o sistema se recupera de falhas) e testes de robustez
(como ele lida com entradas inválidas).
Teste de Manutenibilidade: Avalia a facilidade com que o software pode ser
modificado, corrigido ou adaptado a novas funcionalidades.
Analogia: funcional é saber que o carro liga; não funcional é saber se
ele acelera bem, consome pouco e é confortável.
Voltando à analogia do carro:
Testes Funcionais: São como verificar se o carro cumpre suas funções básicas:
ele liga? As marchas engatam? O volante vira? Os freios funcionam? Você está
testando se o carro faz o que se propõe a fazer.
Testes Não Funcionais: São como verificar a experiência e o desempenho do
carro:
Desempenho: Ele acelera de � a ��� km/h em quanto tempo? Qual a
velocidade máxima? Ele consome muita gasolina (teste de carga)? Ele
aguenta uma viagem longa sem superaquecer (teste de estresse)?
Segurança: Os airbags funcionam? Os cintos de segurança são eficazes? O
sistema de freios ABS é confiável?
Usabilidade: Os controles são fáceis de alcançar e entender? Os bancos são
confortáveis? É fácil estacionar?
Acessibilidade: Pessoas com deficiência conseguem entrar e sair do carro?
Os controles são adaptáveis?
Ambos os tipos de teste são essenciais. Um carro que liga (funcional) mas não acelera
bem ou não é seguro (não funcional) não é um bom carro. Da mesma forma, um
software precisa não apenas funcionar, mas também ser rápido, seguro, fácil de usar e
confiável para ser considerado de alta qualidade.
�. Gerenciamento de Testes ‒ Controlando tudo que
está sendo validado
O gerenciamento de testes é a prática de planejar, monitorar e controlar as atividades
de teste ao longo do ciclo de vida do desenvolvimento de software [��]. É uma
disciplina crucial para garantir que os testes sejam eficazes, eficientes e alinhados com
os objetivos do projeto. Um bom gerenciamento de testes proporciona visibilidade
sobre o progresso dos testes, a qualidade do software e os riscos envolvidos.
Importância de gerenciar os testes
Gerenciar os testes de forma adequada traz uma série de benefícios:
Visibilidade e rastreabilidade: Permite acompanhar o status dos testes, o
progresso da execução, os defeitos encontrados e sua resolução. Garante que os
requisitos sejam rastreáveis até os casos de teste e os defeitos.
Tomada de decisão: Fornece dados e métricas para que as equipes e
stakeholders possam tomar decisões informadas sobre a qualidade do software,
o risco de lançamento e a necessidade de mais testes.
Otimização de recursos: Ajuda a alocar recursos (pessoas, tempo, ferramentas)
de forma eficiente, evitando desperdícios e garantindo que os esforços de teste
estejam focados nas áreas mais críticas.
Melhoria contínua: Ao analisar os dados de testes, é possível identificar padrões
de defeitos, gargalos no processo e oportunidades de melhoria para futuros
projetos.
Conformidade e auditoria: Facilita a conformidade com padrões de qualidade e
regulamentações, fornecendo um histórico documentado de todas as atividades
de teste.
Benefícios de usar uma ferramenta (ex: visibilidade, rastreabilidade,
histórico)
Embora seja possível gerenciar testes manualmente, o uso de ferramentas de
gerenciamento de testes é altamente recomendado, especialmente para projetos de
médio a grande porte. Essas ferramentas centralizam as informações e automatizam
muitas tarefas, oferecendo benefícios como:
Centralização: Todos os artefatos de teste (planos, casos de teste, resultados,
defeitos) são armazenados em um único local, facilitando o acesso e a
colaboração.
Visibilidade em tempo real: Dashboards e relatórios fornecem uma visão clara e
atualizada do progresso dos testes, da cobertura e da qualidade do software.
Rastreabilidade: Permite vincular requisitos a casos de teste e a defeitos,
garantindo que todas as funcionalidades sejam testadas e que os problemas
sejam rastreados até sua origem.
Histórico e auditoria: Mantém um registro completo de todas as execuções de
teste, resultados e alterações, o que é valioso para auditorias, análises post-
mortem e aprendizado.
Reutilização: Facilita a reutilização de casos de teste em diferentes ciclos de
teste ou projetos.
Colaboração: Permite que equipes distribuídas colaborem de forma eficiente no
planejamento e execução dos testes.
Automação: Muitas ferramentas se integram com ferramentas de automação de
testes, permitindo a execução automatizada e o registro dos resultados.
Jira como ferramenta de gestão de testes (resuma como usar)
O Jira, embora seja primariamente uma ferramenta de gerenciamento de projetos e
rastreamento de issues, é amplamente utilizado para gestão de testes, especialmente
em equipes ágeis, através de plugins e integrações. Ele permite que as equipes
gerenciem todo o ciclo de vida do teste, desde o planejamento até a execução e o
rastreamento de defeitos [��].
Como usar o Jira para gestão de testes (com plugins como Xray ou Zephyr):
�. Criação de Requisitos/Histórias de Usuário: No Jira, os requisitos ou histórias
de usuário são criados como "Issues" (tarefas, histórias, épicos). Cada
funcionalidade a ser testada é representada por uma issue.
�. Criação de Casos de Teste: Utilizando plugins como Xray ou Zephyr, é possível
criar "Tipos de Issue" específicos para casos de teste. Cada caso de teste é
vinculado a um requisito ou história de usuário, garantindo a rastreabilidade. Os
casos de teste podem incluir passos detalhados, dados de entrada e resultados
esperados.
�. Organização em Ciclos de Teste: Os casos de teste são agrupados em "Ciclos de
Teste" ou "Sprints de Teste" para organizar as execuções. Isso permite que as
equipes planejem quais testes serão executados em uma determinada iteração
ou fase.
�. Execução de Testes: Os testadores executam os casos de teste diretamente no
Jira (ou através de integração com ferramentas de automação). Os resultados
(Passou, Falhou, Bloqueado, etc.) são registrados, e evidências (prints, logs)
podem ser anexadas.
�. Reporte e Rastreamento de Defeitos: Se um teste falha, um "Bug" (defeito) é
criado no Jira e automaticamentevinculado ao caso de teste e ao requisito
original. Isso facilita o rastreamento do defeito, a comunicação com os
desenvolvedores e o acompanhamento da correção.
�. Dashboards e Relatórios: O Jira, em conjunto com os plugins, oferece
dashboards e relatórios personalizáveis que fornecem métricas sobre o
progresso dos testes, a cobertura dos requisitos, o número de defeitos
abertos/fechados e a qualidade geral do software. Isso proporciona visibilidade
em tempo real para a equipe e os stakeholders.
O Jira, com seus plugins de gerenciamento de testes, transforma-se em uma
plataforma poderosa para centralizar e otimizar as atividades de QA, promovendo a
colaboração e a transparência em todo o processo de desenvolvimento.
Analogia: como usar um checklist de viagem para não esquecer nada
antes de embarcar.
Pense em planejar uma viagem internacional. Você não pode simplesmente sair de
casa. Você precisa de um "gerenciamento de viagem":
Importância de gerenciar os testes: É como a importância de ter um plano para
sua viagem. Você precisa saber para onde vai, o que precisa levar, quais
documentos são necessários, quanto dinheiro terá, etc. Sem um plano, a viagem
pode ser um desastre.
Benefícios de usar uma ferramenta: É como usar um aplicativo de checklist de
viagem ou uma planilha. Ao invés de tentar lembrar de tudo de cabeça, você tem
uma lista organizada:
Visibilidade: Você vê rapidamente o que já fez (passagens compradas,
hotel reservado) e o que falta (visto, vacinas).
Rastreabilidade: Você sabe que o item "passaporte" está vinculado à
"viagem internacional" e que a "vacina" está vinculada ao "país X".
Histórico: Você pode ver suas listas de viagens anteriores para aprender
com elas e não cometer os mesmos erros.
Jira como ferramenta: É como um super aplicativo de planejamento de viagem
onde você pode:
Criar "tarefas" para cada item da viagem (comprar passagens, reservar
hotel, fazer mala).
Vincular cada tarefa ao seu "destino" (requisito).
Marcar o status de cada tarefa (a fazer, em andamento, concluído).
Registrar "problemas" (bagagem extraviada, voo atrasado) e acompanhar a
resolução.
Ver relatórios de progresso (quantas tarefas concluídas, quantos problemas
abertos).
O gerenciamento de testes, assim como o planejamento de uma viagem, é essencial
para garantir que todos os detalhes sejam cuidados, que nada seja esquecido e que o
objetivo final (um software de qualidade ou uma viagem bem-sucedida) seja
alcançado com sucesso.
�. Modelos de Desenvolvimento de Software ‒ O
terreno onde o QA pisa
O desenvolvimento de software pode seguir diferentes modelos ou metodologias,
cada um com sua própria estrutura, fases e abordagens. O profissional de QA precisa
entender esses modelos, pois o seu papel e as atividades de teste se adaptam a cada
um deles. Vamos explorar os principais modelos e como o QA se encaixa em cada um.
Cascata (Waterfall)
O que é: O Modelo Cascata é uma metodologia de desenvolvimento de software
linear e sequencial, onde cada fase deve ser concluída antes que a próxima possa
começar [��]. As fases típicas incluem: Requisitos, Design, Implementação, Teste,
Implantação e Manutenção. É um modelo tradicional, com pouca flexibilidade
para mudanças após o início do projeto.
Como o QA se encaixa: No modelo Cascata, o teste é uma fase separada e
distinta que ocorre após a fase de implementação estar completa. O QA recebe o
software "pronto" para testar e seu foco principal é encontrar defeitos antes do
lançamento. Há pouca ou nenhuma interação do QA com as fases anteriores,
como requisitos e design.
Vantagens: Simples de entender e gerenciar. Bom para projetos com requisitos
muito estáveis e bem definidos.
Desvantagens: Pouca flexibilidade para mudanças. Defeitos são encontrados
tardiamente, tornando a correção mais cara. Risco de o software não atender às
necessidades reais do usuário se os requisitos iniciais estiverem incorretos.
Ágil (Agile)
O que é: As metodologias ágeis (como Scrum, Kanban, XP) são abordagens
iterativas e incrementais para o desenvolvimento de software [��]. Elas
enfatizam a colaboração, a entrega contínua de software funcional, a adaptação
a mudanças e a interação com o cliente. O trabalho é dividido em ciclos curtos
(sprints), e o feedback é constante.
Como o QA se encaixa: No desenvolvimento ágil, o QA é parte integrante da
equipe multifuncional desde o início do projeto. Ele atua de forma colaborativa e
contínua em todas as fases de cada sprint, participando da definição de
requisitos, do design, do desenvolvimento e dos testes. O foco é na prevenção de
defeitos e na construção da qualidade em cada iteração [�].
Vantagens: Alta flexibilidade e capacidade de resposta a mudanças. Entrega
contínua de valor ao cliente. Detecção precoce de defeitos. Maior colaboração e
comunicação na equipe.
Desvantagens: Requer uma cultura de equipe forte e auto-organizada. Pode ser
desafiador para projetos com requisitos muito rígidos ou contratos fixos.
Modelo V
O que é: O Modelo V é uma extensão do modelo Cascata, que enfatiza a relação
entre cada fase de desenvolvimento e sua fase de teste correspondente [��]. Ele
forma um "V", onde o lado esquerdo representa as fases de desenvolvimento (da
concepção à codificação) e o lado direito representa as fases de teste (do teste de
unidade ao teste de aceitação). Cada fase de desenvolvimento tem uma fase de
teste correspondente para verificar a saída da fase anterior.
Como o QA se encaixa: O QA está envolvido desde as fases iniciais, revisando os
requisitos e o design para criar planos de teste correspondentes. Por exemplo, os
requisitos de negócio são testados no Teste de Aceitação, o design do sistema no
Teste de Sistema, o design de componentes no Teste de Integração, e o design de
módulos no Teste de Unidade.
Vantagens: Maior foco na qualidade desde o início. Detecção precoce de defeitos
em cada nível. Clareza na relação entre desenvolvimento e teste.
Desvantagens: Ainda é um modelo sequencial, com pouca flexibilidade para
mudanças. Pode ser menos adaptável a projetos com requisitos em evolução.
DevOps
O que é: DevOps é uma cultura e um conjunto de práticas que visam integrar o
desenvolvimento de software (Dev) e as operações de TI (Ops) para encurtar o
ciclo de vida do desenvolvimento de sistemas e fornecer entrega contínua de alta
qualidade [�]. Ele enfatiza a automação, a colaboração e a comunicação entre as
equipes, desde o planejamento até a implantação e o monitoramento.
Como o QA se encaixa: No DevOps, o QA se torna "Quality Assistance" ou
"Quality Engineering". A qualidade é uma responsabilidade de todos, e o QA atua
na automação de testes em todas as etapas do pipeline de CI/CD (Integração
Contínua/Entrega Contínua). O foco é em testes contínuos, feedback rápido e
garantia de que o software seja entregue com qualidade e velocidade [�].
Vantagens: Entrega rápida e contínua de software. Maior colaboração e
automação. Redução de erros e tempo de inatividade. Melhoria contínua e
feedback rápido.
Desvantagens: Requer uma mudança cultural significativa. Pode exigir
investimento em ferramentas e automação.
Analogia: diferentes formas de construir uma casa ‒ do planejamento
até a entrega final.
Imagine que construir uma casa é como desenvolver um software. Os modelos de
desenvolvimento são as diferentes abordagens para essa construção:
Cascata: É como construir uma casa com um plano detalhado e fixo desde o
início. Primeiro, você projeta tudo (requisitos e design), depois constrói a
estrutura (implementação), só então inspeciona a casa pronta (teste) e,
finalmente, entrega as chaves (implantação). Se você quiser mudar uma parede
depois que a estrutura estiver pronta, é muito difícil e caro.
Ágil: É como construir a casa em etapas menores e com feedback constante.
Primeiro, você constrói a fundação e uma parte da sala, mostra para o cliente,
pega o feedback e ajusta. Depois, constrói a cozinha, mostra novamente, e assim
por diante. O cliente vê o progresso e pode mudar de ideia sobre detalhesao
longo do caminho, tornando a casa final mais alinhada com suas necessidades.
Modelo V: É como um construtor que, para cada fase da construção (fundação,
paredes, telhado), tem um inspetor específico que verifica a qualidade daquela
etapa antes de passar para a próxima. O inspetor da fundação verifica o projeto
da fundação e depois a fundação construída. O inspetor das paredes verifica o
projeto das paredes e depois as paredes construídas. Há uma verificação
correspondente para cada etapa de construção.
DevOps: É como ter uma equipe de construção que não só constrói a casa, mas
também cuida da manutenção, da jardinagem e de todas as operações pós-
construção. Eles usam robôs e automação para acelerar o trabalho, e todos na
equipe (pedreiros, eletricistas, encanadores) trabalham juntos e se comunicam
constantemente para garantir que a casa seja construída rapidamente, com alta
qualidade e que continue funcionando perfeitamente após a entrega.
Cada modelo de desenvolvimento tem suas particularidades, e o papel do QA se
adapta para garantir que a qualidade seja intrínseca ao processo, independentemente
da abordagem escolhida.
�. Automação de Testes ‒ O braço robótico do QA
A automação de testes é a prática de usar software para executar testes, controlar a
execução de testes e comparar os resultados reais com os resultados esperados [��].
Ela é um componente essencial no desenvolvimento de software moderno,
especialmente em ambientes ágeis e DevOps, onde a velocidade e a frequência das
entregas são altas. A automação de testes não substitui os testes manuais, mas os
complementa, liberando os testadores para se concentrarem em atividades mais
complexas e exploratórias.
O que é automação e quando ela é recomendada
O que é: A automação de testes envolve a criação de scripts de teste que podem
ser executados repetidamente por ferramentas de automação. Esses scripts
simulam a interação do usuário com o software, executam ações, verificam
resultados e geram relatórios. É como ter um "robô" que executa os testes para
você, de forma rápida e consistente.
Quando é recomendada: A automação é particularmente recomendada para:
Testes repetitivos: Testes de regressão, que precisam ser executados a
cada nova alteração no código para garantir que funcionalidades existentes
não foram quebradas.
Testes de carga e desempenho: Simular um grande número de usuários
ou transações para verificar o comportamento do sistema sob estresse.
Testes de rotina: Verificações diárias ou semanais da saúde do sistema
(smoke tests, sanity tests).
Testes que exigem precisão: Cenários onde a entrada de dados ou a
verificação de resultados precisam ser extremamente precisas.
Projetos de longo prazo: Onde o custo inicial da automação se justifica
pela economia de tempo e recursos a longo prazo.
Automação de testes Web
Ferramentas comuns: Selenium WebDriver, Cypress, Playwright, Puppeteer.
Como funciona: Essas ferramentas permitem simular interações do usuário com
navegadores web. Os scripts podem navegar por páginas, clicar em botões,
preencher formulários, verificar textos e elementos visuais. Eles interagem
diretamente com o DOM (Document Object Model) da página.
Exemplo prático: Automatizar o fluxo de login em um site. O script abriria o
navegador, navegaria para a página de login, preencheria os campos de usuário e
senha, clicaria no botão "Entrar" e verificaria se o usuário foi redirecionado para
a página inicial e se a mensagem de boas-vindas aparece.
Automação de testes Mobile
Ferramentas comuns: Appium, Espresso (Android), XCUITest (iOS), Calabash.
Como funciona: A automação de testes mobile permite testar aplicativos
nativos, híbridos e web em dispositivos móveis (smartphones e tablets) ou em
emuladores/simuladores. As ferramentas interagem com os elementos da
interface do usuário do aplicativo, simulam gestos (toques, swipes), verificam o
estado dos elementos e validam o comportamento do aplicativo em diferentes
orientações e tamanhos de tela.
Exemplo prático: Automatizar o processo de compra em um aplicativo de e-
commerce mobile. O script abriria o aplicativo, navegaria pelos produtos,
adicionaria um item ao carrinho, preencheria os dados de pagamento e
verificaria se o pedido foi concluído com sucesso.
Automação de testes de API
Ferramentas comuns: Postman, SoapUI, Rest-Assured (Java), Requests
(Python), Newman (para Postman CLI).
Como funciona: A automação de testes de API (Application Programming
Interface) foca em testar a lógica de negócio e a comunicação entre diferentes
sistemas, sem a necessidade de uma interface de usuário gráfica. Os scripts
enviam requisições HTTP/HTTPS para os endpoints da API, fornecem dados de
entrada (payloads) e verificam as respostas (status codes, dados retornados,
headers).
Exemplo prático: Automatizar o teste de uma API de cadastro de usuários. O
script enviaria uma requisição POST com os dados de um novo usuário,
verificaria se a API retorna um status code ��� (Criado) e se os dados do usuário
foram corretamente armazenados no banco de dados.
Analogia: como ter uma cafeteira automática que repete sempre a
receita perfeita do café, sem erro.
Pense em fazer café:
Fazer café manualmente (Teste Manual): Você pega o pó, a água, liga a
cafeteira, espera, coa. Cada vez que você faz, pode haver pequenas variações. É
bom para experimentar novos grãos ou métodos.
Cafeteira automática (Automação de Testes): Você programa a cafeteira uma
vez com a receita perfeita (quantidade de pó, água, temperatura). A partir daí,
toda vez que você aperta um botão, ela repete a receita exatamente igual, sem
erro, de forma rápida e consistente. Você não precisa se preocupar se o café vai
sair bom, ele sempre sai perfeito.
No software, a automação de testes é essa "cafeteira automática". Ela executa os
testes repetitivos e críticos de forma rápida, precisa e consistente, liberando os
testadores para se concentrarem em atividades mais estratégicas, como o teste
exploratório, que é como experimentar novos grãos de café para criar uma experiência
única. A automação garante a qualidade e a velocidade na entrega contínua de
software.
Conclusão: Dicas Finais para Quem Está Iniciando
Chegamos ao final deste guia completo sobre os fundamentos de testes de software e
a atuação do profissional de Quality Assurance (QA). Esperamos que você tenha
compreendido a importância vital da qualidade no desenvolvimento de software e o
papel estratégico que o QA desempenha nesse cenário. Lembre-se, ser um QA não é
apenas encontrar bugs, mas ser um guardião da qualidade, garantindo que o software
entregue valor e satisfaça as necessidades dos usuários.
Para você que está iniciando nesta jornada, aqui estão algumas dicas finais para
impulsionar sua carreira:
�. Mantenha-se Curioso e Aprenda Continuamente: A área de tecnologia está em
constante evolução. Novas ferramentas, metodologias e desafios surgem a todo
momento. Cultive a curiosidade, esteja sempre disposto a aprender e a se
adaptar. Siga blogs, participe de comunidades, faça cursos e experimente novas
tecnologias.
�. Desenvolva Suas Soft Skills: Habilidades técnicas são importantes, mas a
comunicação, o pensamento crítico, a proatividade e a colaboração são
igualmente cruciais. Um bom QA é um excelente comunicador e um membro
valioso da equipe, capaz de influenciar a qualidade desde as fases iniciais.
�. Pratique, Pratique, Pratique: A teoria é fundamental, mas a prática é o que
realmente consolida o conhecimento. Procure projetos pessoais, contribua para
projetos open source, ou crie seus próprios cenários de teste. Quanto mais você
testar, mais afiada ficará sua percepção para identificar problemas.
�. Entenda o Negócio: Um QA eficaz não apenas entende o software, mas também
o negócio por trás dele. Compreender os objetivos do produto, as necessidades
dos usuários e o impacto das funcionalidades ajuda a priorizar testes e a
identificar cenários de maior risco.
�. Construa Sua Rede de Contatos (Networking): Conecte-se com outros
profissionaisde QA, desenvolvedores e pessoas da área de tecnologia. Participe
de eventos, meetups e grupos online. O networking pode abrir portas para novas
oportunidades e proporcionar aprendizado valioso.
�. Seja um Defensor da Qualidade: Evangelize a cultura de qualidade em sua
equipe e organização. Mostre o valor do QA não apenas na detecção de defeitos,
mas na prevenção e na melhoria contínua dos processos.
�. Não Tenha Medo de Errar: Errar faz parte do processo de aprendizado. O
importante é aprender com os erros, ajustar a abordagem e seguir em frente. A
resiliência é uma característica valiosa para qualquer profissional.
O caminho para se tornar um QA de excelência é contínuo e desafiador, mas
extremamente recompensador. Com dedicação, paixão pela qualidade e a aplicação
dos conhecimentos adquiridos neste guia, você estará bem preparado para contribuir
significativamente para o sucesso de qualquer projeto de software. Boa sorte em sua
jornada!
Referências
[�] IBM. O que são testes de software? Disponível em: https://www.ibm.com/br-
pt/think/topics/software-testing. Acesso em: � jul. ����.
[�] Kalendae. Quality Assurance (QA): entenda sua importância e como aplicar.
Disponível em: https://kalendae.com.br/blog/quality-assurance/. Acesso em: � jul.
����.
[�] Auditeste. É tudo bug? Entenda a diferença entre falha, defeito e erro. Disponível
em: https://auditeste.com.br/falha-defeito-erro/. Acesso em: � jul. ����.
[�] TOTVS. QA: o que é e o que faz a área de Quality Assurance. Disponível em:
https://www.totvs.com/blog/developers/qa/. Acesso em: � jul. ����.
[�] Novo Momento. Profissional de Teste vs. Profissional de QA. Disponível em:
https://novomomento.com.br/profissional-de-teste-vs-profissional-de-qa/. Acesso
em: � jul. ����.
[�] iMasters. Desenvolvimento de software: Profissional de teste vs. Profissional de QA.
Disponível em: https://imasters.com.br/desenvolvimento/desenvolvimento-de-
software-profissional-de-teste-vs-profissional-de-qa. Acesso em: � jul. ����.
[�] VitaminaWeb. O que faz um QA? Disponível em: https://vitaminaweb.digital/o-que-
faz-um-qa/. Acesso em: � jul. ����.
[�] Alura. Guia completo sobre Quality Assurance em softwares. Disponível em:
https://www.alura.com.br/artigos/quality-assurance. Acesso em: � jul. ����.
[�] Testing Company. Qual o papel do profissional de QA nas metodologias ágil e
tradicional? Disponível em: https://testingcompany.com.br/blog/qual-o-papel-do-
profissional-de-qa-nas-metodologias-agil-e-tradicional. Acesso em: � jul. ����.
[��] TestGorilla. � habilidades essenciais de engenheiro de controle de qualidade a.
Disponível em: https://www.testgorilla.com/pt/blog/habilidades-engenheiro-de-qa/.
Acesso em: � jul. ����.
[��] AWS. O que são Testes de unidade? Disponível em:
https://aws.amazon.com/pt/what-is/unit-testing/. Acesso em: � jul. ����.
https://www.ibm.com/br-pt/think/topics/software-testing
https://www.ibm.com/br-pt/think/topics/software-testing
https://kalendae.com.br/blog/quality-assurance/
https://auditeste.com.br/falha-defeito-erro/
https://www.totvs.com/blog/developers/qa/
https://novomomento.com.br/profissional-de-teste-vs-profissional-de-qa/
https://imasters.com.br/desenvolvimento/desenvolvimento-de-software-profissional-de-teste-vs-profissional-de-qa
https://imasters.com.br/desenvolvimento/desenvolvimento-de-software-profissional-de-teste-vs-profissional-de-qa
https://vitaminaweb.digital/o-que-faz-um-qa/
https://vitaminaweb.digital/o-que-faz-um-qa/
https://www.alura.com.br/artigos/quality-assurance
https://testingcompany.com.br/blog/qual-o-papel-do-profissional-de-qa-nas-metodologias-agil-e-tradicional
https://testingcompany.com.br/blog/qual-o-papel-do-profissional-de-qa-nas-metodologias-agil-e-tradicional
https://www.testgorilla.com/pt/blog/habilidades-engenheiro-de-qa/
https://aws.amazon.com/pt/what-is/unit-testing/
[��] Objective. Testes de integração: o que é, quais os tipos e como automatizar?
Disponível em: https://www.objective.com.br/insights/teste-de-integracao/. Acesso
em: � jul. ����.
[��] Zaptest. Testes de Sistema - Tipos, Processo, Ferramentas & Mais! Disponível em:
https://www.zaptest.com/pt-br/o-que-sao-testes-de-sistema-um-mergulho-profundo-
nos-tipos-processo-abordagens-ferramentas-e-muito-mais. Acesso em: � jul. ����.
[��] Objective. Quais são as estratégias que podem ser usadas no teste de aceitação?
Disponível em: https://www.objective.com.br/insights/teste-de-aceitacao/. Acesso em:
� jul. ����.
[��] TripleTen Brasil. Teste de Caixa Branca: o que é e como funciona. Disponível em:
https://tripleten.com.br/blog/teste-de-caixa-branca-o-que-e-e-como-funciona/.
Acesso em: � jul. ����.
[��] Check Point. O que é teste de caixa preta? Disponível em:
https://www.checkpoint.com/pt/cyber-hub/cyber-security/what-is-penetration-
testing/what-is-black-box-testing/. Acesso em: � jul. ����.
[��] Check Point. O que é o teste de caixa cinza? Disponível em:
https://www.checkpoint.com/pt/cyber-hub/cyber-security/what-is-gray-box-testing/.
Acesso em: � jul. ����.
[��] Medium. Técnica de Teste — Particionamento de Equivalência. Disponível em:
https://medium.com/revista-tspi/t%C�%A�cnica-de-teste-particionamento-de-
equival%C�%AAncia-d��a�d���d��. Acesso em: � jul. ����.
[��] BSTQB. Análise de Valor Limite. Disponível em: https://bstqb.qa/analise-de-valor-
limite. Acesso em: � jul. ����.
[��] BSTQB. Teste de Tabela de Decisão. Disponível em: https://bstqb.qa/teste-de-
tabela-de-decisao. Acesso em: � jul. ����.
[��] BSTQB. Teste de Transição de Estado. Disponível em: https://bstqb.qa/teste-de-
transicao-de-estado. Acesso em: � jul. ����.
[��] Atlassian. Testes exploratórios. Disponível em:
https://www.atlassian.com/br/continuous-delivery/software-testing/exploratory-
testing. Acesso em: � jul. ����.
https://www.objective.com.br/insights/teste-de-integracao/
https://www.zaptest.com/pt-br/o-que-sao-testes-de-sistema-um-mergulho-profundo-nos-tipos-processo-abordagens-ferramentas-e-muito-mais
https://www.zaptest.com/pt-br/o-que-sao-testes-de-sistema-um-mergulho-profundo-nos-tipos-processo-abordagens-ferramentas-e-muito-mais
https://www.objective.com.br/insights/teste-de-aceitacao/
https://tripleten.com.br/blog/teste-de-caixa-branca-o-que-e-e-como-funciona/
https://www.checkpoint.com/pt/cyber-hub/cyber-security/what-is-penetration-testing/what-is-black-box-testing/
https://www.checkpoint.com/pt/cyber-hub/cyber-security/what-is-penetration-testing/what-is-black-box-testing/
https://www.checkpoint.com/pt/cyber-hub/cyber-security/what-is-gray-box-testing/
https://medium.com/revista-tspi/t%C3%A9cnica-de-teste-particionamento-de-equival%C3%AAncia-d32a7d689d82
https://medium.com/revista-tspi/t%C3%A9cnica-de-teste-particionamento-de-equival%C3%AAncia-d32a7d689d82
https://bstqb.qa/analise-de-valor-limite
https://bstqb.qa/analise-de-valor-limite
https://bstqb.qa/teste-de-tabela-de-decisao
https://bstqb.qa/teste-de-tabela-de-decisao
https://bstqb.qa/teste-de-transicao-de-estado
https://bstqb.qa/teste-de-transicao-de-estado
https://www.atlassian.com/br/continuous-delivery/software-testing/exploratory-testing
https://www.atlassian.com/br/continuous-delivery/software-testing/exploratory-testing
[��] Objective. Testes funcionais: saiba porque é fundamental para software.
Disponível em: https://www.objective.com.br/insights/testes-funcionais/. Acesso em:
� jul. ����.
[��] Zaptest. Teste não-funcional,Ferramentas,Tipos e Mais! Disponível em:
https://www.zaptest.com/pt-br/testes-nao-funcionais-o-que-e-isso-tipos-abordagens-
ferramentas-mais. Acesso em: � jul. ����.
[��] IBM. O que é gerenciamento de testes? Disponível em: https://www.ibm.com/br-
pt/topics/test-management. Acesso em: � jul. ����.
[��] Atlassian. Como criar e gerenciar casos de teste com o Xray e o Jira. Disponível
em: https://www.atlassian.com/br/devops/testing-tutorials/jira-xray-integration-
manage-test-cases. Acesso em: � jul. ����.
[��] monday.com. As �� principais metodologias de desenvolvimento de software.
Disponível em: https://monday.com/blog/pt/desenvolvimento/metodologias-de-