Il y a quelques mois, nous vous avons proposé un jeu d’immersion pour jongler avec les concepts du syllabus ISTQB CTAL TM. Le suspense a assez duré, voici les réponses aux questions ! 🙂
Comme prévu, nous avons également cité vos meilleures réponses.
À la lecture de ces mails, parmi les 7 activités qui constituent le processus de test standard, auxquelles avez-vous la certitude d’avoir participé dernièrement ?
Rappelons d’abord ce que sont ces 7 activités :
- Planification des tests
- Pilotage et contrôle des tests
- Analyse de test
- Conception des tests
- Implémentation des tests
- Exécution des tests
- Activités de clôture des tests
Les mails permettent d’identifier 4 de ces activités :
Planification des tests
Le plan de test de Servmanyax est évoqué plusieurs fois.
Pilotage et contrôle des tests
Le décalage de la mise en production de Wafwaf est acté suite aux « éléments fournis lors de la dernière sprint review ». Cette mesure correspond à une action corrective, typique du contrôle des tests.
Implémentation des tests
L’automatisation des tests sur l’appli Wafwaf est évoquée.
Activités de clôture des tests
La rétrospective évoquée par Anna Drénalin fait partie des activités de clôture des tests.
Considérez-vous que le plan de test de l’application Servmanyax est validé ? Pourquoi ?
“Le plan de test doit être accepté par toutes les parties prenantes et, par conséquent, les désaccords entre elles doivent être résolus.”
La DSI Jessica Scroute, absente, n’a pas lu le plan de test.
Le DSI adjoint Sam Eum, absent également, approuve le plan de test mais ne l’a pas lu non plus.
Il n’est donc pas validé.
Vos réponses
Une personne anonyme commente élégamment l’attitude de Sam Eum : « On appelle ça du management par tampon encreur » !
Quel est le SDLC du projet Servmanyax ?
Comme l’a dit une personne anonyme, « hybride ou pseudo-agile presque« .
En effet ! Le vocabulaire agile parsème les mails de l’organisation, pourtant certaines pratiques témoignent d’une culture plus traditionnelle. En témoigne le mail de Jacques Antan : « On me met un peu la pression pour avoir des chiffres précis des coûts par fonctionnalité, en amont du lancement. »
Nous vous renvoyons au syllabus CTAL-TM, qui aborde les SDLC hybrides.
Suivant les bons conseils de votre collègue Yves, vous décidez d’organiser un atelier d’identification des risques. Qui serait-il pertinent de consulter pour l’identification et l’analyse des risques, et pourquoi ?
- Farah Antastique, CEO – Si possible. Le contexte ne permet pas de savoir si elle participe à ce genre de réunion. Dans le doute, l’inviter serait une bonne idée.
- Jessica Scroute, DSI – Elle a été sollicitée sur la relecture du plan de test, c’est donc normal qu’elle participe à cet atelier
- Sam Eum, DSI adjoint – Idem
- Charles Apricorne, RSSI – Cette partie prenante est susceptible d’apporter un éclairage unique sur sa spécialité, la sécurité informatique
- Jacques Antan, chef de projet et Product Owner ParapluY et Servmanyax – Cette partie prenante est incontournable pour le projet
- John Okari, administrateur système – Impliquer cette partie prenante est essentiel pour anticiper les risques liés à la mise en production (et limiter les frictions historiques)
- Léonard Ampion, responsable du pôle UX – Cette partie prenante sera impliquée sur le projet, notamment pour les enjeux liés à l’accessibilité
- Yves Olanda, QA – Pour apporter un regard complémentaire sur les risques qualité
- Giani Ustatif, fondateur et gérant du restaurant Le Tofu fou (peut être remplacé par Marion) – En tant que client final
- Marion Outarde, directrice du restaurant Le Tofu fou (peut être remplacée par Giani) – En tant que cliente finale
Quels sont les risques PROJET que vous anticipez d’ores et déjà ?
Nous avions listé celles-ci :
- Absence ou indisponibilité de parties prenantes clés (cf Jessica, mais aussi Sam qu’il a fallu relancer pour la relecture du plan de test)
- Risque de changement d’exigences ou d’objectifs stratégiques (cf Sam et les changements d’avis concernant l’accessibilité)
- Risque lié au manque de préparation ou de clarté dans le plan de test (cf remarques de Yves)
- Risque de surcharge ou de pression sur les ressources (cf Jacques Antan)
- Risque de communication insuffisante ou tardive (cf en interne cf John Okari, et en externe Giani Ustatif)
- Résistance au changement par le personnel, car le personnel du restaurant n’est pas impliqué !
- Relations tendues entre équipes (cf John Okari)
- Flou autour du SDLC (discours très orienté agile alors que dans les faits, on est plutôt sur de l’hybride non assumé)
Vos réponses
D’autres risques ont été relevés en complément :
- « Grégoire est parti. 5 ans d’expérience envolés et visiblement pas de passation. La connaissance elle est partie avec lui. »
- Le fait que le PO de Servmanyax soit aussi PO d’un autre produit pourrait nuire à sa disponibilité sur le projet.
Quels sont les risques PRODUIT que vous anticipez d’ores et déjà ?
Voici ceux que nous avions listés. Notez que les risques produit comprennent des risques fonctionnels et non fonctionnels.
- Réservation en double du même shift
- Portabilité insuffisante (affichage imparfaitement géré en fonction de la taille de l’écran)
- Accessibilité insuffisante
- Fuite de données personnelles via la messagerie
- Accès non autorisé au tableau de bord
- Indicateurs incorrects dans le tableau de bord
- Perte de performance des équipes ou abandon de l’outil en raison d’un temps de chargement trop élevé
- Faible engagement du personnel à cause de la complexité des fonctionnalités
- Produit non conforme aux valeurs du personnel
- Non-respect des règles RGPD
- Non-respect du droit du travail
Vos réponses
D’autres risques ont été identifiés (toujours en anonyme) :
- « La gamification avec les points convertibles en bons cadeaux. Ça sent le calcul foireux et la faille d’exploitation à plein nez. »
- « La marque blanche. Chaque resto va vouloir sa customisation. Faut anticiper les régressions à chaque variante. »
- « Et la gestion des shifts avec pré-réservation et validation manager. Si deux serveurs réservent le même créneau et que le système gère mal le conflit, c’est la cata côté utilisateur. »
L’organisation où vous travaillez semble souffrir de nombreux défauts. Toutefois, quels sont les points forts que vous lui trouvez ?
Effectivement, Tekmanyax n’est pas l’entreprise modèle, ni pour le test, ni pour la méthode agile, ni pour l’organisation de manière générale ! En revanche, voici quelques points sur lesquels que nous avions noté et que vous pourriez capitaliser si vous y travailliez :
- L’entreprise s’intéresse activement aux tests non fonctionnels
- Sécurité (embauche de RSSI)
- Utilisabilité (stratégie d’accessibilité)
- Des compétences en test sont déjà présentes (cf Yves Olanda)
- Plusieurs mails montrent une bonne volonté, une disponibilité et une collaboration active :
- Yves (QA) est un bon soutien.
- Le RSSI est disponible et ouvert à la discussion
- Un service communication existe, qui pourrait éventuellement être mobilisé pour passer des informations sur les tests.
- Les remerciements et les encouragements sont fréquents, même s’il existe par ailleurs des conflits.
Vos réponses
D’autres points ont été soulevés en complément, en anonyme encore :
- L’implication du Tofu Fou, même si elle pourrait être améliorée
- “Y’a des vraies rétros, des sprint reviews, du feedback client. Anna ramène des muffins au daily. C’est con mais ça compte.”
- “Y’a de la transversalité. Le QA bosse avec les devs, le PO, le client. C’est pas chacun dans son couloir…”
- “L’accessibilité est une priorité affichée. C’est pas encore clair sur le niveau WCAG mais au moins c’est sur la table. Y’a un stagiaire UX dédié et un responsable identifié.”
« Les noms des collabs » a aussi été noté comme un atout, nous vous remercions pour cette appréciation de notre humour 😋
Quel facteur d’hygiène favoriserait la stabilité de l’équipe de test ?
Une rémunération convenable (c’est la frustration de Grégoire Ateau à ce sujet qui provoque son départ).
Vos réponses
Alexandrine rappelle : « L’absence de ces facteurs ne motive pas… mais leur présence évite la démotivation et le turnover ».
Que pensez-vous de la proposition de Grégoire en ce qui concerne l’outil d’accessibilité dont il parle ?
Un rappel de ce que dit Grégoire :
J’ai entendu dire qu’on allait enfin s’attaquer à la question de l’accessibilité. C’est une bonne nouvelle et je pense que ce serait bien qu’on utilise l’outil Accessilly. C’est vraiment pas une grosse dépense par rapport à ce que ça va nous apporter. La licence n’est pas chère du tout (100 € par an), et puis on peut tout installer sur notre SI, donc on serait autonomes pour gérer l’appli. Qu’est-ce que t’en penses ? T’en parles à Samuel à l’occasion ?
Grégoire n’évoque à aucun moment les exigences de l’organisation en termes d’outillage d’accessibilité. À ce stade, ces exigences sont d’ailleurs encore en chantier.
De plus, il a une vision très restreinte des coûts qu’implique un outil. La licence est une chose, les coûts de maintenance et de formation (notamment) en est une autre. Il y a également d’autres coûts initiaux à prendre en compte ; en effet, si le logiciel doit être intégré dans le SI, cela nécessite de faire intervenir l’équipe d’exploitation, ce qui n’est pas anodin. Demandez son avis à Jacques Okari !
Vos réponses
Se pose aussi, bien sûr, la question de la gouvernance.
Une personne commente en anonyme : « Grégoire est parti. Donc qui va installer, configurer, maintenir l’outil ? Qui a la compétence ? Lucas le stagiaire ? Léonard le responsable UX ? »
La conclusion d’Yves est-elle correcte au sujet de la maintenance des tests Dynoz ? Si oui, expliquez-la ; si non, expliquez pourquoi.
Voici un rappel de la problématique exposée par Yves :
Pour la maintenance des tests auto de l’appli Dynoz, ça risque d’être vraiment coûteux. Au vu des fois précédentes, je chiffre ça à 100 jours de travail. On comptait déléguer ça à la boîte de prestation habituelle à 500 € / jour, je te laisse faire le calcul… Les scripts de test ont tous été développés par cette boîte avec leur outil open-source qu’on ne connaît pas du tout, dans leur syntaxe zarbi qu’on ne connaît pas du tout non plus, mais je pense que ça vaudrait le coup (et le coût…) de monter en compétences dessus histoire d’être autonomes et de ne pas se ruiner. T’en parles à Samuel ?
Quelques jours plus tard, Yves revient, triomphal :
Ok, j’ai la réponse de la boîte de prestation au sujet de Dynoz. La formation à l’outil et au projet d’automatisation durerait 10 jours, toujours à 500 € la journée. On pourrait demander une formation pour toute l’équipe de test, donc 10 personnes (et pas pour Grégoire d’après ce que j’ai cru comprendre…) Autant te dire que pour 10 fois moins cher, on devient capables de maintenir les tests de Dynoz ! Super non ? Tiens, si tu veux des chiffres, je me souviens de comment on calcule le ROI.
(Bénéfices – Coûts récurrents) / Coût initial * 100
Soit : (50 000 – 0) / 5 000 * 100 = un ROI de 1 000 % !!!
Yves Olanda, QA
PS : Bon, pour être réaliste je pense que vu la complexité de la chose, même après une formation on ne pourra pas bosser aussi rapidement que la boîte de presta, en tous cas pas dès le début. Ce que la boîte fait en 2 jours, on le fera probablement en 3. Mais bon, c’est déjà top !
Aïe aïe aïe ! Bien sûr que c’était trop beau pour être vrai, et plus de la moitié d’entre vous ont bien flairé le piège.
Le coût de formation fournie par la société de prestation est bel et bien 10 fois inférieur au coût de la prestation. Toutefois, cette analyse est superficielle et doit être complétée.
2 éléments majeurs sont omis par Yves :
- Les coûts d’opportunité : pendant que l’équipe de test sera formée et maintiendra ces automates, elle ne pourra rien faire d’autre. Ce sont 150 jours-personne internes qui seront ainsi bloqués pour la maintenance, et 100 jours-personne (10 jours pour 10 personnes) qui seront bloqués pour la formation, soit 250 jours qui seront consacrés à ce sujet, et pas à autre chose.
(150 jours sont prévus pour la maintenance et non 100, car 2 jours pour la société de prestation aguerrie = 3 jours pour le personnel interne selon l’estimation d’Yves) - Le personnel interne a aussi un coût. Il faut mettre en balance les 500 € / jour-personne de la société de prestation, non pas avec une somme de 0 € / jour-personne pour les internes, mais comme l’indique Jacques dans son mail, plutôt 200 €.
Le coût de la prestation est donc de 50 000 €, mais si la formation et la maintenance en interne était choisie à la place, cela pourrait tout de même coûter… 55 000 € !
Ce nombre est calculé ainsi :
- 25 000 € de coût initial
- 5000 € de coût de formation, fournie par la société de prestation
- 10 jours * 10 personnes * 200 € pour la main d’œuvre interne en formation : 20 000 €
- 30 000 € de coût récurrent
- 150 jours * 200 € par personne pour la maintenance = 30 000 €
Selon ce calcul plus réaliste, le ROI de l’internalisation des 100 jours de test est le suivant :
(Bénéfices – Coûts récurrents) / Coût initial * 100
(50 000 – 30 000) / 25 000 * 100, soit… 80 %, bien inférieur aux 1 000 % estimés par Yves.
80 % de ROI, ce n’est bien sûr pas mauvais. Toutefois, choisir ce scénario demanderait tout de même une analyse approfondie.
| Facteurs favorables | Facteurs défavorables |
| L’appli Dynoz va avoir régulièrement besoin de maintenance | L’appli Dynoz risque d’être décommissionnée à moyen terme. |
| Le personnel interne a exprimé son souhait d’être formé sur cette technologie (facteur de motivation) | Le personnel interne considère dans sa majorité que Dynoz et tout son environnement technique sont vieillissants et peu enthousiasmants. On sait déjà que c’est un outil avec une « syntaxe zarbi », propre à cette société de prestation. Prudence… |
| Les décisionnaires déplorent les délais de mobilisation de la société de prestation ; bien souvent, il faut attendre plusieurs semaines avant qu’elle soit disponible | Le personnel interne, même s’il est formé, n’aura pas suffisamment de temps à consacrer à Dynoz. Dans sa majorité, il apprécie de pouvoir s’appuyer sur des compétences externes qui permettent d’alléger sa charge de travail. |
| Les équipes internes connaissent bien le périmètre fonctionnel de Dynoz. | Les équipes internes ne connaissent pas du tout le périmètre fonctionnel de Dynoz, et la documentation est à ce jour lacunaire. Des coûts supplémentaires en transfert de connaissances et en documentation seraient nécessaires. |
| Les équipes de test sont relativement stables dans le temps et partagent efficacement les connaissances. | Les personnes restent en moyenne 2 ou 3 ans dans l’entreprise, ce qui nécessiterait d’autres formations régulièrement. |
Vos réponses
Une personne anonyme suppose qu’Yves n’a pas bien compris les modalités des coûts de formation : « La formation c’est 10 jours à 500 euros par jour pour 10 personnes. 10 x 500 x 10 ça fait 50 000 euros, pas 5 000. Il a oublié un zéro quelque part. » Il est possible en effet qu’Yves ait mal compris la réponse de la société de prestation, à la faveur sans doute d’un biais de confirmation !
_____________________________
Merci à toutes les personnes qui ont participé au jeu ! Souhaitez-vous qu’on en prépare un autre sur une thématique différente ?