Testando¶

Agora que o servidor DHIS 2 foi configurado inicialmente e você instalou o aplicativo em um ou mais dispositivos, você está pronto para iniciar o teste. Enquanto você planeja seus testes, você precisa estar ciente dos próximos lançamentos. É importante fazer parte da comunidade em https://community.dhis2.org/ e usar o [JIRA] (http://jira.dhis2.org/), a ferramenta de gerenciamento de software que UiO utiliza. Isso permitirá que você aprenda sobre os problemas em aberto em termos de recursos e correção de bugs que estão agendados para versões futuras.

Recomendamos testar o aplicativo Android em paralelo com sua configuração, para ter certeza de que suas alterações no servidor são refletidas corretamente e funcionando no aplicativo. Isso é especialmente importante durante a configuração das regras do programa. Além desse teste passo a passo, existem diferentes tipos de teste que você deve realizar antes de lançar o aplicativo.

Há um conjunto inicial de testes que devem ser conduzidos internamente com grupos menores para garantir que as configurações sejam feitas corretamente, que a funcionalidade esteja no lugar e que a aparência e o toque sejam adequados. Como parte desta fase inicial de teste, você conduzirá o que é conhecido como teste interno, seguido pelo teste UAT (Teste de Aceitação do Usuário). Mais adiante nesta seção, iremos elaborar sobre o que esse tipo de teste significa e como conduzi-lo. Depois disso, você conduzirá seus testes de campo e piloto. Nesta fase de teste você conduzirá um conjunto de testes com grupos maiores para garantir, entre outras coisas, que seus fluxos de trabalho, sua infraestrutura e arquitetura estão corretos. Também mais tarde nesta seção, iremos elaborar mais sobre esses tipos de testes e como conduzi-los.

Os gráficos a seguir mostram que as próximas etapas são iterativas por natureza, incluindo novas configurações de servidor com base nos resultados do teste. Provavelmente, você fará várias rodadas de testes e reconfiguração antes de estar pronto para aumentar a escala e implementar.

General Recommendations for Testing an Android App¶

Antes de entrar nas diferentes fases de teste, apresentaremos algumas recomendações gerais que podem ser aplicadas para testar um aplicativo Android. Em geral, qualquer processo de teste pode ser resumido nas seguintes etapas:

1. Reveja. A primeira etapa é revisar as informações sobre o próprio aplicativo acessando [ https://www.DHIS 2.org/android-documentation ] (https://www.dhis2.org/android-documentation). A documentação fornecerá informações sobre os motivos e o que são os seus testes. Deve ajudá-lo a determinar se o aplicativo atende aos seus requisitos, o que o aplicativo pode ou não fazer e ajudá-lo a analisar as discrepâncias. Ele também deve ajudá-lo a identificar novos recursos e configurações, recursos suportados.

2. Plano. Nesta etapa, você precisa identificar o tempo de teste, entendendo o cronograma de sua própria implementação. Como parte desta fase de planejamento, você deve criar uma lista detalhada de requisitos e classificá-los como obrigatórios (DEVE ter) ou bom ter.

3. Design. In this step you must develop the test cases, decide the number of test interactions and the tools you will be using for your testing.

   • Example of testing tools - Jira

   • Example of testing tool - Excel

   • Every test case should include the following sections. The level of detail and the content of the test to be performed will depend on the level of experience-profile of the user.

     • Identification: Cycle number / ID, Test ID, version, test summary.
     • Description: details, steps to reproduce
     • Status report: Date of execution, executed by, expected vs actual result, execution status report ID.

4. Executar. Durante a execução do seu teste, tenha em mente duas questões importantes:

   • Configuração de metadados: Verifique as configurações do programa na web e verifique a documentação para saber o comportamento dos recursos do aplicativo. Isso ajudará a identificar bugs reais versus problemas derivados da configuração ou recursos não suportados.
   • Matriz de Conclusão: Verifique seu progresso de acordo com os prazos que você traçou no estágio do plano. Além disso, certifique-se de que as anotações sejam feitas com rigor para poder relatar um bug.
5. ** Relatório **. Existem três características importantes que seu relatório deve ter
   • O erro relatado deve ser reproduzível
   • As informações devem ser específicas e informativas
   • The report must separate facts from speculations { .center width=80% }
   • The table below summarises a good Bug Reporting with some examples: { .center width=80% }

Internal testing and UAT testing¶

** O que você está testando **

Você está testando a configuração do servidor DHIS 2 e o próprio aplicativo Android.

O que você está procurando?

Program Rules, forms, visual UI, indicators... Bugs, improvements, new requirements, etc.

Como?

Os métodos e períodos de teste variam de grupo para grupo, mas deve ser iterativo, flexível e deve ser feito nas fases iniciais do processo de implantação. Você precisa gastar tempo decidindo quem participará do teste, desenvolver um plano de teste e ter uma estratégia para coletar o feedback. Existem diferentes ferramentas disponíveis para relatar e rastrear bugs e problemas. Dependendo da complexidade do seu teste, você pode usar [trello] (https://trello.com/), [JIRA] (https://www.atlassian.com/software/jira), etc.

Definir a base certa para seus testes internos aumentará a qualidade e a eficiência das sessões de teste. Essas recomendações se aplicam a qualquer um dos diferentes testes que você precisará realizar.

UAT Testing¶

** O que você está testando ** Você está testando a configuração do sistema (entrada), sua IU visual e ícones, usabilidade e seus resultados. Você também pode testar nesta fase a experiência do usuário com diferentes dispositivos (smartphone, tablet, teclado externo, Chromebook).

O que você está procurando?

Ajustes nos itens anteriores e problemas de hardware. Este é um bom momento para começar a identificar campeões que ajudarão nas fases futuras. O objetivo principal do UAT é ter pessoas de diferentes origens de acordo com a configuração para executar os testes de campo. O sucesso desta fase determinará a passagem para a próxima fase, testes de campo

Como?

Use um ambiente controlado. Encontre usuários com pouca exposição à tecnologia, que não estejam necessariamente integrados às práticas de trabalho. Seus usuários podem ser: 1) Especialista na / s área / s de saúde, 2) Oficial de campo, 3) Usuário de campo.

