Ce que les tests pour non-développeurs détectent et que la revue ne peut pas voir
Le mensonge
Un message de succès alors que rien n'a été enregistré. Lire le code montre l'intention, pas le résultat.
La confusion
Un parcours qui fonctionne techniquement et que personne n'arrive à mener à bout. Seule une personne le remarque.
Le présupposé
Fonctionne pour le compte qui l'a créé, échoue pour tous les autres.
Invisible pour celui ou celle qui détient ce premier compte.
Quatre vérifications qui ne demandent aucun code
Faites l'action, puis rechargez la page. Cela sépare « l'écran s'est mis à jour » de « c'est bien enregistré ». La vérification la plus rentable qui soit.
Refaites-le avec un autre compte. Un deuxième compte révèle immédiatement les présupposés sur les permissions.
Faites-le mal exprès. Envoyez une donnée invalide et vérifiez que l'application le signale clairement au lieu d'échouer en silence.
Faites-le sans rien. Les états vides sont construits en dernier et testés le moins souvent.
Rédiger un rapport qui débouche sur un correctif
Trois phrases, sans le moindre vocabulaire technique. Ce que vous avez fait, dans l'ordre. Ce que vous attendiez. Ce qui s'est passé à la place. « J'ai rempli le formulaire et cliqué sur Enregistrer, je m'attendais à voir l'élément dans la liste, la liste est restée vide jusqu'à ce que je recharge la page » désigne directement le défaut et ne demande aucune interprétation.
C'est aussi une vérification. Écrite une fois, elle peut s'exécuter après chaque modification future.
Que faire quand personne ne donne suite à votre rapport
La frustration la plus courante dans ce rôle, c'est de trouver un vrai problème et de le voir rester en plan. En général, ce n'est pas que personne ne vous croit : c'est que le rapport ne contient pas assez d'éléments pour que quelqu'un puisse commencer.
Trois choses comblent ce manque. Précisez quel compte et quel environnement, car un bug qui ne touche qu'un seul type d'utilisateur est un bug différent. Précisez s'il survient à chaque fois ou seulement parfois, car un défaut intermittent et un défaut systématique ont des causes complètement différentes et le savoir fait gagner une heure. Et dites explicitement ce que vous attendiez, car une fois sur deux le désaccord porte en réalité sur le besoin plutôt que sur le code, et mieux vaut s'en apercevoir tôt.
Rien de tout cela n'exige de vocabulaire technique. C'est ce qui sépare un rapport que l'on trie d'un rapport que l'on corrige.
Faire en sorte que vos vérifications vous survivent
La limite des tests pour non-développeurs n'a jamais été la compétence : c'est qu'une personne ne peut revérifier qu'un nombre limité de choses. Décrire le parcours en langage courant et le faire exécuter automatiquement fait sauter ce plafond, sans obliger qui que ce soit à apprendre un framework.
Rien de tout cela ne nécessite un terminal. Créez un projet dans le tableau de bord TestSprite, décrivez la vérification en langage courant et pointez-la vers votre application. Les développeurs de votre équipe peuvent piloter exactement la même chose en ligne de commande s'ils le préfèrent, ce qui se trouve dans le dépôt CLI.
Deux voies possibles, et le choix dépend surtout de qui gère le pipeline. Connecter la GitHub App depuis le tableau de bord ne demande aucune modification de votre dépôt, car elle réagit au déploiement que votre build produit déjà. Ajouter une étape GitHub Actions place la vérification dans le dépôt, où elle est relue comme le reste du build.
Comment TestSprite transforme vos vérifications en quelque chose de durable
Vous décrivez un parcours comme vous l'expliqueriez à un collègue, et TestSprite l'exécute sur l'application. Pas de code de test, pas de framework, pas de terminal. Créez un projet dans le tableau de bord, pointez-le vers votre produit et écrivez les trois phrases : ce que vous avez fait, ce que vous attendiez, ce qui doit être vrai ensuite.
À partir de là, elle s'exécute à chaque modification. Les quatre vérifications de cette page cessent d'être quelque chose que vous répétez à la main pour devenir une trace écrite qui continue de travailler pendant que vous faites autre chose.
L'intérêt est précis : votre connaissance de ce qui devrait se passer ne vit plus uniquement dans votre tête, et c'est ce qui rend votre contribution visible par tous les autres et durable une fois que vous êtes passé à autre chose.
Dois-je apprendre à coder ?
Non. Décrivez le parcours en langage courant. Votre valeur ajoutée, c'est de savoir ce qui devrait se passer, et ce n'est pas une compétence de développeur.
Comment savoir si ma vérification est réelle ?
Cassez délibérément la fonctionnalité et confirmez que la vérification échoue. Une minute, et c'est la seule preuve qu'elle est reliée à quelque chose.
Et si les développeurs balaient mon rapport ?
Utilisez les trois phrases. Une séquence précise assortie d'une attente est bien plus difficile à écarter qu'un « ça ne marche pas ».
Faut-il tester avant ou après une modification ?
Les deux. La vérification qui existait avant vous dit si la modification a cassé quelque chose, et c'est le sens le plus utile.
S'il ne fallait vérifier qu'une seule chose, laquelle ?
Faites une action, puis rechargez la page. C'est là que le plus de produits échouent, et cela prend cinq secondes.
Ne pas lire le code est ici un avantage.
Les tests logiciels pour non-développeurs détectent le mensonge, la confusion et le présupposé, trois choses que la revue de code est structurellement incapable de voir. Rechargez la page, utilisez un deuxième compte, faites-le mal, faites-le à vide, et notez vos vérifications par écrit pour qu'elles survivent à la session.