1 pontos por kyo3553 7 시간 전 | 1 comentários | Compartilhar no WhatsApp

Olá. Estou criando o QAMap, um CLI local que lê o contexto das mudanças em um PR e projeta o QA necessário.

O gargalo que senti em equipes de produto não era escrever código de teste, mas sim reavaliar a cada PR “o que exatamente esta mudança precisa comprovar”. No começo, eu analisava o diff e a estrutura do projeto para recomendar rascunhos de E2E com Playwright·Maestro, mas na prática isso acabava ficando no que os desenvolvedores já sabiam e em testes simples de tela de sucesso.

Por isso, mudei o objetivo. Em vez de tentar entender perfeitamente todos os domínios, o foco é organizar a intenção da mudança e o fluxo funcional com base em commits e diffs, e sugerir QAs com alta probabilidade de terem sido esquecidos entre casos normais, de falha, de limite e de transição de estado. Quando é difícil ter certeza, também mostro a justificativa e o nível de confiança.

No fim, o objetivo é ser uma ferramenta local de QA que, quando um PR for aberto, encontre as funcionalidades impactadas, monte os E2Es e os mock·fixture necessários, execute tudo com segurança e ainda registre a base da validação. No momento está na v0.4.0, e estou atualizando aos poucos para me aproximar desse objetivo, validando um a um os casos em que ele erra em repositórios reais.

Como ainda está em estágio inicial, pode interpretar algo de forma incorreta ou deixar passar cenários importantes. O que mais preciso agora são casos reais de falha. Se o QAMap fizer uma avaliação sem sentido ou sugerir testes que não podem ser usados, fiquem à vontade para me avisar.

1 comentários

 
jeongjin0 1 시간 전

Gosto da abordagem de sugerir até casos de borda e transições de estado com base no diff localmente. Acho que, se ficasse mais claro de qual hunk do diff ou arquivo a justificativa de cada cenário foi extraída, seria mais fácil filtrar falsos positivos durante a revisão.