SuporTI. SuporTI Dota2UpMMR Documento de Teste de Software. Versão 7.0

(1)

SuporTI

Dota2UpMMR

Documento de Teste de Software

(2)

DocTes_SuporTI_V7.0

Histórico da Revisão

Data Versão Descrição Autor

05/ Dezembro /2016 7.0 Versão de Entrega Equipe de Teste 02/ Dezembro /2016 6.2 Revisão e reconstrução do tópico 5.2.2 e

7.6.1

Francisco Marcondes

29/ Novembro /2016 6.1 Revisão e reconstrução do tópico 1.2 e 4 Francisco Marcondes 11/ Novembro /2016 6.0 Versão de Entrega Equipe de Teste

09/Novembro/2016 5.4 Revisão e reconstrução do tópico 2.2 e 1.2 Francisco Marcondes 07/Novembro/2016 5.3 Revisão e reconstrução do tópico 5.2.4,

5.2.2, 5.2.1

Francisco Marcondes

02/Outubro/2016 5.2 Revisão e reconstrução do tópico 7.6.2, 7.6.1

Francisco Marcondes

01/Outubro/2016 5.1 Revisão e reconstrução do tópico 9.3 Francisco Marcondes 30/Setembro/2016 5.0 Versão de Entrega Equipe de Teste 28/Setembro/2016 4.5 Revisão e reconstrução do tópico 5.2.7 e

7.6.1

Francisco Marcondes

25/Setembro/2016 4.4 Revisão e reconstrução do tópico 5 e 5.2.3 Francisco Marcondes 21/Setembro/2016 4.3 Revisão e reconstrução do tópico 3 e 4 Francisco Marcondes 20/Setembro/2016 4.2 Revisão e reconstrução do tópico 4 e 4.1 Francisco Marcondes 15/Setembro/2016 4.1 Revisão geral e entrega de versão. Equipe de Teste 14/Setembro/2016 3.7 Construção dos tópicos 7.3 a 7.6.4. Francisco Marcondes 09/Setembro/2016 3.6 Revisão e reconstrução do tópico 3 e

reestrutura dos RF 09 e 13.

Francisco Marcondes

08/Setembro/2016 3.5 Revisão e reconstrução do tópico 5 e 5.2.1 Reconstrução dos tópicos 5.7.2.

Francisco Marcondes

23/setembro/2016 3.4 Revisão e reconstrução do tópico 4.1 e 4.3 Francisco Marcondes 09/Setembro/2016 3.3 Revisão e reconstrução do tópico 3 Francisco Marcondes 11/Junho/2016 3.2 Revisão e reconstrução do tópico 1.2 Francisco Marcondes 05/Junho/2016 3.1 Revisão geral e construção do tópico 8 Francisco Marcondes 01/Junho/2016 3.0 Revisão geral de documento. Equipe de Teste

31/ Mai/ 2016 2.0 Revisão e reconstrução do tópico 8 atendendo solicitação de banca de projeto.

Francisco Marcondes

19/ Mai/ 2016 1.3 Revisão geral de documento. Equipe de Teste 15/ Mai/ 2016 1.2 Entrega dos tópicos 9.1 e 9.4. Wellison Cesar 15/ Mai/ 2016 1.1 Entrega do tópico 7.6 Wellison Cesar

(3)

11/ Mai /2016 1.0 Versão de Entrega Equipe de Teste 11/ Mai /2016 0.15 Entrega do tópico 13 Leonardo Sobreira 10/ Mai /2016 0.14 Construção e entrega do tópico 10, 11 e 12 Antônio de Oliveira 10/ Mai /2016 0.13 Construção e entrega do tópico 6 Francisco Marcondes 10/ Mai /2016 0.12 Construção e entrega do tópico 5.2.7 Francisco Marcondes 09/ Mai /2016 0.11 Construção e entrega do tópico 8 Francisco Marcondes 09/ Mai /2016 0.10 Construção e entrega dos tópicos 5.2.5 Francisco Marcondes 08/ Mai /2016 0.9 Construção e entrega dos tópicos 5.2.4 Antônio de Oliveira 08/ Mai /2016 0.8 Construção e entrega dos tópicos 5.2.1 Antônio de Oliveira 07/ Mai /2016 0.7 Construção e entrega do tópico 4.2 Francisco Marcondes 06/ Mai /2016 0.6 Construção e entrega do tópico 4.1 Francisco Marcondes 24/ Abr /2016 0.5 Construção e entrega dos tópicos 5 e 5.1 Francisco Marcondes 19/ Abr /2016 0.4 Construção e entrega do tópico 4 Francisco Marcondes 19/ Abr /2016 0.3 Construção e entrega do tópico 3 Francisco Marcondes 17/ Abr /2016 0.2 Construção e entrega do tópico 2 Francisco Marcondes 14/ Abr /2016 0.1 Construção e entrega do tópico 1 Francisco Marcondes

(4)

DocTes_SuporTI_V7.0

Índice Analítico

1. Introdução 3 1.1 Finalidade 3 1.2 Escopo 3 1.3 Público-alvo 4

1.4 Terminologia e Acrônimos do Documento 4

1.5 Referências 5

1.6 Estrutura do Documento 5

2. Missão de Avaliação e Motivação dos Testes 6

2.1 Informações Detalhadas 6

2.2 Missão de Avaliação 7

2.3 Motivadores dos Testes 7

3. Itens-alvo dos Testes 7

4. Resumo dos Testes Planejados 8 4.1 Resumo dos Outros Candidatos a Possível Inclusão 9 4.2 Resumo das Inclusões dos Testes 9 Teste de Determinação do Perfil de Desempenho. 9 Teste de Tolerância a Falhas e de Recuperação. 9

Teste de Configuração. 10

Teste de Teste de Instalação. 10

5. Abordagem dos Testes 10

5.1 Catálogos Iniciais de Ideias de Teste e Outras Fontes de Referência 10 5.2 Técnicas e Tipos de Teste 10

5.2.1 Teste de Integridade de Dados e de Banco de Dados 10

5.2.2 Teste de Função 12

5.2.3 Teste da Interface do Usuário 19

5.2.4 Teste de Carga 21

5.2.5 Teste de Stress 22

5.2.6 Teste de volume 22

6. Critérios de Entrada e de Saída 24

6.1 Plano de Teste 24

6.1.1 Critérios de Entrada de Plano de Teste 24

6.1.2 Critérios de Saída de Plano de Teste 24

6.1.3 Critérios de Suspensão e de Reinício 24

(5)

6.2.1 Critérios de Entrada de Ciclo de Teste 24

6.2.2 Critérios de Saída de Ciclo de Teste 24

6.2.3 Término Anormal do Ciclo de Teste 24

7. Produtos Liberados 25

7.1 Sumários de Avaliação de Testes 25 7.2 Relatórios da Cobertura de Teste 25 7.3 Relatórios da Qualidade Perceptível 25 7.4 Registros de Incidentes e Solicitações de Mudança 25 7.5 Conjunto de Testes de Regressão e Scripts de Teste de Suporte 25 7.6 Produtos de Trabalho Adicionais 26

7.6.1 Resultados Detalhados dos Testes. 26

7.6.2 Scripts de Teste Funcionais Automatizados Adicionais 27

7.6.3 Guia de Teste 27

8. Fluxo de Trabalho de Teste 28

