Index
Documentation Générale Qualité
Documentation Classes Metier
Documentation Liste Qualité Code Review
Documentation Liste Qualité Guideline Development
Documentation Bugs Defaults
Documentation Tests Unitaires
Documentation i18n
Documentation SQL Indexation
Documentation Timeframe

Objectifs zéro retour sur la conception des classes en test & review avant PR & zéro bug en PR

Introduction        4

Objectifs        4

Avantages        4

Cantonner les bugs/défauts et les causes de bugs/défauts dans les phases les plus précoces du workflow        5

Q0 - Initialisation, maturation, ticketing (IN PROGRESS)        5

Projets demandant un développement > 2 jours/homme        5

Q1 - Développement        6

Q2 - Merge master & 1ère review par le développeur lui même        6

Q3 - Merge master, démo et test utilisateur par un autre développeur (si projet > à 2h environ)        7

Q4 - Merge master et test de recette par un autre développeur (si il y a une recette et/ou tests > 2 actions)        8

Q5 - Merge master et stress test (optionnel)        8

Q6 - Merge master et test final + review        9

Retours de Q6 :        9

Q7 - Mettre à jour la documentation        10

Création d’une recette pour les tests        10

Limiter au maximum les retours pour problème de conception        10

Documentation & learning management        10

Support technique        10

Prise en charge des projets        10

Routines à mettre en place pour chaque projet        11

Signaler impérativement les projets finalisés        11

Spécificité vérification portage ou traduction I18N        12

Introduction

Objectifs

• Cantonner les bugs dans les phases les plus précoces du workflow. Plus les bugs sont traités en amont, le plus près possible du développeur, moins ils ont d’impact sur notre organisation et moins on perd de temps.
• Limiter au maximum les retours pour problème de conception (surtout au niveau des classes et des composants).
• Documenter de la manière la plus claire possible (classes, méthodes, typages, tables, readme, .docx, recettes).
• Plus on aura une culture de la qualité et une culture interne technique, plus ça sera simple et passionnant, plus vous pourrez faire de conception, d'analyse et d'encadrement.

Avantages

• Plus les bugs sont traités en amont, le plus près possible du développeur, moins ils ont d’impact sur notre organisation et moins on perd de temps.
• Plus la documentation sera bonne, plus il sera facile de développer ou de reprendre des fonctionnalités, plus agréable cela sera et cela entraînera moins de retour pour problèmes de conception.
• Plus on aura une culture de la qualité et une culture interne technique, plus ça sera simple et passionnant, plus vous pourrez faire de conception, d'analyse et d'encadrement.

Cantonner les bugs/défauts et les causes de bugs/défauts dans les phases les plus précoces du workflow

Q0 - Initialisation, maturation, ticketing (IN PROGRESS)

Projets demandant un développement > 2 jours/homme

Initialisation : Chaque projet doit être abordé comme un nouveau produit. Avec un scope, une finalité, des contraintes, un MVP défini.

• Créer l’EPIC dès l’évocation du projet. Code projet clair, concis séparé par des _. En statut Bloqué
• Créer un ticket de tâche “Initialisation” faisant référence à cette documentation Q0.
• Créer le dossier dans drive/projets au nom de l’EPIC
• Créer un fichier doc nommé [CODEEPIC] notes et commencer par la date.
• Noter date butoire indicative.
• Indiquer la finalité précise, les contraintes, les besoins exprimés ou déduits de la discussion.
• En fin d’initialisation créer le ou les tickets suivants prévisibles : Exemple “Analyse avec intel”, “Recherche de solution pour telle problématique”, “Réunion avec JM pour compléter le dossier” etc…

Maturation :

• Définir les uses cases du MVP sous forme de texte
• Définir si besoin des diagrammes
• Définir si besoin de maquettes interactives (Figma)
• Dev 1ère interface si on a assez d'éléments solides ?
• Définir les navettes entre le tech lead et le dev et les prochaines étapes (découper en tickets/sous-tickets), selon les éléments consolidés peut-on créer/lancer :

