Test¶

Maintenant que le serveur DHIS 2 est configuré et que vous avez installé l'application sur un ou plusieurs appareils, vous pouvez procéder aux tests. Pendant que vous planifiez vos tests, vous devez être informé des prochaines versions. Il est donc important de rejoindre la communauté sur https://community.dhis2.org/ et d'utiliser JIRA, l'outil de gestion de logiciels utilisé par UiO. Cela vous permettra de prendre connaissance des problèmes en suspens en termes de fonctionnalités et de correction de bogues pour lesquels des versions ultérieures sont prévues.

Il est conseillé de tester l'application Android en parallèle avec votre configuration, afin de s'assurer que les modifications apportées au serveur sont correctement prises en compte et fonctionnent dans l'application. Ceci est particulièrement important lors de la configuration des règles du programme. Outre ce test étape par étape, il existe différents types de tests que vous devez effectuer avant le déploiement de l'application.

Il existe une première série de tests qui devraient être effectués en interne avec des groupes plus restreints pour s'assurer que les configurations sont effectuées correctement, que la fonctionnalité est bien en place et que l'aspect et la convivialité sont adéquats. Dans le cadre de cette phase initiale de tests, vous effectuerez ce que l'on appelle des tests internes, suivis par les tests UAT (Tests d'acceptation des utilisateurs). Plus loin dans cette section, nous expliquerons plus en détail en quoi consistent ces types de tests et comment les réaliser. Ensuite, vous effectuerez vos tests sur le terrain et votre test pilote. Dans cette phase des tests, vous effectuerez une série de tests avec des groupes plus importants afin de garantir, entre autres, que vos flux de travail, votre infrastructure et votre architecture sont corrects. Nous reviendrons plus loin sur ces types de tests et sur la manière de les réaliser.

Les graphiques ci-après indiquent que les prochaines étapes sont de nature itérative, y compris les nouvelles configurations de serveur basées sur les résultats des tests. Vous devrez probablement effectuer plusieurs séries de tests et de reconfiguration avant de pouvoir passer à la mise à l'échelle et au déploiement.

General Recommendations for Testing an Android App¶

Avant d'aborder les différentes phases de test, nous allons présenter quelques recommandations générales applicables au test d'une application Android. Globalement, le processus de test peut se résumer aux étapes suivantes :

1. Examiner. La première étape consiste à examiner les informations relatives à l'application elle-même en vous rendant à https://www.DHIS 2.org/android-documentation. Vous y trouverez des informations concernant le pourquoi et le quoi ou encore sur vos tests. Elle devrait vous aider à déterminer si l'application répond à vos exigences, ce qu'elle peut et ne peut pas faire et vous aider à analyser les divergences. Elle devrait également vous aider à identifier les nouvelles fonctionnalités et les nouveaux paramètres ainsi que les fonctionnalités prises en charge.

2. Planifier. À cette étape, vous devez déterminer le moment des tests en tenant compte du calendrier de votre propre mise en œuvre. Lors de cette phase de planification, vous devez créer une liste détaillée des exigences et les classer comme obligatoires (DOIT avoir) ou souhaitables.

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. Exécuter. Lors de l'exécution de vos tests, veuillez tenir compte de deux points importants :

   • Configuration des métadonnées : Vérifiez les paramètres du programme sur le web et consultez la documentation pour vous familiariser avec les fonctionnalités de l'application. Cela permettra d'identifier les véritables bogues par rapport aux problèmes issus de la configuration ou aux fonctionnalités non prises en charge.
   • Matrice d'achèvement : Vérifiez vos progrès en fonction des échéances que vous avez fixées à la phase de planification. Veillez aussi à prendre soigneusement des notes pour être en mesure de signaler un bogue.
5. Rapport. Votre rapport doit présenter trois caractéristiques importantes
   • L'erreur signalée doit être reproduisible
   • L'information doit être spécifique et descriptive
   • 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¶

Que testez-vous ?

Vous testez la configuration de votre serveur DHIS 2 et l'application Android elle-même.

Que recherchez-vous ?

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

Comment ?

Les méthodes et les périodes de tests varient d'un groupe à l'autre, mais les tests doivent être itératifs, flexibles et réalisés dès les premières phases du processus de déploiement. Vous devez donc prendre le temps de décider des personnes qui participeront au test, élaborer un plan de test et disposer d'une stratégie pour recueillir les avis. Il existe différents outils permettant de signaler et de suivre les bogues et les problèmes. Selon la complexité de votre test, vous pouvez utiliser trello, JIRA, etc.