9. Necessidades Ambientais 30

9.1 Hardware Básico do Sistema 30 9.2 Elementos de Software Básicos do Ambiente de Teste 30 9.3 Ferramentas de Produtividade e de Suporte 31 9.4 Configurações do Ambiente de Teste 31 10. Responsabilidades, Perfil da Equipe e Necessidades de Treinamento 32

10.1 Pessoas e Papéis 32

10.2 Perfil da Equipe e Necessidades de Treinamento 35

11. Marcos da Iteração 35

12. Riscos, Dependências, Suposições e Restrições 36

13. Procedimentos e Processos de Gerenciamento 39 13.1 Medição e Avaliação da Extensão do Teste 39 13.2 Avaliação dos Produtos Liberados deste Plano de Teste 39 13.3 Relato de Problemas, Seleção de Pessoas para Resolvê-los e Busca de Soluções 39 13.4 Gerenciamento de Ciclos de Teste 39 13.5 Estratégias de Rastreabilidade 40 13.6 Aprovação e Encerramento 40

(6)

DocTes_SuporTI_V7.0

Plano de Teste

1. Introdução 1.1 Finalidade

A finalidade deste documento de Plano de Teste, é identificar os componentes de Software e requisitos a serem testados, bem como descrever as respectivas modalidades de Testes a serem utilizadas. Neste Plano de Testes será apresentada uma projeção dos esforços e recursos empregados no processo de desenvolvimento do Sistema, descrevendo todo o planejamento dos Testes a fim de que a execução dos mesmos seja realizada de forma prática e organizada no que diz respeito aos seus objetivos.

Este Plano de Teste referente ao Dota2UpMMR suporta os seguintes objetivos: Identifica os itens que devem ser inspecionados pelos Testes.

Identifica a motivação e as ideias subjacentes às áreas de Teste a serem abrangidas. Descreve a abordagem de Teste que será usada.

Identifica os recursos necessários e fornece uma estimativa dos esforços de Teste. Lista os elementos liberados do projeto de Teste.

1.2 Escopo

O sistema Dota2UpMMR será submetido a Teste de Integridade de Dados e de Banco de Dados, Teste de Função, Testes de Usabilidade (Teste de Interface do Usuário, Teste de Comunicabilidade Visual e Funcional, Teste de Responsividade, Teste de Compatibilidade) Teste de Carga, Teste de Stress, Teste de Volume, Teste de Segurança e de Controle de Acesso. Para a execução dos Testes serão utilizadas as ferramentas Jmeter, verificando o desempenho do sistema em meio a vários processos em execução simultaneamente, ou seja, como o Sistema vai se comportar com uma alta taxa de acesso, analisando os níveis de Stress, carga e volume de Dados juntamente com o Banco de Dados, a ferramenta Imacros, que atua com suporte de automação de teste para Sistemas Web.

(7)

Os Testes serão realizados com base nos itens abaixo descritos:

1.2.1 Logar/Logout. 1.2.2 Steam_Web_API. 1.2.3 Importação de Dados.

1.2.4 Chat/Comunicação entre Jogadores 1.2.5 Manter Jogador.

1.2.6 Manter Equipe. 1.2.7 Busca de Jogadores. 1.2.8 Busca Por Equipes.

1.2.9 Visualizar Informações de Jogadores.

1.2.10 Visualizar Informações de Equipe.

1.2.11 Interface de Usuário.

1.2.12 Comunicação Visual.

1.2.13 Comunicação Funcional.

1.2.14 Responsividade.

1.2.15 Compatibilidade de Navegadores.

1.2.16 Teste de Integridade de Dados.

1.2.17 Teste de Performance.

1.3 Público-alvo

Esse documento é destinado para todos os interessados no projeto, equipe de desenvolvimento, Analistas de Testes e stakeholders, abordando a devida representação dos Testes com suas respectivas definições.

1.4 Terminologia e Acrônimos do Documento

(8)

DocTes_SuporTI_V7.0

MVC- Model-view-controller - Modelo-visão-controle.

SQL- Structured Query Language - Linguagem de Consulta Estruturada STAKEHOLDERS – Público estratégico.

1.5 Referências

Documento de Requisitos de Software (DocReq_SuporTI_V2.0) Documento de Arquitetura de Software (DocArq_SuporTI_V 1.0)

1.6 Estrutura do Documento

Este documento está organizado e distribuído com tópicos relacionados à visão geral do Plano de Teste, apresentando a reunião de todas as informações necessárias ao controle das atividades de Teste e está estruturado da seguinte forma:

Seção 01–Esta seção introdutória apresenta uma visão geral do Plano de Teste de

software, com seu respectivo objetivo.

Seção 02–Esta seção descreve a justificativa do teste utilizado juntamente com sua

descrição dentro do projeto.

Seção 03–Esta seção descreve as características e os itens que serão testados no Sistema. Seção 04–Esta seção descreve os Testes que serão abordados nesse Plano de Testes.

Seção 05–Esta seção é descrimina a metodologia que os Testes serão executados e os

tipos de ferramentas utilizadas.

Seção 06–Esta seção descreve critérios de entrada e de saída, abordando o ciclo e a

analise após a realização do Teste.

Seção 07–Esta seção descreve os artefatos que serão criados no período dos Testes e as

ações que serão executadas no Ciclo de Teste.

Seção 08–Esta seção descreve Fluxo de trabalho de teste fornecendo um resumo do fluxo

(9)

Teste.

Seção 09–Esta seção descreve as necessidades ambientais necessárias para o sistema

funcionar sem restrições.

Seção 10–Esta seção descreve a responsabilidades, perfil da equipe e necessidades de

treinamento, apresentando recursos necessários como, conhecimentos, habilidades.

Seção 11–Esta seção descreve a iteração dos principais marcos no período de teste.

Seção 12–Esta seção descreve os riscos, dependências, suposições e restrições que

podem prejudicar o andamento do Plano de Teste.

Seção 13–Esta seção descreve os processos de Gerenciamento, resume as atividades que

deverão serem executadas mediante algum tipo de problema no Plano de Teste e na execução do mesmo.

2. Missão de Avaliação e Motivação dos Testes

O Teste do software é um processo de extrema importância realizado pelo Analista de Testes, onde serão abordadas atividades a partir do levantamento de requisitos até a execução de todos os Testes necessários a fim de cooperar de forma direta com o aumento do ciclo de vida do processo em desenvolvimento. Tem como objetivo identificar falhas, erros e defeitos em tempo hábil para que estas possam ser corrigidas pela Equipe de desenvolvedores antes da finalização do projeto, garantindo a qualidade do Software e a satisfação do cliente.

2.1 Informações Detalhadas

Tendo em vista a necessidade de trabalhar de acordo com normas técnicas, o Software a ser desenvolvido deve obedecer a padrões de qualidade desde o início do seu desenvolvimento, oferecendo confiabilidade, segurança e disponibilidade, dessa forma serão aplicados Testes para a adequada validação das funcionalidades propostas de acordo com os modelos preestabelecidos na sua concepção.

(10)

DocTes_SuporTI_V7.0

2.2 Missão de Avaliação

Encontrar defeitos, erros e falhas no protótipo a ser desenvolvido de modo a maximizar sua qualidade, confiabilidade e segurança e tempo de vida útil.

2.3 Motivadores dos Testes

