A versão candidata chegou
A equipe da Escola Horizonte informa que a Cantina Horizonte está pronta para uma última avaliação antes do uso.
Seu trabalho não é “caçar defeitos até cansar”. É organizar uma avaliação coerente e produzir um parecer técnico.
Versão candidata é uma versão considerada próxima da liberação e submetida a verificações finais antes de ser tratada como pronta.
Desta vez, ninguém vai dizer qual técnica usar
Nos exercícios anteriores, muitas vezes o problema indicava diretamente a técnica que estávamos aprendendo. Agora você precisa reconhecer sozinho o que faz sentido.
Quantidade possui limites. Cupom combina condições. Status depende de estados. Estoque envolve integração. Fluxos críticos podem ser automatizados. Algumas características precisam de observação humana.
Seu primeiro trabalho é decidir como avaliar, e justificar essas escolhas.
Antes de executar, defina o que significará “pronto” neste contexto
Não existe um número mágico universal de testes que transforme qualquer software em “pronto”. Por isso, estabeleça critérios de saída antes da rodada.
Critérios de saída
São condições usadas para decidir se uma atividade de teste possui evidências suficientes para ser encerrada ou se a versão pode seguir para a próxima etapa do processo.
Na Cantina Horizonte, por exemplo, você pode exigir evidências para requisitos de maior risco, ausência de defeitos com impacto inaceitável, regressão executada, pipeline sem falhas não explicadas e limitações registradas.
Comece de um estado conhecido
Antes da rodada final, restaure os dados para que resultados antigos não confundam sua avaliação.
- Encerre qualquer servidor da Cantina com
Ctrl+C. - No Windows, execute
resetar_dados_windows.bat. Em outro ambiente, usepython resetar_dados.py. - Inicie novamente a Cantina.
- Confirme que o Sanduíche voltou ao estoque 8 e o Salgado ao estoque 10.
Agora trate esse estado como a versão candidata da sua avaliação.
O projeto final começa pelo planejamento
- identifique a versão, o ambiente e o objetivo da rodada;
- defina o que entra e o que fica fora do escopo;
- revise requisitos e regras antes de executar;
- priorize riscos;
- defina seus critérios de saída;
- escolha técnicas e níveis de teste adequados ao que pretende avaliar.
Depois, execute como uma equipe de qualidade
Use o que aprendeu quando houver uma razão concreta: revisão estática, partições, limites, tabela de decisão, transição de estados, testes de unidade, integração, sistema, API, E2E e observações não funcionais.
Não é obrigatório usar todas as técnicas em todas as áreas. Uma escolha menor, mas bem justificada, vale mais do que um catálogo de testes sem propósito.
A rastreabilidade precisa chegar até a conclusão
Não é necessário criar uma planilha gigantesca. O importante é conseguir mostrar de onde veio cada conclusão importante.
Pipeline verde não encerra a análise
Execute os testes automatizados e observe o GitHub Actions no seu repositório de exercício. Se tudo passar, isso vira uma evidência útil.
Mas continue perguntando:
O que foi coberto?
Quais comportamentos realmente possuem testes automatizados?
O que ficou de fora?
Quais riscos, ambientes ou características ainda não foram avaliados?
Essa diferença entre “o que sabemos” e “o que ainda não sabemos” faz parte de um parecer profissional.
Defeito conhecido não significa automaticamente a mesma decisão em todo contexto
Um problema que permite estoque negativo pode inviabilizar uma liberação. Já um pequeno desalinhamento visual pode ser documentado e tratado depois, dependendo do contexto e dos critérios acordados.
Por isso, severidade, prioridade, risco e critérios de saída precisam conversar entre si.
Qualidade não é esconder defeitos conhecidos. É torná-los visíveis e avaliar seu impacto com responsabilidade.
Faça também uma pequena validação de uso
Peça para alguém representar a pessoa que trabalharia na cantina e realizar um pedido sem receber instruções detalhadas.
Observe se o fluxo, as mensagens e o resultado atendem à necessidade real. Isso retoma a diferença entre verificar se construímos corretamente e validar se a solução serve ao uso esperado.
Use o modelo de parecer técnico
Documento final
Abrir modelo de parecer técnico →
Adapte o modelo ao que você realmente executou. Não preencha campos apenas para “completar formulário”.
A conclusão deve ser curta, mas sustentada
Evite frases como:
“Testei bastante e parece bom.”
Prefira uma conclusão que diga o que foi avaliado, quais evidências foram obtidas, quais riscos permanecem e o que não foi testado.
Para este projeto, o parecer pode usar três situações práticas: Liberar, Liberar com restrições ou Não liberar ainda. O mais importante é a justificativa ligada aos critérios definidos.
O que será observado no projeto final
| Aspecto | O que demonstra aprendizagem |
|---|---|
| Planejamento | Escopo, riscos e critérios de saída fazem sentido para a versão. |
| Projeto dos testes | As técnicas foram escolhidas pelo problema, não pelo nome. |
| Execução | Resultados e evidências permitem compreender o que ocorreu. |
| Defeitos | Registros são reproduzíveis e possuem impacto analisado. |
| Automação | Testes automatizados e CI são usados como evidência, sem exagerar seu alcance. |
| Conclusão | O parecer reconhece resultados, riscos, limitações e ações necessárias. |
Volte mentalmente à Etapa 0
No começo, a pergunta era:
“O sistema abriu e fez um pedido. Está pronto?”
Agora a mesma pergunta exige outra postura. Você sabe procurar referência no requisito, escolher dados com método, combinar condições, observar estados, priorizar riscos, registrar evidências, comunicar defeitos, automatizar regressão, testar integrações e acompanhar verificações automáticas.
O objetivo nunca foi provar que o software é perfeito. Foi aprender a dizer o que sabemos sobre sua qualidade — e sustentar isso com evidências.
Transferência MbB — da Cantina para a Conecta
A Cantina Horizonte foi o nosso laboratório executável de qualidade e testes. Agora vamos verificar se o raciocínio aprendido consegue atravessar para outro sistema sem reconstruí-lo.
Faça a transferência
- Abra o Dossiê Final da Assistência Técnica Conecta e escolha um requisito ou uma regra de negócio.
- Escreva pelo menos um caso de teste indicando condição inicial, ação ou entrada e resultado esperado.
- Escolha uma técnica ou nível de teste estudado neste módulo e explique por que ele combina com esse requisito.
- Indique qual evidência seria necessária para concluir se o comportamento passou ou falhou.
- Separe o que já pode ser verificado nos artefatos da análise daquilo que só poderá ser executado quando existir uma implementação testável.
O objetivo não é substituir a Cantina pela Conecta. É provar que o método de qualidade e teste aprendido em um sistema pode ser aplicado conscientemente em outro.
Fechamento
Software de qualidade não nasce no último teste. A qualidade acompanha o produto desde a primeira regra, passa por cada decisão de projeto e precisa continuar sendo observada em cada nova versão.
Quando o sistema mudar novamente, a pergunta volta. E o processo começa outra vez, agora com mais conhecimento e evidências acumuladas.
Ao concluir o módulo
Você deve ser capaz de avaliar uma versão de software escolhendo técnicas adequadas, planejando e executando testes, registrando evidências e defeitos, usando automação quando fizer sentido e produzindo um parecer técnico que reconheça riscos e limitações.