Qualidade de Software e Fundamentos de Teste na profissão de QA

O teste de software deixou de ser uma atividade restrita ao final do projeto. Durante muito tempo, o testador tradicional era associado à execução manual de roteiros, ao registro de defeitos e à validação final antes da entrega. No desenvolvimento moderno, esse papel se ampliou para o analista de Quality Assurance, ou QA, profissional que participa desde a concepção do produto, discute critérios de aceite, antecipa riscos, automatiza verificações e ajuda o time a construir qualidade ao longo de todo o ciclo de vida do software. A Figura 1 mostra a linha do tempo evolutiva para estes profissionais, indicando como a carreira mudou até o momento.

Pressman e Maxim (2020) explicam que qualidade de software envolve conformidade com requisitos explícitos, padrões de desenvolvimento documentados e características implícitas esperadas de todo software profissional, como manutenibilidade, confiabilidade e usabilidade. Em outras palavras, qualidade não é apenas “funcionar”; é funcionar de modo previsível, seguro, sustentável e adequado ao contexto de uso.

A relevância estratégica da qualidade aparece com mais força quando se observa o custo das falhas. Quanto mais tarde um defeito é encontrado, maior tende a ser o esforço de correção, pois a falha pode já ter contaminado requisitos, arquitetura, código, testes, documentação, implantação e experiência do usuário. Sommerville (2016) observa que verificação e validação devem acompanhar diferentes fases do desenvolvimento, justamente porque a detecção precoce reduz retrabalho e aumenta a confiança no produto. Boehm (1981), em estudos clássicos sobre economia da Engenharia de Software, também demonstrou que defeitos corrigidos tardiamente podem custar muitas vezes mais do que defeitos identificados nas fases iniciais do projeto. Seu conceito está representado visualmente na Figura 2.

Nesse cenário, o QA deve ser visto não apenas como “quem encontra bugs”, mas quem ajuda a equipe a compreender riscos de negócio, comportamento esperado, critérios de aceitação, qualidade do código, cobertura automatizada, regressão e rastreabilidade. Em times ágeis, a qualidade é uma responsabilidade compartilhada, embora o QA tenha papel central em orientar práticas, ampliar a visibilidade dos riscos e apoiar a colaboração entre negócio, desenvolvimento e operações (Crispin; Gregory, 2009).

Qualidade de software

Qualidade de software pode ser compreendida como o grau em que um produto atende às necessidades declaradas e implícitas de seus usuários, clientes e demais partes interessadas.

A norma ISO/IEC 25010 consolidou um modelo de qualidade que organiza atributos como adequação funcional, eficiência de desempenho, compatibilidade, usabilidade, confiabilidade, segurança, manutenibilidade e portabilidade (ISO/IEC, 2011). A versão de 2023 atualiza e amplia esse enquadramento para produtos de software e produtos de TIC, mantendo a ideia central de que qualidade precisa ser descrita por características avaliáveis, e não por impressões genéricas (ISO/IEC, 2023).

Na Figura 3 temos uma representação dos atributos que a ISO/IEC 25010 atribui à qualidade de software em sistemas completos e robustos.

Os atributos externos são aqueles percebidos no comportamento do sistema em execução. Um usuário percebe qualidade quando a aplicação responde rapidamente, protege seus dados, permanece disponível, apresenta mensagens compreensíveis, evita perda de informações e permite concluir tarefas com eficiência. Esses atributos estão associados à experiência de uso e à operação real do produto. Já os atributos internos dizem respeito à estrutura técnica do software: clareza do código, modularidade, coesão, baixo acoplamento, testabilidade, legibilidade, organização arquitetural e facilidade de manutenção. Embora o usuário final nem sempre veja esses elementos diretamente, eles influenciam a velocidade de evolução do produto, a frequência de defeitos e o custo de manutenção (Pressman; Maxim, 2020).