Identificar na fase de desenvolvimento o máximo de erros possíveis no Sistema, o nível do risco que cada um oferece, bem como o tipo de Teste que o Sistema será submetido, visando a correção adequada sem prejuízos futuros que venham necessitar de uma manutenção corretiva, evitando custos desnecessários propiciando um maior ciclo de vida útil do Software, obedecendo os critérios abordados pela metodologia ágil com a execução das respectivas Sprints.

3. Itens-alvo dos Testes

O planejamento dos Testes ocorrerá em paralelo ao desenvolvimento do Software, a listagem abaixo identifica os itens, software, hardware que foram identificados como alvo dos Testes.

► Testes Funcionais.

► Teste de Comunicação entre Jogadores. ► Teste de Importação de Dados API. ► Teste de Interface do Usuário. ► Teste de Responsividade. ► Teste de Compatibilidade.

► Teste de Integridade de Dados e Banco de Dados. ► Teste de Performance.

(11)

4. Resumo dos Testes Planejados

No decorrer do desenvolvimento do Software, o mesmo será submetido a Testes diferenciados que serão extremamente necessários para sua execução, qualidade bem como um maior ciclo de vida útil.

► Testes Funcionais, o objetivo é assegurar que todas as funções especificadas no Documento de Requisitos venham funcionar na sua totalidade.

► Teste de Importação de Dados API. Será realizado Testes na API de dados fornecida pela Steam, uma vez que a mesma fornecerá dados importantes que permitirá o acesso ao Sistema Dota2UpMMR.

► Teste da Interface do Usuário. Será analisado a interação do usuário com o software. A meta do teste de UI é assegurar ao usuário o acesso e a navegação de forma adequada atendendo as necessidades do mesmo.

► Teste de Integridade de Dados. Será analisado a segurança de todos os dados armazenados, com o objetivo de garantir a integridade dos mesmos, averiguando o armazenamento, e certificando-se de que somente os usuários devidamente cadastrados terão acesso às informações.

► Teste de Stress, será executado com objetivo de compreender como ocorrem falhas no sistema devido a condições que estão no limite ou fora do limite das tolerâncias esperadas.

► Teste de Volume, será analisado o comportamento do Sistema com grandes volumes de dados a fim de determinar os limites que farão com que o software pare de funcionar.

► Teste de Carga. Será analisado o que está relacionado ao desempenho do sistema Dota2UPMMR, com objetivo de medir e avaliar o desempenho do mesmo, verificando se o sistema está adequadamente correto tendo em vista as diferentes cargas de desempenho.

(12)

DocTes_SuporTI_V7.0

Jogadores cadastrados no Sistema que será executado através de uma API Chat.

Resumo das Inclusões dos Testes

Será extremamente necessário incluir no ciclo de Testes, a execução de Testes de Integração com API de Dados fornecida pela Steam, que fornecerá informações inerentes aos usuários que após a importação irá validar e permitir o acesso do Usuário no Sistema Dota2UpMMR, assegurando um diferencial com objetivo de garantir a execução em perfeito funcionamento da API de Dados preservando a integridade e inviolabilidade dos Dados do usuário.

4.1 Resumo dos Outros Candidatos a Possível Inclusão

N/H

4.2 Resumo das Inclusões dos Testes

Teste de Determinação do Perfil de Desempenho.

A princípio este Teste não será executado, o mesmo está condicionado pelo Ciclo de negócios futuros mediante análise criteriosa do objetivo do Sistema no mercado, dessa forma iremos implementar novas funcionalidades e consequentemente testes voltados para o Perfil de Desempenho na seguinte situação:

Será analisado o tempo de consulta/atualização do subsistema e de informações úteis, Chat online, permitindo que o mesmo possa proporcionar mais ferramentas nas conversas, por essa razão serão testados o desempenho e tempo de respostas para operações que envolvam dados multimídia (imagens, vídeos, etc.) com o objetivo de que não ultrapassam 30 segundos.

Teste de Tolerância a Falhas e de Recuperação.

Este Teste não será executado, uma vez que as principais informações dos usuários estarão armazenadas em dispositivos da própria Steam, mesmo em condições de perdas de informações ocasionadas por falta de energia, falta de conexão o usuário precisará refazer os procedimentos de entrada no Sistema.

(13)

Teste de Configuração.

Este Teste não será executado, por se tratar de um Sistema Web de baixo consumo de memória e hardware, porém as exigências de configuração são somente as seguintes; Processador 1.2 GHz com memória RAM de 2G para seu efetivo funcionamento e realização de todos os processos envolvidos no Sistema.

Teste de Teste de Instalação.

Este Teste não será executado, por se tratar de um Sistema Web, projetada através de um navegador fazendo uso da internet, com tecnologia HTML, CSS e PHP que será executada por um servidor HTTP.

5. Abordagem dos Testes

Os testes serão executados de forma manual e/ou automatizada com o auxílio de ferramentas de Testes, Imacros, Jmeter, e a ferramenta de gerenciamento de Testes Testlink, juntamente com uma plataforma de gerenciamento de bugs, Mantis Bugtraker.

5.1 Catálogos Iniciais de Ideias de Teste e Outras Fontes de Referência

Os testes foram levantados dos casos de uso documentados no modelo de Especificação de Requisitos de Software (SRS) e do Documento de Arquitetura de Software (RUP).

5.2 Técnicas e Tipos de Teste

5.2.1 Teste de Integridade de Dados e de Banco de Dados

O Banco de Dados e seus respectivos processos funcionais deverão ser testados como um subsistema independente de forma automatizada e manual, avaliando os critérios de desempenho e integridade de dados, bem como a latência dos retornos do SGBD.

Objetivo da Técnica: Assegurar que todas as informações relacionadas ao acesso do Banco de Dados funcionem de forma satisfatória sem perca de dados e em tempo hábil.

(14)

DocTes_SuporTI_V7.0

Técnica: Chamar cada processo de acesso ao Banco de Dados, certificando

se que as informações adicionadas estão sendo validadas.

Vistoriar e garantir que os dados estejam sendo devidamente processados, adicionados, editados e excluídos como pretendido, proporcionando o funcionamento correto.

Em nível de implementação de teste do sistema Dota2UpMMR o teste deve assegurar, que o retorno de dados resultante da comunicação com API seja devidamente salvo no Sistema.

Todas as informações pertencentes ao usuário apenas possam ser vistas e posteriormente alteradas por ele próprio.

Estratégias: Os testes prosseguiram mantendo ênfase nas características

fundamentais do Banco de Dados observando a relação com os dados colhidos da API em primeira instancia.

O Jmeter será utilizado para criação e consulta de dados no Banco de Dados devido à facilidade de utilização do mesmo e a praticidade em teste envolvendo a base de dados, os Testes prosseguem também manualmente, sendo que os resultados obtidos atestaram a capacidade funcional do sistema.

Ferramentas Necessárias: Jmeter.

Critérios de Êxito: Atestar o recebimento e a gravação dos dados gerados pelo usuário

em sua utilização constante, garantindo a segurança e a inviolabilidade dos mesmos.

(15)

5.2.2 Teste de Função

RF01 - Logar

RF02 - Manter Jogador

Objetivo da Técnica: Assegurar o correto funcionamento permitindo que o usuário tenha

liberdade após edições e armazenamento de Dados alvar o jogador possa manter-se cadastrado na plataforma.

