Comment pousser une démarche qualité quand les enjeux livraisons sont forts ?
L'une des grandes préoccupations d'un client c'est la date de livraison.
De son point de vue, plus tôt son produit est disponible à ses futurs clients mieux c'est.
Hors comment l'influencer & faire comprendre que faire vite & bien n'est pas si facile.
Les coûts cachés
Posons un contexte concret
Les équipes
En admettant des équipes comme suit :
- Développement
- Produit
- SAV
Le cycle de production
Produit -> dévelopement -> SAV (formation)
La fonctionnalité a coûté 3 points, disons d'attention (1 point / équipe)
Cas nominal
- Dans le cas d'une stratégie livraison, l'équipe développe (avec tests manuels mais sans plus).
- Au mieux c'est testé (périmètre restreint à une fonctionnalité) par l'équipe produit
- Si c'est OK, c'est en production
Si tout se passe bien on passe au sujet suivant.
Sinon…
- Les utilisateurs rencontrent des problèmes
- Seul un petit pourcentage remonte le problème
- Le problème est réceptionné, on décide d'agir
On communique et priorise le bug :
SAV -> produit (priorisation) -> dévelopement
On reprend le cycle cité précédemment :
Produit -> dévelopement -> SAV (information)
L'addition
Ici on se rend compte que la fonctionnalité, coûte entre 7 à 9 points :
- Les 3 points initiaux de développement produit
- 3 points de remonter d'informations
- 3 points de livraison des corrections
Le coût réel de la fonctionnalité coûte entre 2 à 3 fois plus en prenant des risques
Spécification - l'ambiguïté
L'équipe de développement ne reproduit pas
- Il manque d'information pour reproduire le bug
- Aller & retours pour obtenir les informations nécessaires
- Il a toutes les informations, mais l'attendu n'est pas le même pour lui et les autres
Les limites d'une fonctionnalité peuvent être implicites & ou ambiguës
Avec une stratégie se concentrant sur la livraison, nous allons chercher des raccourcis à chaque étape, dont celle de la spécification. Une situation qui n'aide pas à fournir les détails précieux de la fonctionnalité.
Le demandeur peut jouer légitiment ou pas avec ce flou.
"Je ne l'ai pas spécifié mais c'est évident"
Démarche qualité produit
Mettre en place des garde-fous pour éviter ce triplement de coût et surtout une frustration utilisateur.
Le surcoût est visible mais ne garantis pas un produit infaillible
Si il y a tout de même un bug, c'est la remise en question saine de la chaîne de production & l'amélioration continue du processus qualité qui limitera encore plus les risques dans le futur. C'est une opportunité !
Le surcoût qualité peut être frustrant pour le demandeur, qui voit ses livraisons aller moins vite.
C'est là un cas de conscience : Sommes-nous dans la délégation ou dans l'instrumentalisation ?
Pyramide des tests
T.U
Les tests unitaires sont cruciaux, on pense petit, on teste petit.
Nous avons donc de petites briques de lego, qui font bien leur travail et sont bien testées dans leur propre limite.
Rien ne m'empêche de provoquer un résultat inattendu en faisant une mauvaise association de ces briques.
C'est là que les tests d'intégration, de bout en bout complètent les vérifications.
Autres tests en renfort
- La base de cette pyramide c'est incontestablement les T.U en grande quantité.
- Plus les tests sont complexes & moins ils seront nombreux.
Avantage & inconvénient - T.U
Avantage : ils offrent une fine granularité sur le problème
Inconvénient : ils ne donnent que peu d'informations sur le fonctionnel impacté
Avantage & inconvénient - T.I
Les tests d'intégrations (qui impliquent plusieurs briques de codes : test de bout en bout d'une API) ont les caractéristiques inverses
Avantage : On connaît précisément le scénario utilisateur défaillant
Inconvénient : Granularité trop grossière pour mettre le doigt précisément sur le problème
Le propos c'est qu'ils se complètent
Équipe QA dédiée
J'ai pu travailler avec des équipes Assurance Qualité dédiées.
C'est un filet de sécurité confortable.
Avantages
- Ils n'oublieront pas de tester
- Ils vont trouver des scénarios vicieux / créatifs, qu'un.e développeur.se sera peut être fatigué de tester
- Cette équipe ne développe pas le produit, il n'y a pas de conflit d'intérêts à trouver des régressions
- L'équipe a des plans de tests prêts à être joués à la moindre évolution
Inconvénients
- Une équipe de plus à former sur les nouvelles fonctionnalités ou changements
- Ne développe pas forcément, ce qui peut être limitant dans l'utilisation des outils de tests
- Le verdict de cette équipe peut être challengé : "ça passe, c'est pressé"
Les tests mobiles chez leboncoin
Les tests de bout en bout c'est un peu compliqué
Les tests de bout en bout pour une application web sont déjà une tanné !
Le DOM est-il bien chargé ? La connexion à la bdd est ok ?…
Les problèmes d'initialisation peuvent arriver de partout.
C'est pire sur mobile
Sur mobile c'est encore plus compliqué. Naturellement, ces tests sont d'abord mis en place pour des simulateurs mobiles.
Mais certaines limites sont vite atteintes puisque la complexité logiciel augmente avec ce nouveau logicielle.
Ferme de robots testeurs
L'équipe de R.Louvet s'est penchée sur cette question il y a 6 ans (leboncoin).
Ils ont crée un "banc de test", avec des vrais téléphones (40), pilotés et filmés avec raspberry pour tester l'application.
ANDON
Ma définition : Quand un problème est rencontré, toute la chaîne de production est arrêtée pour le résoudre. Plusieurs métiers donnent leur avis et le processus qualité est amélioré tout de suite pour que ce problème ne revienne pas.
Avantages : Transparence, responsabilité partagée de la fonctionnalité & de la qualité, solidarité
Inconvénients : Risque d'abus d'alerte qui mobilise beaucoup de monde. La gravité n'est pas évidente à documenter et à interpréter