J'ai identifié 7 étapes clés dans l'évolution des tests pour illustrer l'évolution des approches de l'assurance qualité dans les entreprises. Au cours de la lecture de l'article, vous pourrez suivre l'évolution des tests, déterminer votre stade actuel et découvrir ce qui devrait être fait pour améliorer le processus et la qualité des tests.
L'article a été initialement écrit pour le magazine CIS, mais je pense qu'il sera également intéressant pour les utilisateurs Habr.
Donc, les étapes.
- Il n'y a pas de testeur. Ses fonctions sont assurées par le développeur ou le gestionnaire.
- Les testeurs apparaissent, mais ne testent que les projets au stade d'achèvement.
- Les testeurs vérifient toutes les tâches des développeurs pour la conformité du résultat avec l'énoncé original du problème.
- Les testeurs participent à la conception des tests.
- Un système de gestion des tests est en cours d'introduction.
- L'automatisation des tests apparaît.
- La hiérarchie devient plus complexe, de nouveaux rôles apparaissent dans l'équipe de test.
Maintenant sur chaque étape plus en détail.
Étape 1. Les tests sont effectués par le développeur et / ou le gestionnaire
«Did - check for yourself» - l'approche la plus simple et «instinctive» des tests. Une chose courante dans les petites entreprises. Lorsqu'il n'est pas possible d'embaucher un testeur professionnel ou qu'il n'y a pas de compréhension de la nécessité des tests, ce front de travail se fait seul. Se tester est l'approche la plus irrationnelle et problématique. Voilà pourquoi.
- Le développeur lui-même ne teste que les scénarios qu'il a mis en œuvre avec les données qu'il a utilisées dans le processus de développement. Avec de tels tests «dans le vide», les scénarios alternatifs sont omis. En conséquence, la vie fait des ajustements et, en règle générale, des erreurs se produisent pour les utilisateurs finaux.
- Si le gestionnaire teste, il le fait comme un fardeau supplémentaire, sans posséder d'expertise et sans avoir le temps et la force morale pour s'engager étroitement dans le test. Vous pouvez donc trouver des erreurs grossières, mais de nombreuses nuances sont négligées.
- L'attitude subjective envers le projet, le désir de le passer rapidement conduisent à la tentation de fermer les yeux sur un certain nombre de problèmes apparemment «insignifiants».
Un cas extrême où l'entreprise ne fait pas de tests du tout, et un rapport de bogue amène ... le client. Il a reçu la sortie, tout est déjà sur le champ de bataille, a rapporté le développeur lors du lancement. Le client ouvre le projet et voit une erreur de base de données courante ou une erreur de serveur. Puis de plus en plus d'erreurs. Le client devient testeur pour son propre argent.
Étape 2. Le testeur vérifie le projet à la toute fin
La vérification de l'ensemble du projet au stade de la pré-version est une méthode classique lorsque vous travaillez sur le modèle Waterfall. Le projet est divisé en étapes globales (parfois l'ensemble du projet est une étape). À chaque étape, le logiciel est d'abord créé, puis testé uniquement. Les tests sont déjà là, et c'est bien. Mais il y a aussi des problèmes, très spécifiques.
Premièrement, lorsque nous testons à la toute fin, des erreurs graves au niveau de l'architecture seront détectées trop tard. Il faudra refaire une grande partie, voire l'ensemble du projet. Ce n'est avantageux pour personne.
Deuxièmement, en l'absence de documentation, nous ne pouvons effectuer des tests de surface qu'en utilisant la méthode de recherche gratuite. Cela désactive immédiatement certains des scénarios alternatifs. Il arrive qu'il y ait de la documentation, mais dans le processus, les tâches changent et le produit fini diffère de l'image sur papier. Encore une fois, il est difficile de tester et d'analyser les rapports de bogues.
Troisièmement, presque tout le temps, un projet est généralement axé sur le développement comme tâche prioritaire. Laissez un peu de temps pour vérifier. Mais il n'y a pas de temps pour corriger les erreurs, en conséquence, des améliorations parfois impressionnantes ralentissent le projet et perturbent les délais.
Des tests séparés des étapes posent un autre problème. Entre les étapes, le testeur oublie les détails du projet et à chaque fois il doit se plonger dans ce qui se passe. C'est aussi une perte de temps de travail.
En général, la vérification du projet à la toute fin est logique et semble correcte, mais cette méthode ne prend pas en compte le risque de détection d'erreurs globales. Par conséquent, les tests évoluent davantage.
Étape 3. La conformité du résultat à la tâche d'origine est vérifiée pour toutes les tâches.
De plus, l'entreprise comprend qu'il est préférable de détecter les erreurs à mesure qu'elles s'accumulent. Par conséquent, nous passons du modèle Waterfall à la méthodologie Agile. À ce stade, les testeurs sont plus étroitement intégrés dans le processus de développement. Toutes les tâches commencent à être testées à plusieurs reprises de manière séquentielle: séparément, dans le cadre de la version, sur un environnement de combat.
À ce stade, la conformité des tâches aux exigences énoncées est vérifiée. Agile aide à mieux travailler, mais tous les testeurs, et en particulier leurs dirigeants, ne sont pas prêts à se relier aux tests d'une manière nouvelle.
La tête attend de la vitesse et de la qualité de la part des testeurs, mais elle ne comprend pas la nécessité d'une documentation de test et d'effectuer des tests de régression. D'où les problèmes typiques de cette étape de l'évolution.
Les tests sont plus intuitifs que structurés. Le principe de «ce que je vois est ce que je teste» domine. À chaque itération, différents contrôles sont effectués et dans une séquence différente. Par conséquent, vous pouvez au moins ignorer l'erreur à l'une des étapes de test ou ne pas la voir du tout. Des scénarios alternatifs et des changements dans les fonctionnalités associées peuvent également ne pas être visibles.
De plus, le problème est avec les tests de régression, qui, s'ils sont effectués, ne sont pas systématiques. En fait, le testeur vérifie ce qu'il juge nécessaire ou ce que le développeur / gestionnaire lui a conseillé de vérifier.
Étape 4. Les testeurs participent à la conception des tests.
À ce stade, la conception des tests entre en scène. Les testeurs commencent à prêter consciemment attention à l'analyse des exigences. La fonctionnalité est divisée en blocs logiques, qui sont couverts par des listes de contrôle ou des cas de test.
Liste de contrôle - une liste de contrôles requis pour tester la fonctionnalité. Les listes de contrôle sont plus courantes car elles sont plus faciles à tenir à jour, en particulier dans le cadre d'un grand projet dynamique.
Un scénario de test est une séquence d'étapes qui doivent être prises pour vérifier la fonctionnalité. Une description de chaque étape est accompagnée d'une indication du comportement attendu du système.
Une
documentation de test complète apparaît, selon laquelle vous pouvez suivre la façon dont une fonction particulière est vérifiée. La documentation des tests est utile non seulement pour les tests initiaux, mais aussi pour les tests de régression.
Tout cela s'appelle la conception de tests. On peut dire que des tests professionnels significatifs commencent à ce stade. C'est plus qu'une simple montagne de tâches à vérifier, mais un processus structuré d'analyse des exigences, de génération de documentation de test et de test direct. Y compris changer l'approche des données de test. Les données ne sont plus inventées spontanément dans le processus, mais sont extraites d'ensembles pré-préparés.
Il n'y a aucun inconvénient évident au stade de la conception du test. En général, il s'agit d'un niveau de test décent. Pour les sites de production en streaming ou des projets similaires, la conception des tests est plus que suffisante. L'essentiel est d'aborder correctement le processus de test: analyser le produit, rédiger la documentation et effectuer des tests sur celui-ci.
Étape 5. Un système de gestion des tests est en cours d'introduction
De plus, la société devient de plus en plus obligée d'utiliser des systèmes spécialisés pour stocker les cas de test (listes de contrôle) et effectuer des tests.
Un tel système permet:
- stocker les exigences et les cas de test;
- Associer des exigences à des cas de test
- analyser la couverture des tests;
- stocker différentes versions des cas de test;
- Effectuer des tests
- effectuer une analyse comparative des essais;
- conserver les rapports de test;
- Suivez les charges de travail de l'équipe pour ajuster les tâches et les ressources.
Un système est toujours une nouvelle étape dans l'évolution. Dans notre cas, tout d'abord, le contrôle du processus de test est amélioré. Nous gérons mieux les tests et obtenons un nouveau niveau de qualité des produits.
Aux stades ultérieurs de l'élaboration du projet, un tel système aide tous les participants à se rappeler comment quelque chose devrait fonctionner et comment le vérifier. Le système accélère l'introduction de nouveaux participants dans le projet.
Étape 6. Les contrôles réguliers sont automatisés
Dans le processus de développement à long terme des projets, il est nécessaire d'automatiser les inspections individuelles. Pour cela, les développeurs et les testeurs écrivent des autotests. Les développeurs font généralement des tests unitaires, les testeurs font des tests d'interface utilisateur. Ils commencent par couvrir avec des autotests des scénarios positifs d'utilisation de fonctionnalités clés: autorisation, enregistrement, publication d'enregistrements, etc.
Les autotests développés sont inclus dans le processus d'intégration continue (
CI / CD ), ce qui permet à l'équipe de prendre connaissance des erreurs immédiatement au moment de la validation.
Les autotests réduisent considérablement les coûts des tests de régression et améliorent la qualité du produit final. Mais pour les faire, vous avez besoin d'un certain niveau de testeur. Il convient également de savoir que les autotests n'ont pas de sens dans les premières étapes d'un projet. Le système évolue rapidement, par conséquent, afin d'éviter les erreurs fantômes, il est également nécessaire de modifier les autotests, ce qui prend du temps.
Étape 7. La hiérarchie devient plus complexe, de nouveaux rôles apparaissent
Nous sommes arrivés au stade le plus élevé de l'évolution, lorsque la hiérarchie dans le département de test est considérablement compliquée et que des spécialistes étroits apparaissent: un responsable de test, un responsable de test, un analyste de test, un concepteur de test, etc.
L'équipe s'agrandit, les tâches se compliquent. Par exemple, un
gestionnaire de tests connaît le mieux un produit et organise les tests à un niveau supérieur. Il communique plus souvent et plus étroitement avec les clients et le développement qu'avec l'équipe de test.
Le responsable du test organise les tests sur le projet et répartit les tâches au sein de l'équipe.
L'analyste de test est engagé dans l'analyse des exigences, leur décomposition et leur hiérarchisation, prépare le matériel pour la conception du test et les tests ultérieurs. Et le
concepteur de tests transforme les exigences en listes de contrôle et en scénarios de test.
De nouveaux rôles sont nécessaires sur les grands projets où toute une équipe de testeurs travaille. L'émergence de tels rôles conduit à un processus de test encore plus structuré, sans lequel il est impossible de travailler sur des projets informatiques volumineux et complexes.
Conclusions
Nous avons examiné les étapes clés de l'évolution des tests en entreprise. Les tests professionnels conscients commencent dès la phase de conception des tests. La conception des tests permet une amélioration constante de la qualité des produits.
Le processus de développement des tests n'est pas toujours linéaire. Vous pouvez sauter, combiner, mélanger certaines étapes ou passer immédiatement à un niveau supérieur. Par exemple, chez Qualitica, nous avons un système de gestion des tests, c'est-à-dire que nous en sommes à l'étape 5. Maintenant, presque simultanément, nous avons des spécialistes étroits (nouveaux rôles, étape 7) et de l'automatisation (étape 6).
Tout le monde n'a pas besoin du système de gestion des tests, des autotests, et encore plus d'un concepteur de tests. Mais, restant au stade des tests instinctifs ou se limitant aux vérifications finales, il est peu probable qu'il fasse des projets complexes à long terme. Par conséquent, je vous souhaite de trouver le bon point dans le développement des tests et d'y arriver afin d'améliorer la qualité des tests et de donner aux clients un produit de haute qualité.