Notre robot ArchiSnapper qui est-il, que fait-il

Notre robot ArchiSnapper : qui est-il, que fait-il ?

Plusieurs fois par semaine, un robot utilise ArchiSnapper.

Son rôle est de cliquer sur presque tous les boutons de l’application.

Curieusement, il (restons sur l’hypothèse que le robot est un garçon !) suit à chaque fois la même série de clics.

Voici les étapes suivies par le robot :

  • Il fait un rapport de chantier ou de réception des travaux avec quelques photos, quelques observations et quelques personnes assignées sur iPad.
  • Il synchronise ce rapport dans le cloud
  • Il vérifie si le rapport se trouve bien dans son compte en ligne.
  • Si oui, il affiche une puce verte sur un écran, et continue…
  • Il le clone dans son iPad.
  • Il synchronise ce rapport cloné.
  • Il vérifie, dans son compte en ligne, s’il existe bien deux rapports identiques : le rapport original et le rapport cloné.
  • Il met une puce verte si c’est le cas, et continue.
  • … (et il continue ainsi pendant presque 2 heures !)

Imaginez un peu !

Il doit avoir trop de temps, ou ne sait pas quoi faire de sa vie…

Regardons le robot en action, mettant des puces vertes :

Quelle est la raison de cet étrange comportement ?

Quelques milliers d’utilisateurs se servent de nos applications ArchiSnapper et SafetySnapper, presque quotidiennement ou au moins une fois par semaine.

Nos applications fonctionnent avec des données d’entreprise, et génèrent des rapports de réception des travaux, des rapports de chantier ou des rapports de sécurité – qui ont parfois une valeur juridique.

Notre application est en développement constant depuis 2013 : chaque semaine, de nouvelles fonctionnalités sont ajoutées, affinées et adaptées.

Prenons l’exemple d’une nouvelle fonctionnalité permettant de localiser un élément sur un plan PDF (cette fonctionnalité existe déjà dans notre application, ce n’est qu’un exemple).

Cette fonctionnalité interfère avec un grand nombre de recoins, d’écrans et de boutons dans notre application, ainsi que dans le logiciel en ligne :

  • de nouveaux chantiers à ajouter à la base de données
  • de nouveaux boutons dans les différents écrans de l’application
  • une nouvelle logique, qui doit comprendre les fonctionnements et interactions
  • de nouvelles images dans le rapport de chantier (format PDF), soit la capture d’écran PDF de l’observation localisée
  • … et la liste continue.

Pour mettre au point cette fonctionnalité, notre équipe de développeurs doit ainsi apporter des modifications à presque toutes les parties du code existant.

Une seule petite fonctionnalité peut entraîner la modification de 200 lignes de code dans 20 fichiers différents, afin de le faire passer en production. Une modification plus importante ou une nouvelle fonctionnalité peut impacter jusqu’à 5000 lignes de code dans 100 fichiers différents.

En plus de toutes les modifications de code, il y a aussi beaucoup de chemins possibles – correspondant à différentes façons d’utiliser notre application.

Certains utilisateurs passent d’abord à l’écran A, puis à l’écran B, puis à l’écran C. D’autres sautent B et passent de A à C. Certains utilisateurs ouvrent d’abord l’écran C, puis repassent à A. Certains utilisent notre application sur iPad, d’autres sur iPhone. Certains prennent des photos, d’autres non.

Vous comprenez certainement la complexité du processus.

Nous avons des centaines d’écrans, imaginez seulement le nombre de chemins possibles ! Il existe des milliers de façons de naviguer à travers notre application.

Nous devons nous assurer qu’après avoir changé 5 ou 5000 lignes de code, tous ces « chemins d’accès » fonctionnent toujours, sans bug, sur tous les appareils possibles, dans toutes les langues disponibles de l’application.

Honnêtement : qui dispose de suffisamment de temps, d’énergie, de concentration et d’attention nécessaires pour tester des milliers de chemins de clics possibles dans notre application, sur différents appareils, après quelques changements de code ?

Qui ne risque pas de faire des erreurs humaines, d’être en retard à cause des embouteillages, le tout dans le plus grand professionnalisme sans perdre de temps à bavarder avec ses collègues ?

Bingo… notre robot.

Pour les geeks : techniquement parlant, ce n’est pas un robot mais en fait un autre logiciel, qui est configuré et écrit de manière à tester notre logiciel principal de façon automatique. Autrement appelé développement piloté par les tests (Test Driven Development – TDD).

Nos développeurs écrivent et maintiennent également le logiciel principal (notre application) ainsi que les logiciels de test environnants. 20 à 50 % de leur temps est consacré à l’écriture du logiciel qui effectue le test : notre robot.

Semaine après semaine, mois après mois, année après année, ce robot fera tout ce que nous lui demandons de faire : des milliers de clics, en parcourant toute notre application – après quoi il nous présentera un rapport détaillant les résultats du parcours.

Le code énigmatique ci-dessous :

est en fait une façon de la part du robot pour nous dire qu’il a testé l’application pendant 73 minutes, qu’il a vérifié 4542 éléments, et qu’aucun problème n’a été détecté.

Le détail qui fait tout ? Si nous commandons à ce robot de tester l’application sur Android, il le fera également sur iOS. iPhone ? Oui Monsieur ! iPad ? À vos ordres !

Notre sympathique robot peut nous rassurer en nous indiquant que tout fonctionne, sur tout appareil, sur tous les chemins et combinaisons de clics possibles de notre application.

Robot, on t’♥ tant 🙂

OK très bien, mais en quoi ce robot me concerne-t-il ?

Je vous entends penser : « Bien joli tout ça, mais en quoi cette histoire de robot me regarde-t-elle Pieter ? »

Nos développeurs passent entre 20 et 50 % de leur temps à écrire le logiciel test du robot : la formation de ce robot prend donc du temps et du travail. En revanche… c’est encore bien plus laborieux de s’en passer : si un bug se glisse dans notre application, entraînant une possible perte de données pour nos clients, c’est extrêmement nocif pour la qualité que nous proposons.

Un simple oubli de point ou virgule dans une requête de base de données dans le code peut entraîner une perte de données.

Parfois, cette perte veut dire que 20 jours entiers de rédaction de rapport de réception des travaux sont perdus, volatilisés. L’horreur !

« perte de données » multiplié par « 100 utilisateurs » = un nombre important de plaintes, voire pire : un procès.

Notre robot minimise ce risque. Pour vous, comme pour nous.

Il vous assure un logiciel stable et durable. Un logiciel qui minimise le risque de crash, et donc de perte de données (… des données si souvent cruciales !).

Si vous choisissez un logiciel ou une application pour, par exemple, des rapports de chantier, de réceptions des travaux, une collaboration sur un projet de construction (tout ce qui a tôt ou tard une valeur juridique ou commerciale), vous souhaitez certainement avoir un logiciel qui fonctionne et qui dure. Notre robot nous permet de vous le proposer !

Au travail 🙂 et merci pour tout, robot !

Au travail 🙂 et merci pour tout, robot !

(Visited 2 times, 1 visits today)