Técnica: Executar o teste utilizando dados válidos e inválidos, para verificar

se a função de manter jogador após o devido cadastro bem como edições de jogador poderá ser mantida no Sistema Dota2UpMMR sem restrições.

As mensagens de erro ou aviso apropriadas serão exibidas quando dados inválidos forem utilizados.

Objetivo da Técnica: Assegurar que o reconhecimento dos usuários através de login e

senha ocorram de forma satisfatória.

Técnica: Executar o teste utilizando dados válidos ou inválidos, para

verificar a entrada do usuário no Sistema Dota2UpMMR.

O resultado esperado ocorre quando entradas válidas são utilizadas. Erros apropriados ocorrem quando entradas inválidas são utilizadas.

Estratégias: Simular usuário final executando login no Sistema, inserindo

dados válidos e inválidos como senha e usuário, após a verificação da API Steam, surgirá ou não a validação e a liberação de entrada do usuário no Sistema.

Ferramentas Necessárias: Imacros.

Critérios de Êxito: Todos os testes planejados serão executados, e os possíveis erros

(16)

DocTes_SuporTI_V7.0

Estratégias: Os Testes prosseguiram mantendo ênfase nas características

fundamentais dos requisitos.

encontrados serão devidamente identificados e tratados.

RF03 – Manter Equipe

Objetivo da Técnica: Assegurar após critérios de adição, edição e exclusão de

jogadores, a composição de nova equipe em caráter definitivo na Plataforma.

Técnica: Executar o teste utilizando dados válidos analisando se a Função

manter Equipe após as operações de edição, inclusão e exclusão estarão funcionando no Sistema Dota2UpMMR sem restrições. As mensagens de erro ou aviso apropriadas são exibidas quando dados inválidos são usados.

(17)

RF04 – Visualizar Perfil de jogador.

Objetivo da Técnica: Assegurar e permitir ao jogador a visualização do Perfil de outros

Jogadores inseridos no Sistema.

Técnica: Após a localização do Jogador, acionar o Botão VISUALIZAR e

verificar se a referida função estará funcionando no Sistema

Dota2UpMMR sem restrições.

RF05 - Realizar Busca de Jogadores

Objetivo da Técnica: Assegurar e permitir que o usuário realize busca de jogadores.

Técnica: Executar o teste utilizando dados válidos e inválidos, para

verificar se a função de Realizar Busca de Jogadores após as operações de edição, inclusão e exclusão estarão funcionando no Sistema Dota2UpMMR sem restrições.

As mensagens de erro mediante Jogador Inexistente serão acionadas automaticamente.

(18)

DocTes_SuporTI_V7.0

RF06 - Visualizar Informações de Equipes

Objetivo da Técnica: Assegurar e permitir ao jogador a visualização das informações

das equipes inseridas no sistema.

Técnica: Executar o Teste utilizando dados válidos e inválidos, para

verificar se a função de Visualizar Informações de Equipes após as operações de edição, inclusão e exclusão estarão funcionando no Sistema Dota2UpMMR sem restrições.

RF07- Listar Equipes

Objetivo da Técnica: Assegurar e permitir que o jogador execute listagem das equipes,

inclusive as que ele estiver cadastrado.

verificar se a função de Listar Equipes estará funcionando no Sistema Dota2UpMMR sem restrições.

As mensagens de erro ou aviso apropriadas são exibidas quando dados inválidos são usados.

(19)

Critérios de Êxito: Todos os testes planejados serão executados, e os possíveis erros encontrados serão devidamente identificados e tratados.

RF08 - Visualizar Informações dos Jogadores

Objetivo da Técnica: Assegurar e permitir ao jogador a visualização dos dados de

outros jogadores inseridos no sistema.

Técnica: Executar o teste localizando e visualização o Perfil dos Jogadores

inseridos na Plataforma, verificando se a respectiva Função estará funcionando no Sistema Dota2UpMMR sem restrições.

As mensagens de erro sobre inexistência de jogador com perfil específico serão acionadas automaticamente.

RF09 - Realizar Buscar por Equipes.

Objetivo da Técnica: Assegurar e permitir ao jogador a busca por equipes inseridas no

Sistema.

verificar se a função de Realizar Busca por Equipes após as operações de edição, inclusão e exclusão estarão funcionando no Sistema Dota2UpMMR sem restrições.

As mensagens de erro mediante Equipe inexistente serão acionadas automaticamente.

(20)

DocTes_SuporTI_V7.0

RF12 - Notificação entre Jogadores

Objetivo da Técnica: Assegurar e permitir que o jogador se comunique através de

mensagens com outros usuários ou grupos.

Técnica: Executar o teste através de entrada de dados em forma de

mensagens entre usuários com observação de uma resposta do Sistema no que diz respeito à conclusão de processo de comunicação, certificando se a mensagem chegou a seu destino.

Ferramentas Necessárias: Teste Manual.

(21)

RF13 - Steam Web API

Objetivo da Técnica: Assegurar a execução em perfeito funcionamento da API de

Dados fornecida pela Plataforma Steam.

Técnica: Executar o teste avaliando o retorno da API, prosseguindo

utilizando dados válidos e inválidos, para verificar se o Subsistema API de Dados fornecida pela Steam funciona na sua totalidade alcançando o objetivo de interagir com o Sistema Dota2UpMMR permitindo validação de Login bem como importação de dados de Jogadores.

As mensagens de erro ou aviso apropriadas são exibidas quando dados inválidos são usados.

RF14 - Importação de Dados do Usuário

Objetivo da Técnica: Assegurar a execução de importação de Dados da Steam para o

Sistema Dota2UpMMR.

Técnica: Efetuar login, para verificar se o Subsistema API de Dados

fornecida pela Steam executa a função de liberação de Dados de forma segura e sem perda de pacotes, para o Sistema

Dota2UpMMR importar para sua base de dados.

As mensagens de erro ou aviso apropriadas são exibidas a importação não for realizada com sucesso.

(22)

DocTes_SuporTI_V7.0

Ferramentas Necessárias: Teste Manual

RF15 - Mensagem de Confirmação de Operação.

Objetivo da Técnica: Assegurar a execução com êxito da emissão de confirmação de operação sempre que o processo for executado bem como a emissão de mensagem de erro de processo.

Técnica: Executar o teste utilizando dados válidos para obter retorno de

confirmação de Operação e dados inválidos, para obter retorno de erro de operação com base em execução de processos funcionais.

5.2.3 Teste da Interface do Usuário

O Teste da Interface do Usuário (UI) verifica a interação do usuário com o software. A meta do teste de UI é assegurar que a UI forneça ao usuário o acesso e a navegação adequados através das funções do objetivo do teste. Além disso, o teste de UI assegura que os objetos contidos na UI funcionem conforme o esperado e estejam em conformidade com padrões corporativos ou da indústria.

(23)

Objetivo da Técnica: A abordagem desta técnica de teste, via obter métricas de aceitação em relação ao emprego da linguagem de comando, que define teclas de funções, juntamente com recursos de engenharia cognitiva, engenharia semiótica e Effordances obrigatoriamente presentes no sistema.

Sendo assim o teste é a aprovação de todos os critérios acima mencionados o que garante uma interface que estipule qualidade em ícones, contexto empregado, comunicabilidade de funções e enfatizando sua interatividade desde o primeiro contato com o usuário final.

