🛠️Infraestrutura

Este processo de versionamento para os produtos contam com a estrutura:

Produção

Ambiente restrito, onde apenas o administrador possui acesso. As informações que estão neste ambiente foram homologadas e aprovadas através dos administradores.

Pré-Produção

Ambiente de qualidade, onde os analistas de qualidade irão fazer a validação do código fonte que irá para produção. Este ambiente é para códigos emergentes, onde é necessário um fluxo mais rápido de entrega.

Homologação

Ambiente de qualidade, onde os analistas de qualidade irão fazer a validação do código fonte que irá para produção. Este ambiente é para funcionalidades que irão ser entregues ao final de um ciclo de desenvolvimento. As informações neste ambiente serão constantemente atualizadas a medida que a pré-produção efetuar as atualizações e o desenvolvimento efetua as entregas.

Correções com maior tempo de entrega (bugfix) serão feitas neste ambiente.

Desenvolvimento

Este ambiente é para criação de novas funcionalidades, utilizada por desenvolvedores.

Equipe técnica e gerencial, e plano de implementação e melhoria contínua

A equipe dedicada ao projeto – Registro Eletrônico de Contratos – é composta pelos profissionais descritos a seguir:

Testes Manuais

Os testes manuais é a percepção quanto à facilidade de uso do aplicativo. Isso significa verificar na visão de um usuário o quanto o software é eficiente e atende as necessidades reais.

Pré requisito

Documento gerado pela equipe de Requisito - Caso de uso.

Criação de Plano de Testes

O plano de teste é um documento com uma abordagem sistemática para os testes de sistemas, como hardware ou software. Ele geralmente consiste numa modelagem detalhada do fluxo de trabalho durante o processo.

Criação de Caso de Testes

Caso de Testes é um conjunto de valores de entrada, pré-condições de execução, resultados esperados e pós-condições de execução, desenvolvidas para um determinado objetivo ou condição de teste.

Exemplo de Caso de Testes

Testes Regressivo

Os testes regressivo são realizados quando, ocorre alguma alteração grande no sistema, como por exemplo a inclusão de uma nova funcionalidade, que é preciso validar se outros componentes não foram prejudicados com a alteração.

Teste Exploratório

Os testes exploratórios têm como objetivo validar cenários que não foram pensados na criação dos casos de testes, são realizados baseado nas experiências do analista de testes.

Testes de Aceite

Os testes de aceite são realizados para validar se a funcionalidade está de acordo com o que foi solicitado, o cliente recebe um roteiro de testes baseado na regra de negócio.

Execução dos Testes

A execução dos testes se inicia quando, a versão para ser testada está no ambiente de homologação ou pré-produção e todos os casos de testes já estejam levantados.

Fluxo de trabalho de Qualidade de Software - Testes Manuais

Primeira Fase: Levantamento de plano de testes, casos de testes e análise de requisito

Segunda Fase: Execução de testes, testes exploratório e levantamento de bug.

Terceira Fase: Reteste de bug levantados e regressivo.

Saídas

Todas as saídas extraídas de Qualidade.

Levantamento de Bug

Os bugs são reportados sempre quando finalizamos a segunda fase dos testes, registramos eles na ferramenta de gerenciamento de projetos Jira.

Evidência de Testes

As evidências de testes comprovam que os testes passaram ou reprovaram. Consideramos que aquele caso de testes passou quando realizamos os testes e evidenciamos o mesmo utilizando vídeo ou print da tela com resultado final esperado alcançado com sucesso.

Status Report

Documento simples que existe para atualizar periodicamente os envolvidos a respeito da situação do andamento dos testes, pontos de atenção e entregas que foram realizadas em um determinado ponto de tempo.

Modelo de classificação de BUG

Prioridade

1 - Alta

Alto grau de certeza de que o erro será detectado pelo usuário durante a operação normal do sistema em suas funcionalidades mais elementares / usuais.

2 - Média

O erro é percebido apenas em situações específicas ou funcionalidades não essenciais do produto.

3 - Baixa

Erro detectado em situações extremamente específicas e que necessitam de uma rara combinação de fatores para que ocorra. O erro raramente será percebido pelo usuário.

Severidade

1 - Crítico

• Falha geral da aplicação.

• Perda de dados.

• Instabilidade da aplicação ou de seus serviços.

• Impede a continuidade dos testes ou do uso da aplicação como um todo.

• Build da aplicação corrompido.

• Funcionalidades principais da aplicação seriamente comprometidas.

2 - Grave

• Sério comprometimento de funcionalidade (funcionalidade impossível de ser utilizado, sistema travando ou se comportando de maneira não prevista).

• Bug em funcionalidade essencial do produto com workaround complexo.

• Comprometimento moderado da continuidade dos testes.

3 - Moderado

• Problemas moderados em funcionalidades do produto.

• Existe um workaround simples.

• Baixo impacto nos testes.

• Ergonomia razoavelmente comprometida e com viabilidade de melhoria.

4 - Cosmético

• Não chegam a comprometer o objetivo final da funcionalidade.

• Afetam a aparência na forma de erro, não de melhoria.

5 - Melhoria

• Não são erros, mas oportunidades de melhoria identificadas no uso do sistema durante a fase de inspeção.

• Existe grande probabilidade de o cliente sugerir a mesma melhoria no futuro.

• Ação pró-ativa.

Modelo de Evidência de Testes

Todas as evidências de teste são adicionadas dentro do Jira, com a definição do projeto a qual a tarefa foi atribuída.

Manual (Testes manuais)

• Plano de Teste

• Caso de Teste

• Prints

• Gravação dos testes – Awesome Screen Video Recorder