O tamanho do grupo irá variar dependendo do tipo de projeto para o qual você está implementando o App. Um grupo de teste UAT de tamanho médio seria entre 5 e 10 pessoas.

Ao decidir quem participará de seu teste, pense sobre todos os diferentes tipos de usuários e suas funções. Com isso em mente, selecione seus testadores. Você deve fornecer aos seus testadores a integração e orientação corretas. Eles precisam estar bem informados sobre os métodos que você usará para o teste, as expectativas e os objetivos e metas gerais do teste. É aconselhável, se possível, organizar sessões de teste com um ou dois líderes, onde os testadores podem ajudar uns aos outros e têm a possibilidade de fazer perguntas e obter ajuda in loco dos líderes. Outro aspecto importante a considerar são os dados de teste. Você deve ter dados suficientes em seu servidor de teste para permitir o teste de diferentes casos de teste.

Field Testing/Pilot¶

** O que você está testando **

• Você está testando seus SoP e fluxos de trabalho.
• Você está testando sua infraestrutura / arquitetura.
• Você está testando os diferentes dispositivos.
• Você está testando seus procedimentos e materiais de treinamento.

O que você está procurando?

• Ajustes nos itens anteriores.
• Adequação dos dispositivos selecionados para o espaço de trabalho e ambiente.
• Avalie sua solução
• Identifique os campeões.

Como?

20-30 usuários. Recomendado 2 meses (planeje com antecedência!). Decida a distribuição (locais). Não escolha o mais fácil ou o mais complexo. Mantenha-o simples, mas desafie sua solução.

** Considerações para avaliar seu piloto **

Você deve definir seus indicadores para avaliar seus resultados e decidir sua estratégia para testar seu sistema. Você pode usar seu sistema atual e o novo sistema em paralelo por alguns meses ou simplesmente substituí-lo. Ambas as estratégias têm vantagens e desvantagens e você deve analisá-las cuidadosamente com sua equipe antes do piloto.

Algumas vantagens de ter o sistema atual e o novo em paralelo são:

• Você pode ter evidências de como o novo sistema melhora em comparação com o antigo em termos de oportunidade ou qualidade dos dados, por exemplo, esses parâmetros dependem do propósito de seu projeto específico.
• Você tem seu sistema anterior como mecanismo de backup se algo funcionar conforme o esperado
• Gera confiança nos usuários ao comparar os dois resultados.

Algumas desvantagens são:

• Você está definindo um mecanismo de relatório duplo, que duplica o tempo e o nível de esforço de seus usuários. A TI é importante para lidar com isso com sensibilidade e preparar recursos humanos de suporte em potencial quando necessário.
• A possibilidade de os usuários comparar os dois sistemas em paralelo pode ser uma faca de dois gumes, já que os usuários tendem a resistir às mudanças.