Martin (2009) reforça essa relação ao defender que código limpo é aquele que expressa claramente sua intenção, reduz surpresas e facilita mudanças seguras. Portanto, qualidade externa e qualidade interna não devem ser tratadas como dimensões separadas. Um sistema pode parecer funcional por algum tempo, mas, se sua estrutura interna for frágil, cada nova alteração aumenta o risco de regressões, atrasos e falhas em produção.

Fundamentos de teste

No campo dos testes, duas abordagens clássicas ajudam a organizar a avaliação do software: teste de caixa-preta e teste de caixa-branca, conforme a Figura 4. O teste de caixa-preta, também chamado de teste funcional, avalia o comportamento observável do sistema sem exigir conhecimento da implementação interna. O foco está nas entradas, saídas, regras de negócio, fluxos alternativos, mensagens, restrições e critérios de aceite. Técnicas como particionamento de equivalência, análise de valor limite e tabelas de decisão são comuns nessa abordagem (Myers; Sandler; Badgett, 2011).

Suponha uma tela de cadastro de usuário. Nela, o QA avaliaria se o sistema aceita e-mails válidos, rejeita e-mails inválidos, exige senha com tamanho mínimo, impede CPF duplicado e apresenta mensagens adequadas. Nesse caso, pouco importa como a função foi implementada internamente, pois o interesse está no comportamento esperado pelo usuário e pelo negócio.

Por outra lado, o teste de caixa-branca, ou teste estrutural, parte do conhecimento da implementação. A análise considera caminhos de execução, decisões condicionais, laços, tratamento de exceções, cobertura de instruções, cobertura de ramos e complexidade do código. Essa abordagem é especialmente útil em testes unitários, revisão de código e avaliação de trechos críticos, pois permite verificar se partes relevantes da lógica foram exercitadas pelos testes (Pressman; Maxim, 2020).

É importante destacar que essas abordagens não competem entre si. Pelo contrário, elas se complementam. Testes de caixa-preta ajudam a confirmar se o sistema atende ao que foi pedido e testes de caixa-branca ajudam a investigar se a estrutura lógica foi suficientemente exercitada. Um produto confiável geralmente combina as duas perspectivas.

Níveis de teste

A progressão dos níveis de teste também é fundamental. O teste de unidade verifica pequenas partes isoladas do software, como funções, métodos ou classes. O teste de integração avalia a interação entre módulos, serviços, APIs, bancos de dados, filas ou componentes externos. O teste de sistema verifica o produto como um todo, considerando fluxos completos de negócio, requisitos funcionais e não funcionais, ambiente de execução e comportamento integrado (Sommerville, 2016).

Essa progressão forma uma espécie de pirâmide conceitual, igual a descrita na Figura 5. Na base, muitos testes unitários rápidos verificam regras pequenas. No meio, testes de integração avaliam contratos entre componentes. No topo, menos testes de sistema e interface validam jornadas completas, normalmente com maior custo de execução e manutenção.

Essa organização reduz dependência de testes manuais tardios, aumenta a capacidade de detectar defeitos rapidamente e, consequentemente, contribui para a diminuição de custos durante o desenvolvimento e a manutenção do software.

Testes unitários e isolamento de código

Testes unitários verificam unidades pequenas de comportamento, geralmente de forma rápida, automatizada e repetível. Beck (2003), ao apresentar o Desenvolvimento Guiado por Testes, defende que testes pequenos e frequentes ajudam o programador a evoluir o código com mais segurança, pois cada alteração pode ser imediatamente confrontada com expectativas previamente definidas.

Um bom teste unitário deve ser determinístico, legível, rápido e independente. Determinístico significa produzir o mesmo resultado sempre que executado sob as mesmas condições; Legível significa expressar claramente o cenário, a ação e o resultado esperado; Rápido significa poder ser executado várias vezes ao longo do dia; e Independente significa não depender de ordem de execução, rede instável, banco de dados real ou serviços externos sem controle.

