Módulo 7 · Sistemas de Informação · Semana 5 · Aula 4
Encontro expositivo e aplicado · 02/09/2026
Testes e cutover
Como se demonstra que um sistema empresarial está apto a entrar em operação: técnicas de teste, níveis de maturidade, o que muda em software de prateleira e o plano que conduz a virada.
Caixa-preta, branca e cinzaNíveis e tipos de testeTMMiSAP e COTSPlano de cutover
Aula 3 · o que foi parametrizadoRegra de negócio configurada e documentada no ERP.
Aula 4 · o que se verificaComportamento esperado, dados migrados e processo fim a fim.
Aula 4 · como se viraSequência, janela, critérios de go/no-go e retorno.
Ritual do projeto
Daily · 15 minutos
Cada grupo informa o avanço dos artefatos, a atividade prevista para o encontro e os impedimentos que exigem decisão.
15:00
O que foi concluídoO que será produzidoImpedimentosProgresso da entrega
Estrutura do encontro
Quarenta e cinco minutos de exposição, cinquenta e cinco minutos de sala invertida com pitch e cinco minutos de fechamento.
A atividade da segunda metade exige a leitura prévia do material da aula. Cada grupo executa uma tarefa distinta no ambiente do parceiro e a demonstra à turma ao final.
Qualidade como propriedade rastreável
A qualidade de um sistema empresarial se demonstra pela cadeia que liga o direcionador de negócio ao produto instalado. Cada camada existe porque a camada superior a exige e determina, por sua vez, o que deve ser verificado.
Por que o sistema existe
Enunciado da necessidade do negócio. Requisito sem direcionador correspondente não se admite no escopo.
O que faz e com que qualidade
O requisito funcional origina casos derivados da especificação. O cenário de qualidade fixa o estímulo, a resposta esperada e a medida exigida.
Decisão e tecnologia
A ADR registra a decisão estrutural e a tática que a realiza. O teste provoca a condição prevista no cenário e observa a resposta obtida.
Da parametrização à verificação
A Aula 3 encerrou com a regra configurada, documentada e rastreada. Esta aula estabelece como demonstrar que a configuração se comporta conforme o esperado e como conduzi-la até a operação.
RegraParametrizada no ERP
Caso de testeEntrada, ação e resultado esperado
ExecuçãoEvidência e defeito registrado
AceiteUsuário-chave assina o UAT
CutoverVirada e operação assistida
Engano humano
Ação da pessoa que produz um artefato incorreto: uma regra mal compreendida, um campo trocado na configuração.
Imperfeição no artefato
A consequência do erro registrada no código, na configuração ou no documento. Permanece latente enquanto o caminho não é executado.
Comportamento observado
A manifestação do defeito durante a execução. É o que o usuário percebe e o que o teste procura antecipar.
Verificação responde se o produto foi construído conforme a especificação. Validação responde se o produto atende à necessidade do negócio. Um ERP pode passar na primeira e falhar na segunda.
Caixa-preta: comportamento observável
O caso é derivado da especificação, sem conhecimento da estrutura interna. É a abordagem predominante em sistemas de prateleira, nos quais o código pertence ao fornecedor.
Como derivar os casos
- Partição de equivalência: agrupar entradas tratadas do mesmo modo e testar um representante de cada classe.
- Análise de valor-limite: exercitar a fronteira de cada classe, onde a maior parte dos defeitos se concentra.
- Tabela de decisão: combinar condições de negócio e o resultado esperado de cada combinação.
- Transição de estados: percorrer os estados do documento e as transições permitidas.
Alçada de aprovação de requisição
Regra: requisição até R$ 5.000,00 é aprovada pelo gestor imediato; acima disso, exige o diretor da área.
- Classes: valor até 5.000; valor acima de 5.000; valor inválido (negativo ou nulo).
- Limites: 4.999,99; 5.000,00; 5.000,01.
- Combinação: valor acima do limite com diretor inativo no cadastro.
O limite declarado na regra pertence a uma das duas classes. A especificação precisa dizer se R$ 5.000,00 exige o diretor, e o caso de teste precisa provar a interpretação adotada.
Caixa-branca: estrutura interna
O caso é derivado do código ou do fluxo de execução. Aplica-se ao que a equipe desenvolve: relatórios, extensões, integrações e código customizado sobre o produto de prateleira.
| Critério de cobertura | O que exige | Uso típico no projeto |
|---|---|---|
| Comando | Cada linha executável percorrida ao menos uma vez. | Piso mínimo para rotina customizada; detecta código nunca exercitado. |
| Decisão ou ramo | Cada desvio condicional avaliado como verdadeiro e como falso. | Regras de negócio com condição; expõe o caminho alternativo esquecido. |
| Condição | Cada condição atômica de uma decisão composta avaliada nos dois valores. | Cálculo fiscal e de desconto com múltiplos critérios combinados. |
| Caminho | Cada sequência completa de execução percorrida. | Inviável em rotina extensa; reserva-se a trechos críticos e curtos. |
Cobertura elevada indica apenas que o código foi executado. A verificação do resultado esperado depende da asserção do caso de teste.
Caixa-cinza: conhecimento parcial
O caso é derivado da especificação com acesso a estruturas internas: modelo de dados, contrato de interface, log de execução e tabela de configuração.
Integração entre sistemas
O testador conhece o contrato da interface e consulta a tabela de destino para confirmar o que foi gravado, sem acesso ao código do produto.
Diagnóstico da causa
A falha deixa de ser apenas observada na tela: o log e o registro no banco indicam em qual etapa o processamento divergiu.
Viés de projeto do caso
O conhecimento da estrutura tende a conduzir o teste pelos caminhos previstos, reduzindo a chance de encontrar o uso inesperado.
| Abordagem | Conhecimento exigido | Quem costuma executar | Defeito que revela |
|---|---|---|---|
| Caixa-preta | Especificação e processo de negócio | Analista funcional e usuário-chave | Regra ausente, cálculo divergente, fluxo bloqueado |
| Caixa-branca | Código e estrutura interna | Pessoa desenvolvedora | Caminho não tratado, exceção silenciosa, condição invertida |
| Caixa-cinza | Contrato, dados e configuração | Pessoa de integração e de qualidade | Divergência entre sistemas, dado corrompido no percurso |
Níveis e tipos de teste
O nível indica o objeto sob teste; o tipo indica a característica de qualidade verificada. Um projeto de implantação combina os dois eixos.
Do componente ao aceite
- Componente: unidade isolada de código ou objeto de configuração.
- Integração: a comunicação entre módulos e entre sistemas.
- Sistema: o processo de negócio completo no ambiente integrado.
- Aceitação: a decisão do usuário-chave sobre a aptidão para operar.
Por característica verificada
- Funcional: o resultado corresponde à regra especificada.
- Regressão: o que funcionava permanece funcionando após a alteração.
- Fumaça: verificação curta que autoriza o início do ciclo.
- Desempenho: tempo de resposta e comportamento sob volume.
- Segurança e autorizações: perfis, segregação de funções e trilha.
- Migração de dados: completude, integridade e reconciliação.
O teste de regressão é o que sustenta a operação continuada de um sistema de prateleira: cada nota, pacote de suporte e atualização do fornecedor exige a reexecução do conjunto crítico.
Maturidade do processo de teste
O modelo TMMi descreve cinco níveis cumulativos. A posição da organização determina quais perguntas ela consegue responder sobre a própria qualidade.
| Nível | Designação | O que caracteriza | Pergunta que a organização passa a responder |
|---|---|---|---|
| 1 | Inicial | Teste executado de forma reativa, ao final do desenvolvimento, sem planejamento próprio. | Nenhuma de forma sistemática; o resultado depende das pessoas envolvidas. |
| 2 | Gerenciado | Política, estratégia, planejamento, monitoramento, projeto de casos e ambiente definido. | O que foi testado, por quem, com qual resultado e sob qual critério de saída. |
| 3 | Definido | Processo padronizado na organização, teste integrado ao ciclo de vida, revisões e teste não funcional. | Como o teste de um projeto se compara ao de outro e onde o processo é ajustado. |
| 4 | Medido | Medição do processo e avaliação quantitativa da qualidade do produto. | Qual é a qualidade esperada da próxima entrega, com base em dado histórico. |
| 5 | Otimização | Prevenção de defeitos, otimização do processo e controle de qualidade estatístico. | Qual causa raiz eliminar para reduzir a classe de defeito mais cara. |
A escala avalia o processo de teste da organização, independentemente da aplicação considerada. Um sistema estável em organização de nível 1 depende do cuidado individual, sem garantia de que a próxima entrega repita o resultado.
Como medir a posição do projeto
Quatro indicadores tornam a maturidade observável no projeto do parceiro, sem a necessidade de avaliação formal.
1
Rastreabilidade
Proporção de regras de negócio com ao menos um caso de teste associado e executado.
2
Defeito escapado
Defeitos encontrados após o aceite, divididos pelo total encontrado. Indica a eficácia do ciclo anterior.
3
Reexecução
Tempo necessário para repetir o conjunto crítico após uma alteração. Determina a viabilidade da regressão.
4
Critério de saída
Existência de regra escrita que autoriza o encerramento do ciclo, com limite por severidade.
Registre os quatro valores hoje, ainda que estimados. Eles constituem a linha de base contra a qual a evolução do projeto será comparada nas próximas entregas.
Software de prateleira: o que muda
Em produto adquirido, o código pertence ao fornecedor e é testado por ele. A responsabilidade do cliente se desloca para a aderência ao próprio processo.
O produto padrão
- Correção funcional do código entregue.
- Compatibilidade entre versões e pacotes de suporte.
- Correção de defeito reportado, por nota ou atualização.
A implantação
- Parametrização e regras configuradas.
- Código customizado, extensões e relatórios próprios.
- Integrações com os demais sistemas da organização.
- Dados migrados do sistema anterior.
- Perfis de acesso e segregação de funções.
- Processo de ponta a ponta, atravessando módulos.
O defeito mais frequente em implantação de ERP decorre da combinação entre parametrização, dado migrado e processo real da organização.
Ciclo de testes em implantação SAP
A sequência abaixo corresponde à fase de realização da metodologia de implantação e antecede a preparação para a entrada em operação.
| Ciclo | Escopo | Quem executa | Critério de saída |
|---|---|---|---|
| Teste unitário de configuração | Cada parâmetro e objeto configurado, isoladamente. | Consultor funcional | Todo item da lista de configuração executado com evidência. |
| Teste de cadeia | Sequência de transações de um mesmo processo dentro do módulo. | Consultor funcional | Documento gerado e encerrado em cada etapa da cadeia. |
| Teste integrado | Processo de ponta a ponta entre módulos e sistemas satélites. | Equipe de projeto com usuário-chave | Cenários críticos concluídos; defeitos de severidade alta encerrados. |
| Teste de aceitação | Cenários de negócio conduzidos pelo usuário na linguagem da operação. | Usuário-chave da área | Termo de aceite assinado, com pendências classificadas. |
| Teste de regressão | Conjunto crítico reexecutado após nota, pacote de suporte ou transporte. | Equipe de qualidade, preferencialmente automatizada | Ausência de divergência em relação ao resultado anterior. |
| Teste de conversão | Carga dos dados migrados, com reconciliação de contagem e de saldo. | Equipe de dados com a área usuária | Totais conferidos com o sistema de origem, divergência justificada. |
Instrumentação e rastreabilidade
Em implantação de porte, o caso de teste é vinculado ao processo documentado e ao defeito correspondente, de modo que a cobertura seja demonstrável ao patrocinador.
Processo como âncora
Cada processo documentado recebe os casos que o exercitam. A cobertura passa a ser medida por processo de negócio, e não por transação isolada.
Planos e execuções
Ferramentas de gestão de teste do próprio ecossistema — Solution Manager e Cloud ALM — organizam plano, sequência, responsáveis e resultado de cada execução.
Reexecução viável
Automação por captura de interface ou por ferramenta de mercado torna a regressão executável a cada atualização, com custo compatível com a frequência exigida.
| Severidade | Definição operacional | Efeito sobre o cronograma |
|---|---|---|
| 1 · Crítica | Processo de negócio interrompido, sem alternativa manual. | Bloqueia a entrada em operação. |
| 2 · Alta | Processo executável apenas com contorno manual relevante. | Exige correção antes do aceite ou plano de contorno aprovado. |
| 3 · Média | Divergência que não impede a operação do processo. | Programada para a operação assistida. |
| 4 · Baixa | Melhoria de usabilidade, texto ou apresentação. | Registrada no backlog de evolução. |
Cutover: a virada para a operação
Entende-se por cutover o conjunto de atividades que transfere a operação do sistema anterior para o novo, dentro de uma janela definida e com critérios explícitos de decisão.
1
Sequência
Tarefas ordenadas, com responsável, duração estimada, dependência e ponto de verificação.
2
Janela
Intervalo acordado com o negócio, incluindo o congelamento do sistema anterior e o prazo máximo de indisponibilidade.
3
Dados
Carga final, reconciliação de contagens e saldos, e validação por amostragem com a área usuária.
4
Decisão
Critérios de continuidade avaliados em reunião formal, com autoridade nomeada para autorizar ou suspender.
EnsaioCutover simulado, cronometrado
CongelamentoSuspensão de mudanças no legado
Carga finalMigração e reconciliação
VerificaçãoTestes de fumaça em produção
Operação assistidaSuporte reforçado e monitoramento
Estratégias de virada
A escolha decorre do apetite a risco do negócio, da janela disponível e da capacidade de operar dois sistemas simultaneamente.
| Estratégia | Como opera | Quando é adequada | Risco assumido |
|---|---|---|---|
| Big bang | Todo o escopo entra em operação em uma única data. | Escopo integrado, janela curta disponível, legado com desligamento contratado. | Concentração de risco em uma data; retorno complexo após o início da operação. |
| Faseada | Entrada por módulo, unidade ou localidade, em ondas sucessivas. | Organização distribuída; equipe de suporte limitada. | Convivência temporária entre sistemas exige interfaces provisórias. |
| Paralela | Os dois sistemas operam com os mesmos dados e os resultados são comparados. | Processo de alto risco financeiro ou regulatório. | Custo elevado e duplicação do trabalho da área usuária. |
| Piloto | Uma unidade representativa opera primeiro e serve de referência. | Necessidade de validar premissas antes da adoção ampla. | Resultado do piloto pode não se reproduzir nas demais unidades. |
O plano de retorno é elaborado antes da virada e contém o prazo limite para acioná-lo. Após a entrada de transações no sistema novo, o retorno deixa de ser uma reversão simples e passa a exigir reconciliação.
Critérios de decisão e operação assistida
A decisão de virar se apoia em evidência confrontada com critérios acordados previamente.
O que se verifica antes
- Defeitos de severidade 1 e 2 encerrados ou com contorno aprovado.
- Aceite assinado pelos usuários-chave dos processos críticos.
- Reconciliação de dados concluída, com divergências justificadas.
- Ensaio de cutover executado dentro da janela prevista.
- Equipe de suporte escalada e canais de atendimento publicados.
O período após a virada
- Duração definida, com critérios de encerramento declarados.
- Monitoramento dos processos críticos e das interfaces.
- Fila prioritária de atendimento com acordo de tempo de resposta.
- Reunião diária de situação com o patrocinador.
- Transferência formal para a operação regular ao final.
Atividade · uma tarefa por grupo
Cinquenta e cinco minutos executados sobre a implantação em curso. Cada grupo recebe uma tarefa a realizar no ambiente do parceiro e a demonstra à turma no papel de comitê de aprovação.
A tarefa incide sobre o que já está implantado: as regras do catálogo parametrizadas em 26/08, a carga tratada na Aula 2, as interfaces em uso e os perfis de acesso configurados. O resultado atualiza os artefatos existentes do projeto, sem produção de documento novo.
10
PreparaçãoAbrir o ambiente com o perfil necessário e localizar no catálogo o objeto da tarefa.
DadosSelecionar os valores que serão usados, inclusive os de fronteira e os de exceção.
PapéisQuem opera o sistema, quem captura a evidência e quem demonstra no pitch.
25
ExecuçãoRealizar a tarefa no ambiente, capturando a tela de cada passo executado.
CorreçãoComportamento divergente da regra é corrigido na parametrização e reexecutado.
ResultadoO que permanece no projeto: parametrização comprovada, base conciliada ou tempos do ensaio.
20
PitchCinco minutos por grupo, com demonstração ao vivo no sistema.
ArguiçãoUma pergunta obrigatória do grupo seguinte, dirigida ao que foi executado.
DecisãoA turma registra se autorizaria a virada e a justificativa técnica.
Objeto sem insumo disponível é registrado como lacuna, com responsável e prazo, e substituído por outro do mesmo catálogo. Evidência fabricada invalida a demonstração.
As três tarefas
Cada tarefa é executada no ambiente do parceiro e produz um resultado que permanece no projeto.
Regra de maior risco
- No ambiente: executar no ERP a regra de maior impacto já parametrizada — caso nominal, valor no limite, primeiro valor fora da faixa e tentativa sem o aprovador previsto.
- Corrigir: comportamento divergente do que a regra determina é ajustado na parametrização e reexecutado.
- Fica no projeto: a regra comprovada nos quatro cenários, com as evidências vinculadas à ficha de parametrização.
Carga e interface
- No ambiente: reprocessar a carga tratada na Aula 2, comparar contagem e soma de um campo de valor entre origem e destino e disparar uma operação da interface até localizar o registro gravado.
- Corrigir: abrir um registro rejeitado, identificar a causa e reprocessá-lo.
- Fica no projeto: base conciliada, divergências identificadas por causa e pendências com responsável.
Ensaio da virada
- No ambiente: executar cronometrada a sequência da virada com os dados atuais — congelar entradas, extrair, carregar, conferir totais e liberar acesso — e tentar a operação restrita com perfil sem autorização.
- Verificar: reexecutar as regras já aceitas pelo parceiro e identificar as que as últimas alterações quebraram.
- Fica no projeto: o tempo real de cada passo, as regras que seguem válidas e o ponto de não retorno da janela.
O pitch: cinco minutos por grupo
A apresentação ocorre com o sistema aberto. A sequência define o que é executado diante da turma e o que o grupo sustenta em cada trecho.
| Tempo | No sistema | O que o grupo sustenta |
|---|---|---|
| 0:00–0:45 | O objeto da tarefa localizado no catálogo do projeto | Que regra, interface ou sequência foi verificada e por que ela é crítica para a virada |
| 0:45–2:30 | Execução ao vivo do cenário de fronteira e do cenário de exceção | O que a regra determina e o que o sistema efetivamente fez |
| 2:30–3:30 | A divergência encontrada e a correção aplicada na parametrização | A causa identificada, a correção feita em sala ou o defeito que permanece, com severidade |
| 3:30–4:15 | O efeito sobre a janela de virada | O que a janela precisa contemplar em razão do que foi executado, e em que prazo |
| 4:15–5:00 | A recomendação ao comitê | Entrar em operação, entrar com contorno ou não entrar, sustentado no que a turma acabou de ver |
Após cada pitch, o grupo seguinte formula uma pergunta dirigida ao que foi executado e a turma registra se autorizaria a virada, com a justificativa técnica correspondente.
Síntese do encontro
Seis proposições para conduzir a verificação e a virada do sistema do parceiro.
A decisão de entrar em operação se sustenta em evidência de teste e em plano de virada, com critérios definidos antes da data.
1 · Técnica conforme o objeto
Caixa-preta para o produto configurado, caixa-branca para o código próprio, caixa-cinza para a integração.
2 · Nível e tipo combinados
O nível define o objeto sob teste; o tipo define a característica verificada.
3 · Maturidade observável
Rastreabilidade, defeito escapado, tempo de reexecução e critério de saída medem a posição do projeto.
4 · Prateleira desloca o foco
Testa-se a parametrização, a integração, o dado migrado, a autorização e o processo fim a fim.
5 · Regressão sustenta a operação
Cada atualização do fornecedor exige a reexecução do conjunto crítico.
6 · Retorno planejado antes
O plano de retorno e seu prazo limite são definidos antes da janela de virada.
Referências do encontro
Fontes normativas e técnicas para aprofundamento e consulta durante a atividade.
Fundamentos de teste
- ISO/IEC/IEEE 29119 — Software testing, partes 1 a 4.
- ISTQB — Certified Tester Foundation Level Syllabus.
- TMMi Foundation — Test Maturity Model integration.
- ISO/IEC 25010 — Modelo de qualidade de produto.
Prática em sistemas empresariais
- SAP Activate — fase de realização e preparação para a entrada em operação.
- SAP — gestão de teste no Solution Manager e no Cloud ALM.
- ITIL 4 — habilitação de mudança e liberação.
- PMBOK — encerramento de fase e transferência para a operação.
Próximo encontro: gestão de mudanças, requisição formal de mudança e governança da alteração em ambiente produtivo.
Sobre este encontro
Testes e cutover no contexto de sistemas empresariais · 02/09/2026 · Prof. Afonso
Objetivo de aprendizagem
Ao final do encontro, o estudante deve ser capaz de selecionar a técnica de teste adequada ao objeto verificado, derivar casos a partir de uma regra parametrizada no ERP, avaliar a maturidade do processo de teste do próprio projeto e elaborar o plano de cutover correspondente, sustentando a recomendação de entrada em operação com evidência de execução.
Estratégia do encontro
Exposição dialogada em quatro blocos — técnicas de caixa-preta, caixa-branca e caixa-cinza; níveis e tipos de teste; maturidade do processo; verificação em software de prateleira e plano de cutover — seguida de atividade em sala invertida: cada grupo recebe um recorte técnico, ensina-o à turma e o aplica ao sistema do parceiro, encerrando com pitch de cinco minutos perante a turma no papel de comitê de aprovação.
Estrutura do encontro
- Daily: estado dos artefatos, atividade prevista e impedimentos — 15 min
- Abertura: da parametrização à verificação; erro, defeito e falha; verificação e validação — 5 min
- Técnicas e níveis: caixa-preta, caixa-branca, caixa-cinza; níveis e tipos de teste — 20 min
- Maturidade: os cinco níveis do TMMi e os quatro indicadores observáveis no projeto — 6 min
- Software de prateleira: divisão de responsabilidade e ciclos de teste em implantação SAP — 8 min
- Cutover: plano, ensaio, estratégias de virada, critérios de decisão e operação assistida — 6 min
- Sala invertida: estudo dirigido, produção com evidência e pitch com arguição — 55 min
- Fechamento: síntese das seis proposições e encaminhamento para a Aula 5 — 5 min