• des tables //définir les noms des tables et les principales colonnes
• des classes //définir les signatures
• des interfaces //définir
• des tests techniques/preuves de concept (ex une connexion et usage Api tiers ou un plugin JS, ou un module/composant etc...)

Ticketing :

• Compléter la description de l’EPIC
• Créer systématiquement un ticket d’analyse du projet par le développeur.
• Relecture de chaque tickets/sous-tickets proposés dans l’étape de maturation. Associer les liens vers les documents. Questionner les initiateurs jusqu’à que le ticket soit clair.
• Suivre la DOC…[A compléter, voir avec Nicolas]

Q1 - Développement

Voir d’abord le chapitre Prise en charge des projets .

Toute modification lors de développement doit être testée partout où c’est nécessaire, console ouverte. Les warning, notice et fatal errors, sont traités au fur et à mesure.

1 ligne de code modifiée = un test certifié = vous devez vous assurer que vous testez bien ce que vous pensez tester , si vous avez un doute et cela arrive souvent, mettre des die(‘test’) à l’endroit de la modification.

Faire des tests versatiles : Ne testé pas juste le minimum, pensez systématiquement aux cas d’usages réels (exemple : Vous créez une liste avec filtres, vous avez créé une ligne, ne testez pas juste avec une seule ligne, il faut tester tous les cas liés au filtres). Autre exemple, votre méthode attend un float, que se passe-t-il si un NULL ou un string est fourni ?

1 méthode crée = 1 à x tests unitaires DOCTESTSUNITAIRES 

Lire impérativement “Limiter au maximum les retours pour problème de conception”

Pendant Q1 dev doit faire des Q2 intermédiaires au fur et à mesure, et compléter progressivement la recette.

Q2 - Merge master & 1ère review par le développeur lui même

Tous les fichiers modifiés doivent être testés avec certitude. Il faut s’assurer que chaque ligne de code modifiée fonctionne correctement. Aussi, si il y a un doute sur quand est exécuter une ligne modifiée, il faut chercher ou demander comment elle fonctionne et quand est-elle exécutée.

Merger le master et ensuite comparer tout HTK/ à origin/master et vérifier :

• Console ouverte

• Redeployer et appliquer upgradefrommaster/

