relatorio cruzada

Plano de Teste - Habitica - Grupo 2

O plano de teste é um artefato de planejamento que serve de guia para a execução dos testes. Ele está diretamente ligado aos requisitos especificados e por isso pode ser visto como um mecanismo de comunicação entre os stakeholders. Visto isso, abaixo é possível ver o desenvolver do plano de teste para o Habitica. O relatório inicialmente relata as informações da funcionalidade escolhida e depois expõe a estratégia de testes proposta, transparecendo as dimensões de qualidade, níveis, tipos e técnicas escolhidas.

1 - Habitica

Habitica é um aplicativo android, ios e web para gerenciar as tarefas pessoais com gamificação. Assim, é possível tratar tarefas do dia-a-dia como “fases” ou objetivos de um jogo.

Ao cuprir os objetivos, o jogador pode costumizar seu personagem, desbloquear itens e missões, derrotar monstros com os amigos, ganhar prêmios, entre outros mecanismos que provocam a imersão do usuário no software.

Para o escopo desse plano de teste foi escolhida apenas a versão mobile para Android dele, que se encontra disponível no github (https://github.com/HabitRPG/habitica-android). Alguns módulos que podem ser citados nesta versão são o inventário, convite, registro e notificações. O código é de livre acesso e está escrito em Java.

2 - Funcionalidade de registro

Dentre as várias possibilidades de funcionalidades do Habitica optou-se por se escolher a de Registro, pois é ela que contempla os requisitos estabelecidos. A princípio foi olhado outras, como as Recompensas. Todavia, essa não tinha campos calculados, nem tampouco campos obrigatórios e mensagens de erro. Isso devido a filosofia do software de ser fácil de se utilizar.

Desta forma, apesar do Registro ser uma funcionalidade bem comum nos sistemas, no Habitica ela tem o adicional da comunicação com a API do Facebook e da Google para o registro de usuário.

Tentou-se buscar a especificação dessa funcionalidade, porém não se obteve sucesso. Logo, antes de se pensar nos casos de teste para melhor entendimento e como guia, elaborou-se uma especificação contendo o fluxo principal e fluxos de exceção para o Registro.

Para se ter ideia de como é o registro no aplicativo, abaixo segue uma sequência de imagens das mensagens e telas que são apresentadas.

(IMAGENS)

2.1 - Registro no Habitica

Requisitos

1. Como todos os campos são obrigatórios. Caso o usuário deixe de inserir algum campo. O botão: “Comece agora!”, não será habilitado.

2. Os campos não tem limite mínimo e máximo de caracteres.

3. O nome dos usuários não devem ser repetidos.

4. Não há validação de registro pelo email.

Fluxo principal

O usuário deve inserir:

O nome do usuário no campo: “Usuário”

O e-mail do usuário no campo: “E-mail”

A senha do usuário no campo: “Senha”

Reescrever a senha inserida no campo “Senha” no campo de “

Confirmação de senha”

Após inseridas as informações necessárias, o botão: “Comece agora!”, será habilitado, o usuário deve clicar nesse. Com todas informações corretas, o usuário será registrado no sistema. Sem nenhuma mensagem confirmando o sucesso da operação.

Fluxos alternativos

1. Nome do usuário já existente

Caso o nome do usuário inserido já exista no sistema. Será emitido uma mensagem de erro informando: “Nome de usuário já está sendo utilizado.”. Impedindo que a operação de registro no sistema seja concluída com sucesso.

2. E-mail errado

Caso o usuário insira um e-mail que não corresponda ao formato: “[email protected]”. Será emitido uma mensagem de erro informando: “Endereço de e-mail inválido.”. Impedindo que a operação de registro no sistema seja concluída com sucesso.

3. E-mail do usuário já existente

Caso o e-mail do usuário inserido já exista no sistema. Será emitido uma mensagem de erro informando: “Endereço de e-mail já está sendo usado em uma conta.”. Impedindo que a operação de registro no sistema seja concluída com sucesso.

4. Senhas não correspondentes

Caso a senha inserida não corresponda a senha do campo de confirmação de senha. Será emitido uma mensagem de erro informando: “A confirmação de senha não corresponde à senha.”. Impedindo que a operação de registro no sistema seja concluída com sucesso.

5. Campo vazio

Caso um campo esteja vazio e o usuário clique no botão: “Registrar”. Será emitidos uma mensagem de erro informando: “Erro de Validação: Você precisa preencher todos os campos.” Impedindo que a operação de registro no sistema seja concluída com sucesso.

3 -Foco de qualidade

om a funcionalidade escolhida, o passo posterior foi identificar as dimensões de qualidade que poderiam ser exploradas. Notou-se, é claro, que seria necessário construir casos para a dimensão de funcionalidade, já que existem requisitos por trás dela.

Entretanto foram escolhidas outras dimensões, como a usabilidade, para analisar a facilidade do usuário em preencher o cadastro, a confiabilidade, para que seja analisado a integração com as APIs, o desempenho, a fim de se ter uma média de quantidade de registros que o aplicativo tolera de forma estável e a suportabilidade, para averiguar se as especificações de versão do android são seguidas.

4 - Tipos de teste

Com o foco de qualidade bem definido e observando a tabela apresentado sobre a equivalência das dimensões de qualidade com o tipo de teste, foi estabelecido os seguintes teste: teste de funções, de usabilidade, de integridade, de carga, de configuração e de instalação.

5 - Níveis de teste

Tendo em vista que o aplicativo se encontra na fase só de manutenção e evolução para essa funcionalidade não se viu uma aplicabilidade imediata na adoção de níveis de teste mais baixo, mais voltados para a parte de desenvolvimento.

Assim sendo, escolheu direcionar os esforços para níveis mais altos, como o de aceitação e de sistema. Esses níveis proporcionam principalmente a validação dos requisitos e a integração da funcionalidade com outras, respectivamente.

6 - Técnicas

Como relatado anteriormente, não se pensou em casos de teste que abrange a fundo o código fonte do aplicativo, Das técnicas então que foram apresentadas, a única que não foi utilizada foi a de caixa-branca. A técnica de caixa-preta foi a que mais se adequou, pois ela se relaciona muito bem com o nível de aceitação. Além dela buscou-se utilizar a técnica de Valor Limite para os testes de instalação e configuração. A ideia de utilizar ele é que o aplicativo tem uma versão mínima do android para funcionar, Então, ao se utilizar o valor limite no teste de instalação pegaria um valor abaixo, uma acima e o valor mínimo da versão exigida para a instalação.

Outra que se buscou usar é a técnica do Particionamento de Equivalência no teste de carga, para que a partir de intervalos de uso do sistema seria gerado intervalo e dentre esse intervalo definido métricas para categorizar o comportamento do sistema com uma certa quantidade de registros efetuados. Entretanto, essa técnica não foi totalmente quantificada já que os dados de acesso para essa funcionalidade não está disponível.

7 - Ambiente

Para os testes escolhidos não se tem a necessidade de execução de testes na versão que é disponibilizada para o usuário. Sendo uma boa prática a criação de um ambiente de homologação, que tem as características bem próximas da versão de produção, e que no caso por exemplo de um teste de carga não oferece riscos concretos ao aplicativo.

(Testes)[https://docs.google.com/spreadsheets/d/1YfbNSDtA4DUnyl5ztKkyc8R-ihoQhAOFNFBP2Uyxsss/edit?usp=sharing]