O Desafio

Em um projeto de desenvolvimento de software em cascata típico, os testes ocorrem imediatamente antes do lançamento daquele release em produção. Isso significa que quando bugs ou problemas de usabilidade são encontrados nesta etapa, o lançamento acaba por ser adiado até que os problemas sejam corrigidos.

Neste modelo, o teste torna-se um gargalo que impede seriamente a capacidade de entrega dos projetos no prazo, causando grandes prejuízos aos negócios da empresa. Outro grande problema desta prática, é o custo para corrigir o defeito tardiamente.

O gráfico a seguir, retirado de artigos do NIST (National Institute of Standards and Technology), ajuda a visualizar como o esforço para detectar e corrigir defeitos aumenta à medida que o software passa pelas cinco grandes fases de desenvolvimento de software.

Para entender por que os custos aumentam dessa maneira, vamos considerar os seguintes pontos:

• Coding - É muito mais fácil detectar problemas no código quando os desenvolvedores ainda estão escrevendo o código. Como o código ainda está fresco na mente é trivial corrigir até mesmo problemas complexos. Conforme o tempo passa e o código avança para os estágios posteriores, os desenvolvedores precisam se lembrar de tudo e procurar os problemas antes de corrigi-los. Se um sistema automatizado, como uma integração de qualidade contínua, destaca problemas no código quando os desenvolvedores ainda estão escrevendo o código, eles são muito mais propensos a incorporar a correção pelo mesmo motivo.
• Integration/component Testing - Uma vez que o software está em fase de teste, reproduzir os defeitos no ambiente de desenvolvimento apresenta outra tarefa demorada. Embora seja muito fácil detectar algo que não está de acordo com os requisitos, é incrivelmente difícil descobrir defeitos que são mais fundamentais - pense em invasão de memória, condições de corrida (race conditions), etc. Se esses problemas escaparem da fase de codificação, eles geralmente não se apresentam até a fase de produção, ou um ambiente de teste mais completo, infelizmente.
• Production/post release - Depois que o software foi disponibilizado e está em uso, não é apenas difícil encontrar defeitos - é incrivelmente arriscado também. Além de evitar que usuários ativos sejam afetados pelos problemas, garantir a disponibilidade do serviço é fundamental para os negócios. Esses efeitos aumentam e o custo é de até 30x maior do que fossem corrigidos logo no início.

O Shift Left Testing promete melhorar este tipo de cenário, envolvendo equipes de teste no início do processo. Os problemas, sejam no design ou no código, podem ser resolvidos logo no início, antes de se tornarem importantes. Na verdade, o deslocamento para a esquerda tem menos a ver com a detecção de problemas e mais com a prevenção de problemas.

Mas como trazer agilidade em plataformas mainframe?

Se todos estes problemas podem ser um desafio na Plataforma distribuída, onde a prática de DevOps e metodologias ágeis são muito mais comuns, imagine o cenário em ambientes de desenvolvimento na plataforma mainframe.

Por ser uma Plataforma centralizada, com alto custo e escassez de mão de obra especializada, o cenário fica muito mais complexo. 

Atualmente, a maioria dos projetos envolvem ambas as plataformas – Plataforma distribuída e Plataforma z/OS, onde, caso um dos lados atrase, os testes podem ficar comprometidos. E devido a estrutura centralizada do mainframe, é comum haver atrasos o que acaba impactando os negócios da empresa.

E o mercado atual é muito competitivo. O custo do atraso de produto para área de negócios pode ter impacto financeiro considerável.

Garantindo qualidade e antecipando problemas básicos

Durante a codificação, o uso de ferramentas de análise estática do software é uma das muitas opções para localizar possíveis bugs, problemas de performance e ineficiências no software. Como os compiladores, os analisadores estáticos usam um programa como entrada e geram relatórios de qualidade de código, apontando possíveis problemas, utilização de recursos proibidos ou que sejam considerados nocivos pela empresa.

Com a implementação deste tipo de ferramenta, já no momento de compilação do código, é possível antecipar algumas situações antes mesmo deste código seguir para as etapas de testes funcionais.

Existem varias ferramentas disponiveis no Mercado para Plataforma distribuída, porém, e na plataforma Mainframe? Para plataforma mainframe a Eccox possui ferramentas unicas, como o Eccox QC for Cobol e Eccox QC for DB2, que executam a avaliação de código diretamente no mainframe, trazendo agilidade nos resultados e ajudando a garantir a qualidade de entrega dos programas. Isto serve como um primeiro filtro e pode diminuir a quantidade de problemas encontrados durante a fase de testes.