Técnica: Executar Testes que apontem questões de usabilidade levando em

consideração critérios apresentados por estudos de interação humano computacionais, com a colaboração de três usuários testando e avaliando a usabilidade do Sistema.

As interfaces presentes no sistema deverão ser submetidas a um conjunto de análises envolvendo grupo de desenvolvimento e usuários. Este conjunto de esforços deve levar em consideração as noções de interatividade deferindo novos testes para garantir interfaces mais completas.

Estratégias: A interface prosseguirá sendo reavaliada pela equipe de teste sendo acompanhada por gerente de teste e tento aval de representação do público alvo do projeto a fim de cooperação em teste, chegando a decisões unanimes sobre perspectivas de interfaces.

(24)

DocTes_SuporTI_V7.0

Critérios de Êxito: A IU será terá êxito após ser submetida às experiências de teste apresentadas neste tópico abordando exigências técnicas própria de estudos de interação humano computacionais e tendo sido aprovada por um grupo previamente classificado pela equipe de teste como entidade representacional do público final do sistema proposto. Tendo isso se espera que:

O sistema consiga atender as normas de usabilidade considerando as técnicas de afordance e design contextual.

O usuário possa usufruir de uma interface agradável, sendo esta aprovada por representantes dos usuários finais.

5.2.4 Teste de Carga

O teste de carga aborda o desempenho do sistema Dota2UPMMR, cujo objetivo é medir e avaliar o desempenho, verificando se o sistema está em condições de funcionamento, tendo em vista as diferentes cargas submetidas, avaliando as características desse teste adequando até a carga máxima esperada, sob análise do tempo de resposta e outros aspectos do sistema Dota2UPMMR.

Objetivo da Técnica: O teste irá verificar os funcionamentos do sistema com objetivo de

identificar sobrecarga.

Técnica: O Teste verificará a quantidade de carga suportada pelo servidor

com objetivo de evitar sobrecargas que possam comprometer o desempenho do Sistema.

Estratégias: Fazer uma simulação do maior número possível de usuários

utilizando o sistema, para uma análise de uma possível sobrecarga do Sistema.

(25)

Critérios de Êxito: A técnica suporta o teste de Emulação de Carga de Trabalho, que é a emulação bem-sucedida da carga de trabalho sem que nenhuma falha ocorra devido a problemas de implementação do Teste. Considerações Especiais: O teste de carga deverá ser executado em uma máquina dedicada

ou em um período de tempo dedicado. Isso permitirá o controle total e a medição exata.

5.2.5 Teste de Stress

Serão analisadas as situações anormais de uso, como grandes quantidades de carga, redução dos recursos computacionais disponíveis e sucessivas entradas de Dados. A partir dos testes de estresse torna-se possível observar o comportamento do sistema durante situações críticas, identificando falhas não toleráveis e potencialmente difíceis de serem encontradas em situações normais de funcionamento.

Objetivo da Técnica: Observar o comportamento do sistema com tráfego de requisições

simultâneas realizadas em um curto espaço de tempo, ou quando o sistema é processado num computador com pouca capacidade de processamento observando o nível de segurança da aplicação. Buscando garantir que o usuário tenha sempre disponível as funcionalidades do Sistema.

Técnica: Realizar diversos testes de função simultaneamente com objetivo

de analisar o comportamento do Sistema,

Estratégias: Serão realizadas tentativas de acessar o módulo com logins não

cadastrados ou com senhas inválidas, verificadas também as restrições associadas a cada usuário.

Ferramentas Necessárias: Apache JMeter

5.2.6 Teste de volume

(26)

DocTes_SuporTI_V7.0

Sistema Dota2UPMMR suporta esse volume sem comprometer no funcionamento e desempenho dele de acordo com o período determinado para o uso do sistema. Teste de Volume usará um grande banco de dados de testes e verificará se o comportamento do software foi normal.

Objetivo da Técnica: Simular um determinado número de usuários utilizando o Sistema

executando a mesma função, a fim de verificar o desempenho do Software, analisando de acordo com a quantidade de requisições o comportamento do Sistema e se esse processo afetará o desempenho do mesmo.

Técnica: Utilizar uma grande quantidade de volume de Dados, avaliando o

funcionamento do Software, distribuindo as metas de volume máximo com objetivo de encontrar limitações para o fluxo de informações antes do comprometimento do Software.

Estratégias: A quantidade de requisições e volume de dados utilizadas pela

quantidade máxima de usuários, irá gerar uma sobrecarga de dados enviados, assim podendo usar ferramentas para a verificação do volume máximo de dados gerado pelo sistema para a correção dessa falha. Com isso utilizaremos o banco de dados a fazer uma verificação a quantidade de volume suportada neste teste, juntamente com as requisições e funcionalidades que leva as informações do banco com maior volume.

Ferramentas Necessárias: Apache Jmeter

Critérios de Êxito: Medir uma amostra de quantidade de dados emitida para sistema,

encaminhando para o banco de dados verificando a reação dos dados no sistema mostrando se o Banco de Dados do Sistema está apto para o armazenamento de um grande volume de dados.

(27)

6. Critérios de Entrada e de Saída 6.1 Plano de Teste

6.1.1 Critérios de Entrada de Plano de Teste

Mediante conclusão da construção de todo o Plano de Testes, será iniciada a execução dos Testes.

6.1.2 Critérios de Saída de Plano de Teste

Resultados condizentes com as estimativas prontamente realizadas e documentadas significam Testes concluídos.

6.1.3 Critérios de Suspensão e de Reinício

Haverá suspensão e reinício dos Testes mediante identificação de um grave problema na execução do fluxo de Testes, bem como a interrupção da execução dos Testes por um fator humano, em último caso se o usuário detectar após a entrega algum problema não antes percebido pela Equipe.

6.2 Ciclos de Teste

6.2.1 Critérios de Entrada de Ciclo de Teste

Os Ciclos de teste seguirão a ordem já especificada no plano de Testes.

6.2.2 Critérios de Saída de Ciclo de Teste

Os testes devem passar por todos os Ciclos, sendo que nos últimos Testes, eventuais defeitos e exceções devem estar corrigidos.

6.2.3 Término Anormal do Ciclo de Teste

Os testes serão suspensos somente se houver uma falha no planejamento de plano de Testes.

(28)

DocTes_SuporTI_V7.0

7. Produtos Liberados

7.1 Sumários de Avaliação de Testes

A elaboração e a execução dos Testes serão realizadas pela equipe de teste da SuporTI, com a presença de um usuário utilizando o sistema Dota2UPMMR, verificando o desempenho, interface e usabilidade para a execução dos Testes. Testes esses que serão executados de acordo com os quesitos abordados no tópico 5.

7.2 Relatórios da Cobertura de Teste

Esse relatório de Teste será feito após o início dos Testes para avaliar se o software está verificado e validado em estado de pronto, para isso precisa de métodos de Teste que vão abranger as funcionalidades e a necessidade do acompanhamento do cliente, sendo que o mesmo de forma trivial irá participar como cliente na execução final dos testes avaliando por completo as funcionalidades do Sistema.

7.3 Relatórios da Qualidade Perceptível

