Gerência de Qualidade (GQA, Nível F)
As MPS.BR GQA definem um conjunto de padrões para garantir a qualidade do software na seção de Gerência de Qualidade. Como em todas as MPS.BR, não há um exemplo direto a ser seguido, apenas diretrizes que devem ser atendidas:
- RAP 4. Medidas são planejadas e coletadas para monitoração da execução do processo e ajustes são realizados;
- RAP 10. (A partir do nível F) A aderência dos processos executados às descrições de processo, padrões e procedimentos é avaliada objetivamente e são tratadas as não conformidades.
- RAP 13. Os produtos de trabalho são colocados em níveis apropriados de controle;
- RAP 14. Os produtos de trabalho são avaliados objetivamente com relação aos padrões, procedimentos e requisitos aplicáveis e são tratadas as não conformidades.
Citando a própria MPS, "O propósito do processo Garantia da Qualidade é assegurar que os produtos de trabalho e a execução dos processos estejam em conformidade com os planos, procedimentos e padrões estabelecidos". Para tal, nos utilizamos de diversos testes sobre o nosso sistema.
Antes de apresentar os testes em si, vamos definir alguns conceitos sobre testes.
Um teste unitário é um teste focado apenas em um pedaço de código, geralmente uma função ou módulo. Fazendo o teste ser específico, conseguimos descobrir pequenos bugs individualmente. Estes testes devem ser pequenos e rápidos, e assim podemos utilizar vários deles para as diversas funções do sistema.
Existem também os testes de integração (que avaliam como as partes menores funcionam em conjunto) e testes de aceitação (que avaliam a aplicação como um todo).
TDD ou Test Driven Development é um processo de escrita e execução de testes, que visa aumentar o alcance destes sobre a aplicação e ainda obter a capacidade de descobrir bugs nos próprios testes. O processo é o seguinte:
- Primeiro escreva o teste
- Execute todos os testes. O teste recém escrito deve falhar. Se este não falhar, ele não está testando a coisa certa
- Escreva um código mínimo que faça o teste passar
- Execute os testes novamente. O novo teste deve passar
- Escreva o teste na sua forma final
- Repita
BDD ou Behavior Driver Development é um conjunto de práticas para escrever testes bons. Deve ser utilizado em conjunto com TDD e métodos de teste unitário.
Em BDD, ao invés de testarmos a implementação, nós focamos nossos testes no comportamento do código. Ou seja, ao invés de pensarmos na implementação, nós pensamos no cenário e contexto do sistema, e testamos se as funções atendem ao que é esperado desse cenário.
No nosso sistema, nós utilizamos as seguintes ferramentas para escrever os testes:
- Specflow: adapta o Cucumber do java para o C#. Este framework permite que nós escrevamos cenários de acordo com a metodologia BDD, e auxilia na criação e implementação de funções que implementem os testes nessa paradigma.
- NUnit: é um framework de testes unitários para a plataforma .NET. Os cenários do Specflow geram testes unitários que são implementados utilizando este framework.
- Xamarin.UITest: é um framework automatizado de teste baseado no Calabash, que visa auxiliar na implementação de testes para aplicativos Android e iOS.
Vamos fazer aqui a descrição dos principais cenários de teste do nosso sistema. Os cenários serão apresentados de acordo com a linguagem Gherkin, utilizada pelo Cucumber e Specflow. Cada cenário representa um caso de uso do nosso sistema.
Quando o usuário faz seu cadastro no nosso sistema, os dados informados devem ser válidos. Além disso, não podem haver emails duplicados na nossa base de dados.
Os usuários cadastrados fazem seu login no sistema no início da sessão.
Um usuário logado no sistema pode checar as suas combinações (pessoas com um interesse compatível com o do usuário em relação a cada item).
Outro aspecto muito importante na gerência de qualidade é a qualidade do código em si. Código bem feito, seguindo regras pré-estabelecidas que promovem clareza, é muito mais fácil de se fazer manutenção e documentação (Paulo Sérgio, 2016).
Nesse parte, podemos destacar duas vertentes: padrões de projeto e clean code.
Segundo o professor da UFMG Jeferson Alex dos Santos, padrões de projeto são combinações recorrentes de elementos de modelagem que ocorrem em algum contexto. Esses padrões podem ser aplicados em diversas etapas do desenvolvimento de software, e nos fornecem modelos à serem seguidos para resolver problemas recorrentes de forma elegante e clara.
Citando Bjarne Stroustrup, inventor da linguagem C++:
I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well.
Segundo Grady Booch, Clean Code deve ser lido como uma prosa: deixando clara a intenção do autor, mas cheia de abstrações e linhas de controle diretas.
Ou seja, não há uma definição universal de Clean Code. É apenas um modelo onde deve imperar a clareza e eficiência, de forma a facilitar o entendimento, manutenção, modularização, entre diversos fatores, onde tudo depende do contexto de uso e desenvolvimento do software.
No nosso trabalho, optamos por utilizar um software de análise de código chamado SonarQube. SonaQube é um projeto de código aberto que faz a análise do código à partir de padrões pré-definidos, apontando falhas nas normas escolhidas, falhas lógicas, redundâncias, entre outros fatores que diminuem a clareza e eficiência do software.
O SonarQube, no nosso caso, é executado localmente por cada um dos programadores no branch local. A branch master do projeto só deve conter código limpo, ou seja, onde foi feita a análise do código e este foir aprovado.
Já as branches development e derivadas não necessariamente contém código limpo. Muitas vezes é mais fácil implementar o código de uma forma mais desordenada e só depois efetur as melhorias, e por esta razão deixamos a análise em aberto nessas branches. Entretanto, antes de qualquer merge para a branch master, deve ser feita a análise completa da branch development e essa obrigatoriamente deve ser aprovada.
Além disso, como todo o nosso trabalho foi desenvolvido na plataforma .NET, adotamos as normas de Clean Code padrão para C# do SonarQube.
A tabela abaixo mostra a definição das métricas de qualidade para o nosso projeto.
Essas métricas estão sendo validadas e acompanhadas através do SonarQube e testes internos entre os desenvolvedores.
Segue abaixo uma tabela mostrando as táticas adotadas pela equipe ao tratar de atributos de qualidade.
