La taverne du testeur

Nés du chaos

Cet article est mon 100ème article. J’ai donc décidé de marquer le coup en sortant des sentiers battus. L’idée de cet article est de parler de la genèse des tests logiciels et de faire un parallèle avec mon parcours professionnel… Comme le titre de cet article l’indique, après une analyse des 2 parcours je suis arrivé à ce résultat : le test, tout comme mon parcours professionnels sont « Nés du chaos ».

Pour cela je vais mettre en parallèle  mon parcours et celui des tests en leur faisant suivre 6 étapes :

nés de chaos

1.      Le chaos :

Moi :

J’ai eu mon Bas S assez facilement ce qui m’a permis d’accéder facilement à une classe préparatoire sur Paris.

Ma première année a été très compliquée (mauvaise en fait) pour de nombreuses raisons, la principale étant que je n’avais pas assez travaillé, particulièrement lors des 3-4 premiers mois.

Je n’ai pas été accepté en seconde année et on m’a clairement dit que je n’avais pas le niveau pour réussir des concours du niveau des ENSI.

Les tests :

C’est le niveau 0 des tests.

Les tests sont une tâche ingrate, faits à la fin des projets juste avant une mise en production et la retardant de temps en temps.

Les tests sont confiés à n’importe qui (dans le sens où on prend la première personne venue). Bref les tests sont faits en mode « héroïque » et ne sont pas considérés comme un métier à part entière. Tout est fait en exploratoire, sur des tests fonctionnels.

Les problèmes critiques, sont alors assez peu fréquents car les applications sont « simples ». Néanmoins avec leur complexification, la multiplication des intervenants et des interfaces on arrive rapidement à des logiciels inutilisables ayant des grosses anomalies qui doivent être alors corrigées avec des mises à jour faites à la va vite… Intégrant de nouvelles anomalies !

2.      Reconstruction :

Moi :

J’ai alors trouvé une prépa à Chartres qui m’a accepté en seconde année.

L’environnement (mais également mon état d’esprit) était plus propice au travail (j’étais en internat) et je gagnais 2 heures de transports par jour, j’étais donc moins fatigué.

La première année (3/2) a été une année pour rattraper mon retard et j’ai donc fait une 5/2 pour atteindre le niveau souhaité, ce qui est arrivé car j’ai été admissible aux ENSI.

ps : Je tiens à préciser que contrairement à beaucoup de personnes j’ai vraiment apprécié mes années de prépa car j’y ai énormément appris. J’étais par contre très fatigué les derniers mois de ma 5/2.

Les tests :

Vient alors la prise de conscience.

L’absence de test coûte trop cher. Il faut donc en faire, et de préférence les planifier. Pour cela certaines personnes sont taguées comme testeur et font du test à plein temps.

On faits des niveaux de tests différents types de tests, on prévoit des couvertures de tests…

Les tests commencent à être organisés en campagne, release… On élabore même des stratégies de test !

3.      Nouveau départ

Moi :

S’ensuit mes 3 ans en école d’ingénieur où il n’y a rien à signaler, à part le fait que j’ai tout de suite su que le développement n’était pas pour moi et que je préférais m’orienter vers du test ou de l’AMOA.

Les tests :

Les tests sont maintenant bien intégrés au cycle en V, tout roule parfaitement.

Les tests et les testeurs gardent encore une mauvaise image. Malgré cela il est hors de question de ne pas tester une application.

4.      Les péripéties s’enchainent

Moi :

Voici donc mon arrivée dans la vie active. Premier emploi, premier échec. Viré pendant ma période d’essai pour motif officieux différent de l’officiel, mais bon c’est le jeu des périodes d’essais.

Je trouve alors un nouveau poste dans une nouvelle SII, j’ai là une super mission, un environnement épanouissant (évidemment quelques erreurs à mon arrivée mais rien de vraiment notable). Problème ? Mon employeur n’est pas mon « client ». Je souhaitais continuer à évoluer ne pas rester avec le syndrome de « La cage dorée » et ai donc démissionné.

S’ensuit un nouvel emploi avec une société de conseil. Une mission avec beaucoup de challenges sur un projet stratégique… Malheureusement, une grosse erreur de communication initiale, une envie de trop bien faire m’a fait partir du mauvais pied avec mon responsable et cela m’a suivi tout au long de ma mission qui s’est finie après 1 an et 4 mois. Suite à cette mission une autre mission sur les tests de régressions, où à part quelques problèmes de… Communication (encore envie de trop bien faire, trop vite !).

Les tests :

Le cycle en V arrive à ses limites. Maintenant on veut plus, plus vite. On s’aperçoit que les corrections d’anomalies coûtent cher, trop cher. Le meilleur moyen de limiter ce coût est de trouver les bugs plus tôt. On veut donc tester plus tôt et on parle de shift left.

Les méthodes incrémentales (souvent agiles) sont de plus en plus plébiscitées. Il est alors nécessaire d’avoir de bonnes campagnes de régression… Et de les exécuter régulièrement. Malheureusement les tests sont souvent manuels et cela prend beaucoup de temps, les testeurs dépriment car ils en on marre de toujours faire la même chose…

L’automatisation devient obligatoire !

