Processo de Entrega de Soluções

h1. 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.

h1. 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:

*  %*{color:green}Testes de Interface/Fumaça*%: 

>> *Premissas:*

> # O Percentual de cobertura de testes a ser atingido estará descrito no Contrato ou na Ordem de Serviço;

> # É 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;

> # 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; 

> # É 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;

> # Testes de interface automatizados %{color:red}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;

*  %*{color:green}Teste unitário*%: 

>> *Premissas:*

> # O Percentual de cobertura de testes a ser atingido estará descrito no Contrato ou na Ordem de Serviço;

> # %{color:blue}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 ;

*  %*{color:green}Teste de integração*%: 

>> *Premissas:*

> # 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*;

> # O comportamento do sistema não deve ser simulado através de valores fictícios (mocks)

> # 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;

> # 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;

h1. 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.