Processo de Entrega de Soluções

h1. 1.3 - Qualidade

h3. 1.3.1 Tipos de testes %*{color:red}obrigatórios%* aos projetos envolvendo Fábrica de Software  

*  %*{color:green}Teste funcional/de aceitação*%: assegurar a funcionalidade da solução de software (aplicação, sítio, portal ou aplicativo móvel), incluindo navegação, entrada de dados, processamento e resposta, verificando se a aplicação está pronta e pode ser utilizada pelos usuários finais. As partes, ou módulos, do sistema são testadas em conjunto

*  %*{color:green}Teste unitário*%: processo em que se verificam as menores unidades de software desenvolvidas (pequenas partes ou unidades da aplicação). O objetivo é encontrar falhas de funcionamento dentro de uma pequena parte da aplicação funcionando independentemente do todo;

*  %*{color:green}Teste de interface*%: verifica se a navegabilidade e os objetivos das telas funcionam como especificados; valida se a navegação através da solução de software reflete corretamente as especificações dos requisitos, incluindo janela-a-janela e campo-acampo, além de uso dos métodos de acesso (teclas tab, movimentos de mouse, teclas de atalho etc.). Além disso, no caso do MP, deve-se verificar a conformidade com padrões de mercado e governamentais, dentre eles o e-MAG – Modelo de Acessibilidade de Governo Eletrônico (www.governoeletronico.gov.br/acoes-e-projetos/e-MAG);

h3. 1.3.2 Testes não funcionais e outros tipos passíveis de serem aplicados aos projetos:

*  %*{color:green}Teste de carga*%: processo que testa e mede a alteração no desempenho da solução de software sob um volume maior de carga, como, por exemplo, a carga máxima esperada em um determinado momento no ambiente de produção;

*  %*{color:green}Teste funcional/de aceitação*%: assegurar a funcionalidade da solução de software (aplicação, sítio, portal ou aplicativo móvel), incluindo navegação, entrada de dados, processamento e resposta, verificando se a aplicação está pronta e pode ser utilizada pelos usuários finais;

*  %*{color:green}Teste de desempenho*%: processo que testa e mede o desempenho da solução de software em uma situação normal de uso, bem como o quanto a solução requer de recursos de hardware e o tempo de espera necessário entre as ações e transações, com base no cenário esperado normalmente para ambiente de produção;

*  %*{color:green}Teste de estresse*%: processo que busca descobrir qual a carga máxima suportada pela solução de software. Esse limite pode ser um valor muitas vezes acima do esperado na carga máxima;

*  %*{color:green}Teste de exploração*%: processo em que o ser humano explora as funcionalidades da aplicação;

*  %*{color:green}Teste de falha e recuperação*%: validar se o processo de recuperação (manual ou automático) restaurou corretamente os dados diretamente afetados em caso de falha;

*  %*{color:green}Teste de segurança*%: permite avaliar as vulnerabilidades do software em relação à segurança, tais como ataques de negação de serviço, Cross-Site Scripting (XSS) e SQL Injection, para que sejam corrigidas antes de ser operacionalizado em ambiente de produção. Verificar se os requisitos de segurança estabelecidos pelas normas e diretrizes do MP estão sendo atendidos. Inclui-se neste tipo de teste a inspeção de códigos-fonte para garantia de desenvolvimento de software seguro;

*  %*{color:green}Teste de integridade de dados*%: para garantir que os métodos e processos de acesso ao banco de dados funcionem adequadamente e sem corromper os dados;

*  %*{color:green}Teste de regressão*%: consiste em se aplicar, a cada nova versão do software ou a cada ciclo, todos os testes que já foram aplicados nas versões ou ciclos de teste anteriores para garantir que manutenções (corretivas e/ou evolutivas) não tenham afetado alguma funcionalidade existente;

*  %*{color:green}Smoke test*%: subconjunto de casos de testes que cobrem as funcionalidades mais importantes de um componente ou sistema, para verificar se as funções cruciais do software executam corretamente.

h3. 1.3.2 Artefatos de Teste previstos no Contrato

Os relatórios gerados pelas ferramentas de teste automatizados serão aceitos de forma equivalente aos documentos produzidos de forma manual desde que acordados com o Líder de Projeto.

> Exemplos : Relatórios de ferramentas como o Sonar, Jacoco, Serenity conforme Arquitetura de Referência a ser utilizada no Produto.

Os modelos de documento abaixo devem ser utilizados nos casos excepcionais que se justifique a não utilização de ferramenta automatizada para execução de testes e geração dos relatórios;

* [[1.3.3 - Estratégia de Testes]]

* [[1.3.4 - Plano de Testes]]

* [[1.3.5 - Roteiro de Testes]]

* [[1.3.6 - Evidência de Testes]]

* [[1.3.7 - Evidência de Defeitos]]

* [[1.3.8 - Relatório de Testes]]