Adopter la méthode allégée lors des essais

L’équipe des médias numériques de TELUS a fait de la méthode de développement agile et allégée son cheval de bataille. Pour ce qui est de mon équipe, qui se charge de l’évaluation du comportement des utilisateurs, cette approche signifie que nous avons rapidement dû approfondir nos connaissances en traduction ou, dans certains cas, revoir nos processus de fond en comble. L’approche allégée est synonyme de produit minimal viable (PMV) et de produit minimal testable (PMT), mais aussi de collaboration à grande échelle, d’établissement des sources d’information et d’essais et erreurs. Or, depuis le début du projet, l’équipe a pour crédo « une équipe, un rêve ». S’avouer rapidement vaincu et se retrousser les manches est devenu non seulement un réflexe, mais aussi une seconde nature pour l’ensemble des membres de l’équipe; inutile de dire à quel point cette expérience s’est avérée enrichissante.

Communication

À l’instar d’autres bonnes équipes, nous avons adopté de saines pratiques et su tirer le maximum de ces méthodologies afin de mettre au point un cadre de travail qui nous convenait. Le rôle des testeurs ne se limite pas aux seuls essais; ils font partie intégrante de l’équipe et continuent de participer activement aux différentes phases du projet. À tout le moins, ils sont conscients de tous les aspects d’un cycle de développement typique. La collaboration et la communication entre les différentes équipes fonctionnelles jouent donc un rôle crucial dans chacune de nos rencontres d’équipe. Nous éliminons les barrières géographiques au moyen de technologies comme Skype, G-chat, Basecamp et Trello, mais aussi de caméras Web et d’appels téléphoniques.

Cycles de développement

Dans le cadre du développement piloté par les tests (TDD), la programmation et les essais auprès des utilisateurs (tant manuels qu’automatisés) surviennent simultanément et de façon itérative, les cycles étant extrêmement rapides. Toutes les activités sont chronométrées et les testeurs ont le pouvoir de décider combien de temps ils accordent à chacun des éléments. En somme, l’équipe adopte une approche fondée sur le risque pour déterminer la nature des essais d’un élément donné au cours d’une même itération. Le risque associé à chacun des éléments est établi conjointement par le responsable du cycle de développement, des demandeurs et de nos clients. Le processus est donc extrêmement transparent, y compris pour les clients.

Comme les testeurs participent à chacun des cycles de développement, ceux-ci ont ainsi une excellente compréhension de la portée du cycle en cours, ce qui leur permet de s’assurer que tous les aspects du projet de développement sont abordés. Ils connaissent également à fond tous les produits et services. De plus, les bogues identifiés lors des essais contribuent souvent à l’amélioration de ces mêmes produits et services, faisant des testeurs de véritables catalyseurs d’innovation. Les connaissances approfondies de l’équipe de testeurs, sans oublier ses nombreuses contributions, en font une ressource irremplaçable.

Pendant que les programmeurs s’attèlent à la tâche, nous en profitons pour planifier notre approche (y compris les modifications découlant des commentaires d’utilisateurs et de leur validation), puis nous débutons dès que les éléments sont prêts à être testés.

Le code est d’abord testé dans un segment dont l’adresse est similaire à la version en production avant de passer successivement par l’environnement de développement et de production. Ce « segment de développement » permet notamment aux programmeurs d’introduire de nouvelles composantes au code existant sans risquer de l’abîmer ou de le rendre inutilisable.

Les bogues, quant à eux, sont communiqués aux programmeurs dès qu’ils sont identifiés, puis testés à nouveau une fois corrigés. Ce cycle imbriqué dans un autre cycle (programmation > essai > correction) peut ainsi se poursuivre au sein du segment de développement. Ensuite, le code est migré vers l’environnement de développement, puis vers la production, jusqu’à ce que nous disposition d’un produit minimal viable (PMV) prêt à être lancé et testé par les utilisateurs. Des tests de régression sont également effectués à chaque étape afin de nous assurer que les modifications n’ont en rien affecté le code préalablement testé.

Correction des bogues

Le fait d’évoluer dans un environnement de développement agile nous permet d’identifier les bogues dès que ceux-ci se manifestent. Les programmeurs accordent de plus en plus de temps à la correction des bogues vers la fin de chacun des cycles de développement, alors qu’ils finissent de publier leur code. En raison de ce surcroît d’attention apporté aux bogues restants, la gestion initiale de ces mêmes bogues se doit d’être très rigoureuse, claire et concise. En conséquence, toutes les activités qui en découlent sont minutieusement planifiées et surveillées afin que les bogues soient classés correctement en fonction de leur sévérité et de la priorité qui doit leur être accordée. Le produit est donc testé deux fois avant même que le premier bogue soit corrigé, ce qui en fait un produit de qualité.

Jusqu’à maintenant, le projet se compare à une véritable ballade en montage russe. De nouveaux concepts sont mis en place afin de remédier aux faiblesses des méthodes et processus actuels. Et parfois, quand tout change autour de nous, on se rend compte que le changement peut s’avérer très stimulant.