QA Learning / Git

Módulo 3: Pull Request e o papel do QA

Abrir um PR, ler um diff com olhos de quem testa, e entender o ✓ e o ✗ do CI

Aquecimento: 2 perguntas do Módulo 2

1. Para que serve a área de preparo (staging)?
Para escolher o que entra em cada commit: commit é uma unidade de sentido, não um backup de tudo que você mexeu no dia.

2. Por que trabalhar em branch e não direto na main?
Porque o branch cria o "antes de entrar": o CI roda, o PR mostra o resultado, e a main só recebe o que passou.

O que é um Pull Request

O Pull Request (no GitLab, Merge Request) é o pedido formal: "peguei este branch, fiz estas mudanças, por favor revisem e juntem na main".

Ele é muito mais do que um botão de juntar. Um PR reúne, num lugar só:

  • o diff: todas as linhas adicionadas e removidas, arquivo por arquivo;
  • a discussão: comentários presos a linhas específicas do código;
  • os checks do CI: o ✓ ou ✗ de cada pipeline que rodou;
  • a aprovação: quem revisou e liberou.

Para QA, o PR é o melhor momento do processo. É onde você descobre o que mudou antes de a mudança existir em qualquer ambiente, em vez de receber a versão pronta e adivinhar o que testar.

Abrindo o seu

  1. Depois do git push, abra o seu repositório no GitHub. Aparece uma faixa amarela: "Compare & pull request".
  2. Escreva um título que diga o que muda (mesma lógica do título de bug do Módulo 5 de Fundamentos) e uma descrição com: o que muda, por quê, e como testar.
  3. Clique em Create pull request.
  4. Espere: em alguns segundos os checks aparecem no rodapé do PR. É o CI rodando sozinho.

Se você está trabalhando no seu próprio fork, abra o PR do seu branch para a main do seu próprio repositório, assim o pipeline roda na sua conta e você pode mexer nele à vontade.

Ler um diff com olhos de QA

Você não precisa saber programar para tirar valor de um diff. Precisa saber fazer perguntas. Ao abrir a aba Files changed:

  • Quais arquivos foram tocados? Se a história era sobre o carrinho e o diff mexe em autenticação, isso é uma pergunta, não uma acusação, uma pergunta.
  • Algum número mudou? Limites, percentuais, tamanhos máximos. Todo número alterado é um caso de valor limite esperando por você (Fundamentos, Módulo 3).
  • Alguma condição mudou? Um > que virou >=, um and que virou or. São as mudanças de uma linha que mais causam defeito.
  • O que foi removido? Linhas vermelhas são risco: uma validação apagada é um caminho que ficou aberto.
  • Veio teste junto? Um PR que muda comportamento sem tocar em nenhum teste é uma pergunta legítima na revisão.
  • Mexeu em migração de banco? Então existe risco de dados, e vale conferir no banco depois de subir, é exatamente o que a Trilha de SQL te prepara pra fazer.

Comentário de QA em PR não precisa ser sobre código. "Essa condição agora aceita valor igual a 300: o requisito diz 'acima de 300'. Qual é o certo?" é o tipo de comentário que evita bug antes de ele existir.

Os checks: o ✓ e o ✗

No rodapé do PR aparece uma lista de verificações automáticas. Neste repositório existem duas, que você vai conhecer por dentro na Trilha de CI/CD: 

✓  trilha-3-pytest / pytest      Successful in 42s
✗  trilha-5-k6 / carga           Failing after 1m 10s     Details
  • ✓ verde: aquele pipeline rodou e todos os comandos terminaram bem.
  • ✗ vermelho: algum comando falhou. Clique em Details pra ver o log completo: a saída é a mesma que apareceria no seu terminal.
  • 🟡 amarelo: ainda rodando.

O que fazer diante de um ✗: abra o log, role até o fim (a falha normalmente está nas últimas linhas), e leia a mensagem. Na prática ela cai em três casos: um teste falhou de verdade (ótimo, o CI fez o trabalho dele), o ambiente do pipeline quebrou (faltou dependência), ou o teste é instável (flaky), e aí você tem um problema mais sério do que o bug.

Nunca normalize o vermelho. Um time que convive com checks falhando perde o sinal: quando o ✗ importar de verdade, ninguém vai olhar.

Olhar de QA

Aprender Git não é sobre decorar comandos: é sobre conseguir participar da conversa onde as decisões acontecem. Com Git você lê o que mudou em vez de perguntar, comenta na linha exata em vez de mandar mensagem solta, versiona os seus próprios testes, e entende por que o build está vermelho. É o que transforma QA de "quem recebe a versão pronta" em parte do time que a constrói.

Sua vez

  1. Abra um Pull Request do branch que você publicou no Módulo 2.
  2. Escreva uma descrição com três seções: o que muda, por quê, como testar.
  3. Espere os checks e veja o resultado. Clique em Details em um deles e leia o log até achar a linha onde os testes rodaram.
  4. Vá na aba Files changed e deixe um comentário numa linha específica do seu próprio arquivo, só pra ver como funciona.
  5. Faça o merge do PR e depois rode, na sua máquina: git switch main e git pull. A sua mudança está lá.

Feito isso, você tem o ciclo completo de trabalho de um time de software, e está pronto pras Trilhas de pytest e CI/CD, que partem exatamente daqui.

Terminou este módulo? Marque: o ✓ aparece no índice da trilha e a barra de progresso anda no começo do site. Fica salvo só no seu navegador.