À l’université, les critères d’acceptation étaient simples : obtenir la note de passage ou non. Dans votre nouveau travail, en revanche, les critères sont différents. La décomposition du billet devient alors un élément clé pour les comprendre. Le client ou le commanditaire peut avoir des testeurs qui vérifient que le logiciel fonctionne comme prévu. Mais il y a aussi les utilisateurs finaux, dont les critères d’acceptation diffèrent. Ils se concentrent généralement davantage sur leur expérience quotidienne avec le logiciel, telle qu’elle est décrite dans la décomposition du billet.
Chaque ticket sur lequel vous travaillez possède ses propres critères d’acceptation. Ceux-ci sont souvent clarifiés lors de la décomposition du billet. Vous les trouverez dans les spécifications ou les documents d’exigences, souvent utilisés dans les environnements de développement en cascade. Vous les trouverez aussi directement dans la description du ticket, qui reprend en détail cette décomposition du billet.
Ne réfléchissez pas trop à votre solution. Oui, vous avez hâte de montrer vos compétences, mais ce n’est pas le sujet ici. Il s’agit de coder une solution dont la conception s’intègre bien au reste du code et respecte la décomposition du billet. Si vous surdimensionnez votre solution, vous risquez d’introduire involontairement de la dette technique ou des bogues. N’oubliez pas que les solutions à architecture complexe sont optimales lorsque vous les mettez en œuvre pour un problème métier qui le requiert. Ce problème est précisément celui que définit la décomposition du billet.
Soyez fier de votre code. Voyez-le comme un moyen de bâtir votre réputation dans le secteur du développement logiciel. Assurez-vous que le prochain développeur qui travaillera sur votre code puisse le comprendre. Il doit aussi retrouver facilement la décomposition du billet qui a guidé vos choix. Ce n’est plus le moment approprié d’étaler votre intelligence ! Il s’agit, par conséquent, de trouver une solution efficace immédiatement, sans engendrer de dette technique.
Décomposition du billet
« Étant donné » décrit le contexte initial ou la précondition : c’est l’état du système ou de l’utilisateur avant que l’action ne se produise. « Quand » représente l’action que l’utilisateur ou le système effectue : c’est le déclencheur qui active le comportement. « Alors » spécifie le résultat attendu : c’est ce que vous devez vérifier pour confirmer que votre code fonctionne correctement.
Voici un exemple concret : « Étant donné qu’un utilisateur est connecté, Quand il clique sur ‘Supprimer son compte’, Alors une fenêtre de confirmation s’affiche avant toute action irréversible. » Cet exemple vous dit exactement trois choses. L’utilisateur doit être authentifié. Vous testez l’action de suppression de compte. Vous devez afficher une confirmation avant de procéder. Ainsi, il n’y a aucune ambiguïté, car la décomposition du billet est claire.
Demander des clarifications avant de coder est une pratique professionnelle, non un signe de faiblesse. Au contraire, cela démontre que vous prenez le travail au sérieux et que vous voulez éviter les allers-retours inutiles plus tard. Par exemple, si un critère de la décomposition du billet mentionne « validation », demandez précisément : est-ce une validation côté client (front-end), côté serveur (back-end), ou les deux ? Cette simple question peut vous économiser plusieurs heures de refactorisation.
Vous auriez perdu ce temps si vous aviez mal compris la portée du travail. En revanche, les meilleures équipes de développement encouragent ces questions. Elles savent qu’elles conduisent à des solutions plus robustes et à moins de bogues en production.
Ce que vous devez faire avant de commencer à coder
Une erreur courante chez les jeunes développeurs consiste à tester uniquement le chemin heureux — le scénario principal où tout fonctionne parfaitement — et à oublier les cas limites. Qu’arrive-t-il si un champ est vide ? Si l’utilisateur soumet un format invalide ? Si quelqu’un sans autorisation tente d’accéder à cette ressource ? Ces scénarios d’exception ne sont pas des luxes optionnels. Ce sont, en effet, souvent les points où les bogues se cachent et où les utilisateurs rencontrent des problèmes frustrants.
Ces bonnes pratiques — décomposition du billet, critères d’acceptation, communication avec l’équipe — sont au cœur de mon manuscrit D’étudiante à professionnelle TI. Ce guide pratique s’adresse aux nouvelles développeuses et nouveaux développeurs qui veulent réussir leur transition de l’université vers le monde professionnel en TI. Il couvre les habitudes professionnelles, la livraison constante, la communication efficace et la confiance en équipe. La prévente est disponible dès maintenant.
Avant de passer votre travail au QA, testez-le manuellement vous-même. Cliquez sur tous les boutons, essayez de contourner les validations, testez avec différents navigateurs si pertinent. Cette pratique renforce non seulement votre compréhension du code que vous venez d’écrire. Elle fait aussi bonne impression sur votre équipe et montre que vous prenez l’ownership de votre travail.
Une erreur courante chez les jeunes développeurs consiste à tester uniquement le chemin heureux — le scénario principal où tout fonctionne parfaitement — et à oublier les cas limites. Qu’arrive-t-il si un champ est vide ? Si l’utilisateur soumet un format invalide ? Si quelqu’un sans autorisation tente d’accéder à cette ressource ? Ces scénarios d’exception ne sont pas des luxes optionnels. Ce sont souvent les points où les bogues se cachent et où les utilisateurs rencontrent des problèmes.
Ensuite, avant de passer votre travail au QA, testez-le manuellement vous-même. Cliquez sur tous les boutons, essayez de contourner les validations, testez avec différents navigateurs si pertinent. Cette pratique renforce votre compréhension du code que vous venez d’écrire. Elle fait aussi bonne impression sur votre équipe et montre que vous prenez l’ownership de votre travail.
Comment savoir si votre ticket est terminé
Les critères d’acceptation constituent la définition de « terminé ». Avant de marquer votre ticket comme « Done » ou de le passer au QA, examinez chaque critère un par un. Vérifiez que vous l’avez satisfait, conformément à la décomposition du billet.