• Lancer tous les tests unitaires (https://docs.google.com/document/d/1bDJR4FrgHWQ8VYRBE48iKDWy7zkQtR7vsvBe8d9VzQE/edit )
• Aucun fichier modifié en dehors du scope de la branche.
• Modifications qui ont des conséquences transversales à tester (exemple changement dans une méthode d’une classe).
• Rien de suspect au niveau code (bricolage, choses bizarres etc…).
• Le code est commenté et typé (les méthodes, les lignes de code).
• La nomenclature et l’esprit des classes métiers est respecté (https://docs.google.com/document/d/1WVZIlfP8VFVhBY8B3pxaBMSdaqGCvbEYiZEqpi8U3lo/edit )
• Tester toutes les modifications/créations de codes sans exception. Repérez les difficultés dans le code (Exemple typique un Mdselect qui vient remplacer un vieux select avec de l’ajax et des filtres sql, il faut vérifier que le Mdselect reprend bien toutes les fonctionnalités de l’ancien). prenez le temps de bien cibler les points sensibles de vos interventions et de bien vérifier derrière que tout est ok. Il est largement préférable de passer 2 heures de plus et d’être sûr de notre coup.
• Le développeur rédige à cette occasion la recette (Modèle Recette V2) (si tests > 2 actions) pour les fonctionnalités qu’il a développées ou modifiées en créant des sections dans le tableau de recettes pour en faciliter la compréhension et l’usage. Chaque ligne doit être compréhensible par n’importe qui et comporter les détails nécessaires pour reproduire les actions. Si pas de lien vers recette le demander.
• Mergez votre branche de dev dans la branche de preprod du projet et indiquer en commentaire de l’EPIC le nom de la branche de dev et en toutes lettres “Mergée dans preprod_…”

Q3 - Merge master, démo et test utilisateur par un autre développeur (si projet > à 2h environ)

0/ 2 types :

Intermédiaire : Pour une ou un lot de fonctionnalités :

• Le dev fait une démo au testeur d’abord (pour comprendre et déceler éventuellement les pbs évidents et faire un retour immédiat au dev pour qu’il corrige avant de continuer).
• Si la démo passe sans pb, qu’il n’y a rien d'évident à corriger, à ce moment-là le testeur va faire une Q3 en profondeur.

Complète : Idem que pour intermédiaire mais pour l’ensemble des fonctionnalités à livrer par les développeurs.

• Les devs vont faire une démo de leur partie au testeur d’abord (pour comprendre et déceler éventuellement les pbs évidents et faire un retour immédiat au dev pour qu’il corrige avant de continuer).
• Si la démo passe sans pb, qu’il n’y a rien d'évident à corriger, à ce moment-là le testeur va faire une Q3 en profondeur.

1/ Vérifications de base

Merger le master et ensuite comparer tout HTK/ à origin/master et vérifier :

• Console ouverte

• Redeployer et appliquer upgradefrommaster/

• Lancer tous les tests unitaires (DE TESTS UNITAIRES)
• Aucun fichier modifié en dehors du scope de la branche.
• Modifications qui ont des conséquences transversales à tester (exemple changement dans une méthode d’une classe).
• Rien de suspect au niveau code (bricolage, choses bizarres etc…).
• Le code est commenté et typé (les méthodes, les lignes de code).
• La nomenclature et l’esprit des classes métiers est respecté (DOCCLASSMETIER)

2/ Tester sans recette

Se mettre à la place de chaque utilisateur et en essayant d’effectuer les tâches du programme sans support (c’est le cas des utilisateurs réels).

Avoir un esprit critique large et exigeant (ergonomie, design, mise en page, syntaxe, ton employé, conception).

En cas de bug : Préparer un ticket de correctif (type bugfix) rattaché au projet, avec le lien vers la recette dans la description et contenant un sous-tickets par fix, que le testeur complète au fur et à mesure de ses observations (en plus de remarques dans la recette). Quand il a fini, il signale son ticket de bugfix à n.chevillard@gdn.fr sans l’assigner.

En cas de défauts : Les noter dans la recette dans les remarques avec des détails et si besoin en faisant des captures (dans le second onglet de la recette).^[a]

Q4 - Merge master et test de recette par un autre développeur (si il y a une recette et/ou tests > 2 actions)

Tous les fichiers modifiés doivent être testés avec certitude. Il faut s’assurer que chaque ligne de code modifiée fonctionne correctement. Aussi, si il y a un doute sur quand est exécuter une ligne modifiée, il faut chercher ou demander comment elle fonctionne et quand est-elle exécutée.

Faire Q3/0 et Q3/1 puis suivre et compléter la recette, console ouverte (tail -f apachelog/hightekers.process-id.com-error_log). Les warning, notice et fatal errors doivent être remontés.

Avoir un esprit critique large et exigeant (ergonomie, design, mise en page, syntaxe, ton employé, conception).

En cas de bug : Préparer un ticket de correctif (type bugfix) rattaché au projet, avec le lien vers la recette dans la description et contenant un sous-tickets par fix, que le testeur complète au fur et à mesure de ses observations (en plus de remarques dans la recette). Quand il a fini, il signale son ticket de bugfix à n.chevillard@gdn.fr sans l’assigner.

En cas de défauts : Les noter dans la recette dans les remarques avec des détails et si besoin en faisant des captures (dans le second onglet de la recette).^[b]

Q5 - Merge master et stress test (optionnel)

Faire Q3/1 puis faire un test dit de “stress” qui consiste à essayer de faire bugger le programme par n’importe quel moyen qui vous passe par la tête.

Selon les cas, créer des tests de masse.

Là aussi console ouverte. Les warning, notice et fatal errors doivent être remontés.

En cas de bug : Préparer un ticket de correctif (type bugfix) rattaché au projet, avec le lien vers la recette dans la description et contenant un sous-tickets par fix, que le testeur complète au fur et à mesure de ses observations (en plus de remarques dans la recette). Quand il a fini, il signale son ticket de bugfix à n.chevillard@gdn.fr sans l’assigner.

En cas de défauts : Les noter dans la recette dans les remarques avec des détails et si besoin en faisant des captures (dans le second onglet de la recette).

Q6 - Merge master et test final + review

Nous sommes sur l’étape finale avant PR. A ce stade, il ne doit plus y avoir aucun bug.

Faire Q3/1 + Q4.

Review très attentive. Tester toutes les modifications/créations de codes sans exception.

Avoir un esprit critique large et exigeant (ergonomie, design, mise en page, syntaxe, ton employé, conception).
Les tests doivent être fait en se posant : Prenez une tisane, respirez et mettez-vous à la place de l’utilisateur. Quand vous testez vous devez vous mettre en position d’observateur impitoyable (vous savez l’inspecteur des travaux fini qui vient pointer ce qui ne va pas). Il faut vous conditionner mentalement pour cet exercice bien particulier et on doit tous faire de même.

Tous les fichiers modifiés doivent être testés avec certitude. Il faut s’assurer que chaque ligne de code modifiée fonctionne correctement. Aussi, si il y a un doute sur quand est exécuter une ligne modifiée, il faut chercher ou demander comment elle fonctionne et quand est-elle exécutée.

En cas de bug : Préparer un ticket de correctif (type bugfix) rattaché au projet, avec le lien vers la recette dans la description et contenant un sous-tickets par fix, que le testeur complète au fur et à mesure de ses observations (en plus de remarques dans la recette).

En cas de défauts : Les noter dans la recette dans les remarques avec des détails et si besoin en faisant des captures (dans le second onglet de la recette).

Retours de Q6 :

• Préparer le retour sous forme de ticket avec captures et explications si nécessaire.
• Marquer les points les plus sensibles, compliqués ou demandant une explication.
• Organiser une visio de revue avec le ou les devs concernés + éventuellement le chef de projet en se limitant aux points marqués.
• Signaler son ticket de bugfix à n.chevillard@gdn.fr sans l’assigner.

Une fois le test passé, recommencer et si tout est bon, créer un ticket de PULL Request.

Pour cela, revenir sur l’Epic et aller dans Actions > Créer Ticket PR

Q7 - Mettre à jour la documentation

Dès que le projet (l’EPIC) est mergée dans le master (statut DONE). Reprendre toutes les documentations et les mettre à jour : Diagrammes, Uses cases (pas les maquettes figma).

Création d’une recette pour les tests

TODO

Limiter au maximum les retours pour problème de conception

Documentation & learning management

Documentation produite essentiellement par les développeurs : classes, méthodes, typages, tables, readme, recettes.

Ressources : documentation AA - Index DOCS 

Support technique

Support informatique niveau 3 (N3) > Discord > @MatthiasD : expertise par domaines de compétence, réponses aux questions techniques avancées, recherche aide pour trouver des solutions techniques.

Prise en charge des projets

• Phase d’analyse du projet systématique : Le premier sous-ticket des stories sera maintenant un temps d’analyse du développeur qui découvre le projet. La ou les solutions proposées paraissent-elles bien déjà ?, est-ce que vous comprenez les problématiques que vous essayez de résoudre (sinon contacter le chef de projet), est-ce que vous voyez une solution plus simple ou plus propre (dans le contexte et dans le temps que l’on veut à peu prêt y consacrer).
• Lire le ticket, les sous-tickets, les documents s’il y en a.
• S’assurer que l’on comprend bien l’ensemble du projet ainsi que chaque ticket.
• Contacter le « reporter » du projet dès que vous avez un doute, une question, une suggestion, repéré une erreur, un oubli etc… Si du code legacy doit être réformé cela doit faire l’objet d’un autre projet qui suis un process, une analyse, une temporalité et une logique de natures différentes., signalez le et demandez au chef de projet de s’en occuper.
• Vérifier les timeframes de chaque tickets (Noté « [TFx] » dans les titres) et nous faire un retour si besoin pour adapter le timeFrame.
• Être proactif sur les interactions et les feedbacks, les tickets sont imparfaits, des phrases mal formulées, des incohérences possibles... c'est de la communication, l'important est de demander dès que vous avez un doute. Il vaut mieux enfoncer des portes ouvertes en nous appelant que de bloquer des heures sur un détail qui aurait pu être résolu en quelques minutes.
• Pas de « bidouille », si vous avez l'impression que vous contournez ou qu'il y a une meilleure façon de faire, appelez/demandez.
• Validez avec le « reporter » du projet les points techniques dès que vous pensez que c’est mieux pour limiter les retours (par exemple lors du portage de fonctions anciennes vers une classe métier).
• Documenter systématiquement les classes, les méthodes en vous mettant à la place d’un dev qui ne connaît rien au projet.
• Si la branche de départ n’est pas le master, commencer toujours par merger le master dans cette branche avant de créer votre nouvelle branche depuis cette dernière.

Routines à mettre en place pour chaque projet

• Analyse, notes, demander une réunion en visio avec le “reporter” du projet.
• Autoreview.
• Faire un point tous les 2 jours maximum sur un projet avec un tech lead.
• Tests efficaces ne rien laisser passer. Toute ligne de code modifiée ou ajoutée = tests qui correspondent.
• Tests croisés > ne rien laisser passer. Toute ligne de code modifiée ou ajoutée = tests qui correspondent.
• Ne pas hésiter à compléter les tickets avec des commentaires quand on fait des tests ou quand on fait des changements par rapport au ticket.
• Pour les ajouts de fichiers dans upgradeFromMaster

• Je créer le répertoire pour mon projet s’il n’existe pas, nommé avec le nom de la branche, qui doit commencer par le numéro de l’épic (par exemple HTK-2250-...)
• Je crée ou modifie le fichier README.md dans ce répertoire même s’il n’y a qu’un seul fichier.
• Je spécifie les actions à réaliser et dans quelle ordre les réaliser. S’il n’y a pas d’ordre, il faut aussi le spécifier.
• Pour les scripts CLI, je spécifie aussi dans le README.md lesquels il faut lancer et à quel moment.

Signaler impérativement les projets finalisés

Signaler impérativement par un email au chef de projet quand un projet/une branche est finalisée et doit être mise en production selon vous. Ceci pour tous types de projets : bugfix, storie etc... Seulement si c'est une finalisation, pas les tickets intermédiaires.

Spécificité vérification portage ou traduction I18N

• 2 écrans, 2 interfaces master et la branche et comparer, ça doit être exactement pareil. Faire une comparaison très attentive et surtout visuelle et interactive (typiquement des chants selects qui interagissent avec d’autres ou des champs select qui se modifient après un POST du formulaire). S’il y a des différences, c’est surement un bug, faire des recherches dans ce cas pour documenter.  Demander un second serveur pour avoir  le master et ta branche pour les comparer.
• Attention en cas de portage ou I18NV2 lors du test & review, quand vous faites la différence entre le master et la branche testée, repéré au fur et à mesure les difficultés dans le code (exemple typique portage d’un select complexe avec ajax dans un MDSelect).