O relatório de qualidade será reproduzido através dos êxitos nos Testes e nascondições de aplicação do mesmo. O êxito está relacionado a todos os integrantes de Teste da equipe SuporTI. Para execução de possíveis Testes o hardware tem que está em pleno funcionamento e fatores dependentes externos, como energia elétrica, acesso à internet. A partir da execução desses Testes serão montados resultados em paralelo para atendendo as possíveis mudanças e atualizações do Documento de Testes com os resultados voltados a qualidade do Software. Com isso será feito um gerenciamento através de Ferramentas de Gerenciamento de testes e de Bugs.

7.4 Registros de Incidentes e Solicitações de Mudança

Os métodos para a utilização de incidentes estão sendo adotados de acordo com a evolução da fase de execução dos Testes, através de um controle de qualidade emitido pelas Plataformas de Gerenciamento.

7.5 Conjunto de Testes de Regressão e Scripts de Teste de Suporte

Os testes de regressão serão iniciados na identificação de um erro no Sistema apontado pelos Testes, sendo que será tratado e executado novos testes para a verificação da correção do erro. Em seguida será feito uma avaliação minuciosa com objetivo de verificar se essas

(29)

atividades do build alteraram alguma outra funcionalidade tendo em vista a possíveis e sucessivas regressões até a finalização do ciclo de execução dos Testes.

7.6 Produtos de Trabalho Adicionais

7.6.1 Resultados Detalhados dos Testes.

Obedecendo o Ciclo de Testes tendo como base a prioridades, foi identificado incidentes nos seguintes Casos de Testes:

► Caso de Teste Funcional 1.2 – Importação de Dados do Usuário – O Teste realizado de forma manual detectou erros na funcionalidade Importação de Dados do Usuário. O resultado não condiz com o esperado, a importação dos Dados está apresentando irregularidades no processo de atualização do Perfil do usuário.

Os demais Testes Funcionais foram executados e sem indícios de erros, falhas e ou defeitos nas respectivas Funcionalidade.

► Caso de Teste Funcional 2.1 – chat comunicação entre jogadores – Foi identificado na Funcionalidade TROCA DE MENSAGEM ENTRE JOGADORES “CHAT” erros na emissão das mensagens, sendo que as mesmas estão sendo enviadas corrompidas, com textos incompletos. Foi identificado uma irregularidade na caixa de Texto das mensagens, uma vez que está apresentando uma instabilidade onde as mensagens estão percorrendo a caixa de diálogo deixando visível as mensagens mais antigas. Foi identificado que ao digitar as mensagens na caixa de diálogo, a fonte está apresentando um tamanho que implica em dificuldade de visualização.

► Caso de Teste Funcional 2.2 – Mensagem de Confirmação de Operação – Foi identificado na execução da Mensagem de Confirmação de Operação uma irregularidade que implica em dificuldade de visualização da mensagem, pois a mesma está com uma fonte pequena impossibilitando a comunicação visual e Funcional com o usuário.

(30)

DocTes_SuporTI_V7.0

► Caso de Teste de Usabilidade 6.1 a 6.9.1 – Interface. Comunicabilidade Visual e

Funcional – Foram identificadas irregularidades em todas as telas do Sistema dota2UpMMR, as

mesmas encontram-se totalmente fora dos padrões estabelecidos nas técnicas de IHC direcionadas pela Engenharia Semiótica, Cognitiva e Effordances.

Após a identificação dos erros, através do gerenciamento de Bugs, com o auxílio da Ferramenta Mantis Bugtraker, os bugs foram informados e encaminhados aos desenvolvedores para execução do processo de correção em todas as telas, uma vez que todas as telas foram implementadas e estão em estado de pronto, atendendo aos requisitos solicitados pelos padrões de qualidade da Engenharia Semiótica, Cognitiva e dos conceitos de Effordance.

► Caso de Teste de Usabilidade 6.1 a 6.9.1 – Interface. Responsividade – Foram identificadas irregularidades em todas as telas do Sistema dota2UpMMR, as mesmas encontram- se totalmente fora dos padrões estabelecidos nas técnicas de IHC, implicando em problemas de suportabilidade e compatibilidade com outras plataformas de navegação, Tabletes, celulares.

Após a identificação dos erros, através do gerenciamento de Bugs, com o auxílio da Ferramenta Mantis Bugtraker, os bugs foram informados e encaminhados aos desenvolvedores para execução do processo de correção em todas as telas, uma vez que todas as telas foram implementadas e estão em estado de pronto, atendendo aos requisitos solicitados pelos padrões de qualidade atendendo a arquitetura de outras Plataformas.

7.6.2 Scripts de Teste Funcionais Automatizados Adicionais

Será realizado Scripts de geração usuários Virtuais nos Testes de Desempenho para avaliar processos correlacionadas ao Banco de Dados, avaliando o nível suportado de carga, Stress e volume como medida de segurança para o funcionamento do Sistema sem restrições.

7.6.3 Guia de Teste

Todo o guia de Testes está sendo documentado e Registrado na Ferramenta de Gerenciamento de Testes Testlink com o suporte da Ferramenta de Gerenciamento de Bugs Mantis Bug Tracker.

(31)

8. Fluxo de Trabalho de Teste

Figura 1.Representação de Fluxo de Teste

O fluxo de trabalho a ser seguido pela equipe de Teste no desenvolvimento e na execução deste Plano de Teste está distribuído e organizado de acordo com representação da figura 1 mediante as seguintes descrições:

● Elaboração do Plano de Teste – Nessa fase é destacado a importância do Plano no processo de desenvolvimento de software, com objetivo de orientar a Equipe de Teste na definição dos itens que devem compor esse Plano e justificar as necessidades no processo de desenvolvimento do Sistema Dota2UPMMR com ênfase nas seguintes metas:

1. Definir um cronograma de atividades: estabelecer as atividades que devem ser realizadas, as etapas a serem seguidas e a ordem cronológica de execução;

2. Fazer alocação de recursos: definir quem realiza as atividades e quais ferramentas/recursos a serem utilizados;

(32)

DocTes_SuporTI_V7.0

3. Definir marcos de projeto – estabelecer os marcos a serem alcançados com objetivo de fazer o devido acompanhamento.

● Elaboração de Caso de Teste - No caso de teste será estabelecida o que deve ser verificado e classificado pelo requisito ao qual estão associados de acordo com as especificações de Testes, as condições de execução e o resultado esperado.

● Execução dos Testes- Nessa fase será abordada a metodologia “destrutiva”, ou seja, verificar com objetivo de encontrar qualquer tipo de erro, defeito ou falha no Sistema antes da liberação final para o usuário.

● Resultado dos Testes- Após o ciclo de Testes, será analisado todos os tipos de ocorrências que forem ocasionadas, de acordo com a gravidade e tipo de ocorrência serão adotadas as medidas de tratamento e correção dos possíveis erros bem como as anotações dos pontos positivos de toda a fase de Testes.

● Identificação de Erro- De acordo com os resultados dos Testes, os erros, defeitos ou falhas que forem identificados serão devidamente anexados em planilha de Testes para execução de estudos e posteriormente as correções.

● Relatório de Erro- Após identificação de algum tipo de erro, defeito ou falha serão anexadas à planilha de Teste que formaram um relatório final de ocorrências de Testes.

● Implementação de Testes- Nessa fase será implementada uma nova técnica de Testes com objetivo de executar novos Testes e depurar os erros encontrados que foram listados no relatório de erros.

