Qualidade de Software: processos e metodologias de teste

O teste de software é uma etapa que abrange o processo de validação e verificação com o intuito de identificar se o sistema desenvolvido atende aos requisitos definidos pelo usuário e assim garantir a qualidade do software. Esses testes têm a função de localizar bugs, erros e/ou requisitos ausentes no sistema ou software desenvolvido. Portanto, este processo investigativo fornece aos desenvolvedores e stakeholders informações sobre a qualidade do produto.

Tendo em vista a crescente complexidade dos aplicativos de software e a pressão competitiva do mercado, tornou-se necessária a utilização de metodologias que levassem a garantia de qualidade do software desenvolvido a novos patamares. 

O teste de software é uma parte inevitável do Ciclo de Vida de Desenvolvimento de Software. Para manter os testes alinhados com o desenvolvimento do projeto, existem metodologias e técnicas aprimoradas e eficientes.

TDD

Para realizar testes, utilizam-se alguns artifícios e tecnologias, porém cada um para seu objetivo e necessidade. Usualmente, utiliza-se o TDD (Test Driven Development ou Desenvolvimento Guiado por Testes) como boa prática. Ele consiste no desenvolvimento voltado para a realização de testes automatizados com base em ciclos curtos de duração e consistência na qualidade de código. Desse modo, para implementar o TDD, podemos realizar alguns passos:

1. Desenvolva um código que falhe

Inicialmente, deve-se ter um parâmetro de código para se criar problemáticas de tal forma que o algoritmo não passe pelos testes previamente estipulados. Essa fase é denominada “vermelha”, a qual é associada ao erro que normalmente aparece.

2. Adição de Funcionalidades

Após realizarmos a proposta de testes para a aplicação, devem ser adicionadas algumas funcionalidades para fins de melhoria e atualização da aplicação.

3. Solução dos erros iminentes

Após a inserção de novas funcionalidades e realização dos testes, a aplicação requer um tratamento de dados e solução dos erros encontrados. Para isso, é necessário pensar em formas corretas de solucionar esses erros. Na maioria dos casos, essa etapa é a de maior duração, pois podem aparecer erros em ‘cascata’, isto é, sequência de erros que venham a surgir após a solução de outros. Essa fase é denominada “verde”, cuja saída consiste em uma aplicação executando sem erros.

4. Refatoração do código

Logo em seguida, é necessário uma atualização do código com as novas funcionalidades e uma melhoria na qualidade do software. Mediante a isso, é necessária a realização de uma refatoração no código para que se feche o ciclo do TDD e recomece com novos testes.

5. Novos Testes

Após o cumprimento de todas as etapas, propõe-se um novo teste, de modo que cada novo ciclo seja voltado a uma nova funcionalidade. Além disso, escreve-se escrita uma nova versão do código a partir do ciclo precedente. Contudo, é aconselhável que tais testes sejam realizados de forma fragmentada e atômica.

Motivações para o uso do TDD

Para incentivar os desenvolvedores, alguns dos benefícios encontrados com o uso do TDD em suas aplicações serão:

• Feedback mais rápido de novas funcionalidades; 
• Segurança na refatoração do código, pois fica mais fácil de identificar os erros e suas causas;
• Otimização do tempo para um melhor aproveitamento do trabalho, evitando a necessidade resolver bugs em uma quantidade desnecessária e com depuradores;
• Flexibilidade do código, que deve ser fragmentado para os testes, garantindo a sua realização de forma focada;
• Tempo de desenvolvimento ágil com adição de funcionalidades, já que o sistema é mais flexível e o código mais limpo;
• Possibilidade de Integração Contínua, com builds automatizadas e feedbacks rápidos dos problemas.

V-model

O V-Model, também conhecido como modelo de verificação e validação, é um tipo de modelo SDLC (Software Development Life Cycle ou ciclo de vida de desenvolvimento de software) onde o processo é executado de forma sequencial e em forma de V. Este método foi proposto por Paul Rook em 1896 e ainda é utilizado atualmente. O V-Model baseia-se na associação de uma fase de teste para cada estágio de desenvolvimento correspondente.

Verificação no estágio de desenvolvimento do software

No lado referente ao estágio de desenvolvimento do software, temos a fase de verificação, que envolve técnicas de análise estática feita sem a execução de código. Esta fase está dividida em quatro blocos:

• Análise de requisitos: também conhecida como coleta de requisitos, nesta etapa há uma comunicação detalhada com o cliente para entender quais são seus requisitos e expectativas para o produto.
• Projeto do Sistema: neste estágio, o sistema é projetado e há também a configuração completa de hardware e comunicação para o desenvolvimento do produto.
• Projeto arquitetônico: nesta etapa, subdivide-se o projeto do sistema em módulos com diferentes funcionalidades. A transferência de dados e a comunicação entre os módulos internos com o mundo externo devem ser claramente compreendidas neste estágio.
• Projeto do Módulo: o projeto detalhado de cada um dos módulos é especificado nesta etapa.

Validação no estágio dos testes

Referente ao estágio dos testes, temos a fase de validação, que envolve técnicas de análise dinâmica feita pela execução de código. A validação verifica se, após a conclusão da fase de desenvolvimento, o software atende às expectativas e aos requisitos do cliente. A fase de validação se divide também em quatro blocos:

• Teste de aceitação: é o último teste realizado antes da implementação do software. Seu principal objetivo é verificar se todo o sistema funciona conforme o planejado.
• Teste de sistema: esses testes verificam se os componentes de um sistema computacional, tanto componentes de software quanto de hardware, se integram bem e são capazes de realizar as funcionalidades especificadas dos requisitos do projeto.
• Teste de integração: têm o objetivo de encontrar falhas de integração entre os módulos do software que operam em conjunto. Alguns exemplos de testes que podem ser aplicados nessa fase são os testes de interface e os testes de dependências entre os componentes.
• Teste de unidade: valida se cada unidade que compõe o software, isoladamente, funciona conforme o esperado, sendo que uma unidade é o menor componente testável de um aplicativo.

A avaliação da qualidade do software é muito importante para ser feita apenas ao fim do projeto, e o V-Model incorpora os testes em todo o ciclo de vida de desenvolvimento do software. Além da vantagem de se detectar erros na fase inicial do desenvolvimento, o V-Model também é fácil de gerenciar devido à sua rigidez. Cada fase do V-Model tem resultados específicos e um processo de revisão. No entanto, vale ressaltar que este modelo não é adequado para projetos onde os requisitos não são claramente definidos ou fixos.

Qualidade de software e Clean Code

Atualmente, a qualidade de código e escalabilidade são os maiores problemas na área de TI, pois culminam em acúmulos de defeitos e aumentam a dificuldade na comunicação entre desenvolvedores em ferramentas de versionamento, por exemplo.

Escrever um código com defeitos e gambiarras pode até funcionar, mas provavelmente um problema estará sendo adiado, tornando-se uma “bola de neve”. O custo para resolver tais problemas no futuro será muito maior, além de abrir a possibilidade de afetar outras áreas do ambiente de desenvolvimento. 

A partir disso, as padronizações e uma boa organização do código tornam-se necessárias. Portanto, pode ser aplicado o Código Limpo (ou Clean Code) para implementar uma padronização, tomando atitudes que sejam responsáveis pelo profissionalismo e pela qualidade de código.

Em 1982, James Q. Wilson e George L. Kelling escreveram um famoso artigo chamado “Janelas Quebradas”. Em uma citação, trouxeram uma indagação que pode ser adaptada como uma metáfora em diversos setores: “Pense em um edifício com apenas algumas janelas quebradas. Se as janelas não forem reparadas, a tendência é que vândalos quebrem mais janelas. Eventualmente, poderão inclusive entrar no edifício, e se este estiver desocupado, pode ser tomado ou até mesmo incendiado”.

Esse trecho pode ser associado com o comportamento comum de pessoas mais inexperientes em equipes de TI, pois a teoria das janelas quebradas pode ser compreendida como uma analogia dos problemas enfrentados no desenvolvimento de software.

Muitas vezes, o algoritmo não é desenvolvido com cuidado e não possui testes, culminando, assim, na incúria de apenas manter códigos que são executados, contudo contendo diversos métodos de resolução não recomendados e com uma série de riscos, como as famosas “gambiarras”.

Mas, afinal, o que é um código limpo?

A primeiro momento, deve-se ter a noção de que diversos artifícios tornam o código mais fluido, organizado e sólido. Tais padrões são definidos por 7 principais regras: 

1. Nomes são de extrema importância: É primordial possuir nomenclaturas de funções, métodos, classes, parâmetros e variáveis para um bom entendimento do código, de modo que seja direto, objetivo e demonstre a sua utilidade.

2. Regra do Escoteiro: Há uma regra entre os escoteiros que diz “Uma vez que você sai da área em que está acampando, você deve deixá-la mais limpa do que quando a encontrou.”. Portanto, deve sempre aprimorar o código e deixá-lo mais organizado do que quando o herdou.

3. Seja o verdadeiro autor do código: Geralmente, nós pensamos de maneira narrativa, portanto deve-se programar sempre seguindo uma lógica cronológica dos eventos, sempre seguindo os princípios de que as funções devem ser pequenas e elas devem ser cada vez mais atômicas.