Component Testing

O primeiro grande desafio no momento dos testes unitários é de infraestrutura. Muitas vezes, para a execução dos testes unitários, existe a dificuldade para testar programas que interagem com outros recursos, sejam eles entre plataformas, sejam eles entre sistemas. Para isto, existem ferramentas de virtualização, que simulam a execução da integração de recursos externos e também ferramentas de debugging, onde, na falta de dados para cumprir determinado caso de teste, é possível alterar os dados em tempo de execução. Estas ferramentas ajudam, mas não garantem a funcionalidade durante a situação real em produção. Servem apenas para antecipar erros mais básicos.

E para avançar para os testes de integração, muitas vezes é preciso aguardar a liberação do ambiente de testes de integração para evitar conflitos de versões de programas e/ou alterações em dados ou então, correr o risco de juntar testes que possam conflitar e gerar resultados inesperados.

Integration

Aqui é onde ocorre muitas vezes um afunilamento, principalmente quando se trata da plataforma Mainframe. Com frequência no online (CICS/IMS) há uma limitação de testar uma versão de programa por vez, e também, o compartilhamento de uma única base de dados, seja DB2 ou VSAM. Uma alteração de algum dado pode alterar completamente o resultado esperado por outro programa em outro teste e que acesse a mesma tabela ou arquivo. E para evitar este tipo de situação, muitas empresas acabam criando toda uma estrutura de cópias, sejam elas LPARs inteiras ou simplesmente bibliotecas, base de dados, regions CICS, regions IMS, visando manter certo paralelismo. Porém acarreta um custo alto não somente de software, mas também de manutenção e atualização do ambiente. E tem limitação de quantidade de paralelismo.

Como antecipar os testes

Tendo em mente que quanto antes os defeitos forem encontrados e arrumados, os custos do projeto assim como o prazo de entrega podem diminuir drasticamente, o que faria sentido começar os testes integrados o quanto antes. Mas, como fazer para que o paralelismo não acabe por piorar a situação em um ambiente cheio e conflitos? Muitas vezes, misturando testes de diferentes projetos ou diferentes usuários em um mesmo ambiente, pode ser mais prejudicial do que montar uma ordem de prioridades e testar um por vez. Isto poderia trazer mais qualidade nos testes, porem com um prazo maior nas entregas.

Sabemos que, se o programa ainda esta em fase inicial de testes, colocando ele em um ambiente integrado, poderia destruir dados e impactar os testes dos demais usuários.

E se fosse possível dentro da mesma infraestrutura com CICS, IMS e DB2 você conseguisse isolar as execuções de forma que cada um consiga fazer seus testes de forma isolada, tanto para versões de programas quanto para dados, sejam eles DB2 ou VSAM?

Diferente da maioria das ferramentas de mercado que trabalha com virtualização, a Eccox possui uma ferramenta única no mercado que permite a execução de testes em paralelo, com quantidade ilimitada de paralelismo utilizando o conceito de container, o Eccox APT. Com isso, é possível antecipar os testes para versões de programas diretamente dos pacotes de mudança sem impactar o ambiente, uma vez que as bases podem ser isoladas (clonadas). Então, mesmo que o programa ainda esteja com algum defeito de lógica e venha a destruir dados, com o isolamento das bases, este tipo de problema não afeta a execução dos demais testes. E com um simples botão na WEB, é possível recompor os dados a partir do ambiente oficial. A automação reduz os erros humanos, aumenta a confiança, acelera a entrega e permite que sobre mais tempo para as pessoas focarem em tarefas mais desafiadoras/inspiradoras do que passar dias fazendo atividades exaustivas!

Container

O container fornece um modo de executar várias cargas de trabalho isoladas em uma única instância do Sistema, que neste caso pode ser o CICS, IMS, DB2. Utilizando este conceito, é possível fazer o isolamento do teste sem a necessidade de clonar o Sistema completo. O container pode ser montado somente com os recursos desejados, e, os demais recursos que não estiverem no container serão utilizados a versão do próprio ambiente.

AUTORA: Milene Oliveira, Consultora de Soluções de TI.

Soluções relacionadas: Eccox QC, Eccox APT.

Fontes: Computerworld; BMC Blog; NIST.