Nos développeurs sont sur les starting blocks, les doigts sur leurs claviers, les yeux rivés sur vous ! Vous donnez le top du départ. Prêt·e·s ? … Partez !
Développement
Collaborer
Contrairement au mythe, les développeur·se·s travaillent rarement seul·e·s au fond d’une cave, entourés de cadavres de bières, de pizza froide et de café. Ils travaillent en équipe et sont donc amenés à collaborer les uns avec les autres. Hé oui ! Un développeur est aussi un animal social. ;-)
Mais comment collaborer quand on travaille sur un projet partagé par toute une équipe ? Et comment le développeur peut-il être certain que le code sur lequel il travaille est bien la dernière version disponible ?
Finalement, nous avons tous connu ce problème. Nous accumulons les versions de différents documents (“Mémoire v1.doc, Mémoire v1 def.doc, Mémoire def def.doc” etc) pour garder une copie de l’ancien, en attendant que notre document soit corrigé ou tout simplement “au cas où”.
Les développeurs étant également des êtres pragmatiques, ils ont inventé Git, un outil de gestion de versions. Concrètement, Git vous permet de revenir à une version précédente si vous le souhaitez ainsi que de voir l’auteur de toute modification. Très pratique quand on travaille en équipe !
Le miroir de la réalité
Quand un développeur a terminé de développer une fonctionnalité il l’envoie sur un serveur de test (parfois appelé “staging” ou “préprod” pour les intimes). Il s’agit d’un environnement qui ressemble à 100% à celui de production.
Wait, déjà c’est quoi un serveur ?
Un serveur est simplement un ordinateur sur lequel un logiciel a été installé. Ce logiciel permet aux langages de programmation de fonctionner. Vous pouvez "transformer" votre propre ordinateur en serveur ou bien vous connecter à un autre via internet. C'est ainsi que fonctionnent les hébergeurs !
Utiliser un serveur de pré-production vous permet de tester que les fonctionnalités que vous avez développées ne buggent pas dans les conditions réelles d’utilisation. En effet, la configuration peut être très différente entre l’ordinateur d’un développeur et celui sur lequel se connectent nos utilisateurs.
Quand toutes les fonctionnalités ont été implémentées dans le serveur de préproduction, il est temps de tester que le code fonctionne !
Recette
La période de recette peut être assez longue pour les projet fonctionnant en séquentiel. En effet, il faut tester toutes les fonctionnalités dans les moindres détails ! Elles doivent correspondre point pour point aux spécifications fonctionnelles et techniques qui ont été signées précédemment.
Les acteurs qui interviennent pendant cette étape s’appellent les responsables qualité (ou QA managers). Ils sont responsables de la vérification.
Contrairement à ce que nous pourrions imaginer, la majorité des tests est automatique, effectuée par un robot 🤖 (mais codée par un humain !). Il existe deux sortes de tests : les tests unitaires et les tests d’intégration.
Tests unitaires
Les tests unitaires vérifient qu’une petite partie d’une fonctionnalité est bien implémentée. Par exemple, nous pouvons vérifier qu’un numéro de téléphone sous la forme “0000000000” sera bien refusé par le système et ne sera pas enregistré dans la base de données. Vous pouvez lire un exemple de test unitaire dans cet article : Unit Testing in Ruby.
Tests d’intégration
Les tests d’intégration ont pour but de vérifier que les fonctionnalités sont bien interconnectées et que l’ensemble est homogène. Chaque fonctionnalité ayant probablement été développée par un développeur différent, il est nécessaire de vérifier qu’elles communiquent bien entre elles et qu’il n’y a pas de bug.
Si notre programme s’insère dans un autre système, les tests d’intégration vont également vérifier que l’un et l’autre s’agencent harmonieusement et que notre programme ne crée pas de troubles dans l’ancien système.
Prenons un exemple. Imaginons que nous ajoutons une boutique sur le site de la NASA. C’est une révolution : vous pouvez désormais réserver un aller pour la Lune (personne ne parle du retour…) et payer en ligne.
Nous commençons par tester que l’utilisateur ne peut pas rentrer un faux numéro de carte bleue. Il s’agit d’un test unitaire.
Puis nous vérifions que la fonctionnalité “ajouter un produit dans le panier” interagit bien avec la fonctionnalité “payer via Paypal”. Nous faisons cela via les tests fonctionnels.
Enfin, nous vérifions que notre nouvelle boutique est bien intégrée au site officiel et qu’elle ne génère pas de nouveaux bugs. Ceci est également fait via des tests fonctionnels.
Lire un exemple de tests d’intégration (en Ruby).
Tests manuels
Certaines équipes font également des tests manuels, c’est-à-dire qu’ils vont exécuter eux-mêmes les scénarios utilisateurs. Par exemple, la personne effectuant la recette va ajouter “voyage sur la lune” au panier, cliquer sur ce dernier, payer en carte bancaire et quitter le site.
Ces tests sont assez rares néanmoins car ils prennent beaucoup de temps.
Livraison
Quand tous les tests sont positifs, on livre le projet au client. C’est ensuite à lui de décider s’il met en ligne lui-même ou s’il fait appel à la même équipe.
Cette partie du projet devrait être la plus valorisante. Pourtant, c’est assez rarement le cas lorsque notre projet s’organise autour de méthodologies séquentielles. En effet, notre client découvre le rendu à la toute fin et souvent après une longue période de temps. Ses idées ont pu changer, il ne pensait pas que ce qu’il avait imaginé ressemblerait à ça dans la vraie vie du monde véritable.
De plus, les fonctionnalités peuvent être plus ou moins bien écrites et, par conséquent, applicables. Suivre les spécifications à la lettre peut créer des programmes bancales, d’autant plus si aucune personne technique n’a été consultée.
Alors comment intégrer les retours du client au fur et à mesure ? Vous connaissez déjà la réponse. Hé oui, souhaitons la bienvenue aux méthodologies agiles !
-------
Crédits illustrations : icône monde créée par Korawan M. et mise à disposition sur The Noun Project.
