De tempos em tempos, todo software desenvolvido necessita se atualizar: adicionando melhorias e ajustando falhas. E com o módulo Gerencial da SMAR não é diferente. Percebeu-se a oportunidade de utilizar o módulo Gerencial em sistemas operacionais com kernel Linux e de agregar tecnologias mais atuais ao processamento dos dados (back-end) deste módulo, trazendo maior velocidade e ganho de performance.

É uma boa prática no desenvolvimento de software que as novas versões de um sistema recém-lançado passem pelo teste de retrocompatibilidade. O teste de retrocompatibilidade visa garantir que a aplicação funcione corretamente para usuários que possuem diferentes versões do sistema, mesmo havendo alterações no código desta aplicação.

Aplicando em nosso contexto, um dos modos de verificarmos a retrocompatibilidade do módulo Gerencial é através de sua API (Application Programming Interface, ou Interface de Programação de Aplicação), analisando o seu comportamento entre as suas diferentes versões. Para interagirmos com os serviços oferecidos por uma API, os métodos HTTP (Hypertext Transfer Protocol, ou Protocolo de Transferência de Hipertexto) mais utilizados são:

• GET para realizar consultas;
• POST para cadastrar registros;
• PUT para editar registros;
• DELETE para apagar registros.

As interações são denominadas requisições, sendo que cada método é um tipo diferente de ação que realizamos na API. Para cada tipo de requisição esperamos um comportamento diferente por parte da API e, para compreendermos se tudo ocorreu como esperado, existem famílias de respostas padronizadas de código de status, seguindo-se o seguinte padrão:

• Informational (Informação) de 100 à 199: indicam que a requisição foi recebida e que está sendo processada;
• Success (Sucesso) de 200 à 299: indicam que a requisição obteve êxito;
• Redirection (Redirecionamento) de 300 à 399: indicam que requisições adicionais devem ser feitas para se completar a requisição original;
• Client Error (Erro no cliente) de 400 à 499: indicam um erro no entendimento da requisição;
• Server Error (Erro no servidor) de 500 à 599: indicam a ocorrência de um erro no servidor ao tentar executar uma requisição válida.

A conversão do módulo Gerencial foi realizada no setor P&D eo time Quebec, foi o responsável por testar e garantir a qualidade da API do novo Gerencial. Foram então definimos alguns pontos importantes:

• Compreensão toda a dimensão do projeto: organizando o trabalho a ser realizado e estudando a melhor forma de resolvê-lo.
• Emprego da metodologia Scrum: atendendo à necessidade de planejar os testes em pequenos ciclos de trabalho, deixando-o atômico e manejável.
• Planejamento do backlog do projeto: Como a conversão do Gerencial descreveu os detalhes da API através do Swagger, os seus controllers e endpoints, optou-se por criar uma User Story por controller presente nesta documentação.
• Estimativa da complexidade das tarefas: garantimos que todos os endpoints presentes no Swagger seriam cobertos por testes e que as User Stories possuiriam uma complexidade factível. Caso a User Story ficasse com treze Story Points ou mais, essa US era dividida em quantas partes fossem necessárias.

Após este planejamento, partiu-se para a execução dos testes da API verificando determinados aspectos estruturais e de conteúdo de cada endpoint, analisando se o novo Gerencial estava retrocompatível com o antigo.

Como alguns requisitos foram alterados devido ao tempo transcorrido entre a conversão feita até a realização efetiva dos testes no Gerencial, foi necessária a revisão do código pelos desenvolvedores do time antes da passagem de cada User Story para os analistas de qualidade.

Utilizando principalmente a ferramenta Postman, avaliamos se mesmo reescrevendo o código da API com uma nova tecnologia, seriam mantidas as entradas e saídas do antigo. A seguir temos um detalhamento sobre os testes efetuados no Postman para cada um dos endpoints do novo Gerencial:

• Verificação de rota correta: garantia de que o caminho (path) para acessar determinado recurso permaneceu igual ao do módulo Gerencial legado;
• Verificação de autorização (Token de Acesso): para acessar um recurso do Gerencial, o usuário precisa possuir autorização. Foram testados tokens válidos, inválidos e também a sua ausência;
• Verificação de parâmetros e variáveis: cada endpoint possuía particularidades na estrutura de sua requisição e necessitavam de parâmetros exclusivos para o seu pleno funcionamento, atendendo desta maneira as regras de negócio. Foram testados: o “caminho feliz”, aquele em que todos os parâmetros e variáveis estão corretos; e os caminhos alternativos, aqueles em que se altera os valores dos parâmetros e das variáveis, visando-se avaliar os seus limites, as suas ausências e seus diferentes tipos;
• Verificação de resposta e status: assegurando que as requisições retornavam de maneira idêntica as respostas em relação ao antigo Gerencial, comparando status e estruturas das respostas;
• Acompanhando alterações: utilizando o banco de dados como apoio aos testes, pudemos observar que as alterações eram realmente efetivas no sistema.

A reta final dos testes contou com o auxílio do time Echo. Tendo todos os processos de testes consolidados e validados pelo time Quebec, o apoio de outra equipe pôde ser feito de forma veloz e com enorme entrega de valor.

Após a finalização dos testes de conversão dos 359 endpoints do Gerencial, divididos em 93 User Stories, podemos garantir a qualidade na entrega de um módulo renovado e com maior eficiência, além da certeza de que este modelo de trabalho pode ser facilmente replicado em futuros projetos da SMAR.

Referências bibliográficas:

• MDN Web Docs - https://developer.mozilla.org/en-US/docs/Web
• API RESTful - Boas práticas - https://www.brunobrito.net.br/api-restful-boas-praticas/
• Teste de API: o que é, como fazer e boas práticas - https://www.lucidchart.com/blog/pt/teste-de-api-guia-completo