● Teste realizado com sucesso e Fase de Teste encerrada- Após a realização de todas as fases acima citadas encerra-se o ciclo de Testes do Software.

(33)

● Artefatos de Testes- Nessa fase todos as execuções e alterações serão devidamente registradas e documentadas.

● Fase de Testes encerrada- Processos realizados, documentados e entregues.

9. Necessidades Ambientais 9.1 Hardware Básico do Sistema

Os conjuntos de tabelas a seguir apresentam os recursos do sistema necessários ao esforço de teste descrito neste Plano de Teste.

Recursos do Sistema

Recurso Quantidade Nome e Tipo

Servidor de Banco de Dados MySql PDO

Rede ou Sub-rede A ser definido

Hospedagem de Sites LTDA

Nome do Banco de Dados BancoDota2UPMMR

PCs de Teste Cliente N/A

Repositório de Teste Testlink - Mantis

Rede ou Sub-rede Nome do Servidor

PCs de Desenvolvimento de Teste 1 Processamento 1.2 GHz Dual Core,

com memória RAM 2Gb e HD 2 Gb.

9.2 Elementos de Software Básicos do Ambiente de Teste

São necessários os seguintes elementos de softwares básicos no ambiente de teste deste Plano de Teste.

Nome do Elemento de Software Versão Tipo e Outras Observações

(34)

DocTes_SuporTI_V7.0

Nome do Elemento de Software Versão Tipo e Outras Observações

Internet Explorer 9.0 Navegador da Internet

Firefox 37 Navegador da Internet

Google Chrome 42.0.2311.135 m Navegador da Internet

Opera 41.0.2353.56 Navegador da Internet

9.3 Ferramentas de Produtividade e de Suporte

Serão utilizadas as seguintes ferramentas para suportar o processo de teste deste Plano de Teste. Categoria ou Tipo de Ferramenta Nome da Marca da Ferramenta Fornecedor ou Desenvolvida Internamente Versão

Gerenciamento de Teste TestLink TestLink 1.9.14

Gerenciamento de Bugs Mantis Bug Traker Mantis Bug Traker 1.3.3

Ferramenta ASQ para teste funcional

Imacros Ipswitch V.08

Ferramenta ASQ para teste de desempenho

Apache Jmater Apache software

Fundation

2.0

9.4 Configurações do Ambiente de Teste

Devem ser fornecidas e suportadas as seguintes Configurações de Ambiente de Teste para este projeto.

Nome da Configuração Descrição Implementada na

Configuração Física

Configuração do usuário comum

01 Computador Processamento 1.2 GHz

Dual Core, com memória RAM 2Gb e HD 2 Gb Mínima configuração

suportada

01 Computador Processamento 1.2 GHz

Dual Core, com memória RAM 2Gb e HD 2 Gb Instalação de Rede (não

cliente)

(35)

10. Responsabilidades, Perfil da Equipe e Necessidades de Treinamento

10.1 Pessoas e Papéis

Gerente de Testes: Francisco Marcondes Analista de Teste: Wellison Cesar

Time de Teste: Antonio de Oliveira e Leonardo Sobreira.

Recursos Humanos

Papel Recursos Mínimos

Recomendáveis (Número de papéis alocados em tempo integral) Responsabilidades ou Comentários Específicos

Gerente de Testes 1 Gerente de Testes:

Francisco Marcondes.

Supervisiona o gerenciamento. Define Ciclo de Vida de Testes. Define Missão de Testes.

Estabelece Ferramentas de Teste. Avaliar e Reprovar Testes.

Analista de Teste 1 Analista de Teste:

Wellison Cesar.

Identifica e define os testes específicos a serem conduzidos.

Definição de Erros.

Encaminhamento de Erros Documentados E avaliar conclusão de Testes

(36)

DocTes_SuporTI_V7.0

Recomendáveis (Número de papéis alocados em tempo integral) Responsabilidades ou Comentários Específicos

Designer de Teste 1 Designer de Testes:

Francisco Marcondes.

Define a abordagem técnica referente à implementação do esforço de teste. Estas são as responsabilidades: Definir a abordagem dos testes. Definir a arquitetura de automação de teste.

Verificar as técnicas de teste.

Definir os elementos de testabilidade. Estruturar a implementação dos testes

Testador 1 Testador:

Wellison Cesar. Time de Teste: Antonio de Oliveira. Leonardo Sobreira.

Implementa e executa os testes. Supervisão do processo de Teste. Documentar Resultados dos testes. Documentar incidentes ocorridos. Realizar FeedBack das operações.

Administrador do

Sistema de Teste.

Time de Teste: Antonio de Oliveira. Leonardo Sobreira.

Assegura a manutenção e o gerenciamento dos recursos e do ambiente de teste. Evitar Crises.

Prover Assistência. Evitar interrupções.

(37)

Recomendáveis (Número de papéis alocados em tempo integral) Responsabilidades ou Comentários Específicos Administrador do Banco de Dados, Gerente do Banco de Dados Time de Teste: Antonio de Oliveira Leonardo Sobreira

Assegura o gerenciamento e a manutenção dos recursos e do ambiente dos dados de teste (banco de dados).

Atuar Sobre testes referentes ao banco de dados.

Estas são as responsabilidades:

 Suportar a administração dos dados de teste e das plataformas de teste (banco de dados)

Designer Time de Teste:

Antonio de Oliveira Leonardo Sobreira

Identifica e define as operações, os atributos e as associações das classes de teste.

 Define as classes de teste

necessárias para suportar os

requisitos de estabilidade

conforme definido pela equipe de teste.

Implementador Time de Teste:

Antonio de Oliveira Leonardo Sobreira

Implementa as classes de teste e os pacotes de teste e efetua testes de unidade nos mesmos.

 Cria os componentes de teste

necessários para suportar os

requisitos de testabilidade

(38)

DocTes_SuporTI_V7.0

10.2 Perfil da Equipe e Necessidades de Treinamento

Esta seção resume como abordar o perfil da equipe e o treinamento dos profissionais que ocuparão os papéis de teste no projeto

A equipe de projeto uma vez engajada no processo de teste irá incluir em sua carga de atividades um período fixo próprio para treinamento interno do grupo. O treinamento será conciso e focado exclusivamente em maximizar o domínio individual do plano de teste como um todo. Para tal a equipe utilizará da abordagem das ferramentas selecionadas para executar os testes previstos, seguindo o princípio de teste que será implementado no projeto em questões de prática.

As ferramentas de Teste Selecionadas proporcionam aprendizado e ao mesmo tempo capacitação individual. A equipe composta por quatro membros dará início ao processo de treinamento antes do início marcado para se iniciar os testes e seguirá com o plano de treino até o período inicial de teste.

11. Marcos da Iteração Marco Data de Início Planejada Data de Início Real Data de Término Planejad a Data de Término Real Plano de Iteração combinado 20/06/2016 20/06/2016 01/09/2016 11/11/2016 Início da iteração 25/06/2016 25/06/2016 01/09/2016 11/11/2016 Elaboração da baseline dos requisitos 25/06/2016 25/06/2016 26/06/1016 11/07/2016 Elaboração da baseline da arquitetura 28/06/2016 28/06/2016 02/07/2016 05/10/2016 Elaboração da baseline da Interface do Usuário 30/06/2016 30/06/2016 04/07/2016 08/11/2016 Liberação do primeiro build para teste

(39)

