Idées fausses courantes sur l'automatisation des tests

Dans cet article, nous examinerons certaines des idées fausses les plus courantes sur l'automatisation des tests et comment celles-ci empêchent les organisations de réussir dans l'automatisation des tests.

Il n'est pas difficile d'imaginer les avantages d'avoir des tests automatisés parallèlement au développement de produits - des versions plus rapides, une couverture de test accrue, une exécution de tests fréquente, un retour plus rapide à l'équipe de développement, pour n'en nommer que quelques-uns, mais de nombreuses organisations n'ont pas fait le mouvement ou sont résistant à l’investissement dans l’automatisation des tests.



Idées fausses sur l'automatisation des tests

L'aspect le plus difficile et le plus stimulant de toute entreprise d'automatisation de test est peut-être de comprendre les limites des tests automatisés et de définir des objectifs et des attentes réalistes pour éviter les déceptions. Dans cet esprit, voyons quelques-uns des malentendus et mythes les plus courants sur l'automatisation des tests:


Les tests automatisés sont meilleurs que les tests manuels

En référence au billet de blog de Michael Bolton Test vs vérification , les tests automatisés ne sont pas vraiment des tests. C'est la vérification des faits. Lorsque nous avons une compréhension du système, nous pouvons appliquer cette compréhension sous forme de contrôles, puis en exécutant les contrôles automatisés, nous confirmons notre compréhension. Le test, quant à lui, est un exercice d'investigation dans lequel nous cherchons à obtenir de nouvelles informations sur le système testé par l'exploration.

Les tests nécessitent qu'un humain porte un jugement judicieux sur l'utilisabilité du système. Nous pouvons repérer des anomalies alors que nous n'anticipions pas. Nous ne devons pas être indulgents envers l'un ou l'autre, car les deux méthodes sont nécessaires pour avoir un aperçu de la qualité de l'application.


Réaliser des tests 100% automatisés

Tout comme il n'existe aucun moyen pratique d'atteindre une couverture de test à 100% (en raison des permutations possibles infinies), il en va de même pour l'automatisation des tests. Nous pouvons augmenter la couverture des tests en exécutant des tests automatisés avec plus de données, plus de configurations, couvrant toute une variété de systèmes d'exploitation, de navigateurs, mais atteindre 100% reste un objectif irréaliste. Lorsqu'il s'agit de tests automatisés, plus de tests ne signifient pas nécessairement une meilleure qualité ou une meilleure confiance. Tout dépend de la qualité d'un test. Plutôt que de viser une couverture complète, concentrez-vous sur le domaine de fonctionnalité le plus important qui est crucial pour l'entreprise.

ROI rapide

Lors de la mise en œuvre d'une solution d'automatisation des tests, il existe d'autres activités de développement interdépendantes que de simples scénarios de test de script. Normalement, un cadre doit être développé pour prendre en charge des opérations sur mesure utiles et significatives pour l'entreprise, telles que la sélection de cas de test, la création de rapports, la gestion des données, etc.

Le développement du framework est un projet en soi et nécessite des développeurs qualifiés et prend du temps à construire. Même lorsqu'un cadre entièrement fonctionnel est en place, la création de scripts de contrôles automatisés prend initialement plus de temps que l'exécution manuelle du même test. Par conséquent, lorsque nous avons besoin de commentaires rapides sur la nouvelle fonctionnalité qui vient d'être développée, la vérifier manuellement est généralement plus rapide que l'automatisation du test. Cependant, le retour sur investissement est retourné sur le long terme lorsque nous devons exécuter les mêmes tests à intervalles réguliers.

Taux de détection des défauts plus élevé grâce à des contrôles automatisés

Bien que de nombreuses solutions d'automatisation de test fournies par le fournisseur et préparées à domicile soient très sophistiquées et hautement capables d'effectuer des opérations complexes, elles ne seront jamais en mesure de rivaliser avec l'intelligence d'un testeur humain qui peut détecter des anomalies inattendues dans l'application tout en explorant ou exécution d'un ensemble de tests scriptés sur le système testé. Ironiquement, les gens s'attendent à ce que les tests automatisés trouvent beaucoup de bogues en raison d'une couverture de test prétendument augmentée, mais en réalité, ce n'est pas le cas.


Certes, les tests automatisés sont efficaces pour détecter les problèmes de régression - après qu'une nouvelle fonctionnalité a été ajoutée à la base de code existante, nous devons nous assurer que nous n'avons pas interrompu la fonctionnalité actuelle et que nous avons besoin de ces informations rapidement - mais, le nombre de problèmes de régression, dans la plupart des cas, cela a tendance à être beaucoup moins que les nouvelles fonctionnalités en cours de développement.

Un autre point à garder à l'esprit est que les contrôles automatisés vérifient uniquement ce pour quoi ils ont été programmés pour vérifier par la personne qui a écrit le script. Les scripts sont aussi bons que la personne qui les a écrits. Tous les contrôles automatisés pourraient réussir, mais des défauts majeurs peuvent passer inaperçus, ce qui peut donner une fausse impression de la qualité du produit. En substance, la vérification peut prouver l'existence de défauts, mais elle ne peut pas prouver leur absence.

Nous n'avons besoin que de l'automatisation des tests unitaires

