Avant de se lancer à corps perdu dans le paramétrage de tests Selenium, encore
faut-il savoir quels tests réalisés, comment les organiser, qui participera à
leur paramétrage... Bref il faut s'organiser un peu.
Choisir un plan de test
Pour s'organiser en matière de projet web, on n'a pas encore trouvé mieux que
des spécifications bien découpées. Prenons un exemple. Pour tester le cycle de
vie d'un article, il faut vérifier qu'il peut être :
- créé
- validé
- publié
- promu
- archivé
- supprimé
- ...
Il faut aussi vérifié quel profil peut réaliser ces actions :
- redacteur
- valideur
- webmasteur
- administrateur
- ...
Évidemment il est impossible de tester l'archivage de l'article avant sa
création. Donc, première bonne pratique : les tests Selenium doivent être
organisés chronologiquement. Ce qui n'est pas si simple quand on a 900 tests
à ordonnancer. Notre expérience montre que les étapes classiques, donc les
scénarios Selenium, sont :
- création des utilisateurs,
- paramétrage,
- création des contenus,
- validation,
- publication,
- listage,
- affichage,
- modification,
- suppression.
A l'intérieur de chaque scénario Selenium, on retrouve également un ordre
logique : on créé d'abord l'administrateur qui créera ensuite les autres
utilisateurs.
Répartir le travail entre les participants
Se pose alors la question de comment répartir la création des tests entre
plusieurs acteurs sans qu'ils interfèrent les uns avec les autres. Notre
expérience montre qu'une répartition en deux temps est nécessaire : d'abord,
chaque participant créé un ou plusieurs types de contenu basic (lien, image,
article, vidéo...) ; puis les participants les plus expérimentés créé les
types de contenus complexes basés sur les types de contenu basic (cas d'un
dossier qui regroupe des articles, liens, vidéos...). Donc, deuxième bonne
pratique : les tests selenium doivent être organisés en fonction de la
complexité structurelle de chaque type de contenu.
Une règle de nommage à toute épreuve
Une fois le découpage réalisé, il faut se mettre d'accord sur la façon de
nommer chaque test de manière à pouvoir automatiser ensuite la création des
scénarios. Si ce travail n'est pas fait, vous devrez renommer à la main 900
fichiers... Bon courage ! Dans notre cas, lors de notre dernière campagne de
test, nous avons opter pour la forme :[id]_[nom_de_la_fonction_a_tester]-[profil].html
Où l'id est à la fois l'id de la fonction (créé lors de la rédaction des
spécifications détaillées) et l'id du test ; le nom de la fonction est
également directement issu des spécifications. A ce stade, on commence à voir
qu'une méthode intégrée (expression du besoin > faisabilité > spécifications >
tests) garantie une grande cohérence tout en réduisant la charge de travail.
Les questions métaphysiques
Quelques questions fondamentales vous aideront à établir votre propre plan de
test :
- Est-ce que je veux tester un processus complet ou plutôt réaliser une série de tests unitaires (au sens fonctionnel) ?
- Est-ce que je veux avoir n versions de chaque test (une version par profil) ou plutôt un test comportant tous les profils ?
Au final et pour résumer, quelle granularité est nécessaire pour que les tests
soient fiables, réalisables dans les contraintes du projets, puis maintenables
? Dans notre cas, nous avons pris le parti de créer n versions de chaque test
(une version par profil) pour avoir plus de souplesse lors de la génération
des scénarios.
Générer les scénarios
L'un des enjeux majeurs du plan de test est la granularité du découpage : les
scénarios doivent pouvoir être créés en fonction du besoin. Pour cela on doit
pouvoir facilement trier les tests en fonction de la fonction (création,
modification...) et du profil (rédacteur, webmaster). Dans notre cas, nous
avons pu créer un générateur de scénario très simple (une grille Excel) parce
que nous disposions de spécifications détaillées bien découpées.
Tout ce travail de découpage et d'ordonnancement est évidemment facilité par
des spécifications détaillées de bonne qualité.
Pour en savoir plus, le site officiel :