4. DRY (Don’t Repeat Yourself): As ambiguidades na escrita do código devem ser estritamente evitadas, pois isso atrapalha o desenvolvimento dele e a sua compreensão. Portanto, de modo algum, mais de uma funcionalidade deve executar a mesma coisa.

5. Comente apenas o necessário: Deve-se sempre evitar uma grande quantidade de comentários no código, pois isso pode deixá-lo confuso e poluído. Desse modo, é importante sempre se perguntar “esse comentário é necessário?” Além disso, é importante observar se ele pode ser substituído por uma melhor especificação na nomenclatura.

6. Tratamento de erros: É fundamental que o desenvolvedor conheça sua aplicação e reconheça a importância de manter o seu pleno funcionamento, porém é comum que aconteçam erros. Contudo, o programador é responsável por garantir que a sua aplicação continue fazendo o que precisa. Portanto, saber tratar as exceções de forma correta é um importante passo para um programador em desenvolvimento.

7. Testes limpos: O desenvolvedor deve ter em mente o princípio que o seu código só deve ser validado por uma série de testes, que também devem ser limpos. Esses testes obedecem a alguns princípios:

• Rápido: Deve ser realizado rapidamente, de forma que possa ser realizado diversas vezes. 

• Independente: Deve ser realizado de forma que evite o efeito cascata, o que dificulta a análise de software.

• Repetível: Os testes devem ser repetidos diversas vezes e executável em diversos ambientes diferentes.

• Auto-validação: Os retornos devem possuir uma saída booleana (true ou false), de modo que evite a subjetividade.

• Oportuno: Os testes devem obedecer ao critério da pontualidade. Desse modo, é aconselhável que sejam escritos antes mesmo de começar a construir o próprio código, pois evita a complexidade para que seja testado.

Ao implementar o Clean Code, os resultados são bem definidos, aparecem menos bugs e há também uma menor dificuldade em compreender códigos herdados. 

Pair Programming

Um problema comumente encontrado nas equipes é a dispersão de alguns desenvolvedores ou baixa cooperação entre eles. Diante disso, é realizado um método cooperativo de programação com dois desenvolvedores, chamado Pair Programming. Este método consiste em programar em duplas, de modo que atenue as distrações durante o processo produtivo, aumentando o foco e diminuindo a quantidade de interrupções desnecessárias que venha a acontecer por terceiros. Ademais, muitas vezes aumenta a produtividade pelo princípio de “duas cabeças pensam melhor do que uma só”, além de aumentar a disseminação de conhecimento na equipe, aproximar mais os desenvolvedores e facilitar o processo de gestão, culminando na redução da curva de aprendizado de forma relevante.

Refatoração de Código

A refatoração de código, também conhecida pelos padrões do Clean Code como Refatoring, de acordo com o Martin Fowler: “Refactoring é uma alteração feita na estrutura interna do software para torná-lo mais fácil de ser entendido e menos custoso de ser modificado, no entanto, sem alterar seu comportamento observável.”

De fato, ao realizarmos a refatoração do código, agregamos longevidade e competitividade ao software, de modo que é adaptável à grande rotatividade de desenvolvedores que há nas empresas. Assim, com a adaptação e cuidados com o código, ele se torna independente da pessoa que o escreveu.

Qualidade de Software: processos e metodologias de teste – Considerações finais

As metodologias de teste em engenharia de software são estratégias, abordagens ou métodos utilizados com o intuito de testar um sistema específico para garantir sua usabilidade, garantindo que o produto final funcione de acordo com as especificações fornecidas. Portanto, para que essa escolha seja realizada com eficácia, existem diversos modelos de testes de software. Contudo, cada um emprega uma metodologia de teste distinta, testando a qualidade do software e a segurança dele de maneiras diferentes e em estágios diferentes.

Escolher uma estratégia de teste de software adequada é uma decisão essencial e deve ser finalizada antes do início do projeto. Contudo, é essencial adotar metodologias de teste robustas para garantir que o software em desenvolvimento seja totalmente testado, atenda aos requisitos necessários e opere com sucesso em todos os ambientes previstos com a usabilidade e segurança necessárias.

Para que tudo isso seja entrelaçado e possamos garantir a qualidade final do software, também é aconselhável que boas práticas sejam implementadas na equipe de desenvolvimento e em empresas, como o Clean Code, de forma que profissionalize, agregue eficácia no desenvolvimento e produtividade às pessoas envolvidas no processo.

Ficou com alguma dúvida sobre os processos e metodologias de teste que garantem a qualidade do software? Deixe o seu comentário.

Autores