Como este tema funciona na sua empresa
Termo de aceite é simples (confirmação visual que está pronto). Desafio: não tem expertise para testar. Abordagem: fornecedor faz teste, você valida visualmente em reunião (30 minutos), aceita quando "parece pronto". Garantia curta (30 dias), fornecedor corrige bugs descobertos sem custo durante garantia. Documentação informal (email confirmando aceite é suficiente).
Termo de aceite formal com critério documentado. Desafio: balancear rigor de testes e velocidade de go-live. Abordagem: teste funcional antes de aceite (2-4 semanas), termo assinado por ambas partes (checklist de funcionalidades), garantia 60-90 dias com SLA de correção. Documentação: ata de reunião de teste, termo de aceite assinado.
Termo de aceite muito rigoroso (teste de performance, segurança, carga). Desafio: teste não pode bloquear projeto indefinidamente. Abordagem: teste automatizado antes de aceite (4-6 semanas), critério de aceite muito clara (funcionalidades, performance, segurança), garantia 90-180 dias com SLA escalada por severidade. Documentação: relatório completo de teste, termo formal assinado.
Termo de aceite é documento formal que formaliza entrega de projeto, confirmando que atende critério acordado. Garantia é período após aceite quando fornecedor corrige bugs descobertos sem custo adicional. Ambos são críticos: aceite define quando responsabilidade passa para cliente; garantia limita quanto tempo fornecedor responde gratuitamente[1].
Rigor de teste antes de aceite
Teste é etapa onde você valida que projeto atende requisitos. Antes de aceitar, não pagar última parcela sem teste completo. Pequenas empresas frequentemente confiam em "parece funcionar" (risco: descobre bug depois, fornecedor diz "fora de garantia"). Melhor prática: definir critério de aceite claro antes do projeto (exemplo: "sistema deve suportar 100 usuários simultâneos, com tempo de resposta < 2 segundos, com uptime de 99.5%"). Validar cada critério antes de aceitar. Documentar resultado do teste (passou ou falhou em quais critérios). Se falhou, não aceitar; pedir correção. Teste deve ser realista: use dados de produção (ou similar), simule carga real, teste funcionalidades críticas.
UAT (User Acceptance Testing): teste com usuários reais
UAT é fase onde usuários finais testam se software atende necessidade deles (não apenas requisitos técnicos). Típico: 2-4 semanas. Fornecedor oferece ambiente de teste; usuários testam com dados reais ou similares; fornecedor oferece suporte durante UAT. Resultado: lista de defeitos descobertos durante UAT. Pequenos defeitos podem ser aceitos com "ressalvas" (documentados no termo de aceite); críticos impedem aceite. Exemplo: sistema funciona, mas relatório de vendas não aparece; crítico, bloqueia aceite; fornecedor deve corrigir antes. Outro exemplo: botão "Ajuda" não funciona; menor, pode aceitar com ressalva ("Ajuda será corrigida em 30 dias pós-aceite").
Período de garantia: duração e SLA
Após aceite, período de garantia começa. Durante este período, fornecedor corrige bugs sem custo. Duração típica: pequena (30 dias), média (60-90 dias), grande (90-180 dias). Quanto maior o projeto, maior a garantia (mais provável descobrir bugs depois). SLA durante garantia deve ser agressivo (incentiva rápida correção). Exemplo: garantia 90 dias, crítico: 2 dias para resposta; alto: 5 dias; médio: 10 dias. Após garantia, qualquer bug é "suporte" (você paga). Deixar claro no contrato: quando termina garantia? Qual é a diferença entre bug durante garantia (grátis) e após garantia (pago)? Defeito descoberto 1 dia após término de garantia é responsabilidade sua (risco alto); considerar garantia estendida para crítico (ex: 180 dias para crítico, 90 para menor).
Processo de aceite: (1) fornecedor entrega; (2) você (e um usuário-chave) testam por 1-2 semanas informalmente; (3) assinam termo de aceite simples (checklist de funcionalidades); (4) garantia 30 dias. SLA durante garantia: fornecedor responde em 24h, corrige em 3-5 dias. Documentação: email ou formulário simples com data e assinatura. Risco: descobrir bug na semana 5 pós-aceite, estar fora de garantia, ter de pagar para corrigir. Mitigation: se descobrir bug cedo (primeira semana pós-aceite), pedir favor a fornecedor (geralmente corrige mesmo fora de garantia se é bug óbvio).
Processo de aceite: (1) UAT de 2-4 semanas com usuários reais; (2) lista de defeitos é criada; (3) críticos: correção antes de aceite; menores: "aceito com ressalvas" (documentar); (4) termo de aceite formal assinado (ata de reunião + checklist); (5) garantia 60-90 dias. SLA durante garantia: crítico 2 dias, alto 5 dias, médio 10 dias. Documentação: relatório de UAT, termo de aceite assinado. Contrato deve especificar: qual é o critério de "aceito com ressalvas"? Fornecedor deve corrigir em quanto tempo? (p.ex.: dentro de 30 dias pós-aceite, sem custo).
Processo de aceite: (1) teste técnico (performance, segurança, carga) de 4-6 semanas; (2) UAT com usuários finais de 3-4 semanas; (3) lista de defeitos é gerenciada por severidade; (4) críticos bloqueiam aceite; menores aceitáveis com ressalvas documentadas; (5) termo formal assinado (relatório completo de teste, evidência de execução); (6) garantia 90-180 dias. SLA durante garantia muito agressivo: crítico 4h, alto 8h, médio 24h, menor 3 dias. Documentação: relatório de teste (automático + manual), UAT report, termo de aceite. Contrato deve especificar: quem paga se descobrir bug crítico 6 meses depois? (típico: garantia cobre 6 meses para crítico, 90 dias para menor).
Defeito vs. Mudança: distinção critica
Durante garantia, distinção entre "defeito" (você não paga) e "mudança" (você paga) é crítica. Defeito: software não atende critério acordado. Exemplo: sistema foi entregue para processar 100 usuários; você testa com 150 e fica lento; é defeito (fornecedor entregou fora de spec). Mudança: você pede funcionalidade não prevista. Exemplo: sistema funciona bem, mas você pede novo relatório que não foi combinado; é mudança (você paga). Disputa comum: você diz "é defeito, esperava isso"; fornecedor diz "é mudança, nunca foi solicitado". Mitigar: deixar critério de aceite muito claro no contrato (o que é in-scope vs. out-of-scope). Exemplo: "In-scope: relatório de vendas diárias, relatório de estoque. Out-of-scope: relatório de previsão de vendas" (muito específico).
Não pagar última parcela sem termo de aceite assinado
Estratégia financeira importante: não pague última parcela do contrato até término de garantia (ou mínimo até aceite assinado). Isso dá alavanca para fornecer corrigir problemas. Exemplo: contrato R$100k em 4 parcelas; última parcela de R$25k só é paga após 30 dias de garantia. Se durante garantia descobrir bugs, fornecedor tem incentivo a corrigir (não recebe última parcela se deixar bug aberto). Cuidado: fornecedor pode rejeitar esta abordagem (quer receber tudo antes de aceite). Negociar: "última parcela (20% do total) só após 30 dias de garantia". Isto é justo: você paga pelo trabalho, mas fornecedor tem responsabilidade pós-entrega.
Sinais de que sua empresa está em risco com termo de aceite fraco
Se você se reconhece em três ou mais cenários abaixo, fortaleça seu processo de aceite.
- Aceitou projeto verbal ("fornecedor disse que está pronto"; nenhum documento formal)
- Pagou última parcela antes de testar; agora descobriu bugs que fornecedor recusa corrigir
- Garantia muito curta (30 dias); descobriu bugs críticos na semana 5
- Teste foi apenas "visual"; ninguém testou funcionalidades complexas ou performance
- Termo de aceite não especificou critério; "aceito como está" é muito vago
- Garantia não tem SLA; fornecedor responde "quando tiver tempo" a bugs descobertos
- Não tem documentação de teste; se houver disputa, não tem prova do que foi testado
Caminhos para estruturar seu processo de aceite
Fazer teste robusto internamente antes de aceitar.
- Perfil necessário: gestor de projeto + usuários chave + técnico TI
- Tempo estimado: 2-4 semanas para UAT completo
- Faz sentido quando: projeto é crítico; você tem recursos internos para testar
- Risco principal: teste interno pode não ser tão rigoroso quanto deveria
Contratar especialista em teste de aceitação para validar entrega.
- Tipo de fornecedor: consultores de QA (qualidade) e teste de aceitação
- Vantagem: teste mais rigoroso, independente, expertise em diferentes tipos de sistemas
- Faz sentido quando: projeto é grande/crítico; você quer garantia de teste independente
- Resultado típico: 4-6 semanas, relatório completo de testes, confiança de que foi testado bem
Precisa estruturar seu processo de aceite e garantia?
Termo de aceite fraco pode custar caro (bugs pós-garantia = você paga, fornecedor recusa). oHub conecta você gratuitamente a consultores de teste e gerentes de projeto que ajudam a definir critério de aceite claro e período de garantia adequado. Em menos de 3 minutos, descreva seu projeto (tipo, criticidade, tamanho) e receba recomendação personalizada, sem compromisso.
Encontrar fornecedores de TI no oHub
Sem custo, sem compromisso. Você recebe orientação e decide se quer apoio especializado.
Perguntas frequentes
Quanto tempo dura período de garantia típico?
Varia: pequeno projeto (30 dias), médio (60-90 dias), grande/crítico (90-180 dias). Regra: quanto mais complexo projeto, maior a garantia. Considerar: qual é a janela de tempo onde é provável descobrir bugs? Para software, 2-3 meses é comum. Para infraestrutura, 6 meses é comum (mais lentamente aparecem problemas sob carga normal).
O que fazer se defeito aparece 5 dias após término de garantia?
Tecnicamente, está fora de garantia; você paga. Mas se é defeito óbvio (não é mudança), pedir favor a fornecedor (muitas vezes aceitam corrigir como "gesto de boa vontade"). Se fornecedor recusa, você tem duas opções: (1) pagar para corrigir, (2) aceitar e conviver. Para futuro, negociar garantia estendida para defeito crítico (180 dias em vez de 90).
Teste de performance deve ser antes de aceite?
Sim, absolutamente. Se requisito é "sistema deve suportar 1000 usuários simultâneos", validar isto ANTES de aceitar. Teste de carga é crítico para sistemas que têm requisito de performance. Fazer teste de carga em produção após aceite é arriscado (pode descobrir insuficiência tarde demais). Melhor: teste de carga em ambiente de teste que simula produção, antes de aceite.
Qual é diferença entre "aceito com ressalvas" e "aceito"?
"Aceito": entrega atende todos os critério; garantia começa. "Aceito com ressalvas": entrega atende critério, mas há bugs menores que você tolera (documentados); fornecedor deve corrigir em prazo específico (durante garantia) sem custo. Recurso importante: permite ir-live sem bloquear projeto em bugs menores. Mas deixar muito claro: quais são as ressalvas, qual é o prazo para correção, qual é o SLA.
Como estruturar SLA durante garantia?
SLA durante garantia deve ser mais agressivo que fora de garantia (incentiva rápida correção). Exemplo: crítico (durante garantia: 2 dias; fora: 5 dias); alto (durante: 5 dias; fora: 10 dias). Ou usar modelo de "escalação": primeira semana de garantia = SLA muito agressivo (24h); segunda/terceira semana = menos agressivo (3 dias). Objetivo: incentivar fornecedor a corrigir bugs rápido enquanto sob garantia.
Quando é "mudança" vs. "defeito"?
Defeito: software não faz o que foi combinado (está fora de especificação). Mudança: você pede funcionalidade que não foi combinada. Exemplo: defeito = "relatório de vendas deveria somar, mas não está somando correto"; mudança = "pode incluir também coluna de margem?" (nunca foi solicitado). Mitigar: deixar escopo muito claro no contrato (o que é in-scope vs. out-of-scope). Sem clareza, disputa é garantida.
Fontes e referências
- PMI — Project Management Institute: PMBOK Guide and Acceptance Testing Standards. PMI, 2021.
- ISO/IEC 5055:2021 — Software Quality and Acceptance Criteria. International Organization for Standardization.
- Gartner: Testing and Acceptance Practices in IT Projects. Gartner Research, 2023.
- IEEE Standards Association: Standards for Software Testing and Acceptance. IEEE, 2022.