1. Como ler este material
Este material antecede o encontro. A segunda metade da aula é conduzida em sala invertida sobre a implantação em curso: cada um dos três grupos executa uma tarefa distinta sobre um objeto já implantado no sistema do parceiro. A seção 14 descreve as três tarefas e o que cada uma deixa registrado no projeto.
O texto trata de duas questões encadeadas. A primeira é como demonstrar que um sistema empresarial se comporta conforme o esperado, o que envolve técnicas de derivação de casos, níveis de teste e maturidade do processo. A segunda é como transferir a operação do sistema anterior para o novo, o que envolve plano de virada, critérios de decisão e operação assistida.
Os exemplos partem do ERP configurado na Aula 3. A regra parametrizada por cada grupo é o objeto sobre o qual as técnicas serão exercitadas.
2. Erro, defeito e falha
A literatura de teste distingue três termos que a linguagem corrente costuma confundir. O erro é o engano humano: a pessoa que interpreta incorretamente a regra de alçada e configura o limite errado. O defeito é a imperfeição resultante, registrada no artefato — a tabela de configuração com o valor incorreto. A falha é o comportamento observado quando o defeito é exercitado: a requisição de seis mil reais aprovada por quem não tem alçada para tanto.
A distinção tem consequência prática. O defeito existe desde a configuração, ainda que ninguém o perceba; ele se converte em falha apenas quando o caminho é percorrido. Por isso, a ausência de falhas observadas demonstra apenas que os caminhos executados até o momento não alcançaram os defeitos existentes.
Verificação e validação
A verificação confronta o produto com sua especificação: o sistema faz o que foi escrito que ele faria. A validação confronta o produto com a necessidade: o que foi escrito corresponde ao que a organização precisa. Um sistema empresarial pode ser aprovado na verificação e reprovado na validação, quando a especificação registrou uma regra que a operação real não pratica.
3. Caixa-preta
Na abordagem de caixa-preta, os casos são derivados da especificação, sem conhecimento da estrutura interna. É a abordagem predominante em implantação de sistemas de prateleira, porque o código pertence ao fornecedor e o que se verifica é o comportamento resultante da configuração.
Partição de equivalência
Entradas tratadas do mesmo modo pelo sistema formam uma classe de equivalência. Testa-se um representante de cada classe, sob a premissa de que o comportamento observado se estende aos demais membros. Para a regra de alçada, as classes são: valor até o limite, valor acima do limite e valor inválido.
Análise de valor-limite
Os defeitos se concentram na fronteira entre classes, porque é ali que a comparação é escrita. Para um limite de cinco mil reais, exercitam-se os valores imediatamente abaixo, exatamente igual e imediatamente acima. A especificação precisa declarar a qual classe o valor exato pertence.
Tabela de decisão
Quando a regra combina mais de uma condição, a tabela de decisão organiza as combinações e o resultado esperado de cada uma. Ela expõe as combinações que a especificação não previu, que são a origem frequente do defeito encontrado em produção.
| Valor | Centro de custo | Diretor ativo | Resultado esperado |
|---|---|---|---|
| Até 5.000 | Válido | Indiferente | Aprovação pelo gestor imediato |
| Acima de 5.000 | Válido | Sim | Encaminhamento ao diretor |
| Acima de 5.000 | Válido | Não | Bloqueio com mensagem de substituto ausente |
| Qualquer | Bloqueado | Indiferente | Recusa na criação da requisição |
Transição de estados
Documentos de ERP percorrem estados definidos: criada, liberada, aprovada, convertida em pedido, encerrada. O teste percorre as transições permitidas e tenta as proibidas, verificando se o sistema impede o retrocesso indevido e preserva o histórico.
4. Caixa-branca
Na abordagem de caixa-branca, os casos são derivados da estrutura interna do código. No contexto de implantação, ela se aplica ao que a equipe desenvolve sobre o produto padrão: relatórios próprios, rotinas de carga, extensões e integrações.
A medida associada é a cobertura. A cobertura de comando exige que cada linha executável seja percorrida ao menos uma vez. A cobertura de decisão exige que cada desvio condicional seja avaliado como verdadeiro e como falso, o que revela o caminho alternativo que ninguém exercitou. A cobertura de condição trata cada condição atômica de uma expressão composta. A cobertura de caminho exige percorrer cada sequência completa de execução e cresce de forma combinatória, o que a restringe a trechos curtos e críticos.
5. Caixa-cinza
A abordagem de caixa-cinza deriva os casos da especificação, com acesso parcial a estruturas internas: o contrato da interface, o modelo de dados de destino, o log de execução e as tabelas de configuração. É a abordagem característica do teste de integração em ambiente empresarial.
O ganho é o diagnóstico. Quando a nota fiscal não aparece no sistema fiscal, o testador de caixa-preta registra a ausência; o testador de caixa-cinza consulta o log da interface, identifica a mensagem rejeitada e aponta o campo que causou a rejeição. O diagnóstico localizado reduz o tempo de resolução do defeito.
O limite é o viés: quem conhece a estrutura tende a projetar casos pelos caminhos previstos, o que reduz a probabilidade de encontrar o uso inesperado que a operação real produz.
6. Níveis e tipos de teste
O nível indica o objeto sob teste; o tipo indica a característica de qualidade verificada. Os dois eixos se combinam: há teste funcional de integração, teste de desempenho de sistema e teste de segurança de aceitação.
| Nível | Objeto | Exemplo em implantação de ERP |
|---|---|---|
| Componente | Unidade isolada de código ou objeto de configuração | Rotina de cálculo de desconto; parâmetro de alçada isolado |
| Integração | Comunicação entre módulos e entre sistemas | Requisição de compra que gera pedido e reserva orçamentária |
| Sistema | Processo de negócio completo no ambiente integrado | Do pedido ao pagamento, atravessando compras, estoque e finanças |
| Aceitação | Aptidão do sistema para a operação, na visão do usuário | Cenário conduzido pelo usuário-chave, com termo de aceite |
Tipos frequentes em implantação
- Funcional: o resultado corresponde à regra especificada.
- Regressão: o comportamento anterior permanece após alteração, nota ou pacote de suporte.
- Fumaça: verificação curta que autoriza o início de um ciclo mais extenso.
- Confirmação: reexecução do caso que falhou, após a correção do defeito.
- Desempenho: tempo de resposta e comportamento sob volume representativo.
- Segurança e autorizações: perfis, segregação de funções e registro de trilha.
- Migração de dados: completude, integridade referencial e reconciliação de saldos.
7. Maturidade do processo de teste
O modelo TMMi organiza a evolução do processo de teste em 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 | Áreas de processo características | O que a organização passa a responder |
|---|---|---|---|
| 1 | Inicial | Ausência de processo definido; teste ao final, sob pressão de prazo | Nada de forma sistemática; o resultado depende das pessoas envolvidas |
| 2 | Gerenciado | Política e estratégia, planejamento, monitoramento e controle, projeto e execução, ambiente de teste | O que foi testado, por quem, com qual resultado e sob qual critério de saída |
| 3 | Definido | Organização de teste, programa de treinamento, ciclo de vida integrado, teste não funcional, revisões por pares | Como o processo se repete entre projetos e onde ele é ajustado |
| 4 | Medido | Medição do processo, avaliação da qualidade do produto, revisões avançadas por pares | Qual é a qualidade esperada da próxima entrega, com base em série histórica |
| 5 | Otimização | Prevenção de defeitos, otimização do processo, controle de qualidade | Qual causa raiz eliminar para reduzir a classe de defeito mais onerosa |
Quatro indicadores para posicionar o projeto
A avaliação formal do modelo exige auditoria. Para o projeto do parceiro, quatro indicadores tornam a maturidade observável de imediato:
- Rastreabilidade: proporção de regras de negócio com ao menos um caso de teste associado e executado.
- Defeito escapado: defeitos encontrados após o aceite, divididos pelo total encontrado no ciclo.
- Tempo de reexecução: horas necessárias para repetir o conjunto crítico após uma alteração.
- Critério de saída: existência de regra escrita que autoriza o encerramento do ciclo, com limite por severidade.
8. Software de prateleira
Em produto adquirido, também designado COTS, o código pertence ao fornecedor e é testado por ele antes da distribuição. A responsabilidade do cliente recai sobre a aderência do produto ao seu processo, o que altera o objeto do teste.
Responsabilidade do fornecedor
- Correção funcional do código entregue no padrão.
- Compatibilidade entre versões e pacotes de suporte.
- Correção de defeito reportado, por nota ou atualização.
Responsabilidade do cliente
- Parametrização e regras de negócio 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.
Dessa divisão decorre o peso do teste de regressão na operação continuada. Cada nota aplicada, pacote de suporte e atualização de versão altera o comportamento do produto sob a configuração do cliente, e a única forma de demonstrar que o processo permanece íntegro é reexecutar o conjunto crítico.
9. Ciclo de testes em implantação SAP
A sequência a seguir corresponde à fase de realização das metodologias de implantação e antecede a preparação para a entrada em operação. Os nomes variam entre metodologias; a lógica de encadeamento se mantém.
| Ciclo | Escopo | Executor | Critério de saída |
|---|---|---|---|
| Unitário de configuração | Cada parâmetro e objeto configurado, isoladamente | Consultor funcional | Lista de configuração integralmente executada com evidência |
| Teste de cadeia | Sequência de transações de um processo dentro do módulo | Consultor funcional | Documento gerado e encerrado em cada etapa |
| 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; severidades 1 e 2 encerradas |
| Aceitação | Cenários de negócio na linguagem da operação | Usuário-chave da área | Termo de aceite assinado, com pendências classificadas |
| Regressão | Conjunto crítico após nota, pacote de suporte ou transporte | Equipe de qualidade, preferencialmente automatizada | Ausência de divergência em relação ao resultado anterior |
| Conversão de dados | Carga dos dados migrados, com reconciliação | Equipe de dados com a área usuária | Totais conferidos com a origem; divergências justificadas |
| Autorizações | Perfis, papéis e segregação de funções | Equipe de segurança | Acesso concedido conforme matriz; conflitos tratados |
| Desempenho | Transações críticas sob volume representativo | Equipe técnica | Tempo de resposta dentro do limite acordado |
Instrumentação
Em projetos de porte, o caso de teste é vinculado ao processo documentado e ao defeito correspondente, de modo que a cobertura seja demonstrável por processo de negócio. As ferramentas de gestão de teste do próprio ecossistema — Solution Manager e Cloud ALM, no caso SAP — organizam plano, sequência, responsáveis e resultado de cada execução. A automação da regressão, por captura de interface ou por ferramenta de mercado, torna a reexecução compatível com a frequência das atualizações.
10. Gestão de defeitos
O registro de defeito distingue severidade, que descreve o efeito técnico sobre o processo, de prioridade, que descreve a urgência de correção decidida pelo negócio. Um defeito de severidade média em processo de fechamento contábil pode ter prioridade máxima na véspera do encerramento do mês.
| 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 contorno aprovado |
| 3 · Média | Divergência que não impede a operação do processo | Programada para o período de operação assistida |
| 4 · Baixa | Melhoria de usabilidade, texto ou apresentação | Registrada no backlog de evolução |
O critério de saída do ciclo é escrito antes da execução e costuma combinar três condições: ausência de defeitos de severidade 1 e 2 em aberto, proporção mínima de casos executados e aceite formal dos processos críticos.
11. Plano de cutover
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. O plano é um cronograma detalhado em horas: cada tarefa recebe responsável, duração estimada, dependência e ponto de verificação.
Componentes do plano
- Sequência de tarefas: ordem de execução com dependências explícitas, do congelamento à liberação do acesso.
- Janela: intervalo acordado com o negócio, com prazo máximo de indisponibilidade e horário de decisão.
- Congelamento: suspensão de mudanças no sistema anterior e no escopo do projeto, a partir de data acordada.
- Migração final: carga dos dados transacionais e de saldos, com reconciliação de contagens e totais.
- Verificação em produção: testes de fumaça sobre os processos críticos, executados pela área usuária.
- Comunicação: quem é avisado, em qual momento e por qual canal, incluindo o aviso de indisponibilidade.
- Plano de retorno: condições de acionamento, procedimento e prazo limite para a decisão.
Ensaio
O ensaio de cutover reproduz a sequência completa em ambiente de qualidade, cronometrada, com as mesmas pessoas que atuarão na virada. Projetos de porte executam de dois a três ensaios; o primeiro costuma revelar a insuficiência da janela planejada, informação que justifica a realização do ensaio.
12. Estratégias de virada
| 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, desligamento do legado contratado | Concentração de risco; retorno complexo após o início da operação |
| Faseada | Entrada por módulo, unidade ou localidade, em ondas | Organização distribuída; equipe de suporte limitada | Convivência entre sistemas exige interfaces provisórias |
| Paralela | Os dois sistemas operam 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 | Necessidade de validar premissas antes da adoção ampla | Resultado do piloto pode não se reproduzir nas demais unidades |
13. Decisão e operação assistida
A decisão de entrar em operação é tomada em reunião formal, com autoridade nomeada e critérios acordados antes da data. Os critérios usuais são: defeitos de severidade 1 e 2 encerrados ou com contorno aprovado; aceite assinado nos processos críticos; reconciliação de dados concluída; ensaio executado dentro da janela; equipe de suporte escalada.
A operação assistida é o período imediatamente posterior à virada, com suporte reforçado e monitoramento contínuo dos processos críticos e das interfaces. Sua duração é definida no plano, com critérios de encerramento declarados, e termina com a transferência formal para a operação regular. Sem esse marco, o projeto permanece indefinidamente responsável por atividades que pertencem à sustentação.
14. Atividade do encontro
A segunda metade da aula é executada no ambiente do parceiro, em cinquenta e cinco minutos. Cada um dos três grupos recebe uma tarefa distinta, incidente 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 da tarefa atualiza os artefatos do projeto; não há documento produzido apenas para a aula.
| Tempo | Atividade | Resultado |
|---|---|---|
| 10 min | Preparação: abrir o ambiente com o perfil necessário, localizar no catálogo o objeto da tarefa e selecionar os valores que serão usados | Ambiente aberto, objeto identificado e dados de fronteira e de exceção escolhidos |
| 25 min | Execução da tarefa no ambiente, com captura da tela de cada passo e correção da parametrização quando o comportamento divergir da regra | Parametrização comprovada, base conciliada ou tempos do ensaio, conforme a tarefa |
| 20 min | Pitch de cinco minutos por grupo, com demonstração ao vivo no sistema e uma pergunta obrigatória do grupo seguinte | Recomendação sobre a entrada em operação e decisão registrada pelo comitê |
As três tarefas
| Grupo | No ambiente | Fica no projeto |
|---|---|---|
| 1 Regra de maior risco | Executar no ERP a regra de maior impacto já parametrizada, em quatro cenários: caso nominal, valor no limite, primeiro valor fora da faixa e tentativa sem o aprovador previsto. Comportamento divergente do que a regra determina é ajustado na parametrização e reexecutado. | A regra comprovada nos quatro cenários, com as evidências vinculadas à ficha de parametrização, e o defeito que permanecer registrado com severidade. |
| 2 Carga e interface | Reprocessar a carga tratada na Aula 2, comparar contagem de registros e soma de um campo de valor entre origem e destino, abrir um registro rejeitado, identificar a causa e reprocessá-lo. Disparar uma operação da interface na origem e localizar o registro gravado no destino. | Base conciliada, divergências identificadas por causa, registros pendentes com responsável e a tolerância adotada para a diferença remanescente. |
| 3 Ensaio da virada | Executar cronometrada a sequência da virada com os dados atuais — congelar entradas, extrair, carregar, conferir totais e liberar acesso —, tentar a operação restrita com perfil sem autorização e reexecutar as regras já aceitas pelo parceiro. | O tempo real de cada passo da sequência, as regras que seguem válidas e as que as últimas alterações quebraram, e o ponto de não retorno da janela. |
Estrutura do pitch
A apresentação ocorre com o sistema aberto e o grupo executa diante da turma o que verificou.
| 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. Objeto sem insumo disponível no ambiente é registrado como lacuna, com responsável e prazo, e substituído por outro do mesmo catálogo.
15. Falhas recorrentes
- Teste conduzido apenas pelo caminho principal. O cenário de sucesso é executado e a exceção permanece desconhecida até a operação.
- Caso de teste sem resultado esperado. A execução termina com a observação de que "funcionou", sem critério que permita reprovar.
- Evidência ausente. O resultado é relatado verbalmente e desaparece na semana seguinte, quando o defeito reaparece.
- Dado de teste irreal. Cadastro fictício com valores redondos oculta o defeito que o dado real revela.
- Aceite sem usuário. A equipe de projeto executa o teste de aceitação e assina o próprio termo.
- Cutover sem ensaio. A sequência é executada pela primeira vez na noite da virada, com duração desconhecida.
- Retorno declarado sem procedimento. O plano afirma que existe retorno, sem descrever como executá-lo nem até quando.
16. Referências
- 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 de software.
- 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 — práticas de habilitação de mudança e de gestão de liberação.