Réunion octobre CI

Suivant >

CI/CD

Évolution des méthodes

Procédures de test et validation

2 sept

nov

oct

Août

26 juil

19 juil

Mise en place des protections

Prise en main des méthodes

core & common

Prise en main des nouvelles méthodes

Coordination / mise en place Pierre

// Rappel

>

>

>

<Pourquoi tester ?>

Plus une anomalie est détectée tôt, moins les impacts financiers sont importants

Un regard extérieur est toujours plus efficace sur des développements qui peuvent être longs

Confiance et crédibilité : détecter les anomalies avant la mise en production permet de minimiser l'insatisfaction client

Le testeur est garant de la qualité du produit livré : moins de responsabilité sur le développeur

Utilisation d'un logiciel de test permet d'avoir un périmètre de test défini et de produire des livrables

Tests automatisés : Plus coûteux initialement, rentable à long termeTests manuels : Moins coûteux à court terme, moins rentable à long terme

Coût

Tests automatisés : Rapides en exécution mais lents en rédaction Tests manuels : Lents en exécution mais rapides en rédaction

Rapidité

Tests automatisés : Scripts sans humain, exécutables à l'infini Tests manuels : Étapes prédéfinies suivies par un testeur qui interagit avec l'application

Définition

>

>

// Tests automatisés et manuels

// Fonctionnement actuel

Remontée d'anomalies par le client

>

Réunion

DEV

Livraison

MR/PR

// Fonctionnement prévu

Remontée d'anomalies

>

Cahier des charges

DEV

Tests

Livraison

MR/PR

Rédaction des tests

Les problèmes bloquants gardent leur procédure spécifique simplifiée et ne sont pas totalement concernés par les procédures suivantes.

HOTFIX

// DISCLAIMER

>

1. Rédaction du cahier des charges
2. Définition des impacts/risques que peuvent causer cette fonctionnalité
3. Création d'une branche à partir de preprod => Développeur/Intégrateur
4. Développement et commits sur cette branche
5. Pull ou rebase à partir de preprod
6. Ouverture de la MR/PR
7. Code review => Responsable dev.
8. Tests manuels et/ou automatisés => Testeur
9. Déploiement sur preprod => Responsable dev.
10. Planification
11. Déploiement en production

// Workflow de travail

TERMINÉ

VÉRIFiÉ @acourciere

EN COURS @dev/inté

A TESTER @pmoirez

OUVERT @acourciere

A TESTER @acourciere

Déploiement

Prêt audéploiement

TESTS

CODE REVIEW

DEV.

Création ticket

// Workflow YouTrack

>

>

<Bonnes pratiques de développement>

Chaque ticket YouTrack doit avoir un périmètre de test : chaque développeur doit indiquer clairement ce qui peut être impacté par ses modifications et ce qu'il faut tester Chaque développeur doit tester un minimum le code produit Rédaction des MR : il faut être rigoureux dans leur rédaction. Le but n'étant pas de perdre du temps à relire l'intégralité des (longs) tickets pour comprendre de quoi on parle. Tout ce qui n'est pas indiqué dans la MR ne sera pas pris en compte (tests, vérifications, etc). Nomenclature des commits : [change] [ME-152] Modification du pictogramme d'envoi FTP

>

>

<Bonnes pratiques de tests>

La version à tester doit être identifiée (versionning via les numéros de commit des versions de core/common/default et du site testé) La version à livrer au client doit être la dernière testée Ce sont des tests itératifs, ce qui est déjà passé en OK ne sera pas re-testé, à part pour le sanity Création d'un sanity qui retrace un parcours utilisateur classique et qui sera passé en dernière itération (peut être remplacé par les tests auto) Rédactionnel/traduction : les procédures de validation ne sont pas garantes des textes et des éventuelles fautes d'orthographe. Si elles sont détectées, elles sont bien sûr remontées Tout ne peut pas être testé à 100% : il y aura forcément des choses hors périmètre. Il faut trouver le bon ratio entre tests manuels et tests automatisés

>

>

// Bilan

Planification et tests : plus de qualité, moins de clients impactés Une branche = une fonctionnalité/un bug/un changement Tous les tickets de développement entrants assignés au Resp Dev. pour planification Tous les tickets de développement terminés assignés au Resp Dev. pour revue + planif des tests Une planification efficace évite les retards de livraison et préserve une bonne qualité La qualité de la V3 se joue dès maintenant sur l'adoption de ces bonnes pratiques

>

>

On a besoin de vous pour une meilleure qualité !

>

>

Des Questions ?