L’automatisation est mal implémentée, la maintenance mal évaluée et trop coûteuse. Les tests ne sont plus maintenus. Les bugs reviennent en production car les campagnes de régressions deviennent inutiles.

On travaille alors à faire des tests automatisés scriptés et plus facilement maintenable. Les testeurs ont de plus en plus de mal à écrire ces cas…

En parallèle, il y a une multiplication des « environnement » avec notamment une multiplication des appareils mobiles ou configuration de PC. il devient alors très compliqué de pouvoir tout tester ou simplement reproduire des bugs.

On pense alors à des fermes de mobiles, de la virtualisation, des phases de bêta test…

5.      Après la pluie, le beau temps !

Moi :

Cette étape représente ma situation actuelle.

Je décide alors de partir vers de nouveaux challenges. Je change d’employeur en indiquant clairement que je veux des responsabilités, des perspectives d’avenir. Cette fois-ci j’ai de la chance et tout fonctionne. Il y a évidemment des difficultés mais j’avance et j’apprends plus vite que je n’espérais.

Les tests :

J’estime que l’on en est maintenant à peu près ici.

Le Test a acquis ses lettres de noblesse (et sa majuscule ! :o). On parle de plus en plus de test, on les intègre au plus tôt, on paye même les testeurs autant que les développeurs (étude APEC).

Ce dont j’ai parlé dans la partie précédente est soit mis en place soit en cours et dans tous les cas de plus en plus mature.

Tout semble aller dans le meilleur des mondes, l’horizon est dégagé, le test a de beaux jours devant lui… Enfin, il semblerait.

6.      Le futur !

Moi :

C’est à moi de le construire. Pour qu’il soit radieux je dois continuer à avancer, à ne pas me reposer sur mes lauriers. Je n’ai que 6 ans d’expérience, ma carrière ne fait que commencer !

Les tests :

Tout comme pour moi, même si l’avenir semble tracé, la plus mauvaise chose à faire serait de se reposer sur ses lauriers.

Les problématiques actuelles vont s’amplifier. Le déploiement continu va se généraliser, la diversité des « appareils » va croitre à un niveau que je n’imagine sûrement pas (IOT), l’IA va simplifier le travail comme la robotique l’a fait dans l’industrie…

Toutes ces évolutions vont nécessiter des adaptations. Si le test ne s’adapte pas à l’essor de l’IA, que fera un testeur quand un IA sera capable, d’après une expression de besoin, capable de faire un modèle et de générer les tests automatiquement.

Que fera un testeur quand les algorithmes de BI seront si complexes qu’il ne les comprendra plus et ne sera plus comment les tester ?

Il faudra alors se concentrer sur les points fort du test, se concentrer là où la plusvalue est la plus importante. Par exemple mieux gérer les anomalies pour élaborer de meilleures stratégies. Laisser les « machines » faire et créer des tests automatiser et se concentrer sur des tests exploratoires…

Le futur est particulièrement intéressant. Pour que le test continu à grandir il faudra appréhender et anticiper le futur, ses challenges afin de s’y adapter le mieux possible.

 

Conclusion :

Mon parcours, comme le parcours du test n’est pas rectiligne. Néanmoins, à force de persévérance et d’autocritique nous en sommes arrivés à un point de confort. Un point où tout semble aller.

Néanmoins nous n’en sommes qu’au début de notre carrière. Il faut continuer à évoluer pour ne pas être dépassé. Il faut s’informer, s’adapter et faire de la veille technologique. De plus il ne faut pas oublier que d’autres problèmes surviendront.

Echouer n’est pas un problème. Le vrai problème c’est de ne pas apprendre de ses erreurs et abandonner.

C’est en échouant que l’on apprend et grandit le plus. C’est ce que nous apprend le test à travers sa brève histoire (c’est également grâce aux échecs que le test existe !)

Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !

N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

2 Responses

  1. Hello Marc,
    Super article ! Ton évolution est allée dans le bon sens malgré quelques péripéties 🙂
    Je ne peux que te conseiller d’ajouter un bouton ‘like’ ici sur ton blog, pour que tu puisses voir quel article sont les plus lus et orienter ta ligne éditoriale dans ce sens 🙂 exemple sur l’histoire du test, technique du test ou le vécu des testeurs sur les projets.

    Bon courage 🙂

    1. Bonjour Bibette,
      Merci pour ce retour.
      Par défaut il y a déjà un bouton « J’aime ». J’en conclus qu’il n’est pas assez visible, je vais donc devoir travailler là dessus.
      Encore merci!

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

conférence

[PTC] Les défis de la qualité durable

J’ai eu le plaisir le 9 octobre dernier d’animer avec Stanislas Bobiec une conférence sur la Qualité durable lors de la 5ème édition de la ParisTestConf (PTC). Cette conférence a été enregistrée et est disponible en diffusion sur la chaîne de la PTC: Ci-dessous le support de présentation enrichi de

Lire la suite »
Automatisation

Automatiser ou ne pas automatiser? Telle est la question.

Cet article est fortement inspiré de celui-ci, que j’ai lu grâce au groupe Ministry Of Testing un groupe que je recommande fortement à tous les testeurs qui ne sont pas allergiques à la langue de Shakespeare. Pour ces mêmes personnes voici ma version (librement interprétée, ce n’est pas une traduction)

Lire la suite »