Il est important de bien préparer vos tests en interne pour améliorer la qualité et l'efficacité des séances de test. Ces recommandations s'appliquent à tous les tests que vous aurez à effectuer.

UAT Testing¶

Que testez-vous ?
Vous testez la configuration de votre système (entrée), votre interface visuelle et vos icônes, la facilité d'utilisation et vos sorties. Vous pouvez également tester à ce stade l'expérience utilisateur avec différents appareils (smartphone, tablette, clavier externe, chromebook).

Que recherchez-vous ?

Les modifications apportées aux points précédents ainsi que les problèmes liés au matériel. C'est un moment propice pour commencer à identifier ceux qui pourront contribuer aux phases ultérieures. L'objectif principal de l'UAT est d'avoir des gens aux expériences variées en accord avec la configuration pour l'exécution des tests sur le terrain. La réussite de cette étape est la condition pour passer à la phase suivante, à savoir les tests sur le terrain

Comment ?

Utiliser un environnement contrôlé. Trouver des utilisateurs ayant peu d'exposition à la technologie, qui ne sont pas nécessairement associés aux pratiques professionnelles. Vos utilisateurs pourraient être : 1) Expert dans le domaine sanitaire, 2) Agent de terrain, 3) Utilisateur sur le terrain.

La taille du groupe variera en fonction du type de projet pour lequel l'application est mise en œuvre. La taille moyenne d'un groupe de test UAT varie entre 5 et 10 personnes.

Lorsque vous décidez des personnes qui participeront à votre test, pensez à tous les différents types d'utilisateurs et à leurs rôles. Sélectionnez vos testeurs en tenant compte de cet aspect. Vous devez fournir à vos testeurs des informations et des conseils appropriés. Ils doivent être bien informés des méthodes que vous utiliserez pour le test, des attentes et des objectifs généraux du test. Il est conseillé, dans la mesure du possible, d'organiser des séances de test avec un ou deux responsables, où les testeurs peuvent échanger des informations et avoir la possibilité de poser des questions et d'obtenir de l'aide sur place de la part des responsables. Un autre aspect important à considérer est celui des données du test. Vous devez disposer de suffisamment de données dans votre serveur de test pour permettre de tester différents cas de test.

Field Testing/Pilot¶

Que testez-vous ?

• Vous testez vos POS et vos flux opérationnels.
• Vous testez votre infrastructure/architecture.
• Vous testez les différents appareils.
• Vous testez vos méthodes et matériels de formation.

Que recherchez-vous ?

• Ajustements relatifs aux éléments précédents.
• Adéquation des appareils sélectionnés à l'espace et à l'environnement de travail.
• Évaluer votre solution
• Identifier les promoteurs.

Comment ?

20 à 30 utilisateurs. 2 mois recommandés (prévoir à l'avance !). Décidez de la distribution (lieux). Ne pas opter pour le plus simple ou le plus complexe. Faites simple, mais remettez en question votre solution.

Considérations relatives à l'évaluation de votre projet pilote

Vous devez définir vos indicateurs pour évaluer vos résultats et décider de votre stratégie de pilotage du système. Vous pouvez utiliser votre système actuel et le nouveau système simultanément pendant quelques mois ou simplement le remplacer. Les deux stratégies présentent des avantages et des inconvénients et vous devez les analyser soigneusement avec votre équipe avant le pilotage.

Voici quelques avantages de la mise en parallèle du système actuel et du nouveau système :

• Vous pouvez avoir des preuves que le nouveau système est meilleur que l'ancien en termes de rapidité ou de qualité des données, par exemple ; ces paramètres dépendent de l'objectif de votre projet spécifique.
• Votre ancien système sert de mécanisme de secours lorsque quelque chose ne fonctionne pas comme prévu
• Il renforce la confiance des utilisateurs lorsqu'ils comparent les deux résultats.

Voici quelques inconvénients :

• Vous mettez en place un mécanisme de double reporting ; celui-ci double le temps et le niveau d'effort de vos utilisateurs. Les services informatiques se doivent donc de traiter cette question avec sensibilité et préparer les éventuelles ressources humaines de soutien en cas de besoin.
• La possibilité pour les utilisateurs de comparer les deux systèmes en parallèle pourrait être une arme à double tranchant, car certains utilisateurs ont tendance à résister au changement.