Un logiciel ne casse presque jamais sur le chemin prévu. Il casse sur celui que personne n'avait imaginé : une remise appliquée deux fois parce que la page a été rechargée, un arrondi de TVA qui diffère de deux centimes entre l'écran et le PDF, une adresse collée depuis un tableur avec un retour à la ligne au milieu. Les tests fonctionnels consistent à parcourir ces chemins-là de façon méthodique, à relever ce qui se produit réellement et à le comparer à ce qui avait été promis dans le cahier des charges.
Relever des anomalies isolées ne représente que la moitié du travail. L'autre moitié, c'est un jeu de scénarios qui grossit version après version et se rejoue de plus en plus vite.
Nous lisons les parcours utilisateurs et le cahier des charges avant que la première ligne de code existe. Une règle de remise calculée sur le montant TTC dans un paragraphe et sur le montant HT trois pages plus loin coûte une réunion à ce stade, et une semaine de reprise six mois plus tard.
Des étapes numérotées avec le résultat attendu, tenues dans TestRail, Xray ou un tableur partagé. Vos équipes peuvent les rejouer sans nous, et ils servent ensuite de base aux scripts automatisés.
Quantité à zéro puis à 9 999, date du 29 février, code postal commençant par un zéro, nom composé avec apostrophe, champ rempli de quatre cents caractères. C'est exactement sur ce genre de saisie que les formulaires rendent l'âme.
Nous suivons une commande jusqu'au bout : écriture dans Sage, Cegid ou Pennylane, taux de TVA correct sur la facture, étiquette Colissimo générée, statut de livraison Chronopost remonté dans l'espace client, encaissement Stripe rapproché de la bonne commande.
Une nouveauté ne doit pas abîmer l'existant. Après chaque livraison nous rejouons les scénarios des zones touchées par les développeurs, puis ceux des fonctions qui ont déjà connu un incident.
Étapes, environnement, navigateur et version, jeu de données, résultat obtenu et résultat attendu, déposés directement dans Jira, GitLab ou Azure DevOps. Le développeur n'a aucune question à poser avant de commencer.
Ce qui a été couvert, ce qui ne l'a pas été, les anomalies encore ouvertes et le risque que vous prenez en livrant aujourd'hui plutôt que la semaine suivante.
La première campagne est la plus longue, puisque tout est à écrire. Les suivantes se déroulent nettement plus vite. Nous travaillons à distance sur votre environnement de recette ou sur une préproduction.
Nous apprenons le produit et repérons avec vous les fonctions qui rapportent de l'argent et celles qui peuvent patienter.
Périmètre, navigateurs, terminaux, et surtout ce que nous laissons volontairement de côté. Tout vérifier est impossible : les priorités viennent du risque.
Nous déroulons les scénarios, déclarons les anomalies et vérifions les correctifs dès qu'ils arrivent sur l'environnement de recette.
« On livre » ou « on attend », avec la liste des anomalies ouvertes et des zones restées sans couverture.
« Le panier ne marche pas » n'est pas une anomalie, c'est une humeur. Ce genre de message circule entre trois personnes pendant deux semaines et finit classé « non reproductible ». Nous rédigeons chaque constat pour qu'un développeur le reproduise du premier coup : étapes numérotées, compte de test, jeu de données, navigateur et version, capture ou courte vidéo.
Cela dépend du nombre de parcours et du niveau de couverture souhaité ; le volume d'heures est chiffré dans le plan de test avant le démarrage. Une version allégée existe : nous ne vérifions alors que les parcours principaux et une partie des anomalies arrivera chez vos utilisateurs. C'est parfois un choix raisonnable, à condition qu'il soit assumé et écrit.
Non. Nous commençons par des tests exploratoires : nous découvrons le produit comme le ferait un nouvel arrivant et nous consignons son comportement réel. Vous récupérez au passage une première description fonctionnelle, souvent la seule qui existera jamais.
Sur ceux de vos visiteurs, pas sur une liste standard. Vos statistiques d'audience donnent la répartition réelle : Chrome et Safari sur mobile pour un service grand public, Edge et un parc Windows homogène pour un outil interne. Les modèles que nous n'avons pas sous la main sont couverts par une ferme d'appareils en ligne.
Au temps passé, 95 € HT/h, avec un plafond d'heures inscrit dans le plan de test. Si vous livrez souvent, la recette récurrente entre dans un forfait mensuel Start, Business ou Premium, ce qui rend le budget stable d'un mois sur l'autre.
Décrivez le système et ce qui vous inquiète. Nous préparons un plan de test et une estimation du volume d'heures.
Votre demande nous est parvenue
Vous recevrez une réponse sous un jour ouvré. Si vous signalez une panne qui immobilise vos équipes, elle passe en priorité.
Cette ville ne figure pas dans la liste. Vérifiez l'orthographe ou choisissez la grande ville la plus proche : nous travaillons à distance, cela ne change rien au périmètre de nos prestations.