O isolamento de código é necessário porque uma unidade raramente vive sozinha. Uma classe de serviço pode depender de repositórios, APIs externas, serviços de e-mail, gateways de pagamento, relógio do sistema ou filas de mensagens. Para testar apenas a regra de negócio da unidade, essas dependências podem ser substituídas por componentes simulados. Meszaros (2007) organiza esse campo com o conceito de test doubles, isto é, objetos usados no lugar de dependências reais durante os testes.

Para estes testes, podemos usar três objetos que auxiliam na execução (vide Figura 6):

• Mocks: são objetos simulados usados para verificar interações. Eles são úteis quando o teste precisa confirmar se determinado método foi chamado com certos parâmetros. Por exemplo, ao testar um serviço de recuperação de senha, um mock pode verificar se o serviço de e-mail foi acionado após a geração do token.
• Stubs: são objetos que fornecem respostas pré-definidas ao código testado. Eles são adequados quando a unidade precisa receber dados de uma dependência, mas o teste não está interessado em validar a dependência em si. Por exemplo, um stub de repositório pode sempre retornar um usuário ativo para testar a regra de autorização.
• Fakes: são implementações simplificadas, mas funcionais, de uma dependência. Um banco de dados em memória usado apenas nos testes pode ser considerado fake. Diferentemente do stub, que costuma responder de forma fixa, o fake possui comportamento mais próximo do real, embora simplificado.

Essa distinção ajuda o QA e o desenvolvedor a escolherem o recurso certo para cada cenário, lembrando que mocks validam chamadas, stubs fornecem respostas e fakes substituem componentes reais por versões leves e controladas (Meszaros, 2007).

As obrigações do QA na cultura ágil

Na cultura ágil, o QA participa do trabalho desde o refinamento das histórias, ou seja, sua atuação começa antes do código. Ele ajuda a questionar requisitos ambíguos, levantar cenários alternativos, identificar riscos, propor critérios de aceite, discutir dados de teste e antecipar dependências.

Crispin e Gregory (2009) organizam a atuação do QA ágil em torno da colaboração contínua. O QA conversa com Product Owners (POs) para entender o valor de negócio, com desenvolvedores para discutir testabilidade e riscos técnicos, com designers para avaliar usabilidade e com operações para compreender ambiente, monitoramento e implantação. Sua rotina inclui análise de histórias, planejamento de testes, escrita de cenários, execução exploratória, automação, revisão de defeitos, acompanhamento de métricas e participação em cerimônias ágeis.

Pensando nessa organização moderna para equipes de desenvolvimento, North (2006) formulou a abordagem chamada Desenvolvimento Guiado por Comportamento (BDD). Ao formular a abordagem do BDD, North (2006) buscava reduzir ambiguidades entre o que o negócio espera e o que o time implementa.

O BDD amplia essa colaboração entre membros da equipe ao propor a descrição do comportamento esperado do sistema em uma linguagem compreensível por pessoas técnicas e não técnicas. Na prática, cenários das regras de negócio podem ser descritos em formato “Dado, Quando, Então”, que ajudam a transformar critérios de aceite em exemplos executáveis ou semiexecutáveis.

Um cenário de BDD para um sistema acadêmico poderia ser descrito assim: “Dado que um aluno possui mensalidades em atraso, quando ele tentar emitir a declaração de matrícula, então o sistema deve informar que há pendências financeiras e orientar a regularização”. Esse tipo de descrição explicita contexto, ação e resultado esperado. O QA contribui para que esses cenários cubram fluxo principal, exceções, regras de negócio, limites e mensagens relevantes.

O QA, nesse contexto, precisa compreender qualidade funcional tanto quanto engenharia de entrega. Ele deve saber quais testes pertencem a cada nível, quais podem rodar em etapas mais longas, quais cenários são críticos para bloquear uma entrega e quais verificações devem ser monitoradas em produção.

