Lorsqu’on écrit des tests automatisés, on veut ajouter le maximum de valeur avec le moins de coût ou de temps possible. Le nombre total de cas de test pour vérifier qu'un grand système moderne complexe ne comporte pas d'erreurs est presque infini. « Tout » ne peut pas être automatisé. Dans cet article, nous examinons de plus près ce qui ne peut/doit pas être automatisé et pourquoi.
On doit penser stratégiquement pour sélectionner un nombre limité de tests à automatiser. Ces tests doivent couvrir la plus grande partie possible du système, être simples à mettre en œuvre, stables et fiables, et peu coûteux à modifier et à maintenir.
L'automatisation des tests consiste à rationaliser certaines parties du travail de test, du moins les parties les plus appropriées. Par conséquent, il existe certaines catégories de tests que nous ne devrions pas automatiser.
Un ordinateur est totalement dépourvu d'intelligence, de goût et de sentiment. Il n'est donc pas possible de créer de bons tests automatisés pour évaluer des éléments tels que les suivants :
Ne perdez pas de temps et d'énergie à essayer de vérifier ne serait-ce qu'une partie de ces aspects. Un ordinateur n'a pas la capacité d'évaluer ces aspects. Les tests deviennent complexes et peu fiables et ne peuvent, même en théorie, vérifier qu'une fraction négligeable de ce que nous souhaitons.
Les tests qui interagissent avec l'application via l'interface utilisateur graphique (GUI) sont très sensibles aux changements. Des modifications apparemment minimes de l'interface utilisateur de l'application entraînent l'arrêt des tests. Par conséquent, ce n'est pas une bonne idée d'automatiser des tests avec une application qui n'est pas encore stable. Le fait qu'elle ne soit pas stable signifie qu'elle sera changée, modifiée ou corrigée, ce qui entraînera l'arrêt des tests.
Les tests qui interagissent avec l'application via l'interface utilisateur graphique sont, par rapport à d'autres types de tests automatisés, complexes, volumineux, longs et difficiles à modifier. Par conséquent, il est préférable d'attendre que le système ait commencé à se stabiliser et qu'aucun changement perturbateur ne soit prévu avant de mettre en œuvre ces types de tests.
Nous rencontrons parfois des composants ou des parties d'un système pour lesquels il est très difficile de mettre en œuvre des tests automatisés. Cela peut être dû à plusieurs raisons. Un exemple est la sécurité où le but est d'éviter les bots ou les manipulations automatisées non désirées. Un autre exemple est celui des composants propriétaires dont les détails d'implémentation sont inconnus ou secrets.
La mise en œuvre de solutions créatives (souvent complexes) pour contourner le problème est généralement une mauvaise idée à long terme. Les tests deviennent erratiques et complexes. Ne passez donc pas un temps disproportionné à vous débattre avec des tests dans des situations presque impossibles où les résultats seront médiocres.
Consacrez plutôt votre temps et votre énergie dans la mise en œuvre de tests automatisés dans les domaines où cela est à la fois faisable et susceptible de porter ses fruits. Ce qui est utile et précieux, ce sont les tests qui s'exécutent rapidement, qui sont fiables, robustes, faciles à modifier et à entretenir.
Si les tests manuels n'ont pas été concluants, cela suggère que l'application n'est pas encore totalement stable. Même de légères modifications de l'interface utilisateur entraînent des défaillances dans les tests. Ainsi, il est déconseillé d'opter pour des tests automatiques via l'interface utilisateur graphique (GUI) pour une application dont les tests manuels ne se sont pas révélés satisfaisants.
D'un autre côté, cela ne s'applique pas aux tests automatisés via une API (par exemple, des services Web tels que REST ou SOAP). En effet, les tests automatisés via une API sont, comparativement aux tests automatisés via une interface graphique, triviaux, courts et rapides à mettre en œuvre et faciles à modifier.
Si nous pouvons tester le système via l'API au début du cycle de développement, c'est une bonne idée de commencer à mettre en œuvre des tests exhaustifs à ce niveau. Lorsque le système a commencé à se stabiliser et qu'il ne faut plus s'attendre à des changements révolutionnaires, il est très efficace de compléter par un plus petit nombre de tests automatisés via l'interface utilisateur graphique de l'application.
La méthode la plus efficace consiste à mettre en œuvre les tests automatisés parallèlement à la mise en œuvre du système. Les tests automatisés doivent se situer à un niveau d'automatisation aussi bas que possible (niveau du dispositif, niveau de l'API, niveau de l'interface graphique) afin de détecter les défauts le plus près possible de la source (là où ils se produisent).
L'automatisation des tests au niveau de l'interface graphique intervient relativement tard dans la chaîne de développement. On souhaite que le développement du système se soit stabilisé et qu'aucun changement ou remaniement radical ne soit attendu. Ceci, comme mentionné ci-dessus, est dû à la complexité et à la taille de ces tests, ainsi qu'au coût et au temps des modifications et de la maintenance.
Il est essentiel que les personnes en charge des tests automatisés aient une connaissance approfondie du fonctionnement du système. En l'absence de ces connaissances, et si l'équipe, l'organisation, ou toute autre personne ne peut pas transmettre ces informations, la création de tests automatisés significatifs devient extrêmement complexe.