Validações funcionais
POs realizavam testes funcionais e, em alguns contextos, também produziam registros ou roteiros de validação.
← Voltar para todos os cases
Case 1 · Diagnóstico e maturidade de QA
Diagnóstico AS-IS e Evolução da Maturidade de Testes
Estruturei um diagnóstico AS-IS para compreender como os testes eram realizados antes da formação de uma atuação dedicada de QA. Criei um formulário com base em normas, modelos e práticas reconhecidas de Qualidade de Software, consolidei as respostas das pessoas que executavam as validações e transformei as lacunas identificadas em planos de ação acompanhados ao longo do tempo.
Contexto inicial
Antes da estruturação de QA, as validações funcionais eram realizadas por Produto e Desenvolvimento.
O primeiro desafio foi transformar uma percepção dispersa sobre os testes em uma visão estruturada do processo real, sem avaliar o cenário apenas pela expectativa de como ele deveria funcionar.
Verificações técnicas
Desenvolvimento e coordenação técnica atuavam em testes unitários, de integração e outras verificações em código.
Informações dispersas
Não havia uma leitura única e organizada sobre planejamento, documentação, cobertura, riscos, evidências e automação.
Necessidade de uma linha de base
Era necessário registrar o cenário existente para definir prioridades e acompanhar a evolução das práticas.
Minha atuação
Estruturei o levantamento, consolidei o diagnóstico e usei os resultados para orientar a evolução.
Criação do formulário
Elaborei um questionário com 17 perguntas para mapear práticas de Testes de Software antes da entrada do time de QA.
Base de referência
As perguntas foram construídas a partir de normas, modelos e práticas reconhecidas de Qualidade de Software e testes, incluindo características de qualidade da ISO/IEC 25010.
Consolidação das respostas
Organizei as informações por dimensão e classifiquei cada prática conforme o estágio de adoção observado.
Planos de ação
Os itens amarelos e vermelhos foram utilizados para definir prioridades e orientar ações de melhoria.
Acompanhamento periódico
Atualizei o diagnóstico em diferentes momentos para registrar avanços, ações em andamento e novas necessidades.
Adaptação por contexto
A abordagem também foi adaptada para outro fluxo de produto, com questionário e plano de ação próprios.
Importante:
o levantamento utilizou referências de Qualidade para orientar
as perguntas, mas não representou auditoria, certificação ou
avaliação formal de conformidade normativa.
Base do diagnóstico
As perguntas cobriram dimensões essenciais da atividade de Testes de Software.
Estratégia e planejamento
- Planejamento prévio dos testes
- Definição de técnicas
- Análise baseada em risco
- Indicadores e cobertura
Documentação e rastreabilidade
- Documentação de testes
- Registro de inconsistências
- Evidências acessíveis
- Revisão de artefatos
Colaboração
- Pair testing
- Alinhamento com desenvolvimento
- Participação antecipada
- Compartilhamento de informações
Ambientes e execução
- Controle de ambientes
- Testes funcionais e responsivos
- Testes unitários e de integração
- Testes não funcionais
Automação e engenharia
- Automação Web
- Automação de API
- Revisão de código automatizado
- Gerenciamento dos testes
Funcionamento
O diagnóstico foi utilizado como um ciclo contínuo de aprendizado e evolução.
Levantar
Coletar informações com quem executava as validações.
Consolidar
Organizar respostas por práticas e dimensões de Qualidade.
Classificar
Identificar o que era realizado, parcial ou não realizado.
Priorizar
Selecionar lacunas com maior necessidade de evolução.
Agir
Transformar os pontos críticos em planos de ação.
Reavaliar
Atualizar o AS-IS e acompanhar a mudança ao longo do tempo.
Não realizado
Realizado parcialmente
Realizado
Linha evolutiva
O AS-IS foi atualizado ao longo dos anos para registrar avanços e novas prioridades.
Período selecionado
Ações e estágios
As iniciativas foram apresentadas conforme o estágio realmente observado.
Incorporadas ao processo
- Planejamento dos testes
- Pair testing
- Ampliação das técnicas de teste
- Organização dos ambientes
- Extração de informações pelo Azure
- Maior controle das atividades de teste
Em andamento em diferentes períodos
- Gestão de riscos
- Automação funcional de API
- Revisão de código automatizado
- Automação funcional Web
Estado futuro desejado
O TO-BE foi utilizado como referência de evolução. Ele orientava prioridades, mas não era apresentado como um cenário integralmente alcançado.
Resultados observados
O diagnóstico criou visibilidade, direção e uma base para melhoria contínua.
Linha de base estruturada
O cenário inicial deixou de depender apenas de percepção e passou a ser registrado por dimensões.
Lacunas visíveis
Práticas ausentes ou parciais puderam ser identificadas e discutidas de forma objetiva.
Priorização orientada
Os planos de ação foram construídos a partir das necessidades observadas no diagnóstico.
Acompanhamento contínuo
As atualizações periódicas permitiram diferenciar avanços, ações em andamento e objetivos futuros.
Fortalecimento de QA
A iniciativa apoiou a evolução gradual da participação de Qualidade ao longo do ciclo de desenvolvimento.
Reutilização da abordagem
O modelo foi adaptado para outro contexto de produto, preservando a lógica de diagnóstico e ação.
Resultados qualitativos:
os materiais não apresentam percentuais consolidados de evolução,
redução de defeitos ou ganho de produtividade. Por isso, o case
registra resultados observados sem criar métricas não medidas.
“Transformei a percepção informal sobre os testes em um diagnóstico estruturado, utilizado para identificar lacunas, priorizar ações e acompanhar a evolução contínua das práticas de Qualidade.”
Competências demonstradas
Diagnóstico, estratégia, governança e melhoria contínua em Qualidade.
Confidencialidade:
a versão pública utiliza conteúdo resumido e anonimizado.
Formulários completos, nomes de sistemas, pessoas, empresas
e apresentações internas não são disponibilizados.