1008 lines
27 KiB
Markdown
1008 lines
27 KiB
Markdown
# Plan de validation fonctionnelle
|
|
|
|
Statut: plan de tests manuel
|
|
Public: testeurs, exécutifs, mainteneurs
|
|
Dernière révision: 2026-06-02
|
|
|
|
Ce document décrit les scénarios à exécuter pour vérifier que tous les processus importants fonctionnent comme prévu. Il complète les [processus applicatifs](20_PROCESSUS.md), les [règles métier](30_REGLES_METIER.md) et les [liens de causalité](40_LIENS_CAUSALITE.md).
|
|
|
|
## Principes de validation
|
|
|
|
- Tester au moins une fois depuis une installation vanille.
|
|
- Tester avec le groupe de démonstration et avec un groupe créé manuellement.
|
|
- Tester avec trois profils: membre ordinaire, exécutif, sysadmin.
|
|
- Vérifier les effets visibles à l'écran, les effets financiers, les rapports PDF, le journal et l'isolation entre groupes.
|
|
- Après chaque action modifiante, vérifier que le journal ou l'historique conserve une trace exploitable.
|
|
- Après un redéploiement, vérifier que les données existantes sont conservées.
|
|
|
|
## Préparation
|
|
|
|
### Installation vanille
|
|
|
|
Scénario:
|
|
|
|
1. Déployer l'application sur une VM Debian vanille.
|
|
2. Ouvrir l'application depuis `https://app.87-16.org`.
|
|
3. Lancer le playbook de vérification.
|
|
|
|
Résultats attendus:
|
|
|
|
- L'application répond en HTTP derrière le proxy TLS.
|
|
- La page publique affiche les groupes sous forme de tuiles fermées.
|
|
- `Groupe Démonstration` existe.
|
|
- Le bouton discret `Sysadmin` est visible en bas de la page publique.
|
|
- Le playbook `ansible/verify.yml` réussit.
|
|
|
|
### Données de démonstration
|
|
|
|
Scénario:
|
|
|
|
1. Ouvrir `Sysadmin`.
|
|
2. Saisir le PIN sysadmin.
|
|
3. Ouvrir la gestion des groupes.
|
|
4. Cliquer `Réinit` sur `Groupe Démonstration`.
|
|
|
|
Résultats attendus:
|
|
|
|
- Les données du groupe de démonstration sont réinitialisées.
|
|
- Les autres groupes ne sont pas modifiés.
|
|
- Le groupe de démonstration contient un historique crédible: rencontres, assemblées, membres, postes, décisions, trésorerie, inventaires et journal.
|
|
|
|
## Accès, groupes et identité
|
|
|
|
### Sélection d'un groupe
|
|
|
|
Scénario:
|
|
|
|
1. Ouvrir la page publique.
|
|
2. Ouvrir la tuile d'un groupe.
|
|
3. Se connecter avec un membre de ce groupe.
|
|
|
|
Résultats attendus:
|
|
|
|
- La tuile fermée affiche le jour, l'heure et le nom du groupe.
|
|
- La tuile ouverte affiche les coordonnées et les options de connexion.
|
|
- Après connexion, l'entête affiche le nom du groupe courant.
|
|
- Le membre voit seulement les données de son groupe.
|
|
|
|
### Isolation entre groupes
|
|
|
|
Scénario:
|
|
|
|
1. Créer deux groupes.
|
|
2. Créer un membre différent dans chaque groupe.
|
|
3. Créer une rencontre, une dépense et une décision dans le premier groupe.
|
|
4. Se connecter dans le deuxième groupe.
|
|
|
|
Résultats attendus:
|
|
|
|
- Le deuxième groupe ne voit pas les membres, rencontres, dépenses, décisions, finances, rapports ou journaux du premier groupe.
|
|
- Les permissions d'un poste du premier groupe n'ont aucun effet dans le deuxième groupe.
|
|
|
|
### Connexion d'un membre
|
|
|
|
Scénario:
|
|
|
|
1. Se connecter avec un identifiant valide et un PIN valide.
|
|
2. Tenter une connexion avec un mauvais PIN.
|
|
3. Désactiver le membre.
|
|
4. Tenter une nouvelle connexion.
|
|
|
|
Résultats attendus:
|
|
|
|
- La connexion valide ouvre l'application.
|
|
- Le mauvais PIN est refusé.
|
|
- Un membre désactivé ne peut pas se connecter.
|
|
- La désactivation n'efface pas l'historique du membre.
|
|
|
|
### PIN
|
|
|
|
Scénario:
|
|
|
|
1. Changer le PIN d'un membre.
|
|
2. Saisir un PIN non conforme.
|
|
3. Saisir deux confirmations différentes.
|
|
|
|
Résultats attendus:
|
|
|
|
- Le PIN n'est pas lisible à l'écran pendant la saisie.
|
|
- Un PIN invalide est refusé.
|
|
- Deux confirmations différentes sont refusées.
|
|
- Le nouveau PIN fonctionne seulement après confirmation correcte.
|
|
|
|
### Sysadmin d'instance
|
|
|
|
Scénario:
|
|
|
|
1. Cliquer `Sysadmin` sur la page publique.
|
|
2. Saisir le PIN sysadmin.
|
|
3. Ouvrir la gestion des groupes.
|
|
4. Changer le PIN sysadmin.
|
|
|
|
Résultats attendus:
|
|
|
|
- Le sysadmin d'instance n'est pas connecté dans un groupe.
|
|
- Il accède seulement aux fonctions d'administration d'instance.
|
|
- Le changement de PIN exige deux saisies identiques.
|
|
- L'ancien PIN ne fonctionne plus.
|
|
|
|
### Sysadmin de groupe
|
|
|
|
Scénario:
|
|
|
|
1. Se connecter comme `Sysadmin` dans un groupe.
|
|
2. Tenter de supprimer le compte `Sysadmin`.
|
|
3. Impersonifier un membre.
|
|
|
|
Résultats attendus:
|
|
|
|
- Le compte `Sysadmin` du groupe a tous les accès du groupe.
|
|
- La suppression de `Sysadmin` est refusée.
|
|
- L'impersonification permet d'agir comme le membre ciblé.
|
|
- Le journal conserve l'identité du sysadmin responsable.
|
|
|
|
## Navigation et ergonomie
|
|
|
|
### Page publique
|
|
|
|
Scénario:
|
|
|
|
1. Ouvrir la page publique sur téléphone.
|
|
2. Vérifier les tuiles de groupes.
|
|
3. Vérifier les liens `Sysadmin`, `Charte`, `Confidentialité` et `Découvrir`.
|
|
|
|
Résultats attendus:
|
|
|
|
- Les tuiles sont fermées par défaut.
|
|
- Le gros bouton `Découvrir l'application` n'est plus présent.
|
|
- Les liens sont discrets et placés au bas de la page publique.
|
|
- Ces liens ne sont pas affichés dans l'accueil interne d'un groupe.
|
|
|
|
### Accueil interne
|
|
|
|
Scénario:
|
|
|
|
1. Se connecter comme membre ordinaire.
|
|
2. Se connecter comme exécutif.
|
|
3. Comparer les modules visibles.
|
|
|
|
Résultats attendus:
|
|
|
|
- Les modules visibles correspondent aux permissions.
|
|
- La gestion des groupes n'est jamais accessible depuis l'accueil interne d'un groupe.
|
|
- Le bouton `Déconnexion` est présent dans l'entête.
|
|
- Le nom du groupe est visible dans l'entête.
|
|
|
|
### Pages principales
|
|
|
|
Scénario:
|
|
|
|
1. Naviguer entre `Accueil`, `Rencontres`, `Assemblées` et `Gestion`.
|
|
2. Ouvrir un module.
|
|
|
|
Résultats attendus:
|
|
|
|
- Les pages sont cohérentes visuellement.
|
|
- Le menu inférieur n'est pas affiché dans un module pour récupérer l'espace.
|
|
- Les actions principales restent accessibles au pouce sur téléphone.
|
|
|
|
## Membres
|
|
|
|
### Invitation
|
|
|
|
Scénario:
|
|
|
|
1. Comme exécutif, générer une invitation.
|
|
2. Utiliser le code pour créer un nouveau membre.
|
|
3. Réutiliser le même code.
|
|
|
|
Résultats attendus:
|
|
|
|
- Le membre est créé dans le groupe de l'invitation.
|
|
- Le code ne peut être utilisé qu'une seule fois.
|
|
- Un code expiré est refusé.
|
|
|
|
### Création par un exécutif
|
|
|
|
Scénario:
|
|
|
|
1. Comme exécutif, créer un compte pour un autre membre.
|
|
2. Se connecter avec ce compte.
|
|
|
|
Résultats attendus:
|
|
|
|
- Le compte est créé dans le groupe courant.
|
|
- Le membre peut se connecter avec son PIN.
|
|
- L'action est journalisée.
|
|
|
|
### Profil et notifications
|
|
|
|
Scénario:
|
|
|
|
1. Ouvrir le profil.
|
|
2. Modifier des informations.
|
|
3. Choisir des catégories de notifications avec cases à cocher.
|
|
4. Enregistrer.
|
|
|
|
Résultats attendus:
|
|
|
|
- Les préférences sont conservées après rafraîchissement.
|
|
- Les notifications restent optionnelles.
|
|
- Le changement est visible au journal ou à l'historique.
|
|
|
|
### Droit à l'oubli
|
|
|
|
Scénario:
|
|
|
|
1. Appliquer le droit à l'oubli à un membre.
|
|
2. Consulter les décisions, mandats, dépenses et journal liés à ce membre.
|
|
|
|
Résultats attendus:
|
|
|
|
- L'enregistrement du membre n'est pas supprimé.
|
|
- L'ID et le prénom demeurent.
|
|
- Les coordonnées, nom, abstinence, préférences et abonnements push sont effacés.
|
|
- L'historique reste intelligible.
|
|
|
|
## Postes, mandats et permissions
|
|
|
|
### Postes à pourvoir
|
|
|
|
Scénario:
|
|
|
|
1. Ouvrir `Postes à pourvoir`.
|
|
2. Cliquer une tuile de poste.
|
|
3. Postuler.
|
|
4. Comme exécutif, proposer un autre membre.
|
|
|
|
Résultats attendus:
|
|
|
|
- La liste affiche une tuile par poste disponible.
|
|
- La tuile ouverte affiche la description et les candidatures.
|
|
- `Postuler` crée une candidature pour soi.
|
|
- `Proposer` crée une candidature pour le membre choisi.
|
|
|
|
### Gestion des postes
|
|
|
|
Scénario:
|
|
|
|
1. Comme exécutif, ouvrir `Gestion des postes`.
|
|
2. Créer un poste.
|
|
3. Modifier ses attributs.
|
|
4. Ouvrir `Permissions`.
|
|
5. Associer et dissocier des permissions.
|
|
|
|
Résultats attendus:
|
|
|
|
- Tous les postes sont présentés en tuiles.
|
|
- Le bouton `Permissions` ne montre pas de nombre.
|
|
- Les permissions changent les modules visibles pour les membres occupant ce poste.
|
|
- Le backend refuse une action non autorisée même si l'interface est contournée.
|
|
|
|
### Mandat et nomination
|
|
|
|
Scénario:
|
|
|
|
1. Affecter un membre à un poste.
|
|
2. Fournir proposeur et secondeur.
|
|
3. Vérifier les décisions.
|
|
4. Terminer le mandat.
|
|
|
|
Résultats attendus:
|
|
|
|
- L'affectation crée une décision de type `Nomination`.
|
|
- La décision porte le préfixe `NOM`.
|
|
- Le poste n'est plus à pourvoir pendant le mandat actif.
|
|
- Terminer le mandat libère le poste sans effacer l'historique.
|
|
|
|
## Rencontres
|
|
|
|
### Planification
|
|
|
|
Scénario:
|
|
|
|
1. Ouvrir la page `Rencontres`.
|
|
2. Cliquer `Planifier une rencontre`.
|
|
3. Vérifier les dates proposées.
|
|
4. Choisir une date, une heure, un sujet et un animateur.
|
|
|
|
Résultats attendus:
|
|
|
|
- Les rencontres sont affichées en tuiles fermées par défaut.
|
|
- Les dates proposées respectent le jour de réunion configuré.
|
|
- Les dates sont présentées en ordre chronologique inverse lorsque l'utilisateur doit choisir une date.
|
|
- L'animateur par défaut est le membre occupant le poste d'animateur, si défini.
|
|
- La tuile fermée affiche seulement date, heure, sujet et animé par.
|
|
|
|
### Modification
|
|
|
|
Scénario:
|
|
|
|
1. Comme exécutif, ouvrir une rencontre.
|
|
2. Modifier le sujet, l'heure ou l'animateur.
|
|
|
|
Résultats attendus:
|
|
|
|
- Les détails sont mis à jour.
|
|
- Le rapport futur reflète les nouvelles informations.
|
|
- La modification est journalisée.
|
|
|
|
### Collecte
|
|
|
|
Scénario:
|
|
|
|
1. Ouvrir une rencontre.
|
|
2. Saisir une collecte.
|
|
3. Tenter de saisir une deuxième collecte pour la même rencontre.
|
|
4. Comme trésorier, accuser réception.
|
|
|
|
Résultats attendus:
|
|
|
|
- Une seule collecte est permise par rencontre.
|
|
- La collecte devient un montant à recevoir.
|
|
- La réception augmente l'encaisse.
|
|
- La date comptable est la date de la collecte, même si la réception est saisie plus tard.
|
|
|
|
### Ventes
|
|
|
|
Scénario:
|
|
|
|
1. Saisir une vente de littérature.
|
|
2. Saisir une vente de jetons.
|
|
3. Saisir une rencontre sans vente.
|
|
4. Comme trésorier, recevoir les montants.
|
|
|
|
Résultats attendus:
|
|
|
|
- Plusieurs ventes sont permises par rencontre.
|
|
- Une vente de littérature diminue l'inventaire de littérature.
|
|
- Une vente de jetons diminue l'inventaire de jetons.
|
|
- L'argent devient un montant à recevoir, puis augmente l'encaisse à la réception.
|
|
- Une rencontre sans vente reste valide.
|
|
|
|
### Jetons et gâteaux statistiques
|
|
|
|
Scénario:
|
|
|
|
1. Saisir une remise de jeton.
|
|
2. Saisir une remise de gâteau.
|
|
3. Vérifier l'inventaire.
|
|
|
|
Résultats attendus:
|
|
|
|
- Les remises sont comptabilisées aux statistiques.
|
|
- L'inventaire ne change pas.
|
|
- Seules les ventes affectent l'inventaire.
|
|
|
|
### Rapport de rencontre
|
|
|
|
Scénario:
|
|
|
|
1. Ouvrir une tuile de rencontre.
|
|
2. Cliquer l'icône de rapport.
|
|
3. Vérifier le PDF.
|
|
4. Cliquer `Clôturer`.
|
|
5. Tenter de modifier les intrants de la rencontre.
|
|
|
|
Résultats attendus:
|
|
|
|
- L'icône est discrète et placée sur la tuile fermée.
|
|
- Le rapport contient l'entête du groupe, les coordonnées, la rencontre, la collecte, les ventes, les remises et les notes.
|
|
- Le PDF est conçu pour impression lettre.
|
|
- Après clôture, le rapport est cristallisé.
|
|
- Les intrants qui composent le rapport ne peuvent plus être modifiés directement.
|
|
|
|
## Assemblées
|
|
|
|
### Planification
|
|
|
|
Scénario:
|
|
|
|
1. Ouvrir la page `Assemblées`.
|
|
2. Cliquer `Planifier une assemblée`.
|
|
3. Vérifier les dates proposées.
|
|
4. Créer l'assemblée.
|
|
|
|
Résultats attendus:
|
|
|
|
- La page est dédiée aux assemblées.
|
|
- Les assemblées sont affichées comme les rencontres: une tuile par assemblée, fermée par défaut.
|
|
- Les dates respectent le rang mensuel configuré dans les paramètres du groupe.
|
|
- Les dates sont présentées en ordre chronologique inverse.
|
|
- Chaque tuile offre une icône de rapport.
|
|
|
|
### Présences
|
|
|
|
Scénario:
|
|
|
|
1. Ouvrir une assemblée.
|
|
2. Ouvrir la section `Présences`.
|
|
3. Saisir les membres présents.
|
|
|
|
Résultats attendus:
|
|
|
|
- La section s'ouvre et se ferme sans quitter la page.
|
|
- Les présences sont conservées.
|
|
- Le rapport PDF les reprend.
|
|
|
|
### Invitation et accès invité
|
|
|
|
Scénario:
|
|
|
|
1. Ouvrir une assemblée.
|
|
2. Générer le texte d'invitation.
|
|
3. Ouvrir le lien invité dans un autre navigateur.
|
|
4. Attendre ou simuler l'expiration du lien.
|
|
|
|
Résultats attendus:
|
|
|
|
- Le texte est prêt à copier/coller.
|
|
- Le lien ouvre directement la page de l'assemblée en lecture seule.
|
|
- L'URL BBB réelle n'est pas exposée comme lien permanent.
|
|
- Un invité ne peut rien modifier.
|
|
- Un lien expiré refuse l'accès.
|
|
|
|
### Ordre du jour
|
|
|
|
Scénario:
|
|
|
|
1. Ouvrir une assemblée.
|
|
2. Vérifier les sections disponibles.
|
|
|
|
Résultats attendus:
|
|
|
|
- La page d'assemblée tient lieu d'ordre du jour.
|
|
- Les sections s'ouvrent et se ferment comme dans les rencontres.
|
|
- Les actions disponibles comprennent présences, décisions, contributions, postes à pourvoir et rapport.
|
|
|
|
### Adoption du PV précédent
|
|
|
|
Scénario:
|
|
|
|
1. Ouvrir l'assemblée courante.
|
|
2. Consulter le PV précédent.
|
|
3. Apporter une correction avant adoption.
|
|
4. Cliquer `Adopter`.
|
|
5. Choisir proposeur et secondeur.
|
|
6. Tenter une modification après adoption.
|
|
|
|
Résultats attendus:
|
|
|
|
- Les corrections sont possibles avant adoption.
|
|
- L'adoption exige proposeur et secondeur.
|
|
- Une fois adopté, le PV est cristallisé, historisé, consultable et imprimable.
|
|
- Une correction postérieure ne modifie pas le PV adopté; elle doit être portée à une assemblée subséquente.
|
|
|
|
### Adoption du rapport du trésorier
|
|
|
|
Scénario:
|
|
|
|
1. Ouvrir l'assemblée.
|
|
2. Ouvrir le rapport du trésorier.
|
|
3. Tenter de décider une contribution avant adoption.
|
|
4. Adopter le rapport avec proposeur et secondeur.
|
|
5. Retenter la contribution.
|
|
|
|
Résultats attendus:
|
|
|
|
- Une contribution est bloquée tant que le rapport du trésorier requis n'est pas adopté.
|
|
- L'adoption exige proposeur et secondeur.
|
|
- Après adoption, le rapport est cristallisé.
|
|
- Les contributions peuvent ensuite être décidées.
|
|
|
|
### Rapport d'assemblée
|
|
|
|
Scénario:
|
|
|
|
1. Cliquer l'icône de rapport d'une assemblée.
|
|
2. Vérifier le PDF.
|
|
3. Adopter l'assemblée avec proposeur et secondeur.
|
|
|
|
Résultats attendus:
|
|
|
|
- Le rapport sert de procès-verbal.
|
|
- Le PDF contient l'ordre du jour, les présences, les propositions, les décisions, les contributions, les nominations, les postes à pourvoir et les rapports adoptés.
|
|
- Après adoption, le rapport est cristallisé et ne peut plus être altéré directement.
|
|
|
|
## Gouvernance
|
|
|
|
### Proposition
|
|
|
|
Scénario:
|
|
|
|
1. Soumettre une proposition avec un objet et un contenu.
|
|
2. Soumettre une proposition sans objet.
|
|
|
|
Résultats attendus:
|
|
|
|
- La proposition valide apparaît dans `Gouvernance`.
|
|
- Une proposition sans objet est refusée.
|
|
- Une proposition n'a pas de type au départ.
|
|
|
|
### Seconder
|
|
|
|
Scénario:
|
|
|
|
1. Comme membre, cliquer `Je seconde`.
|
|
2. Comme exécutif, seconder pour un autre membre.
|
|
3. Comme sysadmin, seconder sa propre proposition.
|
|
|
|
Résultats attendus:
|
|
|
|
- Le libellé affiché est `Je seconde`.
|
|
- Un exécutif peut choisir le membre secondeur.
|
|
- Sysadmin peut seconder ses propres propositions et nominations.
|
|
- Les autres membres ordinaires ne peuvent pas seconder pour autrui.
|
|
|
|
### Décision
|
|
|
|
Scénario:
|
|
|
|
1. Transformer une proposition secondée en décision.
|
|
2. Renseigner `ÉTANT DONNÉ QUE`.
|
|
3. Renseigner `LE GROUPE A DÉCIDÉ DE`.
|
|
4. Vérifier l'historique des décisions.
|
|
|
|
Résultats attendus:
|
|
|
|
- Seul un exécutif peut transformer une proposition en décision.
|
|
- La décision exige proposeur et secondeur.
|
|
- Le type est renseigné au moment de la décision.
|
|
- Le préfixe est correct: `RES`, `NOM` ou `DON`.
|
|
- La décision est visible dans l'historique et les rapports.
|
|
|
|
### Rejet
|
|
|
|
Scénario:
|
|
|
|
1. Rejeter une proposition.
|
|
2. Omettre `ÉTANT DONNÉ QUE`.
|
|
3. Consulter l'historique.
|
|
|
|
Résultats attendus:
|
|
|
|
- Le rejet exige une raison.
|
|
- La proposition rejetée est conservée.
|
|
- Elle ne disparaît pas comme si elle n'avait jamais existé.
|
|
- Le journal indique qui a causé le rejet.
|
|
|
|
### Rapport des décisions
|
|
|
|
Scénario:
|
|
|
|
1. Produire le registre PDF des décisions.
|
|
2. Vérifier une décision ayant `LE GROUPE A DÉCIDÉ DE`.
|
|
|
|
Résultats attendus:
|
|
|
|
- La description du rapport est `Décisions prises en Groupe`.
|
|
- La colonne principale est `Résolution`.
|
|
- Le texte de `LE GROUPE A DÉCIDÉ DE` apparaît comme résolution lorsque renseigné.
|
|
- Le rapport ne contient pas de sommaire final inutile.
|
|
|
|
## Contributions
|
|
|
|
### Donner au suivant
|
|
|
|
Scénario:
|
|
|
|
1. Ouvrir `Donner au suivant`.
|
|
2. Choisir un destinataire.
|
|
3. Choisir proposeur et secondeur.
|
|
4. Soumettre.
|
|
|
|
Résultats attendus:
|
|
|
|
- Le module porte le nom `Donner au suivant`.
|
|
- `District 87-16` est présent et sélectionné par défaut au déploiement initial.
|
|
- La contribution crée une décision de type `Contribution` avec préfixe `DON`.
|
|
- La contribution apparaît dans `Trésorerie > À traiter`.
|
|
- Les soldes ne changent pas avant traitement par la trésorerie.
|
|
|
|
### Destinataires
|
|
|
|
Scénario:
|
|
|
|
1. Ajouter un destinataire à la volée.
|
|
2. Gérer les destinataires depuis `Trésorerie`.
|
|
3. Tenter de supprimer `District 87-16`.
|
|
|
|
Résultats attendus:
|
|
|
|
- Le nouveau destinataire devient sélectionnable.
|
|
- La gestion depuis la trésorerie met à jour la liste.
|
|
- `District 87-16` est protégé contre la suppression.
|
|
|
|
## Dépenses
|
|
|
|
### Soumission par un membre
|
|
|
|
Scénario:
|
|
|
|
1. Comme membre ordinaire, soumettre une dépense.
|
|
2. Vérifier le nom du demandeur.
|
|
3. Vérifier la date.
|
|
|
|
Résultats attendus:
|
|
|
|
- Le membre soumet seulement en son nom.
|
|
- La date est la date de soumission.
|
|
- La demande apparaît dans `Trésorerie > À traiter`.
|
|
|
|
### Soumission par un exécutif
|
|
|
|
Scénario:
|
|
|
|
1. Comme exécutif, soumettre une dépense pour un autre membre.
|
|
2. Choisir le membre dans une liste déroulante.
|
|
|
|
Résultats attendus:
|
|
|
|
- L'exécutif peut choisir le demandeur.
|
|
- Le membre choisi est conservé comme demandeur.
|
|
- L'action est journalisée.
|
|
|
|
### Traitement
|
|
|
|
Scénario:
|
|
|
|
1. Traiter une dépense cash.
|
|
2. Traiter une dépense par chèque.
|
|
3. Traiter une dépense par virement.
|
|
4. Tenter de traiter une dépense bancaire supérieure au solde disponible.
|
|
5. Rejeter une dépense.
|
|
|
|
Résultats attendus:
|
|
|
|
- Une dépense cash diminue immédiatement l'encaisse.
|
|
- Une dépense par chèque ou virement crée un engagement.
|
|
- Le débit bancaire diminue la banque lors de confirmation.
|
|
- Une dépense bancaire impossible est refusée.
|
|
- Le bouton `Rejeter` efface la demande soumise.
|
|
- Le module `Dépense` ne duplique pas le traitement de trésorerie.
|
|
|
|
## Trésorerie
|
|
|
|
### Page d'accueil de trésorerie
|
|
|
|
Scénario:
|
|
|
|
1. Ouvrir `Trésorerie`.
|
|
2. Vérifier l'ordre des sections.
|
|
3. Comparer membre ordinaire et exécutif.
|
|
|
|
Résultats attendus:
|
|
|
|
- La page d'accueil montre les positions de trésorerie, les réserves et les éléments à traiter.
|
|
- Tous peuvent voir les éléments à traiter.
|
|
- Seuls les exécutifs peuvent confirmer, traiter, rejeter ou modifier.
|
|
- L'état des résultats est sur une page `Résultats` séparée.
|
|
|
|
### Soldes
|
|
|
|
Scénario:
|
|
|
|
1. Consulter banque, encaisse, réserves et solde disponible.
|
|
2. Faire une collecte reçue.
|
|
3. Faire un dépôt d'encaisse.
|
|
4. Faire un don direct.
|
|
|
|
Résultats attendus:
|
|
|
|
- L'encaisse est une position disponible séparée.
|
|
- La collecte reçue augmente l'encaisse.
|
|
- Le dépôt depuis l'encaisse diminue l'encaisse et augmente la banque.
|
|
- Le don direct augmente la banque sans diminuer l'encaisse.
|
|
- Le solde disponible bancaire est la banque moins engagements et réserves.
|
|
|
|
### Réserves
|
|
|
|
Scénario:
|
|
|
|
1. Créer une réserve.
|
|
2. Tenter de modifier directement son montant.
|
|
3. Faire un virement depuis le disponible vers la réserve.
|
|
4. Faire un virement entre deux réserves.
|
|
5. Faire un virement depuis une réserve vers le disponible.
|
|
6. Supprimer une réserve à solde non nul.
|
|
7. Ramener la réserve à zéro et la supprimer.
|
|
|
|
Résultats attendus:
|
|
|
|
- La réserve est créée à zéro.
|
|
- Le montant ne se modifie pas directement.
|
|
- Les virements modifient les soldes.
|
|
- Les virements apparaissent au registre.
|
|
- Une réserve non vide ne peut pas être supprimée.
|
|
- Une réserve à zéro peut être supprimée.
|
|
|
|
### Registre
|
|
|
|
Scénario:
|
|
|
|
1. Ouvrir le registre.
|
|
2. Filtrer par mois.
|
|
3. Filtrer par type.
|
|
4. Vérifier l'ordre.
|
|
|
|
Résultats attendus:
|
|
|
|
- Les transactions les plus récentes sont affichées d'abord.
|
|
- Les filtres mois et type fonctionnent ensemble.
|
|
- Le registre reflète collectes, ventes, dépenses, dépôts, retraits, dons, contributions et mouvements de réserves.
|
|
|
|
### État des résultats
|
|
|
|
Scénario:
|
|
|
|
1. Ouvrir `Résultats`.
|
|
2. Choisir un mois et une année.
|
|
3. Produire le rapport PDF mensuel.
|
|
|
|
Résultats attendus:
|
|
|
|
- L'état des résultats montre revenus, charges et résultat net.
|
|
- Le rapport PDF utilise toujours le mois précédent.
|
|
- Les positions de trésorerie du rapport sont celles du dernier jour du mois précédent.
|
|
|
|
## Inventaires, littérature et jetons
|
|
|
|
### Consultation
|
|
|
|
Scénario:
|
|
|
|
1. Ouvrir l'inventaire littérature et jetons depuis la page `Gestion`.
|
|
2. Ouvrir les modules de consultation depuis `Accueil`.
|
|
|
|
Résultats attendus:
|
|
|
|
- La gestion littérature et jetons est unifiée dans une même tuile de gestion.
|
|
- Les traitements sont cohérents entre littérature et jetons.
|
|
- Les modules de consultation restent accessibles depuis `Accueil` selon les permissions.
|
|
|
|
### Ajustement
|
|
|
|
Scénario:
|
|
|
|
1. Comme responsable autorisé, ajuster un stock.
|
|
2. Comme membre non autorisé, tenter le même ajustement.
|
|
|
|
Résultats attendus:
|
|
|
|
- L'ajustement autorisé est conservé et journalisé.
|
|
- L'action non autorisée est refusée.
|
|
|
|
### Import initial littérature
|
|
|
|
Scénario:
|
|
|
|
1. Déployer sur une base vide.
|
|
2. Consulter l'inventaire de littérature.
|
|
|
|
Résultats attendus:
|
|
|
|
- L'inventaire initial est renseigné à partir du fichier de prix prévu.
|
|
- Les articles sont disponibles pour les ventes.
|
|
|
|
## Événements
|
|
|
|
### Consultation
|
|
|
|
Scénario:
|
|
|
|
1. Ouvrir `Événements`.
|
|
2. Vérifier événements passés et futurs.
|
|
3. Sélectionner plusieurs filtres.
|
|
|
|
Résultats attendus:
|
|
|
|
- Les événements passés sont visibles.
|
|
- Le filtre `Tous` n'est pas présenté.
|
|
- La sélection multiple fonctionne.
|
|
- Les résolutions ne sont pas affichées dans le calendrier.
|
|
|
|
### Gestion
|
|
|
|
Scénario:
|
|
|
|
1. Comme exécutif, créer un événement.
|
|
2. Comme membre ordinaire, tenter de créer un événement.
|
|
|
|
Résultats attendus:
|
|
|
|
- L'exécutif peut créer et supprimer un événement.
|
|
- Le membre ordinaire ne peut pas créer d'événement si son poste ne l'autorise pas.
|
|
|
|
## Rapports PDF et mode papier
|
|
|
|
### Formulaires vierges
|
|
|
|
Scénario:
|
|
|
|
1. Ouvrir le mode papier.
|
|
2. Produire un formulaire vierge de rencontre.
|
|
3. Produire un formulaire vierge d'assemblée.
|
|
|
|
Résultats attendus:
|
|
|
|
- Les formulaires contiennent une entête propre avec le nom et les coordonnées du groupe.
|
|
- Les cadres de saisie sont proportionnés pour impression lettre.
|
|
- Le formulaire permet une reprise manuelle si l'application devient indisponible.
|
|
|
|
### Rapports cristallisés
|
|
|
|
Scénario:
|
|
|
|
1. Clôturer une rencontre.
|
|
2. Adopter une assemblée.
|
|
3. Télécharger les rapports plus tard.
|
|
|
|
Résultats attendus:
|
|
|
|
- Les PDF cristallisés restent accessibles.
|
|
- Le contenu ne change plus après clôture ou adoption.
|
|
- Les rapports sont consultables et imprimables.
|
|
|
|
## Journal, historique et notifications
|
|
|
|
### Journal
|
|
|
|
Scénario:
|
|
|
|
1. Modifier un membre.
|
|
2. Créer une proposition.
|
|
3. Traiter une dépense.
|
|
4. Ouvrir le journal.
|
|
5. Filtrer par domaine.
|
|
|
|
Résultats attendus:
|
|
|
|
- Chaque action modifiante réussie crée une entrée.
|
|
- La tuile condensée montre seulement date, heure et domaine.
|
|
- La tuile ouverte montre les détails sans redondance.
|
|
- Le journal indique le prénom du membre responsable lorsque disponible.
|
|
- L'ancienne valeur et la nouvelle valeur sont visibles lorsque disponibles.
|
|
- Le filtre du journal fonctionne.
|
|
|
|
### Historique métier
|
|
|
|
Scénario:
|
|
|
|
1. Modifier une donnée sensible ou importante.
|
|
2. Consulter les détails historiques.
|
|
|
|
Résultats attendus:
|
|
|
|
- L'historique indique l'objet modifié.
|
|
- L'ancienne valeur est conservée lorsque pertinente.
|
|
- La nouvelle valeur est conservée lorsque pertinente.
|
|
- La raison de modification est générée automatiquement par l'application.
|
|
- L'utilisateur n'a pas à saisir la raison.
|
|
|
|
### Notifications
|
|
|
|
Scénario:
|
|
|
|
1. Activer les notifications pour une catégorie.
|
|
2. Désactiver une autre catégorie.
|
|
3. Créer une action qui devrait notifier.
|
|
|
|
Résultats attendus:
|
|
|
|
- Le membre reçoit seulement les notifications des catégories choisies, si son navigateur les supporte.
|
|
- Un membre non abonné ou non intéressé ne reçoit pas la notification.
|
|
- L'échec d'une notification push ne bloque pas l'action métier.
|
|
|
|
## Sauvegarde, restauration et exploitation
|
|
|
|
### Sauvegarde par groupe
|
|
|
|
Scénario:
|
|
|
|
1. Créer des données dans deux groupes.
|
|
2. Sauvegarder le premier groupe.
|
|
3. Modifier les deux groupes.
|
|
|
|
Résultats attendus:
|
|
|
|
- La sauvegarde concerne seulement le groupe choisi.
|
|
- Les données personnelles contenues dans la sauvegarde sont traitées comme sensibles.
|
|
|
|
### Restauration par groupe
|
|
|
|
Scénario:
|
|
|
|
1. Restaurer le premier groupe.
|
|
2. Vérifier le deuxième groupe.
|
|
|
|
Résultats attendus:
|
|
|
|
- Le premier groupe revient à l'état sauvegardé.
|
|
- Le deuxième groupe n'est pas modifié.
|
|
- Une sauvegarde de sécurité est créée avant restauration.
|
|
|
|
### Redéploiement
|
|
|
|
Scénario:
|
|
|
|
1. Créer des données.
|
|
2. Redéployer avec Ansible.
|
|
3. Vérifier les données.
|
|
|
|
Résultats attendus:
|
|
|
|
- Le redéploiement ne détruit pas les données.
|
|
- Les services redémarrent correctement.
|
|
- La vérification Ansible réussit.
|
|
|
|
### Cache navigateur
|
|
|
|
Scénario:
|
|
|
|
1. Installer l'application comme PWA.
|
|
2. Déployer une nouvelle version.
|
|
3. Ouvrir l'application sur un appareil qui avait l'ancienne version.
|
|
|
|
Résultats attendus:
|
|
|
|
- L'application se met à jour sans incohérence durable.
|
|
- En cas de problème, la navigation privée ou l'effacement des données du site corrige le symptôme.
|
|
|
|
## Concurrence et changements simultanés
|
|
|
|
### Modification concurrente
|
|
|
|
Scénario:
|
|
|
|
1. Ouvrir la même fiche dans deux navigateurs.
|
|
2. Modifier et enregistrer dans le premier navigateur.
|
|
3. Modifier et enregistrer dans le deuxième navigateur sans rafraîchir.
|
|
|
|
Résultats attendus:
|
|
|
|
- L'application détecte que la donnée a changé.
|
|
- Le deuxième enregistrement n'écrase pas silencieusement le premier.
|
|
- L'utilisateur est informé qu'un rafraîchissement ou une reprise est nécessaire.
|
|
- L'historique conserve le changement réellement appliqué.
|
|
|
|
### Données cristallisées
|
|
|
|
Scénario:
|
|
|
|
1. Ouvrir un rapport non cristallisé dans deux navigateurs.
|
|
2. Cristalliser le rapport dans le premier.
|
|
3. Tenter une modification dans le deuxième.
|
|
|
|
Résultats attendus:
|
|
|
|
- La modification est refusée.
|
|
- Le message explique que le rapport est clôturé ou adopté.
|
|
- Le PDF cristallisé demeure la source consultable.
|
|
|
|
## Contrôles transversaux après chaque scénario
|
|
|
|
Après chaque scénario modifiant des données, vérifier:
|
|
|
|
- le résultat à l'écran;
|
|
- le rafraîchissement de la page;
|
|
- la déconnexion et reconnexion;
|
|
- le journal;
|
|
- l'historique détaillé si applicable;
|
|
- les permissions d'un membre non autorisé;
|
|
- l'absence de fuite vers un autre groupe;
|
|
- les rapports PDF concernés;
|
|
- les soldes ou inventaires si l'action a un effet comptable.
|
|
|
|
## Critères d'acceptation globaux
|
|
|
|
L'application est considérée prête pour une ronde de test avec des membres lorsque:
|
|
|
|
- tous les scénarios critiques d'accès, rencontres, assemblées, gouvernance, trésorerie et rapports passent;
|
|
- aucun membre ordinaire ne peut exécuter une action réservée;
|
|
- aucun groupe ne voit les données d'un autre groupe;
|
|
- les soldes financiers sont explicables par le registre;
|
|
- les rapports adoptés ou clôturés ne changent plus;
|
|
- le journal permet de comprendre qui a causé quoi, quand, et quelle valeur a changé;
|
|
- une installation vanille donne un groupe de démonstration utilisable;
|
|
- un redéploiement ne détruit pas les données;
|
|
- les sauvegardes et restaurations par groupe ont été testées au moins une fois.
|