Nous testons notre qualité avec le Test de Joel

Publié le June 20, 2019
Auteur: Alan Pilloud

Le Test de Joel (en anlgais) est un outil de mesure de qualité d'équipe de développement.

Nous sommes un team de développeurs très attaché à la qualité. Voyons donc si Joel Spolsky pense la même chose que nous et passons ce test.

C'est un test simple, il suffit de répondre par oui ou non. Douze "oui" indiquent un score parfait, onze acceptable.

Voici les points à aborder :

  1. Le code source est-il versionné ?
  2. Pouvez-vous faire un Build de votre projet en une étape ?
  3. Faites-vous des Builds journaliers ?
  4. Avez-vous une base de données de bugs ?
  5. Résolvez-vous les bugs avant d'écrire du nouveau code ?
  6. Avez-vous un agenda bien tenu ?
  7. Avez-vous un cahier de spécifications ?
  8. Les dévelopeurs ont-ils un cadre de travail tranquille ?
  9. Possédez-vous les meilleurs outils possibles ?
  10. Avez-vous des testeurs ?
  11. Les nouveaux candidats écrivent-ils du code pendant leur entretiens d'embauche ?
  12. Faites-vous des tests d'utilisabilité avec Mme.M. Tout le mode ?

Allons-y !

Le code source est-il versionné ?

Oui, c'est primordial, absolument obligatoire. Cela nous permet de documenter les modifications apportées à vos projets, les passer en revue et de travailler à plusieurs sur un même projet sans risque de collision.

Pour ceci, nous utilisons Git et hébergons notre code sur Github.

Pouvez-vous faire un Build de votre projet en une étape ?

Oui, c'est beaucoup plus simple dans notre domaine qu'est le développement web que celui du software.

Faire un Build signifie que le code source est préparé pour être prêt à l'emploi et à la livraison.

Nous utilisons de multiples outils. Le Build et le déploiement est automatisé par Buddy.works qui actionne lui-même divers autres outils comme des gestionnaires de dépendences, transpilateurs, etc.

Faites-vous des Builds journaliers ?

Non, mais un peu. Le but selon Joel est de faire tourner le Build une fois par jour de manière automatisée pour voir s'il n'est pas cassé par du nouveau code. Par exemple, les développeurs soumettent leur code à la fin de la journée, le Build tourne la nuit et le lendemain, une alerte est levée s'il y a un problème.

En cours de projet, nous faisons très régulièrement des Builds.

Devrions-nous vraiment faire ceci ? Je pense que oui, surtout que c'est extrêmement simple à faire grâce à Buddy.works

Avez-vous une base de données de bugs ?

Oui.

Nous utilisons Zoho Projects pour organiser les projets et récolter les bugs.

Résolvez-vous les bugs avant d'écrire du nouveau code ?

Oui. C'est un point plus facile pour nous que pour les équipe de dév pour du Software.

Avez-vous un agenda bien tenu ?

Oui, grâce à Zoho Projects, nous planifions des Sprints pour chaque jalons du projet.

Avez-vous un cahier de spécifications ?

Oui, "mais". Les plus gros projets en bénéficient, mais les sites internet "classiques" sont traités autrement. Une spécification sous forme de liste de tâches à réaliser est écrite à partir du design que nous obtenons et suite à une séance de lancement. Plutôt oui quand même.

Les dévelopeurs ont-ils un cadre de travail tranquille ?

Oui, les développeurs doivent absolument être "protégés" des interférences externes. Nous offrons aussi à nos développeurs de bons claviers, des écrans sur support entièrement adaptables, de bonnes chaises, etc.

Possédez-vous les meilleurs outils possibles ?

Oui, certains sont cités dans cet article. Nous les passons en revue de temps en temps pour savoir si certains outils peuvent être remplacés par de meilleurs.

Avez-vous des testeurs ?

Non. Le but ici étant de décharger les développeurs de cette tâche. Or, nous sommes à la fois des développeurs et testeurs.

Devrions-nous vraiment faire ceci ? Peut-être. Je pense que les tests sont moins fatiguants à mener dans notre domaine que dans celui de Joel. Actuellement, je m'en charge personnellement, mais je ne serai pas déçu de déléguer ce travail.

Les nouveaux candidats écrivent-ils du code pendant leur entretiens d'embauche ?

Oui, c'est essentiel. Au niveau du code, j'ai besoin de tester chez le candidat sa rapidité de frappe, la maîtrise de son éditeur de texte, la connaissance de différents languages de programmation, etc.

Faites-vous des tests d'utilisabilité avec Mme.M. Tout le mode ?

Non, "mais". C'est en général nos clients qui s'en chargent. Nous faisons en sorte de pouvoir livrer un produit testable le plus tôt possible pour que ses fonctionnalités soient testées.

Devrions-nous vraiment faire ceci ? Oui, mais à la demande du client. C'est un coût supplémentaire qu'il n'y a pas lieu d'appliquer à chaque projet.

Résultat 9/12, loupé !

Mince alors !

Aurais-je pris la grosse tête en déclarant que nous sommes une équipe de développement axée sur la qualité ?

Bien sûr que non, la qualité est bien là. Toutefois, ce genre de test montre que nous ne sommes jamais à bout d'idée pour être meilleur demain.

C'est un état d'esprit que j'affectionne : devenir une meilleur version de soi-même, une meilleure entreprise. Regarder en arrière et se dire : "Quel chemin parcouru !", c'est l'état d'esprit du développeur, né pour apprendre sans arrêt.