Marco Data de Início Planejada Data de Início Real Data de Término Planejad a Data de Término Real Aceitação do primeiro build para teste

07/07/2016 07/07/2016 08/07/2016 18/07/2016

Término do ciclo de teste do primeiro build

09/07/2016 18/07/2016 20/07/2016 20/07/2016

O segundo build não será

testado - -

Liberação do terceiro build para teste

21/07/2016 21/07/2016 22/07/2016 11/11/2016

Aceitação do terceiro build para teste

23/07/2016 23/07/2016 24/07/2016 11/11/2016

Término do ciclo de teste do terceiro build

25/07/2016 25/07/2016 03/08/2016 11/11/2016

Liberação do quarto build para teste

04/08/2016 04/08/2016 05/08/2016 11/11/2016

Aceitação do quarto build para teste

06/08/2016 06/08/2016 07/08/2016 11/11/2016

Revisão da Avaliação de Iteração

08/08/2016 08/08/2016 09/08/2016 11/11/2016

Término da iteração 10/08/2016 10/08/2016 10/08/2016 11/11/2016

12. Riscos, Dependências, Suposições e Restrições

Risco Estratégia de Diminuição

Contingência (O risco se concretizou)

Erro na Execução dos Testes.

A equipe de teste deverá verificar com antecedência a documentação de plano de teste

A cada membro da equipe deverá estar

a par de todos os processos

necessários para execução dos testes.

Em caso de erro durante o processo de teste, todo o procedimento deverá ser refeito de seu inicio. O motivo do erro deverá ser documentado para

evitar futuras

(40)

DocTes_SuporTI_V7.0

Risco Estratégia de Diminuição

Contingência (O risco se concretizou)

Não

Documentação dos Testes

A equipe estará sob fiscalização do gerente de teste, sendo deste a obrigação de cobrar o registro de todas as atividades em riqueza de detalhes.

Acarretará a

reconstrução do

processo de teste em questão de seu início. Perca de Dados

do Teste.

A equipe deverá manter cópia de todos os documentos de resultado de teste em posse do analista de testes.

Em caso de perca de

dados importantes o

processo que diz

respeito aos dados

ausentes deverá ser

refeito.

Erro ao

Elicitar

Alterações nos Testes

Em caso de alteração dos testes, o grupo de teste deverá compactuar com

as alterações apresentadas sem

exceção de nenhum membro. Ainda deverá ocorrer a validação de uma segunda parte decidida pelo grupo em iguais condições.

Em caso de ocorrência de erros nos testes todo o processo deverá ser desconsiderado.

Para não ocorrer atraso

nos processos o

procedimento normal

deverá ser acatado. Banco de Dados

Corrompidos

Para trabalhos em relação ao banco de dados deverá existir uma cópia de segurança. Em momento de testes apenas um membro da equipe poderá estar com a base de dados em aberto.

Em caso de dados

corrompidos deverá ser acionada a cópia de segurança e o procedimento de teste deve continuar. Devido a Reanalise do projeto o banco de dados necessite de reconstrução

A equipe estará continuamente

realizando verificações na base

documental do projeto, de modo a entrar em processos de testes sem que necessite reenviar o modulo a ser testado ao desenvolvimento antes de os testes certificarem sua qualidade.

Em caso de atualização

da base de dados

empregada no sistema o processo de teste deverá ser interrompido.

Para que não ocorram atrasos no projeto os

demais processos de

teste deveram ser

(41)

Risco Estratégia de Diminuição Contingência (O risco se concretizou) Não Conhecimento da API Steam

A equipe será orientada a manter períodos de estudo de documentação da API.

A equipe deverá

continuar o

procedimento sem a

presença dos membros

que não mantem

conhecimento da API. Caso os responsáveis pela execução dos testes

não possuam

conhecimento da API o processo de Teste será interrompido.

Dependência entre Impacto Potencial da Dependência Proprietários

Disponibilidade da

Documentação de Plano de Teste

Não realização dos processos de teste.

Gerente de Projetos Gerente de Testes Disponibilidade de

ferramentas de Testes

Não realização dos processos de teste.

Analista de Testes

Suposição a ser comprovada

Impacto se a suposição for

incorreta Proprietários

Capacidade de

Encaminhamento de Dados para Banco

Não Realização dos processos de Teste

Analista de Testes

Prazo de Entregas Atrasos do Projeto Gerente de Projetos

Gerente de Testes

Restrição

Impacto da restrição no esforço de

teste Proprietários

Não Engajamento da Equipe Imprecisão, imperícia na execução

do plano de Testes

(42)

DocTes_SuporTI_V7.0

13. Procedimentos e Processos de Gerenciamento

Ao constatarem-se problemas na realização dos testes as seguintes medidas deveram ser adotadas pela equipe:

 Verificar se a montagem do ambiente de teste foi efetuada de forma correta.  Verificar se a ferramenta utilizada para e execução do teste está em perfeito

funcionamento, ou se a mesma está sendo utilizada de forma adequada.

 Reunir a equipe de teste, fazer o relato do incidente e decidir qual a melhor solução a ser tomada.

 Gerar relatório de erro, para possíveis consultas futuras.

13.1 Medição e Avaliação da Extensão do Teste

A extensão nos testes será avaliada através do acompanhamento feito no Testlink para controle dos testes.

13.2 Avaliação dos Produtos Liberados deste Plano de Teste

Ao termino de cada ciclo de teste, o gerente de teste irá avaliar se os objetivos do teste foram alcançados, em caso negativo, o gerente de teste deverá encaminhar o mesmo a uma reformulação para que se adéque aos objetivos esperados.

13.3 Relato de Problemas, Seleção de Pessoas para Resolvê-los e Busca de Soluções

Problemas encontrados no decorrer dos testes deverão ser encaminhados ao gerente de testes, esse será responsável por organizar uma lista contendo quais problemas foram encontrados e em que teste cada problema foi encontrado. Esses problemas serão avaliados pela equipe de teste, que dera tomar as medidas necessárias para a resolução dos mesmos. Tais medidas podem ser entendidas como sendo a mudança no ambiente de teste ou até mesmo a mudança dos processos adotados para a realização de mesmo.

13.4 Gerenciamento de Ciclos de Teste

Será adotado o mesmo procedimento para a gerência dos ciclos de teste, iniciara o ciclo de teste no termino da execução do Plano de teste, os resultados serão encaminhados ao gerente

(43)

de testes, o mesmo irá analisar os resultados encontrando tomando as devidas providências, não sendo detectado erro, o Teste estará concluso no respectivo requisito.

13.5 Estratégias de Rastreabilidade

Com a finalidade de ter uma maior organização e controle do que será realizado, antes de se iniciar os ciclos de teste será criado um documento (desenvolvido em Word), contendo o tipo de teste e o responsável pela implantação do mesmo, esse documento estará sobre domínio do gerente de teste e o mesmo será responsável por receber e transferi para o documento informações de como foi feito e onde está salvo cada teste realizado pela equipe de teste.

13.6 Aprovação e Encerramento

Ao termino dos ciclos de teste, a equipe irá avaliar se os objetivos dos testes foram alcançados, em caso negativo, a equipe deverá selecionar aqueles que não atingiram a meta e encaminhar para uma reformulação dos mesmos para que se adéquem aos objetivos esperados. Após essa adequação o plano de teste será dado como encerrado e aprovado.