 |
| Bellacosa Mainframe QA QC QI sem misterios |
☕ Um Café no Bellacosa Mainframe
QA, QC e QI sem Mistérios
O Guia do Programador COBOL Padawan para Construir, Verificar e Melhorar Sistemas Dignos da Frota Estelar
Imagine que você acaba de receber sua primeira missão oficial como programador COBOL.
Seu terminal 3270 está ligado. O cursor verde pisca no canto superior esquerdo. Na tela, um membro mais experiente da equipe deixou uma mensagem:
MISSÃO: ALTERAR O PROGRAMA PGMBL001
OBJETIVO: INCLUIR UMA NOVA REGRA DE CÁLCULO
CRITICIDADE: ALTA
JANELA DE IMPLANTAÇÃO: DOMINGO, 02:00
Você abre o código e encontra oito mil linhas de COBOL, cinco copybooks, quatro acessos ao Db2, uma chamada para outro programa, dois arquivos VSAM e um comentário escrito em 1998:
* NAO ALTERAR SEM FALAR COM O CARLOS.
O problema é que ninguém sabe quem é Carlos.
Talvez ele tenha se aposentado. Talvez tenha sido promovido. Talvez esteja escondido em algum planeta remoto da Federação, observando silenciosamente se alguém ousará alterar aquela rotina.
Você respira fundo e pensa:
“Como posso garantir que esta alteração estará correta?”
Essa pergunta parece simples, mas abre as portas para três grandes conceitos da gestão da qualidade:
QA — Quality Assurance
QC — Quality Control
QI — Quality Improvement
Em português:
Garantia da Qualidade
Controle da Qualidade
Melhoria da Qualidade
Esses três conceitos não são sinônimos. Eles fazem parte de uma jornada completa.
QA procura construir corretamente.
QC procura verificar se foi construído corretamente.
QI procura descobrir como construir melhor na próxima missão.
Na Frota Estelar, uma nave não é considerada confiável apenas porque passou por uma inspeção antes de sair da doca. Ela precisa ter sido projetada seguindo padrões, construída com componentes certificados, testada em diferentes condições e continuamente aprimorada com base nas missões anteriores.
No mainframe acontece exatamente a mesma coisa.
Um programa COBOL confiável não nasce apenas porque “compilou sem erro”. Ele nasce da combinação de processos, padrões, testes, monitoramento, aprendizado e melhoria contínua.
Prepare seu café, ajuste a cadeira e abra uma nova sessão no ISPF. Hoje vamos atravessar o quadrante da qualidade.
1. Antes de tudo: qualidade não significa perfeição
Um dos primeiros erros de quem começa a estudar qualidade é imaginar que qualidade significa ausência absoluta de defeitos.
Na prática, qualidade significa que um produto, serviço ou sistema:
atende aos requisitos;
funciona dentro das condições esperadas;
apresenta comportamento previsível;
possui riscos conhecidos e controlados;
entrega valor ao usuário;
pode ser mantido e melhorado.
Um sistema pode funcionar e ainda assim ter baixa qualidade.
Imagine um programa COBOL que calcula corretamente os juros de uma operação financeira, mas:
demora quatro horas para processar;
consome CPU excessivamente;
não gera mensagens claras em caso de erro;
depende de um arquivo manual;
possui variáveis com nomes incompreensíveis;
causa ABEND quando encontra um registro inválido.
Ele pode produzir o resultado correto na maioria das situações, mas ainda possui diversos problemas de qualidade.
Qualidade não é apenas perguntar:
“Funcionou?”
É também perguntar:
“Funcionou corretamente, com segurança, dentro do prazo, com desempenho aceitável e de forma sustentável?”
Essa mudança de mentalidade é o começo da missão.
2. QA: Quality Assurance — construindo qualidade desde o início
Quality Assurance, ou Garantia da Qualidade, é o conjunto de processos utilizados para aumentar a probabilidade de que um produto seja construído corretamente.
QA possui uma visão predominantemente preventiva.
Ele pergunta:
“Estamos organizados para fazer isso da maneira certa?”
Observe que QA não espera o defeito aparecer. Seu objetivo é criar condições para que o erro tenha menos chance de acontecer.
Em uma doca espacial, QA envolve:
padrões de engenharia;
certificação dos componentes;
treinamento da tripulação;
procedimentos de montagem;
documentação técnica;
regras de segurança;
auditorias;
revisões de projeto.
Em um ambiente IBM Mainframe, QA envolve:
padrões de desenvolvimento COBOL;
convenções de nomes;
checklists;
revisão de código;
treinamento técnico;
critérios de segurança;
versionamento;
segregação de ambientes;
documentação;
gestão de mudanças;
padrões para SQL, JCL, CICS, IMS e arquivos.
QA tenta colocar a qualidade dentro do processo.
Esse conceito é conhecido como:
Build quality in.
Ou seja:
“Construa a qualidade dentro do produto, em vez de tentar adicioná-la no final.”
3. QA aplicado a um programa COBOL
Imagine que você precisa criar um programa para ler transações bancárias e atualizar o saldo dos clientes.
Sem QA, talvez cada programador faça a tarefa como preferir.
Um escreve:
01 A PIC X(10).
01 B PIC 9(7)V99.
Outro escreve:
01 WS-CLIENTE.
05 WS-CLIENTE-CODIGO PIC X(10).
05 WS-CLIENTE-SALDO PIC S9(7)V99 COMP-3.
Os dois programas podem funcionar, mas o segundo possui maior clareza e manutenção mais simples.
Um padrão de QA poderia definir:
prefixo WS- para Working-Storage;
prefixo LK- para Linkage Section;
prefixo DB2- para campos de tabela;
nomes significativos;
identação padronizada;
tratamento obrigatório de erros;
comentários apenas quando acrescentam contexto;
proibição de GO TO indiscriminado;
limite de complexidade por parágrafo;
validação de dados de entrada.
Outro padrão poderia exigir o tratamento explícito do SQLCODE:
EXEC SQL
SELECT SALDO
INTO :WS-SALDO
FROM CONTA
WHERE NUM_CONTA = :WS-NUM-CONTA
END-EXEC
EVALUATE SQLCODE
WHEN ZERO
CONTINUE
WHEN 100
MOVE 'CONTA NAO ENCONTRADA'
TO WS-MENSAGEM
WHEN OTHER
PERFORM 9000-TRATA-ERRO-DB2
END-EVALUATE
O objetivo de QA não é burocratizar o trabalho.
O objetivo é diminuir a variabilidade.
Quando cada programador trabalha de uma forma completamente diferente, a equipe depende demais da experiência individual. Quando existem padrões razoáveis, o conhecimento deixa de estar preso apenas à cabeça de algumas pessoas.
QA transforma experiência individual em capacidade organizacional.
4. O perigo do QA teatral
Existe uma armadilha comum: criar muitos documentos, formulários e aprovações, mas não melhorar realmente a qualidade.
Esse fenômeno pode ser chamado de “QA teatral”.
A empresa possui:
quarenta checklists;
vinte modelos de documentos;
oito assinaturas obrigatórias;
três reuniões de aprovação;
um portal que ninguém entende.
Mesmo assim, os mesmos erros continuam chegando à produção.
Isso acontece quando o processo se torna mais importante que o resultado.
Um bom processo de QA deve ser:
A Frota Estelar não pediria o mesmo nível de controle para trocar uma luminária do corredor e para atualizar o núcleo de dobra.
No mainframe, também devemos aplicar controles proporcionais.
Alterar uma mensagem de tela não possui necessariamente o mesmo risco que modificar:
cálculo de juros;
fechamento contábil;
autorização de pagamentos;
rotina de criptografia;
processamento tributário;
interface com órgãos reguladores.
QA eficiente entende criticidade.
5. QC: Quality Control — verificando o que foi construído
Quality Control, ou Controle da Qualidade, é o conjunto de atividades usadas para verificar se o produto atende aos requisitos.
QC possui uma visão mais detectiva.
Ele pergunta:
“O resultado está correto?”
Enquanto QA olha principalmente para o processo, QC olha principalmente para o produto.
Em uma nave, QC inclui:
No desenvolvimento COBOL, QC inclui:
A frase clássica seria:
Check it right.
Ou:
“Verifique se está correto.”
6. Compilar não significa testar
Este é um dos maiores ensinamentos para o programador COBOL iniciante:
Um programa compilado não é necessariamente um programa correto.
O compilador verifica aspectos como:
Mas ele não sabe necessariamente se a regra de negócio está correta.
Considere:
COMPUTE WS-TOTAL =
WS-VALOR * 1.50
O código pode estar sintaticamente perfeito.
Mas talvez a regra correta fosse:
COMPUTE WS-TOTAL =
WS-VALOR * 1.05
O compilador não conhece a política comercial da empresa.
Ele apenas verifica se o comando é válido.
O QC precisa confirmar:
se o cálculo corresponde ao requisito;
se os limites foram considerados;
se os arredondamentos estão corretos;
se existem cenários extremos;
se valores nulos foram tratados;
se o resultado foi gravado corretamente.
Compilação é uma forma de controle, mas está longe de ser suficiente.
7. O passo a passo de um QC bem executado
Vamos imaginar uma alteração em um programa COBOL que calcula desconto.
A nova regra é:
clientes comuns recebem 5%;
clientes premium recebem 10%;
clientes com compra acima de R$ 10.000 recebem 15%.
O primeiro passo é listar os cenários.
Cenário 1: cliente comum
TIPO: COMUM
VALOR: 1.000
DESCONTO ESPERADO: 50
Cenário 2: cliente premium
TIPO: PREMIUM
VALOR: 1.000
DESCONTO ESPERADO: 100
Cenário 3: compra acima de 10.000
TIPO: COMUM
VALOR: 12.000
DESCONTO ESPERADO: 1.800
Cenário 4: valor exatamente igual a 10.000
Aqui surge uma dúvida importante:
A regra diz “acima de 10.000” ou “igual ou acima de 10.000”?
Essa diferença pode mudar o código:
IF WS-VALOR > 10000
ou:
IF WS-VALOR >= 10000
Esse detalhe parece pequeno, mas pode afetar milhares de transações.
QC não significa apenas executar testes. Também significa questionar ambiguidades.
Um bom testador não pergunta apenas:
“O programa funciona?”
Ele pergunta:
“Em quais condições ele pode falhar?”
8. Teste do caminho feliz e teste das anomalias espaciais
O “caminho feliz” é o cenário em que tudo ocorre conforme o esperado.
Exemplo:
arquivo existe;
registro está correto;
cliente foi encontrado;
saldo é suficiente;
banco está disponível;
retorno é zero.
Mas sistemas reais vivem cercados por anomalias.
É necessário testar:
arquivo vazio;
registro duplicado;
chave inexistente;
valor negativo;
campo alfanumérico em posição numérica;
indisponibilidade do Db2;
falha na chamada de programa;
espaço insuficiente;
timeout;
deadlock;
dados incompletos;
fim inesperado do arquivo.
No universo da Frota Estelar, os problemas raramente surgem durante uma viagem tranquila. Eles aparecem quando a nave entra em uma nebulosa, perde comunicação e descobre que um fenômeno temporal está afetando os sensores.
No mainframe, a nebulosa pode ser um arquivo com layout incorreto.
O fenômeno temporal pode ser um processamento que atravessa a virada do mês.
A distorção espacial pode ser um campo data ainda utilizando ano com dois dígitos.
9. QC como última linha de defesa
A imagem apresentada descreve o QC como uma última linha de defesa.
Essa ideia é poderosa.
Quando o processo de QA não evita um defeito, o QC tenta interceptá-lo antes que alcance o cliente.
Mas depender exclusivamente de QC é perigoso.
Imagine uma fábrica que produz dez mil peças por dia e tenta compensar um processo ruim apenas aumentando a inspeção final.
Isso gera:
No software, acontece o mesmo.
Se o código chega constantemente aos testes com problemas básicos, não basta contratar mais testadores.
É necessário melhorar o processo de desenvolvimento.
Essa é a ponte entre QC e QI.
10. QI: Quality Improvement — tornando o sistema melhor
Quality Improvement, ou Melhoria da Qualidade, procura aumentar continuamente a capacidade do processo, do produto e da organização.
QI pergunta:
“Como podemos fazer melhor?”
Esse é o território do aprendizado.
Enquanto QA cria padrões e QC identifica defeitos, QI analisa resultados e modifica o sistema para evitar recorrências.
QI pode envolver:
A ideia central é:
Raise the bar continuously.
Elevar continuamente o padrão.
11. Um exemplo de QI no ambiente mainframe
Imagine que uma equipe registra vinte incidentes em três meses.
Ao analisar os dados, descobre:
8 incidentes: SQLCODE -805
5 incidentes: erro de JCL
4 incidentes: arquivo de entrada incorreto
3 incidentes: falha de regra de negócio
Uma organização imatura resolveria cada incidente separadamente e seguiria adiante.
Uma organização orientada por QI perguntaria:
“Por que temos tantos SQLCODE -805?”
A análise poderia revelar:
pacotes não incluídos corretamente no plano;
processo de BIND manual;
divergência entre ambientes;
documentação desatualizada;
ausência de validação automatizada;
implantação parcial.
A equipe então cria melhorias:
automatiza a validação de packages;
inclui verificação no pipeline;
padroniza o BIND;
documenta dependências;
treina a equipe;
monitora reincidências.
Esse é o QI fechando o ciclo.
O objetivo não é encontrar culpados.
O objetivo é melhorar o sistema.
12. Causa raiz: não culpe o tripulante antes de verificar a nave
Imagine que um operador submeteu um JCL com a biblioteca errada.
A análise superficial conclui:
“Erro humano.”
Mas “erro humano” raramente é uma causa raiz satisfatória.
É necessário perguntar:
por que era possível escolher a biblioteca errada?
os nomes eram semelhantes?
o procedimento estava documentado?
existia validação automática?
o operador recebeu treinamento?
havia pressão de tempo?
o ambiente permitia detectar o problema antes?
a mensagem de erro era compreensível?
Talvez o operador tenha cometido o erro, mas o processo permitiu que o erro se transformasse em incidente.
Uma das técnicas mais conhecidas é a dos Cinco Porquês.
Problema
O job falhou porque utilizou a LOADLIB incorreta.
Por quê?
Porque o JCL apontava para a biblioteca de testes.
Por quê?
Porque o programador copiou um JCL antigo.
Por quê?
Porque não existe PROC padronizada.
Por quê?
Porque cada aplicação mantém seu próprio modelo.
Por quê?
Porque nunca foi criado um padrão corporativo para execução.
A causa inicial parecia ser “programador desatento”.
A causa sistêmica pode ser ausência de padronização.
QI tenta chegar a esse nível.
13. PDCA: o ciclo que nunca termina
Uma das estruturas mais importantes da melhoria contínua é o PDCA:
Em português:
Planejar;
Executar;
Verificar;
Agir.
Plan
Defina o problema e planeje a melhoria.
Exemplo:
Reduzir falhas de JCL em 50% nos próximos três meses.
Do
Implemente uma mudança controlada.
Exemplo:
Criar modelos padronizados e validação automática.
Check
Analise os resultados.
Exemplo:
Comparar a quantidade de falhas antes e depois.
Act
Padronize o que funcionou ou ajuste o plano.
Exemplo:
Adotar o novo modelo em todas as aplicações.
O PDCA não termina.
Depois do Act, um novo ciclo começa.
É como uma missão de exploração: cada viagem produz novos dados, que alteram os procedimentos da próxima viagem.
14. DMAIC: a investigação científica dos defeitos
O DMAIC é muito utilizado em Six Sigma.
Significa:
Define
Measure
Analyze
Improve
Control
Define
Defina claramente o problema.
O batch noturno está ultrapassando a janela em 40 minutos.
Measure
Colete dados.
tempo por step;
consumo de CPU;
quantidade de I/O;
espera por recursos;
duração de SQL;
volume de registros.
Analyze
Descubra a causa.
Talvez um programa esteja realizando:
Improve
Implemente a solução.
otimizar SQL;
utilizar processamento em conjunto;
ajustar índice;
reduzir chamadas;
mover filtro para o SORT;
eliminar processamento redundante.
Control
Garanta que a melhoria permaneça.
monitoramento;
métricas;
alertas;
revisão periódica;
critérios de desempenho.
Sem a etapa Control, o problema pode retornar silenciosamente.
15. QA, QC e QI em um pipeline DevOps
Em um fluxo moderno, os três conceitos aparecem juntos.
REQUISITO
|
v
PADRÕES E CRITÉRIOS
|
v
DESENVOLVIMENTO
|
v
CODE REVIEW
|
v
BUILD
|
v
TESTES
|
v
DEPLOY
|
v
MONITORAMENTO
|
v
MÉTRICAS E MELHORIAS
QA aparece em:
definição de critérios;
padrões;
revisão;
controle de versão;
treinamento;
governança.
QC aparece em:
compilação;
testes;
validações;
inspeções;
homologação.
QI aparece em:
análise de incidentes;
retrospectivas;
métricas;
automação;
melhoria de fluxo;
redução de desperdício.
No DevOps, essas práticas deixam de ser departamentos isolados e passam a fazer parte do fluxo.
A qualidade não pertence apenas ao “pessoal de testes”.
Ela pertence a toda a tripulação.
16. Quem é responsável pela qualidade?
Uma resposta antiga seria:
“O departamento de qualidade.”
Uma resposta moderna é:
“Todos.”
O analista de negócios é responsável por requisitos claros.
O arquiteto é responsável por decisões sustentáveis.
O programador é responsável por código compreensível.
O testador é responsável por desafiar o sistema.
O operador é responsável por observar o comportamento operacional.
O DBA é responsável por integridade e desempenho dos dados.
O sysprog é responsável pela estabilidade da plataforma.
O gestor é responsável por criar condições para que o trabalho seja bem executado.
O cliente também participa ao fornecer feedback.
Qualidade é um sistema de responsabilidades compartilhadas.
17. Curiosidade: qualidade e mainframe nasceram para trabalhar juntos
Mainframes tradicionalmente operam em ambientes onde falhas podem provocar consequências graves.
Pense em:
bancos;
companhias aéreas;
seguradoras;
governos;
hospitais;
telecomunicações;
grandes varejistas.
Nesses ambientes, uma pequena inconsistência pode afetar milhões de registros.
Por isso, a cultura mainframe desenvolveu forte disciplina em:
O mainframe não é apenas uma plataforma tecnológica.
Ele também representa uma cultura de confiabilidade.
Isso não significa que ambientes mainframe sejam perfeitos. Significa que foram moldados por décadas de operação crítica.
18. A relação com Lean e desperdício
Lean procura maximizar valor e reduzir desperdício.
No desenvolvimento de software, desperdício pode incluir:
funcionalidades que ninguém usa;
documentação duplicada;
esperas por aprovação;
retrabalho;
filas;
correções repetitivas;
testes manuais desnecessários;
ambientes indisponíveis;
transferência excessiva de responsabilidade;
tarefas iniciadas e não concluídas.
No mainframe, exemplos comuns podem ser:
jobs executados sem necessidade;
arquivos intermediários redundantes;
múltiplas ordenações;
relatórios que ninguém consulta;
cópias repetidas de dados;
aprovações que não agregam controle real;
procedimentos manuais facilmente automatizáveis.
QI utiliza o pensamento Lean para perguntar:
“Esta atividade gera valor ou apenas consome energia da nave?”
19. Kaizen: pequenas melhorias, grandes jornadas
Kaizen significa melhoria contínua.
Nem toda melhoria precisa ser uma grande transformação.
Exemplos de pequenos Kaizens:
melhorar uma mensagem de erro;
adicionar um exemplo ao procedimento;
padronizar um nome de variável;
automatizar uma verificação;
eliminar um passo manual;
incluir um teste de borda;
documentar um SQLCODE recorrente;
criar um dashboard simples;
corrigir um checklist confuso.
Essas pequenas mudanças podem parecer insignificantes isoladamente.
Mas, acumuladas ao longo dos meses, mudam profundamente a capacidade da equipe.
A nave não se torna confiável por causa de uma única reforma monumental. Ela se torna confiável porque milhares de pequenos aprendizados são incorporados à engenharia.
20. Dicas práticas para o programador COBOL Padawan
Antes de alterar o código
Pergunte:
qual é o requisito?
quem utiliza o resultado?
quais sistemas dependem deste programa?
quais arquivos e tabelas são afetados?
existe documentação?
há processamento concorrente?
qual é o impacto operacional?
como será feito o rollback?
Isso é QA.
Durante o desenvolvimento
Verifique:
Isso também é QA.
Antes da implantação
Execute:
Isso é QC.
Depois da implantação
Observe:
duração;
CPU;
EXCP;
erros;
reclamações;
divergências;
comportamento do batch;
mensagens operacionais;
impactos indiretos.
Isso alimenta QI.
Depois de um incidente
Não pergunte apenas:
“Quem fez isso?”
Pergunte:
“O que no processo permitiu que isso acontecesse?”
Isso é maturidade.
21. Easter eggs para os tripulantes atentos
Primeiro easter egg: aquele comentário “não alterar sem falar com Carlos” representa uma forma de conhecimento tribal.
Conhecimento tribal é aquilo que a equipe sabe, mas não documenta adequadamente. Quando a pessoa sai, o conhecimento desaparece.
QA tenta transformar conhecimento tribal em conhecimento institucional.
Segundo easter egg: o terminal 3270 não é apenas uma interface antiga. Ele simboliza uma filosofia de interação extremamente eficiente, orientada a campos e transações.
Terceiro easter egg: um SQLCODE 100 não significa necessariamente erro. Significa que nenhum dado foi encontrado. O contexto define se isso é esperado ou problemático.
Quarto easter egg: a frase “funcionou no meu ambiente” é o equivalente tecnológico de dizer:
“Os sensores indicam que não há perigo.”
Poucos segundos antes de uma anomalia aparecer na tela principal.
Quinto easter egg: todo sistema legado possui ao menos uma rotina que ninguém deseja tocar. Ela normalmente funciona há anos, possui pouca documentação e parece manter metade da empresa em operação.
Essas rotinas devem ser tratadas com respeito científico, não com medo supersticioso.
22. O verdadeiro nível sênior
O programador iniciante pensa:
“Meu código compilou.”
O programador intermediário pensa:
“Meu código passou nos testes.”
O programador sênior pensa:
“Meu código funciona, pode ser operado, monitorado, mantido, recuperado e compreendido por outra pessoa.”
O especialista em qualidade pergunta ainda:
“O que aprendemos com esta alteração e como podemos melhorar o sistema inteiro?”
Esse é o salto de maturidade.
Qualidade não é apenas uma característica do código.
É uma característica do ecossistema.
Conclusão: a Primeira Diretriz da Qualidade
QA, QC e QI formam uma tríade.
QA cria as condições para que o trabalho seja realizado corretamente.
QC verifica se o resultado atende aos requisitos.
QI utiliza dados, falhas e feedback para elevar continuamente o nível.
Podemos resumir assim:
QA PREVINE
QC DETECTA
QI TRANSFORMA
Ou, em linguagem de Frota Estelar:
QA prepara a nave.
QC testa a nave.
QI melhora a próxima geração da nave.
Um sistema confiável não nasce apenas do talento de um programador brilhante.
Ele nasce de:
padrões sensatos;
processos claros;
testes inteligentes;
colaboração;
observabilidade;
análise de dados;
aprendizado;
melhoria contínua.
Quando QA funciona, menos defeitos são criados.
Quando QC funciona, menos defeitos chegam ao usuário.
Quando QI funciona, a organização deixa de repetir indefinidamente os mesmos erros.
O grande segredo é que os três conceitos formam um ciclo:
QA
|
v
DESENVOLVIMENTO
|
v
QC
|
v
OPERAÇÃO
|
v
QI
|
v
NOVO QA
Cada melhoria aprendida em QI deve atualizar o QA.
Cada novo padrão de QA deve fortalecer o desenvolvimento.
Cada produto desenvolvido deve ser verificado pelo QC.
Cada resultado do QC e da produção deve gerar novos aprendizados.
Esse ciclo é a verdadeira máquina de qualidade.
Portanto, jovem programador COBOL Padawan, quando receber sua próxima missão, não olhe apenas para a PROCEDURE DIVISION.
Observe também:
o processo;
os requisitos;
os riscos;
os testes;
a operação;
as métricas;
o aprendizado.
E quando alguém perguntar quem é responsável pela qualidade, não aponte para outra equipe.
Ajuste o comunicador, olhe para o terminal verde e responda:
“A qualidade é responsabilidade de toda a tripulação.”
Porque, no mainframe como na Frota Estelar, não basta chegar ao destino.
É preciso chegar com segurança, confiabilidade e conhecimento suficiente para tornar a próxima missão ainda melhor.
