L’automatisation, une tâche pour les testeurs ou pour les développeurs ?

L’automatisation, une tâche pour les testeurs ou pour les développeurs ?

Beaucoup d’entreprises n’ont pas d’équipe de test ou d’assurance qualité, et dans un environnement DevOps, la plupart d’entre elles pensent à ajouter un nouveau rôle pour démarrer un nouveau projet d’automatisation de test. Peut-être que vous avez déjà des tests unitaires, des tests d’intégration ou des tests de service qui sont exécutés sur votre CI, et ceux-ci ont certainement été écrits par des développeurs.

Mais quelle est la stratégie derrière cela ? Ces tests sont-ils vraiment pertinents et utiles ? Est-ce qu’ils passent tout le temps et ne sont pas ignorés ? Avez-vous besoin d’une nouvelle équipe pour gérer ces activités de test ou l’équipe actuelle sans testeur dédié est-elle suffisante ? Et enfin quels sont tous ces rôles contenant « Developers in Test » dans le nom ?

L’automatisation est un projet

Premièrement, j’aime à rappeler une chose : l’automatisation des test est un projet de développement logiciel. Et je pense que je vais l’écrire deux fois, en gras, c’est encore mieux : L’automation des tests est un projet de développement logiciel.

Disons que vous travaillez sur le développement d’un e-shop, d’abord uniquement disponible avec un navigateur desktop. Si vous voulez fournir à vos clients une nouvelle application Android et iOS, allez-vous ajouter un ticket dans Jira (ou autre) « Build the Android/iOS app » et l’assigner à l’un des développeurs de l’application Angular desktop ? Probablement pas ? Au moins, vous allez créer un nouveau projet, créer une nouvelle équipe et chercher quelqu’un ayant les compétences nécessaires pour construire une application pour smartphone.

Pareil pour l’automatisation des tests, l’automatisation est un vrai nouveau projet et doit être traité comme tel. Ne vous attendez pas à ce qu’un stagiaire à mi-temps le fasse ! Ne vous attendez pas à ce que vos développeurs le fassent pendant une semaine d’atelier ! Ne vous attendez pas à ce que vos développeurs le construisent pendant 2 sprints en espérant que la batterie de test s’enrichisse d’elle-même à l’avenir, et au bon vouloir des développeurs.

Un projet a besoin d’une stratégie.

Je ne peux pas vous donner LA stratégie qui convient à votre environnement. Je ne peux vous donner qu’une liste de questions auxquelles vous devez répondre, ensuite vous pourrez commencer à réfléchir à une stratégie cohérente:

  • Pourquoi devez-vous automatiser ?
  • Quel est l’objectif?
    • Libérer le produit plus rapidement sans le goulot d’étranglement des tests manuels ?
    • Laisser les autres testeurs de l’équipe se concentrer sur les tests exploratoires ?
  • En avez-vous vraiment besoin ? Pourquoi ne pas le tester « manuellement » ?
  • Avez-vous calculé le retour sur investissement ?
  • Quels niveaux peuvent être testés automatiquement (API, Services, UI) ?
  • Comment les tests seront exécutés ? Localement, dans les jobs CI du produit, ou mieux dans un job CI séparé ?
  • Pouvez-vous être aidé par de l’AI ?
  • Quelles données de test sont disponibles et peuvent être utilisées ?
  • Quel environnement vais-je pouvoir utiliser ? Est-il possible d’avoir un véritable environnement d’essai isolé ?

Si vous voulez en savoir plus, je vous suggère de voir ce cours disponible sur TAU : Setting a Foundation for Successful Test Automation par Angie Jones.

Un projet d’automatisation a besoin d’experts.

L’Automatisation a besoin d’une équipe dédiée. « Si c’est un vrai projet avec une stratégie, j’ai probablement besoin d’une équipe et de gens dans cette équipe, non ? ». Oui, vous avez raison, vous avez besoin de ressources. Mais qui ?

