Quando falamos em desenvolvimento de software, é comum que a palavra “testes” evoque a imagem de uma etapa isolada, situada no final do processo — algo que acontece depois que o código já está escrito. Essa visão, embora ainda presente em muitas organizações, está cada vez mais distante da realidade das equipes de engenharia de qualidade maduras.
O STLC (Software Testing Life Cycle) — Ciclo de Vida de Teste de Software — é o conjunto estruturado de fases que organiza e orienta todas as atividades de teste ao longo do desenvolvimento. Mais do que uma sequência de etapas, o STLC representa uma mudança de perspectiva: a qualidade não é verificada no final, mas construída desde o início.
SDLC e STLC: dois ciclos, um objetivo
Para compreender o STLC, é útil situá-lo dentro de um contexto maior: o SDLC (Software Development Life Cycle), o Ciclo de Vida de Desenvolvimento de Software.
O SDLC organiza o processo de criação de software em fases como:
- Planejamento
- Análise de Requisitos
- Design (Projeto)
- Desenvolvimento (Codificação)
- Testes
- Implantação
- Manutenção
Nesse modelo tradicional, os testes aparecem como uma fase específica — uma etapa entre o desenvolvimento e a implantação. O problema dessa abordagem é que defeitos encontrados tardiamente são significativamente mais caros e difíceis de corrigir.
O STLC responde a esse problema ao estruturar as atividades de teste de forma paralela e integrada ao SDLC. Enquanto o SDLC define o que será construído e como, o STLC define como a qualidade será garantida em cada momento desse processo.
A correspondência entre desenvolvimento e testes
Essa integração não é apenas uma boa prática: é um princípio formalizado. O ISTQB Foundation Level Syllabus (seção 2.1) estabelece explicitamente que para cada atividade de desenvolvimento existe uma atividade de teste correspondente, de modo que todas as etapas do desenvolvimento estejam sujeitas ao controle de qualidade. Complementarmente, o syllabus determina que a análise e o design dos testes para um determinado nível devem ter início durante a fase de desenvolvimento correspondente — não depois dela.
Na prática, isso significa que o QA não aguarda o código pronto para começar a trabalhar. Enquanto os requisitos são definidos, os testes já são planejados. Enquanto o sistema é projetado, os casos de teste são desenhados. Enquanto o código é escrito, o ambiente de testes é preparado. A tabela abaixo ilustra essa correspondência no contexto do modelo sequencial clássico:
| Fase do SDLC | Atividade de teste correspondente |
|---|---|
| Análise de Requisitos | Análise de requisitos testáveis; identificação de condições de teste |
| Design (Projeto) | Planejamento dos testes; definição da estratégia |
| Desenvolvimento (Codificação) | Design dos casos de teste; configuração do ambiente |
| Testes | Execução dos testes; reporte de defeitos |
| Implantação | Encerramento do ciclo; testes de sanidade em produção |
Vale ressaltar que o ISTQB reconhece explicitamente que esse mapeamento varia conforme o modelo de ciclo de vida adotado. Em modelos iterativos e ágeis, as fases se sobrepõem e se comprimem em ciclos curtos — mas o princípio da correspondência permanece: nenhuma entrega de desenvolvimento deveria ocorrer sem uma atividade de qualidade associada.
As fases do STLC
Ao contrário do que alguns materiais podem sugerir, não existe uma definição formal e padronizada do STLC — nenhum organismo como ISO, IEEE ou ISTQB estabelece um modelo oficial com fases fixas e obrigatórias. O que se encontra na literatura técnica e nos guias da indústria é uma convergência em torno de seis fases, amplamente adotada por equipes de qualidade ao redor do mundo, mas que varia em nomenclatura, quantidade de etapas e escopo conforme o contexto, a metodologia e a maturidade de cada organização.
Neste artigo, adoto um modelo de sete fases (6 + 1) como referência — não porque seja “o modelo correto”, mas porque representa uma estrutura coerente, aplicável e suficientemente abrangente para fins educacionais e profissionais. A sétima fase — o acompanhamento pós-liberação — é uma adição deliberada ao modelo mais comum encontrado na literatura, motivada pela realidade de times que operam com entrega contínua e precisam estender a cobertura de qualidade para além da implantação.
Cada fase é descrita com suas atividades típicas e critérios de saída, que devem ser adaptados à realidade de cada time.
1. Análise de Requisitos
Compreensão dos requisitos e identificação de condições testáveis
A primeira fase do STLC começa onde muitos ainda acreditam que os testes não têm lugar: no planejamento e na análise de requisitos. É aqui que o profissional de qualidade (QA) realiza uma das contribuições mais valiosas de todo o ciclo.
Ao participar das reuniões iniciais de uma iniciativa ou projeto — o chamado fluxo upstream –, o QA tem a oportunidade de:
- Identificar o que pode e precisa ser testado, mapeando condições testáveis diretamente a partir dos requisitos;
- Contribuir com sua experiência prática, antecipando situações que historicamente resultam em falhas, sinalizando ambiguidades nos requisitos e promovendo discussões que aumentam a qualidade da especificação antes mesmo que uma linha de código seja escrita.
Essa atuação antecipada do QA é o que fundamenta o conceito de shift-left testing — a ideia de deslocar as atividades de qualidade para a esquerda na linha do tempo do projeto, tornando a detecção de problemas mais precoce, mais barata e mais eficaz.
Critérios de saída desta fase: lista de requisitos testáveis documentada; dúvidas e inconsistências levantadas e encaminhadas para resolução.
2. Planejamento de Teste
Delineação da estratégia geral dos testes
Com os requisitos analisados, a segunda fase estrutura a estratégia que guiará todas as demais atividades. O principal artefato gerado aqui é o Plano de Testes — um documento que formaliza as decisões fundamentais sobre como os testes serão conduzidos.
Um plano de testes bem elaborado contempla, entre outros aspectos:
- Escopo: o que será testado e o que está fora do escopo;
- Estratégias: quais tipos de testes serão aplicados (funcionais, regressivos, automatizados, manuais, de performance, entre outros);
- Responsabilidades: quem executará os testes, incluindo eventual participação de outras equipes;
- Ambientes: em quais ambientes os testes serão realizados (homologação, staging, sandbox);
- Cronograma: quando os testes iniciam e quando devem estar concluídos.
O plano de testes não precisa ser um documento extenso e burocrático. Em contextos ágeis, ele pode ser um artefato enxuto, atualizado de forma contínua e integrado às ferramentas de gestão do time — como um campo descritivo em uma suite de testes dentro de uma plataforma de ALM (Application Lifecycle Management).
Critérios de saída desta fase: plano de testes aprovado pelas partes interessadas; ambientes definidos; cronograma acordado.
3. Design dos Casos de Teste
Desenvolvimento de casos de teste e cenários para cobertura dos requisitos
A terceira fase transforma os requisitos em casos de teste concretos — os roteiros que guiarão a verificação do comportamento do sistema.
Um caso de teste descreve, de forma estruturada, as condições de entrada, as ações a serem realizadas e os resultados esperados para cada cenário de verificação. Sua elaboração exige tanto conhecimento técnico quanto domínio de negócio: um bom caso de teste cobre o cenário esperado (caminho feliz), as variações e os cenários de exceção.
Casos de teste podem ser escritos em diferentes formatos:
- Linguagem natural (passo a passo): mais acessível para equipes multidisciplinares, descreve cada ação do usuário e o resultado esperado de forma sequencial;
- Linguagem Gherkin (BDD): orientada ao comportamento, utiliza a estrutura Given / When / Then para descrever cenários de forma que o negócio e a tecnologia compartilhem o mesmo vocabulário.
Além da criação, esta fase inclui a revisão dos casos de teste — um passo muitas vezes negligenciado, mas essencial para garantir cobertura adequada e eliminar redundâncias.
Critérios de saída desta fase: casos de teste documentados, revisados e organizados em suítes; cobertura de requisitos verificada.
4. Configuração do Ambiente de Teste
Preparação da infraestrutura onde os testes serão executados
Antes que qualquer teste seja executado, é necessário garantir que o ambiente em que isso ocorrerá está adequadamente preparado. Esta fase cuida justamente disso: a instalação, configuração e validação dos ambientes de teste.
Um ambiente de teste deve, idealmente, refletir o ambiente de produção — em termos de sistema operacional, versões de software, volumes de dados e configurações de rede. A distância entre o ambiente de teste e o de produção é uma das principais causas de defeitos que escapam da fase de testes e são encontrados apenas em produção.
As atividades típicas desta fase incluem:
- Provisionamento ou atualização do ambiente (máquinas, contêineres, servidores, bancos de dados);
- Configuração de dados de teste adequados e representativos;
- Validação de que o ambiente está funcional e acessível para a equipe de testes;
- Configuração de ferramentas de teste (frameworks, ferramentas de automação, coletores de evidências).
Em organizações com práticas de DevOps consolidadas, grande parte dessas atividades é automatizada — com ambientes criados e destruídos sob demanda, como parte dos pipelines de CI/CD.
Critérios de saída desta fase: ambiente de teste validado e documentado; ferramentas configuradas e funcionais.
5. Execução dos Testes
Execução dos casos de teste e registro dos resultados
É nesta fase que os casos de teste planejados são efetivamente executados. Para cada caso de teste, o QA segue o roteiro definido, registra o resultado obtido e compara com o resultado esperado.
Quando um comportamento diverge do esperado, estamos diante de uma falha — que deve ser investigada para determinar se se trata de um defeito (bug) no software, um problema no ambiente, uma inconsistência na especificação ou um caso de teste inadequado.
Os defeitos identificados devem ser documentados de forma individual e detalhada, incluindo:
- Descrição clara do comportamento observado vs. comportamento esperado;
- Passos para reprodução;
- Evidências (capturas de tela, logs, vídeos);
- Severidade e prioridade;
- Versão do sistema em que o defeito foi encontrado.
Essa documentação é fundamental para que os desenvolvedores possam investigar e corrigir os problemas com eficiência, e para que o QA possa verificar a correção (reteste) depois.
Paralelamente, os resultados da execução alimentam relatórios e dashboards que oferecem visibilidade em tempo real sobre o progresso e a qualidade da entrega.
Critérios de saída desta fase: todos os casos de teste planejados executados; defeitos documentados e encaminhados; relatório de execução disponível.
6. Encerramento do Ciclo de Testes
Consolidação dos resultados e análise das atividades
A sexta fase formaliza o encerramento do ciclo de testes no ambiente controlado. Mais do que um relatório final, o encerramento é uma oportunidade de aprendizado organizacional.
As atividades desta fase incluem:
- Análise dos resultados: quantos casos foram executados, aprovados, reprovados e bloqueados; qual é o status dos defeitos encontrados;
- Avaliação da cobertura: os requisitos foram adequadamente cobertos pelos testes?
- Registro de lições aprendidas: o que funcionou bem no processo? O que pode ser melhorado no próximo ciclo?
- Arquivamento de artefatos: casos de teste, relatórios e evidências organizados para consulta futura.
Em muitas organizações, esta fase inclui também uma apresentação dos resultados para as partes interessadas — especialmente quando os testes revelaram riscos relevantes ou quando a cobertura alcançada ficou abaixo do planejado.
Critérios de saída desta fase: relatório final de testes publicado; lições aprendidas registradas; métricas de qualidade consolidadas.
7. Além do STLC: acompanhamento pós-liberação
Verificação da entrega no ambiente produtivo e monitoramento contínuo
Em times com práticas DevOps e entrega contínua, a responsabilidade do QA não se encerra com a implantação. Após a publicação em produção, esta fase garante que a entrega funciona conforme o esperado no ambiente real — aquele que, por definição, é o mais imprevisível de todos.
As atividades típicas desta fase incluem:
- Execução de testes não invasivos no ambiente produtivo — os chamados smoke tests ou testes de sanidade — para confirmar que as funcionalidades críticas estão operando corretamente após a liberação;
- Acompanhamento dos testes automatizados de regressão, garantindo que a nova entrega não introduziu quebras em funcionalidades previamente validadas;
- Monitoramento de indicadores de qualidade em produção (taxas de erro, logs de exceção, alertas de performance) como sinal complementar à cobertura de testes.
A inclusão desta fase no modelo reflete uma visão de qualidade que vai além da homologação: o ambiente produtivo é o juiz final, e o QA deve ter visibilidade sobre o que acontece nele após cada entrega.
Critérios de saída desta fase: smoke tests executados e aprovados; ausência de regressões críticas confirmada; evidências de estabilidade em produção registradas.
Controle, Garantia e Gestão da Qualidade no STLC
O STLC opera em três dimensões complementares da qualidade:
- Controle da qualidade (QC): atividades de verificação — encontrar defeitos por meio da execução dos testes;
- Garantia da qualidade (QA): atividades de prevenção — garantir que os processos de desenvolvimento e teste são adequados para produzir software com qualidade;
- Gestão da qualidade: planejamento, monitoramento e melhoria contínua dos processos de qualidade.
Profissionais de QA que atuam em todas as fases do STLC transitam naturalmente entre essas três dimensões — e é justamente essa atuação abrangente que diferencia um time de qualidade maduro de uma equipe que simplesmente “testa no final”.
Conclusão
O STLC representa a organização sistemática das atividades de teste ao longo de todo o ciclo de vida do desenvolvimento. Ao estruturar a qualidade em fases com entradas, atividades e critérios de saída definidos — e ao integrar o QA desde a análise de requisitos –, o STLC transforma a qualidade de um evento pontual em um processo contínuo.
Compreender e aplicar o STLC é um passo fundamental para equipes que buscam não apenas encontrar defeitos, mas evitá-los — entregando software melhor, com mais previsibilidade e menos retrabalho.
