Deutsch English Swedish French
CONTACTEZ-NOUS
CONTACTEZ-NOUS
Deutsch English Swedish

Qualité logicielle et IA

Test logiciel

Assurance qualité pour SAP

Cybersécurité

Banque & Finance

QESTIT Cybersecurity

QESTIT Academy

QESTIT Systems

Blog

Études de cas

Webinars

Livres blancs

Actualités

Qui sommes-nous

Nos partenaires

Nos références
Solutions

Travailler chez QESTIT

Offres d'emploi
CONTACTEZ-NOUS
move-left Back
🌍 All Regions
Quality Assurance Engineering

Qu'est-ce qu'il ne faut pas automatiser ?

Lorsque nous écrivons des tests automatisés, notre objectif est d’apporter un maximum de valeur ajoutée avec un coût et un temps minimaux. Le nombre total de cas de test nécessaires pour vérifier qu’un grand système moderne et complexe ne comporte aucune erreur est pratiquement infini. On ne peut pas « tout » automatiser. Dans cet article, nous examinons de plus près ce qui ne peut pas ou ne doit pas être automatisé, et pourquoi.

Nous devons adopter une réflexion stratégique pour sélectionner un nombre limité de tests à automatiser. Ces tests doivent couvrir une partie aussi large que possible du système, être simples à mettre en œuvre, stables et fiables, et peu coûteux à modifier et à maintenir.

L’automatisation des tests vise à rationaliser certaines parties du travail de test, du moins celles qui s’y prêtent le mieux. Il existe donc certaines catégories de tests que nous ne devrions pas automatiser.

Les tests qui requièrent de l'intelligence et de l'émotion

Un ordinateur est totalement dépourvu d’intelligence, de goût et de sentiments. Il n’est donc pas possible de créer de bons tests automatisés pour évaluer des éléments tels que :

  • La mise en page est-elle pédagogique ?
  • L'expérience utilisateur est-elle agréable ?
  • L'utilisation de l'application est-elle ergonomique ?
  • Le fonctionnement du système est-il facile à comprendre ?
  • L'interface utilisateur est-elle visuellement attrayante ?

Ne perdez pas de temps ni d’énergie à essayer de vérifier ne serait-ce qu’une partie de ces aspects. Un ordinateur n’est pas capable 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 applications qui ne sont pas encore stables (trop tôt dans leur cycle de vie)

Les tests qui interagissent avec l’application via l’interface utilisateur graphique (GUI) sont très sensibles aux modifications. Des changements apparemment mineurs apportés à l’interface utilisateur de l’application suffisent à rendre les tests inopérants. Par conséquent, il n’est pas judicieux d’automatiser les tests sur une application qui n’est pas encore stable. Le fait qu’elle ne soit pas stable signifie qu’elle sera modifiée ou corrigée, ce qui rendra les tests inopérants.

Les tests qui interagissent avec l’application via l’interface utilisateur graphique sont, par rapport à d’autres types de tests automatisés, complexes, volumineux, chronophages et difficiles à modifier. Il est donc préférable d’attendre que le système commence à se stabiliser et qu’aucun changement perturbateur ne soit plus prévu avant de mettre en œuvre ce type de tests.

Applications que l’outil a du mal à prendre en charge (API, interface graphique)

Il arrive parfois que l’on rencontre des composants ou des parties d’un système pour lesquels il est très difficile de mettre en place des tests automatisés. Cela peut s’expliquer par diverses raisons. Prenons l’exemple de la sécurité, dont l’objectif premier est d’empêcher les bots ou toute manipulation automatisée indésirable. Un autre exemple concerne les composants propriétaires, dont les détails de mise en œuvre sont inconnus ou confidentiels.

Mettre en œuvre des solutions créatives (souvent complexes) pour contourner le problème est généralement une mauvaise idée à long terme. Les tests deviennent imprévisibles et complexes. Ne passez donc pas un temps excessif à vous débattre avec des tests dans des situations quasi impossibles où les résultats seront médiocres.

63+++

Consacrez plutôt votre temps et votre énergie à la mise en place de tests automatisés là où cela est facile et efficace. Ce qui apporte utilité et valeur, ce sont des tests qui s’exécutent rapidement, qui sont fiables, robustes et faciles à modifier et à maintenir.

Cas de test qui n’ont pas bien fonctionné en mode manuel

Si certains tests se sont mal déroulés lors de leur exécution manuelle, cela signifie que l’application n’est pas encore vraiment stable. Des modifications apparemment mineures apportées à l’interface utilisateur de l’application suffisent à rendre les tests inopérants. Par conséquent, il n’est pas judicieux de mettre en place des tests automatisés via l’interface utilisateur graphique (GUI) sur une application pour laquelle les tests manuels n’ont pas donné de bons résultats.

En revanche, 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, comparés à ceux via une interface graphique, relativement simples, courts et rapides à mettre en œuvre, et faciles à modifier.

Si l’on peut tester le système via une API dès le début du cycle de développement, il est judicieux de commencer à mettre en œuvre des tests exhaustifs à ce niveau. Lorsque le système a commencé à se stabiliser et qu’aucun changement radical n’est plus à prévoir, il est très efficace de compléter ces tests par un petit nombre de tests automatisés via l’interface utilisateur graphique de l’application.

Il manque des informations sur le fonctionnement du système et un accompagnement pour l’ingénieur en automatisation des tests

La méthode la plus efficace consiste à mettre en œuvre les tests automatisés en parallèle de la mise en œuvre du système. Les tests automatisés doivent se situer au niveau d’automatisation le plus bas possible (niveau périphérique, niveau API, niveau interface graphique) afin de détecter les défauts aussi près que possible de leur 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. Nous souhaitons que le développement du système se soit stabilisé et qu’aucun changement radical ni aucune refonte ne soient prévus. Cela s’explique, comme mentionné ci-dessus, par la complexité et l’ampleur de ces tests, ainsi que par le coût et le temps nécessaires aux modifications et à la maintenance.

Il est important que les personnes chargées de rédiger les tests automatisés aient une connaissance approfondie du fonctionnement du système. Si ces connaissances font défaut et que l’équipe, l’organisation ou toute autre personne n’est pas en mesure de transmettre ces informations, il sera très difficile de créer des tests automatisés pertinents.

Tags

Quality Assurance Engineering All Industries All Business Units