Les développeurs savent coder, mais ne sont pas les meilleurs testeurs. Ils vont donc simplement essayer d’automatiser tout ce qu’ils pourront automatiser, et commenceront probablement par les choses simples et inutiles. Vous pourriez essayer de leur apprendre l’esprit testeur, mais je ne suis pas sûr qu’ils auront la patience et assez d’intérêt pour le sujet.

Les testeurs savent comment tester, mais ne sont pas les meilleurs développeurs. Vous pouvez les former pour les aider à devenir un testeur capable de coder les tests. Si vous pouvez attendre plusieurs semaines avec des développeurs pour les former, c’est une bonne idée. Mais avez-vous vraiment les moyens de faire ça ?

Bien sûr, il va sans dire que les managers, les concepteurs d’UX, les responsables Support Client (Customer Success) ou les coachs agiles ne seront pas non plus les candidats parfaits.

Vous êtes perdu ?

Plusieurs options s’offrent à vous:

  1. Embaucher un spécialiste de l’automatisation, qui est un très bon développeur, mais qui a aussi l’esprit testeur et sera capable de construire une stratégie parfaite afin de ne rédiger que des tests pertinents et utiles au bon niveau (Intégration, API, UI). Malheureusement, ils ne sont pas nombreux et probablement déjà très occupés,
  2. Utiliser un outil sans code qui sera utilisé par vos testeurs. Certains d’entre eux sont très faciles à apprendre, et avec un peu d’aide de développeurs pour des cas très spécifiques, vous devriez être capables d’automatiser les fonctionnalités principales de votre produit. Ces outils sont par contre très coûteux, et nécessiteront des efforts de maintenance importants,
  3. Construire une équipe de développeurs et de testeurs. Parce qu’une bonne stratégie sera probablement d’écrire différents types de tests : tests unitaires, tests d’intégrations, tests API/Service, tests d’interface utilisateur avec ou sans contrôle visuel (rappelez-vous la Pyramide Cohn des tests). Pour cela, des compétences en test et en développement sont nécessaires.

Je pense personnellement que, dans la plupart des cas, si vous ne pouvez pas trouver un expert en automatisation, la meilleure solution sera la troisième au moins pour démarrer le projet. Plus tard, vous aurez peut-être quelqu’un capable de le gérer seul, peut-être un ancien développeur ou un testeur.

Avez-vous besoin d’un STE, STAE, SDET ou d’un SET ?

Voilà beaucoup d’acronymes. Sont-ils utilisés pour le même rôle ou non ?

S signifie Software, D pour Developer ou Design, T pour Testing et E pour Engineer. Vous pouvez ensuite créer votre propre acronyme. Microsoft a été le premier à introduire « Software Developer Engineer in Test » (SDET) en 2005. Google a adopté « Software Engineer in Test » (SET) pour le même rôle. Mais vous pouvez aussi trouver STAE ou STE.

Un autre rôle que vous pouvez trouver est « Software Design Engineer in Test » (c’est un autre SDET) qui est très technique. Les tâches consistent à vérifier l’architecture du logiciel, à tester et à suggérer des améliorations sur les composants et les interfaces. Le SDET (avec un D pour Design) peut aussi écrire des scripts de test pour atteindre ses objectifs, alors il est aussi un SDET (avec un D pour Developer). Les STAE (Software Test Automation Engineers) sont souvent moins techniques et nécessitent moins de compétences en programmation car ils se concentrent principalement sur l’automatisation à l’aide d’outils tels que QTP ou TestComplete.

Alors selon votre contexte, de qui avez-vous besoin ?

Conclusion

C’est à vous de trouver la bonne stratégie et d’être aidé par les bonnes personnes. N’ayez pas honte d’essayer et d’itérer. N’ayez pas peur de dire qu’une bonne automatisation n’est pas facile. Cela peut être facile, mais celle qui a beaucoup de valeur, qui n’échoue que lorsqu’il y a un vrai problème, qui est facile à déboguer, qui est rapide, qui donne de bons rapports est très difficile à atteindre. Et n’oubliez pas que vous aurez toujours besoin de tests non automatisés et exploratoires pour combler les lacunes.

Bonne chance, et n’hésitez pas à parler de votre contexte et à donner votre avis.

Laisser un commentaire

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

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.