Par conséquent, si la probabilité de trouver des défauts est plus grande lors du test de nouvelles fonctionnalités, pourquoi n’exécutons-nous pas nos tests automatisés par rapport à la nouvelle fonctionnalité au fur et à mesure de son développement? Eh bien, c'est un peu le cas pour les équipes qui pratiquent TDD .

Les développeurs écrivent d'abord un test unitaire, le regardent échouer, puis écrivent suffisamment de code pour réussir le test unitaire et le cycle est répété jusqu'à ce que la fonctionnalité prévue soit fournie. Essentiellement, ces tests unitaires automatisés vérifient de nouvelles fonctionnalités et, au fil du temps, ils forment le pack de régression unitaire qui est exécuté à plusieurs reprises au fur et à mesure que de nouvelles fonctionnalités sont fournies.


Mais, il y a une mise en garde à cela. Bien que le TDD soit fortement encouragé et soit une pratique de développement solide dans la construction de la qualité à partir de zéro, les tests unitaires ne sont bons que pour trouver des erreurs de programmeur, pas des échecs. Il y a un aspect beaucoup plus large du test qui se produit lorsque tous les composants sont liés ensemble et forment un système.

En fait, de nombreuses organisations ont la majorité de leurs contrôles automatisés au niveau de l'interface utilisateur du système. Cependant, la création de scripts de vérifications automatisées de l'interface utilisateur ou du système, pendant le développement des fonctionnalités, est au mieux une tâche ardue, car la nouvelle fonctionnalité a tendance à être volatile (sujette à de nombreux changements) au cours du développement. En outre, la fonctionnalité attendue peut ne pas être connue avant plus tard, donc passer du temps à automatiser une fonctionnalité changeante n'est pas encouragé.

Nous n'avons besoin que de l'automatisation de l'interface utilisateur du système

Il existe des valeurs dans l'exécution de contrôles automatisés au niveau de l'interface utilisateur et du système. Nous voyons ce que vit l'utilisateur lorsqu'il interagit avec l'application; nous pouvons tester des flux de bout en bout et 3rdintégration du parti alors que nous ne pouvions pas tester autrement; nous pouvons également faire une démonstration des tests aux clients et aux utilisateurs finaux afin qu'ils puissent avoir une idée de la couverture des tests. Cependant, se fier uniquement aux contrôles automatisés au niveau de l'interface utilisateur présente ses propres problèmes.

L'interface utilisateur change constamment pour améliorer la conception visuelle et la convivialité et l'échec des contrôles automatisés en raison des modifications de l'interface utilisateur et non des modifications de la fonctionnalité peut donner une fausse impression de l'état de l'application.


Les contrôles automatisés de l'interface utilisateur sont également beaucoup plus lents en termes de vitesse d'exécution qu'au niveau de l'unité ou de la couche API et, de ce fait, la boucle de rétroaction vers l'équipe est lente. Cela peut prendre quelques heures avant qu'un défaut ne soit détecté et signalé aux développeurs. Et quand quelque chose ne va pas, l'analyse des causes profondes prend plus de temps car il n'est pas facile de voir où se trouve le bogue.

Il est important de comprendre le contexte de chaque test et à quelle couche le test doit être automatisé. L'automatisation des tests doit faire partie de l'activité de développement, de sorte que toute l'équipe est responsable de l'automatisation des tests, les développeurs écrivant des tests unitaires, les développeurs de logiciels en rédaction de tests exécutant et conservant les tests d'acceptation au niveau de l'API et / ou de l'interface utilisateur.

Perdre la foi et la confiance dans l'automatisation des tests

Ce dernier n'est pas un mythe sur l'automatisation des tests, mais un effet secondaire lorsque l'automatisation des tests tourne mal. Vous passez de nombreuses heures à développer une solution d'automatisation de test parfaite, en utilisant les meilleurs outils et les meilleures pratiques, mais si les contrôles automatisés n'aident pas l'équipe, cela ne vaut rien.

Si l'équipe n'a aucune visibilité ou connaissance de ce qui est automatisé et en cours d'exécution, elle libère avec peur de l'inconnu ou duplique ses efforts de test de régression. Si les contrôles automatisés sont irréguliers, lents et donnent des résultats intermittents, cela peut dérouter l'équipe plus que de fournir un filet de sécurité et un booster de confiance.


N'ayez pas peur de supprimer les contrôles automatisés qui échouent toujours ou donnent des résultats incohérents. Au lieu de cela, visez une série de tests propres et fiables qui peuvent donner des indications correctes sur la santé de l'application.



Conclusion

L'automatisation des tests est un investissement à long terme. Il faudra du temps et de l'expertise pour développer et maintenir des cadres d'automatisation de test et des scripts automatisés. L'automatisation des tests n'est pas un effort ponctuel où vous fournissez une solution et la laissez fonctionner. Il nécessite une surveillance et une mise à jour constantes.

Plutôt que de viser à remplacer les QA manuels ou de s'attendre à ce que les vérifications automatisées découvrent de nombreux défauts, nous devrions plutôt profiter des avantages que cela apporte à l'équipe, comme libérer le temps du QA pour des tests plus exploratoires où les chances de révéler des défauts sont maximisées, ou utiliser l'automatisation. scripts pour créer des données de test pouvant être utilisées pour des tests manuels.

Comprendre les limites et définir des attentes réalistes est important pour surmonter ces mythes de l'automatisation des tests.