Afinal, o que são sistemas legados?

Sistemas legados são caracterizados por um ou mais softwares que ainda estão em uso atendendo às necessidades pelas quais foram projetados, mas, que se tornaram obsoletos por vários outros fatores.

Por exemplo: uma ferramenta utilizada para desenvolvimento pode não possuir mais atualizações pelo lado do fornecedor. Ou uma adoção de tecnologia mais antiga e robusta pode acarretar em impeditivos para integrações com sistemas mais novos. 

Em ambas situações, tal como a dificuldade em modificá-las, podemos encontrar fatores predominantes – especialmente por conter processos de negócios importantes ou por terem sidos customizados de forma a atender as necessidades de uma organização. 

Quais desafios podemos encontrar nestes sistemas?

Quando se fala em sistemas legados, estamos nos referindo a softwares construídos há mais de uma década. Em sua maioria, são sistemas compostos por monólitos, pois detém de várias regras de negócios acopladas em uma única aplicação, possuindo intercorrências dependentes entre vários módulos e integrações. 

Estas dependências podem ocasionar em um grande esforço na manutenção.

Nesse sentido, a qualidade exerce um papel fundamental para a garantia das aplicações mais coesas, prevenindo riscos, erros ou falhas que possam vir a acontecer no sistema.

Outro desafio que podemos nos deparar são as alterações feitas no código fonte que impactam outras dependências do software. Neste caso, devemos garantir que uma correção realizada anteriormente não tenha afetado outras funcionalidades do sistema.

Sabendo disso, precisamos levantar insumos que nos ajudem na garantia da qualidade das nossas aplicações. Por isso, vamos tratar sobre análise de riscos:

sistemas legados

Análise baseada na diminuição de riscos no software

Se um risco é inerente ao sistema, é necessário criar mecanismos para monitorá-los. Esse monitoramento se dá pela análise de riscos, que por sua vez, é uma etapa de suma importância, não somente em sistemas legados, mas também em sistemas de modo geral. 

A análise de riscos contribui na identificação visual de processos que possuem maior criticidade e que devem receber mais atenção.

Para mapeamento dos riscos, podemos usufruir de várias técnicas e ferramentas como: 

  • Análise de causa raiz,
  • Matriz SWOT, 
  • Brainstorming, 
  • Matriz de riscos, dentre outras.

A análise de matriz de riscos pode ser exercitada por todos os integrantes do “dev team”. É nela que se caracteriza, a priori, quão crítico um determinado risco é. Observe abaixo:

Figura 1 – Guia visual de como ler uma Matriz de Riscos (Fonte: https://blogdaqualidade.com.br/o-que-e-uma-matriz-de-riscos/)

Identificando os riscos que devem ter maior atenção, podemos recorrer a algumas abordagens para execução dos testes.

Abordagens para testar aplicações legadas

Para garantir a qualidade de aplicações legadas, devemos ter um olhar voltado para todos os aspectos do sistema, enfatizando sempre os processos possivelmente mais críticos – aqueles que possuem maiores acessos, que de alguma forma possuam maior valor ao cliente ou até mesmo aqueles que concentram maior fluxo de transações. 

Assim, podemos adotar os procedimentos de testes que irão nos auxiliar na compreensão e execução de testes mais efetiva. Abaixo, entraremos em detalhe sobre os tópicos elencados:

Ler e entender o código fonte

Como já comentamos anteriormente, em um sistema legado há uma carência de documentação de software ou a mesma pode se encontrar desatualizada. Portanto, para obtermos bons resultados com os testes, precisamos nos ater a pessoas que possuam domínio e conhecimento das aplicações para levantar insumos.

Uma medida a ser adotada para melhor entendimento do processo é começar pela análise e leitura do código fonte do sistema. 

Verificar históricos de alteração da aplicação

Outra possibilidade que nos ajuda no domínio das funcionalidades da aplicação é verificar os históricos de alterações. Essa abordagem nos ajuda a visualizar as correções, implementações e melhorias realizadas ao longo do tempo. 

Conforme este histórico, conseguimos construir o entendimento da aplicação e mapear os possíveis cenários de testes.

Implementar Testes de Caracterização

Os testes de caracterização têm um papel fundamental em aplicações legadas. Eles auxiliam na verificação de modificações no código fonte, garantindo que a modificação não afete o comportamento de maneira indesejada.

De modo geral, um teste de caracterização não valida o comportamento correto do código (como é feito em testes de regressão, por exemplo) mas sim, o que o código faz atualmente.

Michael Feathers, em Working Effectively with Legacy Code, sugere um script de testes simples para escrever testes de caracterização:

  1. Pegue uma parte do código fonte;
  2. Escreva uma afirmação que você sabe que irá falhar;
  3. Execute o teste e deixe que a falha lhe diga qual é o comportamento real;
  4. Altere o teste para que ele espere o comportamento que o código realmente produz;
  5. Realize uma nova repetição para garantir a efetividade do teste;

Testes de comparação de resultados em processamentos via banco de dados

Algumas aplicações legadas possuem suas regras de negócio voltadas para o banco de dados. Consequentemente, outra alternativa que podemos adotar é a implementação de testes voltados para tal processamento. 

Estes testes irão verificar os valores gerados em uma tabela de banco de dados, comparando-os e garantindo que a troca de uma versão, implementação, melhorias ou correção de um bug não afetaram a sua funcionalidade.

Podem ser implementados por testadores ou desenvolvedores e executados antes de cada release ou dentro das squads a cada alteração/implementação realizada no código fonte.

Implementar Testes Exploratórios 

Testes exploratórios também são muito utilizados em sistemas legados, dado que há uma carência de documentação, e como o próprio nome já diz, estes são testes que exploram a aplicação – entendendo intrinsecamente o que ela faz e o que ela não faz, o que funciona e o que não funciona – sob a perspectiva do usuário. 

Neles, podemos exercitar algumas práticas e abordagens como:

  • Técnicas de caixa-preta;
  • Técnicas baseadas na experiência;
  • Validação de formulários;
  • Tipos de Personas;
  • Tours, entre outros.

Implementar Testes na camada de interface de usuário

Os testes de interface de usuário, também conhecido como testes E2E (end-to-end), são importantes pois validam e verificam se dependências de uma aplicação estão funcionando como deveriam. Assim, atesta-se a comunicação entre os componentes do sistema.

Ou seja, os testes E2E automatizados irão identificar possíveis dependências do sistema e garantir que a informação certa seja passada entre os vários componentes e informações do sistema desenvolvido.

Implementar Testes de Regressão

Através de uma suíte de testes bem estruturada, é possível validar as aplicações críticas ou aquelas pontuadas como importantes para a funcionalidade do sistema. Estes testes garantem que as alterações e/ou implementações não afetaram negativamente as funcionalidades do sistema. 

Outro fator importante é a automação destes testes que reduz os esforços em execuções de testes manuais e repetitivos, além de possibilitar uma rápida resposta sobre alguma falha em outro teste.

Saiba mais sobre outros tipos de testes aqui.

No fim das contas, por onde devo começar?

Em síntese: explore ao máximo a aplicação

Utilize qualquer insumo a seu favor – desde realizar debug no código fonte, analisar alterações feitas ao longo do tempo ou contatar pessoas que detenham da experiência do software. Assim, você irá conseguir realizar/implementar testes nas aplicações de forma mais assertiva, agregando valor e efetividade, buscando melhor qualidade ao seu produto. 

Lembre-se: Começar a implementação dos testes pelas funcionalidades de maior risco ou funcionalidades que contenham uma incidência maior de correção de bugs é a melhor alternativa para garantir que o software fique estável. Deste modo, você evita paradas de operações ou outros fatores agravantes. 

Busque também mecanismos para automatizar testes em camadas mais baixas, pois o custo da detecção e correção de um problema será, consequentemente, menor.

Leave a Reply