Sobre esta ferramenta
A maioria dos times sabe dizer quantos testes automatizados tem. Poucos sabem dizer se esses testes são um sinal em que alguém confia. Este scorecard faz doze perguntas sobre o que realmente acontece hoje, duas para cada uma de seis áreas: estratégia e escopo, framework e qualidade de código, integração com CI/CD, massa de dados e ambientes, confiabilidade e flakiness, e relatórios e ownership. Cada resposta vale de 0 a 3 pontos. Cada área recebe uma nota de 0 a 100 a partir das suas duas respostas, e a nota geral é a média das seis áreas, então um time com um framework lindo que só roda em um notebook não consegue pontuar bem. A nota geral corresponde a um de quatro níveis: Ad hoc (abaixo de 35), Emergente (35 a 59), Estabelecido (60 a 84) e Otimizado (85 ou mais). As áreas mais fracas abaixo de 80, até três delas, voltam como próximos passos concretos com links para as aulas e ferramentas que as cobrem. A pontuação é uma rubrica fixa, descrita no FAQ abaixo. É um ponto de partida para uma retro ou uma sessão de planejamento, não um benchmark contra outras empresas: não há base de dados de outros times por trás dela, e nada disso é alegado.
Como usar
- Responda cada pergunta com a opção que descreve o que o seu time faz hoje. Aspirações e planos contam como a opção em que vocês estão agora.
- Sua nota é atualizada assim que as doze perguntas forem respondidas. As respostas ficam salvas neste navegador, então você pode voltar a elas.
- Leia a lista “Work on next”: as áreas mais fracas primeiro, cada uma com um passo concreto e links para se aprofundar.
- Use “Copy share link” para enviar o resultado ao seu time. O link carrega as respostas, então quem o abrir vê as mesmas notas. “Copy summary” gera texto puro para Slack, um ticket ou um documento de retro.
O que as seis áreas medem
- Estratégia e escopo: se a automação mira o risco de forma intencional e se a maioria das checagens fica no nível mais barato capaz de pegar o bug (unitário e API antes de UI).
- Framework e qualidade de código: se o código de teste é estruturado (page ou component objects, fixtures, configuração) e revisado como código de produção, e se os locators sobrevivem a mudanças de marcação.
- Integração com CI/CD: se os testes rodam a cada mudança sem que alguém precise lembrar de rodá-los, e quanto tempo um pull request espera pela resposta.
- Massa de dados e ambientes: se os testes são donos dos seus dados e podem rodar em paralelo e em qualquer ordem, contra um ambiente que é sempre igual.
- Confiabilidade e flakiness: se um build vermelho significa um problema real. Sleeps fixos e rodar de novo até ficar verde são os culpados habituais.
- Relatórios e ownership: se uma falha pode ser diagnosticada pelo relatório do CI e se o time inteiro, não só o QA, age sobre ela.
Como usar o resultado com um time
Peça a duas ou três pessoas (um tester, um desenvolvedor, quem cuida do pipeline) que preencham separadamente e depois comparem os links compartilhados. Onde as respostas divergem costuma ser mais útil do que a própria nota: se uma pessoa escolhe “a cada pull request” e outra escolhe “noturno”, o time não concorda sobre o que o pipeline faz.
Escolha uma área de “Work on next” por trimestre. Levar uma área de 33 para 67 vale mais do que espalhar o esforço pelas seis. Refaça o scorecard no fim do trimestre com as mesmas pessoas.
Perguntas frequentes: Scorecard de maturidade em automação de testes
Como a nota é calculada?
Cada resposta vale 0, 1, 2 ou 3 pontos, na ordem em que as opções aparecem. Cada área tem duas perguntas, então vale até 6, mostrado como percentual. A nota geral é a média dos seis percentuais das áreas, arredondada. Níveis: Ad hoc abaixo de 35, Emergente 35–59, Estabelecido 60–84, Otimizado 85 ou mais.
Isto é um benchmark do mercado?
Não. O scorecard é uma rubrica fixa baseada em práticas de automação de testes amplamente aceitas, não uma comparação com outras empresas. Não há base de dados de outros times por trás dele, e o SDETRole não coleta suas respostas para criar uma.
Onde minhas respostas ficam guardadas?
No armazenamento local do navegador e no fragmento do link compartilhado (a parte depois do #) quando você o copia. Os navegadores não enviam o fragmento aos servidores, então o SDETRole nunca recebe suas respostas.
Se eu abrir o link de um colega, ele sobrescreve minhas respostas?
Não. Um resultado compartilhado é exibido sem ser salvo. Se você mudar uma resposta, começa sua própria cópia a partir das respostas dele, e essa cópia fica salva no seu navegador.
Ainda não temos automação. Isto ainda é útil?
Sim. Responda com honestidade e você vai pontuar baixo na maioria das áreas; a lista “Work on next” então diz por onde começar, que geralmente é estratégia (o que automatizar primeiro) e CI (rodar automaticamente desde o primeiro dia).