meta données pour cette page
  •  

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision		Révision précédente
certif:dm:methodologie_des_tests [2026/09/29 09:22] – [7.1. Principe de validation] nicolascertif:dm:methodologie_des_tests [2026/09/29 09:30] (Version actuelle) – nicolas
Ligne 1: Ligne 1:
 +|{{:undo-2.svg?30|}} [[certif:dm#methodologie_des_tests|Retour au dossier de maintenance]]||
 +|{{:connexe.jpg?40|}} **Sujets connexes**|[[https://cartographie-fonctionnelle.logeas-web.fr/|Cartographie fonctionnelle de LoGeAs]]\\ [[https://interface.logeas-web.fr/RapportsRelease|Informations sur la version en cours]]\\ [[certif:procedure:develop:gestionversion]]|
 +
 ====== Méthodologie des tests ====== ====== Méthodologie des tests ======
  
Ligne 174: Ligne 177:
 La validation porte sur une exécution précise des tests et sur le code correspondant. La validation porte sur une exécution précise des tests et sur le code correspondant.
  
-==== 7.2. Nouvelle exécution des tests ==== +==== 8.2. Nouvelle exécution des tests ==== 
- +Si les tests sont relancés sur une même version, un nouveau rapport est généré.\\ 
-Si les tests sont relancés sur une même version, un nouveau rapport est généré. +Ce nouveau rapport doit faire l'objet d'une validation distincte.\\
- +
-Ce nouveau rapport doit faire l'objet d'une validation distincte. +
 Les rapports précédents restent consultables et sont marqués comme **« remplacés »**. Les rapports précédents restent consultables et sont marqués comme **« remplacés »**.
  
-==== 7.3. Publication du rapport ==== +==== 8.3. Publication du rapport ====
 Tout rapport validé, avec ou sans réserves, est publié simultanément à sa validation. Tout rapport validé, avec ou sans réserves, est publié simultanément à sa validation.
  
-==== 7.4. Conditions de validation avec réserves ==== +==== 8.4. Conditions de validation avec réserves ====
 Une validation avec réserves n'est admise que si chaque échec est rattaché : Une validation avec réserves n'est admise que si chaque échec est rattaché :
- +  * à un ticket identifié ; 
-* à un ticket identifié ; +  * ou à un échec déjà connu et documenté. 
-* ou à un échec déjà connu et documenté. +Tout échec nouveau par rapport au dernier rapport validé entraîne un refus de validation.\\
- +
-Tout échec nouveau par rapport au dernier rapport validé entraîne un refus de validation. +
 Un commentaire est obligatoire pour toute validation avec réserves ou tout refus. Un commentaire est obligatoire pour toute validation avec réserves ou tout refus.
  
-===== 8. Chaîne de qualification et de livraison ===== +===== 9. Chaîne de qualification et de livraison =====
- +
-==== 8.1. Principe général ==== +
- +
-Aucune version ne peut être livrée sans disposer d'un rapport qualité validé correspondant exactement au code concerné.+
  
 +==== 9.1. Principe général ====
 +Aucune version ne peut être livrée sans disposer d'un rapport qualité validé correspondant exactement au code concerné.\\
 La chaîne de qualification et de livraison comprend les étapes suivantes. La chaîne de qualification et de livraison comprend les étapes suivantes.
  
-==== 8.2. Étape 1 : qualification ==== +==== 9.2. Étape 1 : qualification ====
 La qualification est réalisée à l'aide du script ''qualifier-version''. La qualification est réalisée à l'aide du script ''qualifier-version''.
- 
 Les conditions suivantes doivent être réunies : Les conditions suivantes doivent être réunies :
- +  * les deux dépôts doivent être positionnés sur leur branche de version ; 
-* les deux dépôts doivent être positionnés sur leur branche de version ; +  * aucune modification locale non commitée ne doit être présente ; 
-* aucune modification locale non commitée ne doit être présente ; +  * les dépôts doivent être à jour et leurs modifications poussées ; 
-* les dépôts doivent être à jour et leurs modifications poussées ; +  * la bibliothèque doit être reconstruite à partir de son dernier commit.
-* la bibliothèque doit être reconstruite à partir de son dernier commit. +
 Une fois ces conditions vérifiées, le script exécute l'ensemble des tests et produit le rapport qualité de la version candidate. Une fois ces conditions vérifiées, le script exécute l'ensemble des tests et produit le rapport qualité de la version candidate.
  
-==== 8.3. Étape 2 : validation du rapport ==== +==== 9.3. Étape 2 : validation du rapport ==== 
- +Le rapport de qualification doit être validé dans l'écran **« Rapports de version »** de la cartographie fonctionnelle.\\
-Le rapport de qualification doit être validé dans l'écran **« Rapports de version »** de la cartographie fonctionnelle. +
 Cette validation constitue un préalable obligatoire à la production de la version bêta. Cette validation constitue un préalable obligatoire à la production de la version bêta.
  
-==== 8.4. Étape 3 : livraison de la version bêta ==== +==== 9.4. Étape 3 : livraison de la version bêta ==== 
- +La production de la version bêta est réalisée par le script ''livrer-beta''.\\ 
-La production de la version bêta est réalisée par le script ''livrer-beta''. +Cette étape constitue une **porte bloquante** : la bêta ne peut être produite que si un rapport de qualification validé correspond exactement au code présent dans les deux dépôts.\\
- +
-Cette étape constitue une **porte bloquante** : la bêta ne peut être produite que si un rapport de qualification validé correspond exactement au code présent dans les deux dépôts. +
 La livraison de la bêta est automatiquement inscrite dans la trace du rapport. La livraison de la bêta est automatiquement inscrite dans la trace du rapport.
  
-==== 8.5. Étape 4 : recette de la version bêta ==== +==== 9.5. Étape 4 : recette de la version bêta ==== 
- +Après le déploiement de la bêta sur le serveur de test, une recette est réalisée dans l'écran **« Rapports de version »** de la cartographie fonctionnelle.\\ 
-Après le déploiement de la bêta sur le serveur de test, une recette est réalisée dans l'écran **« Rapports de version »** de la cartographie fonctionnelle. +Cette recette repose sur une liste de contrôle minimale.\\
- +
-Cette recette repose sur une liste de contrôle minimale. +
 Chaque point de cette liste doit être : Chaque point de cette liste doit être :
- +  * vérifié et déclaré conforme ; 
-* vérifié et déclaré conforme ; +  * ou déclaré sans objet, avec une justification.
-* ou déclaré sans objet, avec une justification. +
 Une recette déclarée non conforme nécessite obligatoirement un commentaire. Une recette déclarée non conforme nécessite obligatoirement un commentaire.
  
-==== 8.6. Étape 5 : livraison de la version client ==== +==== 9.6. Étape 5 : livraison de la version client ==== 
- +La livraison de la version client (release) est réalisée par le script ''livrer-release''.\\ 
-La livraison de la version client (release) est réalisée par le script ''livrer-release''. +Cette étape constitue également une **porte bloquante**.\\
- +
-Cette étape constitue également une **porte bloquante**. +
 Les conditions suivantes doivent être réunies : Les conditions suivantes doivent être réunies :
- +  * la recette de la version bêta doit être conforme ; 
-* la recette de la version bêta doit être conforme ; +  * aucun nouveau commit ne doit avoir été ajouté dans l'un ou l'autre des deux dépôts depuis la production de la bêta.
-* aucun nouveau commit ne doit avoir été ajouté dans l'un ou l'autre des deux dépôts depuis la production de la bêta. +
 Le rapport qualité publié constitue alors la pièce qualité de la release. Le rapport qualité publié constitue alors la pièce qualité de la release.
  
-==== 8.7. Gestion des correctifs après livraison d'une bêta ==== +==== 9.7. Gestion des correctifs après livraison d'une bêta ==== 
- +Tout correctif apporté après la production d'une bêta, même mineur, impose une nouvelle qualification et la production d'une nouvelle bêta.\\
-Tout correctif apporté après la production d'une bêta, même mineur, impose une nouvelle qualification et la production d'une nouvelle bêta. +
 Cette règle garantit que la version livrée a bien été testée et validée sur la base du code exact qui la constitue. Cette règle garantit que la version livrée a bien été testée et validée sur la base du code exact qui la constitue.
  
-==== 8.8. Gestion des livraisons d'urgence ==== +==== 9.8. Gestion des livraisons d'urgence ==== 
- +Une livraison réalisée en dehors de cette chaîne reste possible en cas d'urgence.\\ 
-Une livraison réalisée en dehors de cette chaîne reste possible en cas d'urgence. +Dans ce cas, le rapport de release et l'écran **« À propos »** de LoGeAs Web indiquent explicitement que la version est **non qualifiée**.\\
- +
-Dans ce cas, le rapport de release et l'écran **« À propos »** de LoGeAs Web indiquent explicitement que la version est **non qualifiée**. +
 Cette mention permet de distinguer une version ayant suivi l'ensemble de la procédure de qualification d'une version livrée exceptionnellement en dehors de celle-ci. Cette mention permet de distinguer une version ayant suivi l'ensemble de la procédure de qualification d'une version livrée exceptionnellement en dehors de celle-ci.