3.4 - Implementação¶

Do ponto de vista da entrega, existe uma complementação da implementação realizada pela área de engenharia.

O sistema quando chega nesse estágio, já está testado funcionalmente e já foram realizados alguns builds e deploys da etapa de desenvolvimento.

O sistema é validado no ambiente do Ministério do Planejamento, com a infraestrutura similar com a que será utilizada em produção.

São feitos ajustes apenas para adequação de variáveis de ambientes, mas deve ser construído um job similar ao construído na etapa da construção/engenharia.

Como o ambiente é similar ao final, tratamos nessa etapa os testes não funcionais, avaliamos os scripts e seguimos o manual de implantação com a finalidade de validar sua execução.

3.4.1 - Testes Automatizados¶

Em complemento aos eixos de Estruturação 1.3 - Qualidade e Engenharia 2.4.1 - Testes, seguem algumas diretrizes e premissas a serem validadas na implementação dos artefatos de testes automatizados:

• Testes de Interface/Fumaça:

Premissas:

1. O Percentual de cobertura de testes a ser atingido estará descrito no Contrato ou na Ordem de Serviço;
2. É sugerido que o percentual seja definido e aplicado para cada História de Usuário, de acordo com os critérios que o Líder de Projeto e Dono do Produto definirem durante o projeto;
3. Para permitir a rápida identificação da história e dos critérios testados, é importante que o relatório gerado pelo teste automatizado retorne de forma clara a história e critério testado;
4. É de suma importância que a implementação venha parametrizada e preparada para apontar/configurar qual o ambiente será utilizado para a execução dos testes de interface;
5. Testes de interface automatizados não devem fazer a acesso direto a banco de dados a menos que se tenha uma justificativa para o uso de tal implementação.

Momento a ser executado: A cada nova TAG entregue pela Fábrica via processo automatizado de build e deploy;

• Teste unitário:

Premissas:

1. O Percentual de cobertura de testes a ser atingido estará descrito no Contrato ou na Ordem de Serviço;
2. Por conta da natureza deste tipo de teste que executa de forma isolada arquivos/classes, efetuando a simulação de valores fictícios (mock's) para as demais dependências, o Ministério do Planejamento entende que estes devem ser priorizados somente em casos aonde a implementação efetiva de parte da aplicação ainda não possa ser desenvolvida por completo ou é dependente de componente/serviço de terceiro que pode não estar acessível ou pronto no momento do desenvolvimento. Caso este não seja o caso, os Testes de Integração devem ser priorizados no lugar dos Unitários em comum acordo com o Líder de Projeto e a cobertura atingida por eles pode ser utilizada de forma equivalente para o percentual exigido em contrato para os Testes Unitários;

Momento a ser executado: A cada nova TAG entregue pela Fábrica via processo automatizado de build e deploy ;

• Teste de integração:

Premissas:

1. O Percentual de cobertura de testes a ser atingido estará descrito no Contrato ou na Ordem de Serviço e em comum acordo com o Líder de Projeto, poderá ser utilizado de forma equivalente para o atendimento do percentual de Testes Unitários;
2. O comportamento do sistema não deve ser simulado através de valores fictícios (mocks)
3. Deve ser gerado em tempo de execução banco e massa de dados em memória (Ex: Banco H2 em Java ou SQLite em PHP) para a simulação dos cenários de testes necessários, sendo este Banco destruído ao final da execução dos testes;
4. Recomenda-se que o ponto de partida dos testes sejam sempre as portas de entrada do sistema (serviços REST, Controladoras, etc.), desta forma torna-se mais prático e eficiente percorrer todo o código fonte e quantidade de classes de testes que precisarão ser criadas será muito menor;

Exemplo:

• Classe Controladora que expõe o serviço REST acessa:

• Classe de Repositório/Regra de Negócio que acessa:

• Classe de Modelo/Entidades

Momento a ser executado: A cada nova TAG entregue pela Fábrica via processo automatizado de build e deploy;

3.4.2 - Testes Não Funcionais¶

• São testes não funcionais, os realizados com a objetivo de validar ou verificar algum aspecto que não envolvem funcionalidades do sistemas, ou seja, que testam requisitos não funcionais.

• Em complemento a 1.3 - Qualidade, no contexto do Ministério do Planejamento os testes não funcionais são hora parametrizados pelas áreas de negócios, hora definidos por aspectos da infraestrutura e segurança.

• Nos testes de segurança é usada a ferramenta OWASPZAP que testa a lista de vulnerabilidade elencadas pela OWASP a cada dois anos.

• Além disso, podem ser usados inspeções de aplicações feitas por equipamentos de segurança, a depender do projeto.

• Já nos aspectos de confiabilidade e desempenho é usada a ferramenta Jmeter.

• Os testes de manutenibilidade e usabilidade são feitos de forma manual e pontual.

• A própria aferição pelas áreas de negócios da navegabilidade e a instalação e na esteira dos ambientes valida alguns aspectos desses testes.

• A depender do tipo de teste a ser executado, os critérios de qualidade e aceitação devem ser acordados com o Líder de Projeto e precisam estar de acordo com os artefatos previstos no respectivo Contrato que será utilizado.

• Os artefatos entregues deverão ser armazenados no repositório Git quando se tratarem de código-fonte de uma aplicação de teste ou no Redmine quando se tratar de documentos formais e evidências de execução.