A cultura ágil madura evita a ideia de que “qualidade é responsabilidade do QA”., de forma que ela seja compartilhado pelo time. O QA, entretanto, é o profissional que mantém a disciplina da qualidade visível, questiona riscos, fortalece critérios, amplia a cobertura, orienta automação e ajuda a transformar incertezas em evidências verificáveis.

Conclusão

Ingressar na área de QA exige uma combinação de competências técnicas, analíticas e comunicacionais. Do ponto de vista técnico, o analista precisa compreender fundamentos de Engenharia de Software, níveis de teste, técnicas de caixa-preta e caixa-branca, testes unitários, automação, versionamento, APIs, banco de dados, CI/CD e noções de arquitetura. Do ponto de vista analítico, precisa saber identificar riscos, decompor requisitos, desenhar cenários, priorizar testes e interpretar evidências. Do ponto de vista humano, precisa dialogar com negócio, desenvolvimento, produto, design e operações. Portanto, ser QA não é ficar “de boa testando o que os outros fizeram”. É uma área que também exige suas habilidades.

O bom QA é um profissional que pensa sistemicamente. Seu trabalho conecta requisitos, código, experiência do usuário, segurança, desempenho, manutenção e entrega. Em um mercado orientado por ciclos curtos, produtos digitais complexos e alta expectativa de confiabilidade, qualidade deixa de ser uma etapa e passa a ser uma cultura técnica. Logo, aprender sobre qualidade, testes e a profissão de QA é também aprender a construir software com responsabilidade, evidência e capacidade de evolução.

Obrigado pela leitura e bons estudos!

Referências

BECK, Kent. Test-driven development: by example. Boston: Addison-Wesley, 2003.

BOEHM, Barry W. Software engineering economics. Englewood Cliffs: Prentice Hall, 1981.

CRISPIN, Lisa; GREGORY, Janet. Agile testing: a practical guide for testers and agile teams. Boston: Addison-Wesley, 2009.

FOWLER, Martin. Test coverage. 2014. Disponível em: <https://martinfowler.com/bliki/TestCoverage.html>. Acesso em: 23 maio 2026.

FOWLER, Martin; FOEMMEL, Matthew. Continuous integration. 2006. Disponível em: <https://martinfowler.com/articles/continuousIntegration.html>. Acesso em: 23 maio 2026.

HUMBLE, Jez; FARLEY, David. Continuous delivery: reliable software releases through build, test, and deployment automation. Boston: Addison-Wesley, 2010.

INTERNATIONAL ORGANIZATION FOR STANDARDIZATION; INTERNATIONAL ELECTROTECHNICAL COMMISSION. ISO/IEC 25010:2011: systems and software engineering: systems and software quality requirements and evaluation (SQuaRE): system and software quality models. Geneva: ISO, 2011.

INTERNATIONAL ORGANIZATION FOR STANDARDIZATION; INTERNATIONAL ELECTROTECHNICAL COMMISSION. ISO/IEC 25010:2023: systems and software engineering: systems and software quality requirements and evaluation (SQuaRE): product quality model. Geneva: ISO, 2023.

MARTIN, Robert C. Clean code: a handbook of agile software craftsmanship. Boston: Prentice Hall, 2009.

MESZAROS, Gerard. xUnit test patterns: refactoring test code. Boston: Addison-Wesley, 2007.

MYERS, Glenford J.; SANDLER, Corey; BADGETT, Tom. The art of software testing. 3. ed. Hoboken: John Wiley & Sons, 2011.

NORTH, Dan. Introducing BDD. 2006. Disponível em: <https://dannorth.net/introducing-bdd/>. Acesso em: 23 maio 2026.

PRESSMAN, Roger S.; MAXIM, Bruce R. Software engineering: a practitioner’s approach. 9. ed. New York: McGraw-Hill Education, 2020.

SOMMERVILLE, Ian. Software engineering. 10. ed. Boston: Pearson, 2016.