4 raisons pour lesquelles votre approche de test échoue

Il est une chose que l'on utilise quotidiennement mais à laquelle on n'accorde pas assez d'attention : la méthode de test. Bien qu'il s'agisse d'un document simple et direct, il est souvent négligé et considéré comme une perte de temps.

La valeur ajoutée de context-driven testing

Il est une chose que l'on utilise quotidiennement mais à laquelle on n'accorde pas assez d'attention : la méthode de test. Bien qu'il s'agisse d'un document simple et direct, il est souvent négligé et considéré comme une perte de temps. Pourtant, il peut apporter une réelle valeur ajoutée lorsqu'il est créé en fonction du contexte dans lequel il sera utilisé. Vous trouverez ci-dessous les raisons possibles pour lesquelles votre méthode de test échoue et quel système vous pourrez appliquer, tout en vous basant sur le contexte de l’entreprise et projet, afin d’améliorer le processus.

Votre méthode est fréquemment adaptée

Il est normal d'expérimenter plusieurs méthodes lorsque votre projet vient de démarrer et que, par exemple, vous vous trouvez entre le sprint 0 et 3. Cependant, si vous vous trouvez dans le sprint 5 et que vous cherchez encore une meilleure façon d’effectuer vos tests, il est possible que cela démontre que la stratégie n'est pas compatible avec votre contexte. Parfois même, cela se reflète dans le feedback de l'équipe de projet. Vos collègues aiment savoir et comprendre comment les tests sont effectués. Un système de teste défaillant peut entrainer un sentiment de doute auprès de vos coéquipiers.

💡 Qu'est-ce qu'une bonne méthode?
  La méthode de test doit être compatible aux objectifs généraux du projet. Elle doit également décrire   comment et quand les tests seront effectués. Une méthode de test efficace prend en compte les   risques, les ressources, les compétences, les objectifs, etc. mais avant tout, il s'agit d'un ensemble   de règles établies par des experts en la matière.

Nous avons pour habitude de procédé de cette façon

Certaines entreprises ont déjà un système de test instauré, qui n’est pas des plus récent. Dans ces cas-là, il est facile d'utiliser la fameuse expression qui je le suis sure vous semblera familière : “nous avons toujours fait comme ça”. Le plus souvent, cela signifie que les tests sont effectués de la même manière sans vraiment tenir compte du contexte qui a probablement changer au fil du temps. Bien que certaines technologies et systèmes déjà instauré donnent l’impression que le temps s'est arrêté, aujourd’hui on peux vous assurer que ce n’est pas vrai, car il existe même des outils qui permettent d'automatiser les tests mainframe.

Tout comme un plan de test, une méthode de test est un document vivant qui doit être revu et réadapté de temps en temps. Est-il possible qu’au fil du temps des risques ait été ajoutés ? Ou peut-être vous avez accès à une technologie qui n'existait pas auparavant ? Ce n'est qu'en réexaminant régulièrement ce document et en le réadaptant au contexte actuel de votre entreprise que vous serez en mesure de mettre en œuvre un système de test rentable et de donner une valeur ajoutée à votre projet.

💡 Qu'est-ce qu'un document vivant ?
  Un document vivant est un document qui est continuellement édité et mis à jour. L’actualisation   fournit des informations récentes, précises et faciles à comprendre, car elle est mise à jour dès   qu'elle est dépassée.

La méthode est trop abstraite

Il faut faire la distinction entre une stratégie de test et une méthode de test. Une stratégie de test fournit une description générale du processus de test. La méthode de test, adapte la stratégie de test à un projet. Si la stratégie de test est trop générale ou ne s'applique pas à tous les projets de l'organisation, la méthode de test ne peut pas être adaptée au projet. Dans ce cas, une stratégie de test différente est nécessaire pour ce type de situations spécifiques.

    Examinons ce cas:
    L'entreprise X a une stratégie et une méthode de test solide. Elle est bien documentée et couvrent la     plupart des projets. La plupart de ces projets concernent de nouvelles applications ou de nouvelles     fonctionnalités qui sont ajoutées à des applications déjà existantes. Cependant, il existe également     des projets d'infrastructure qui expose, par exemple, l'adaptation d'une version de JDK qui affecte     plusieurs applications. Ces projets ne peuvent pas suivre le processus traditionnel car les projets     de maintenance doivent généralement être testés uniquement sur la régression. Cette situation     exige un type différent de méthode de test, tel que : La méthode RTS (Regression Test Suite).     S’adapter à ce contexte vous permettra d'avancer plus rapidement.

Illustration cycle tests de regression.

Les tests ne donnent pas le résultat escompté

Enfin, si les tests ne donnent pas le résultat souhaité, cela peut démontrer que la méthode de test doit être réadaptée. Une bonne approche de test explique "comment" un produit doit être testé. Ce "comment" doit être adapté au contexte de l’entreprise. Par conséquent, il n'est pas utile d’avoir une méthode de test de 10 pages, si elle ne répond à aucune question. En revanche, elle doit fournir suffisamment d'informations pour vous permettre d'exécuter des actions qui vous donneront un aperçu de la qualité. Keep It Short and Simple (KISS) est toujours une bonne règle à suivre si vous souhaitez créer une méthode de test efficace et claire pour toute l'équipe du projet. La méthode choisie dépend du contexte, tel que : les risques, la sécurité, les ressources disponibles, les compétences, la technologie, la nature du système, les objectifs de test et les réglementations. Si vous tenez compte de tous ces éléments, vous êtes certainement sur la bonne voie.