Les tests dans les grandes entreprises, en entreprise, sont souvent une tâche compliquée et ingrate. L'écart entre les divisions commerciales et l'informatique est énorme: lorsqu'un développeur a une vision au niveau du code, et une vérification au niveau des tests unitaires, et que le client pense travailler ou ne pas travailler même pas avec les services, mais avec des processus entiers qui vont au-delà d'une seule équipe de développement, ou même de l'ensemble divisions \ entreprises. Et il demande d'organiser des tests d'entreprise, ou des tests de bout en bout, ou des tests basés sur des scénarios du début à la fin (fin 2 fin).
Commençons par le tout début - des deux piliers d'où provenait ce fameux «test de bout en bout», à savoir la pyramide des tests et la norme ISO9000.
Test de la pyramide
La pyramide des tests est probablement familière à tout testeur qui est devenu compétent dans sa profession et a accumulé des bosses lors de la communication avec les unités liées. Il est particulièrement nécessaire de faire appel à elle pour justifier l'automatisation des tests. Quels tests sont moins chers et plus importants à développer? Et courir?
L'essence de la pyramide des tests n'est pas délicate: les tests doivent être basés sur les tests d'écriture et d'exécution les plus simples et les plus rapides - les tests unitaires. Bien sûr, la vérification des interfaces des classes et des fonctions n'est pas la chose qui peut être montrée au client, mais sans cette fondation solide, monolithique et sans problème, il n'est guère possible de construire quelque chose de plus élevé. En règle générale, plusieurs dizaines de fonctions, méthodes et classes implémentent une sorte de fonctionnalité pour le client, et en fait, une douzaine de tests unitaires peuvent être réduits à certains tests de niveau supérieur. Le client a déjà besoin d'un bel appartement avec décoration, mais il est peu probable qu'il soit satisfait lorsque les fenêtres inclinées de son appartement cesseront de s'ouvrir et que le sol et le plafond se fissureront dès la première brise soufflante. Cependant, le client lui-même pour entrer dans l'appartement et vérifier sa qualité n'est peut-être pas la meilleure idée. D'accord, il est difficile pour l'utilisateur de vérifier la qualité du béton dans la fondation et de reproduire toutes les conditions météorologiques. Donc, dans les tests, bien sûr, des tests de niveau supérieur sont nécessaires, puis seulement lorsque nous avons élaboré des tests unitaires, les tests de niveau supérieur le sont également.
Il est plus difficile à développer et plus long à effectuer des tests de niveau supérieur - des tests d'intégration, qui vérifient le bon fonctionnement des modules fonctionnant simultanément sur lesquels toute l'équipe a travaillé, libérant leur produit (système). Autrement dit, l'intégration du code est vérifiée, le système est testé sans prendre en compte l'interaction avec les systèmes externes. De tels tests impliquent déjà une vérification de haut niveau, très probablement via un appel au système via l'API système ou même une interface graphique (avant). Travailler avec ce type de test est plus difficile - afin de couvrir toutes les branches et les nuances du code, vous devez très probablement utiliser un grand nombre de vérifications fortement chevauchantes sur diverses données de test, et pendant l'automatisation, développez souvent tout un tas de conditions et de branches dans les scripts. Autrement dit, d'une part, nous avons déjà approché l'utilisateur, ce qui rend la vie difficile, mais d'autre part, il nous est toujours difficile de trouver une langue commune, cela nous coûte plus cher et la qualité des contrôles n'est toujours pas suffisante. Autrement dit, nous pouvons lancer le client dans un nouvel appartement, il peut tout vérifier, mais sans prendre en compte l'interaction avec les autres résidents, les conditions météorologiques et les services publics. D'accord, le sens d'un monde idéal, un modèle, dans la vraie vie, en règle générale, n'est pas beaucoup.
Si nous ajoutons ces conditions, nous verrons comment notre système interagit avec les systèmes externes - fournisseurs et consommateurs, avec notre environnement, c'est-à-dire que nous effectuons des tests de système, alors nous pouvons facilement voir que la complexité des tests augmentera également. Nous devrons parvenir à l'opérabilité simultanée de tous les systèmes en interaction, mais sans l'implication de spécialistes. Pour l'instant, il nous suffit d'accepter simplement certaines données de nos fournisseurs et de transférer nos données à nos consommateurs. Dans la séquence et le format corrects. Le sort ultérieur des données ne nous dérange pas. L'essentiel est que notre système fonctionne correctement dans le bon environnement. Et tout irait bien ici - pour notre client, nous pouvons déjà mener une démonstration à grande échelle, mais ce n'est que dans la vie réelle que tous les critères de réussite de notre développement ne sont pas. Bien sûr, il est bon que le client ait son appartement dans une maison solide, mais si vous devez en sortir, grimper sur les barbelés, puis faire du canoë le long du lac avec des crocodiles dans des huttes regorgeant de serpents, alors peut-être que nous n'avons pas raison y at-il?
Par conséquent, ici, la première idée de test de bout en bout est de vérifier non seulement notre environnement, mais aussi tous les systèmes interconnectés par lesquels passent les données reçues ou envoyées par notre système. Et cela, à son tour, signifie que nous devrons combiner plusieurs de ces "pyramides de test" les unes avec les autres. La construction d'un pont fragile sur lequel nous conserverons les données précieuses pour l'utilisateur par la poignée.
La seule question est de savoir comment faire cela? Qui devrait faire ça? Comment assembler?
ISO9000
Une série de normes qui décrivent le système de gestion de la qualité, y compris le fait que tout processus dans l'organisation doit être décrit, documenté, même s'il s'agit du processus d'émission d'un râteau à l'automne au concierge. Et si c'est le cas, cela ne peut pas décrire un seul processus qui se déroule à l'intérieur du logiciel utilisé et développé dans l'organisation. La question est de savoir comment faire cela? Bien sûr, la meilleure description, du point de vue du BDD, est la description du comportement par des tests, sous laquelle se situera la pyramide des tests. Mais nous reviendrons immédiatement à notre dilemme en combinant plusieurs pyramides avec des cordes minces de haut en haut, le long desquelles notre funambule et ses utilisateurs marcheront sans assurance.
L'approche processus est une stratégie de gestion qui oblige les organisations à gérer leurs processus et les interactions entre eux. Ainsi, vous devez considérer chaque processus majeur de l'entreprise et ses processus de support.
Par conséquent, il est plus facile d'utiliser des abstractions - créez au moins un diagramme de processus, et indiquez ses entrées et sorties, rendez le processus contrôlé et mesurable, assurez l'interconnexion avec les processus parents et enfants, comme requis par ISO9000
Tous les processus ont:
• entrées;
• sorties;
• contrôle opérationnel;
• mesure et surveillance appropriées.
Chaque processus aura des processus de support qui sous-tendent et permettent au processus de se réaliser
Les diagrammes commerciaux sont les mieux adaptés à cet effet, et les normes telles que UML, BPMN, ARIS, etc. sont le plus souvent utilisées. Et les processus eux-mêmes deviennent des organigrammes avec des "cubes" accrochés dessus. Il y a interaction entre les «cubes», dans le standard BPMN c'est un flux d'actions et un flux de messages. Et c'est exactement ce dont nous avons besoin!
Toute entreprise qui souhaite avoir un certificat et respecte la norme ISO9000, a très probablement acquis de tels programmes, et ils font partie intégrante des exigences de haut niveau. Si l'entreprise a de bons analystes, alors, très probablement, les liens avec les exigences pour les actions individuelles des régimes vont descendre aux exigences de bas niveau. Nous en avons besoin.
En fait, sur les diagrammes, nous pouvons voir l'ensemble du processus et comprendre quel scénario nous devons créer et quel système / équipe exécuter avec quelles données à quel moment.
Je ne sous-estime pas le travail des développeurs qui écrivent du code compétent qui envoie des messages entre différentes parties des systèmes logiciels et matériels, mais il est impossible de tout garder à l'esprit. Et lorsque le processus est utilisé dans de nombreux autres processus, il est préférable d'avoir une telle «carte» avec vous pour effectuer des tests compétents, et plus encore pour construire un modèle de test.
Quoi en pratique
Nous avons donc deux introductions - chaque équipe \ système doit avoir une pyramide de tests préparée - des tests unitaires les plus petits aux tests système complexes, ainsi que le fait qu'au sein de l'organisation, nous devons décrire les exigences sous forme d'entreprise -processus. Ce fait nous permettra de répondre rapidement au client quel processus métier comment il fonctionne, et à quel moment il se casse, et nous-mêmes, lors de la réception des défauts de l'exploitation industrielle, effectuons rapidement une analyse des causes profondes (analyse des causes profondes des défauts). En théorie.
Mais en pratique, tout revient à nouveau au testeur - comment, à partir d'une pile de tests, en particulier étrangers, sélectionner les bons, les construire en chaîne, et à l'entrée de chacun des systèmes pour soumettre les données nécessaires et comparer avec le résultat attendu correctement déterminé?
L'option la plus simple consiste à développer initialement des tests basés sur des modèles commerciaux et à diviser les équipes en projets mettant en œuvre un processus métier particulier. Pour cela, dans certains outils de gestion des tests, il est déjà possible de charger des schémas BPMN (par exemple, pour HPE ALM - le chargement au format XPDL est pris en charge). HP ALM lui-même décomposera le schéma en un ensemble d'exigences (actions) et, si vous le souhaitez, créera une hiérarchie d'exigences (module Exigences-> Modèles commerciaux). Ensuite, il est de notre devoir de couvrir les exigences avec des tests, puis de construire les exigences, et donc les tests en chaînes qui couvrent notre processus métier. Ces chaînes dans HPE ALM sont appelées «chemins» et vous permettent de voir toutes les combinaisons de séquences. Si vous le souhaitez, les chaînes peuvent être immédiatement converties en tests.
Mais même si vous n'utilisez pas d'outils de test, vous devez quand même créer des chaînes à partir du processus métier. En particulier compte tenu de l'imperfection des outils (tout n'est pas si rose), ainsi que du fait que, très probablement, le modèle de test devra être assemblé post-factum et exécuté sous la forme d'une régression par une «équipe commune» qui n'est pas attachée à de nouveaux projets.
De combien de façons un écureuil peut-il atteindre une bosse?Dans ce cas, nous devrons ouvrir les tests de chaque équipe, trouver ceux qui sont liés aux exigences qui apparaissent dans le modèle économique et construire des chaînes à partir d'eux, en les sauvegardant dans un «espace commun». La création d'un espace commun est une sorte de substitut, mais dans tous les cas, cela devrait être, même sous la forme d'un livre de grange, d'Excel ou d'une zone de projet dans un outil de gestion des tests. Si nous parlons à nouveau de HPE ALM, le module BPT (Business Process Testing) est responsable de cette fonctionnalité, qui vous permet en même temps de transférer les résultats d'un test vers les paramètres d'un autre. Cependant, si vous le souhaitez et que vous travaillez dur sur HPE ALM, il est possible de l'implémenter en reconstruisant les ensembles de tests (Ensemble de tests) dans le flux d'exécution (Flux d'exécution). Ensuite, lors du démarrage de l'ensemble complet, les testeurs chargés de transmettre chacun des composants du script de bout en bout seront appelés tour à tour.
Et, hélas, les tests seuls ne suffisent pas. D'après ma pratique, presque tous les outils ont des défauts fatals, et donc, si vous arrivez au stade de tester l'automatisation dans un processus métier, vous arriverez à la création d'un script qui tirera les tests dans le bon ordre.
En conséquence, deux conclusions peuvent être tirées:
1) pour les scénarios de bout en bout, il est très probable que des tests développés précédemment soient utilisés pour chacun des systèmes inclus dans la chaîne de processus métier (scénario)
Il est possible de présenter toutes les suites de tests complètes d'une entreprise sous la forme d'une matrice clairsemée, où les tests pour chaque système sont répartis en colonnes (pour plus de simplicité - tests système), et les processus métier en lignes. Autrement dit, pour certains processus métier, vous devez sélectionner \ créer des tests couvrant le processus métier, établir des relations. S'il n'y a pas de couverture, c'est l'occasion de combler les lacunes du modèle de test, ou de s'assurer que la qualité est assurée par d'autres niveaux de test (tests d'intégration, tests unitaires, révision de code et exécution par des analyseurs).
2) Un outil est nécessaire pour surveiller, suivre et mettre à jour le processus métier pour la synchronisation avec le modèle de test.
Et si les outils de test gèrent de manière plus ou moins tolérable la création d'un modèle de test, alors tout est vraiment mauvais avec la mise à jour, il est souvent plus facile de recréer le modèle que d'essayer de voir les changements dans le processus et le modèle de test. Et l'expérience de vraies équipes suggère qu'il vaut mieux créer une visualisation en direct de l'architecture. La façon la plus simple de le faire est dans la zone commune, en utilisant un simple marqueur et des autocollants. Ensuite, les équipes qui participent au processus métier peuvent clairement voir comment le processus est modifié (les connexions sont supprimées et ajoutées, les actions sont supprimées et ajoutées). L'essentiel est que tout le monde ait accès au forum. De plus, notez que si le processus implique des messages entre les systèmes, alors, en règle générale, il devrait y avoir au moins deux tests de chaque système - pour l'envoi et la réception de données. Cependant, au lieu d'autocollants, vous pouvez utiliser une ville Lego entière (à partir de grands blocs), ou quelque chose d'encore plus créatif. L'essentiel ici est une langue et un espace d'information, ce qui fait très défaut dans l'entreprise.
En conclusion
Organiser des tests visuels et appropriés des processus métier est une chose complexe et très coûteuse. Veuillez noter que le test E2E n'est pas seulement une acceptation, un test utilisateur que le client effectuera, il construit un pont, prenant en compte toutes les situations possibles que le client suivra et conduira les utilisateurs dans le pied.
Encore une fois - E2E - ce n'est pas une promenade sur Lada Kalina à travers le pont, et même pas deux passages kamaz. C'est un travail d'ingénierie compliqué, peser des ponts avec des capteurs et effectuer toutes les vérifications et situations possibles - au moins une description de ces scénarios.
Que votre entreprise ait ou non besoin d'une telle finition idéale dépend exclusivement de vos objectifs et de vos besoins. Comme pour tout test, vous devez toujours évaluer les risques potentiels de défauts manquants à ce stade, ainsi que le coût de la préparation et de la conduite des tests de bout en bout. Évaluer ce qui vous coûtera plus cher et agir ensuite. Mais dans le cas de tests de bout en bout sur les processus métier, il convient de rappeler que cela n'a pas de sens sans une base solide sous la forme de tests unitaires de passage à 100% (~ 90-100% de couverture), sans tests d'intégration (~ 60-80% de couverture, 90- 100% de taux de réussite), sans tests système (couverture 20-40%, taux de réussite 80-100%). L'établissement de critères de réussite (portes de qualité) est plus une exigence pour la qualité du produit, la principale chose à retenir ici est que le volume des tests E2E n'est que le sommet de la pyramide (couverture de 1-2%, ~ 99% de passage), qui ne devrait pas être plus grand que sa base, non en même temps être un bouchon de trous des étapes précédentes. Il s'agit d'un supplément qui a priori est considéré comme clos aux étapes précédentes.
L'organisation de tels tests consiste principalement à préparer et synchroniser des cas de test et des données (analyses de tests), ainsi qu'un ensemble de mesures organisationnelles, synchronisant les équipes en un seul endroit en même temps sur un site de test réalisable. En gardant cela à l'esprit, il ne faut pas essayer de montrer au client des «tests de bout en bout» avant la date prévue afin de ne pas perdre de temps à la fois un grand nombre de personnes sans que tous les composants de travail soient assemblés.
PS a décrit les outils, ainsi que les pratiques - purement par exemple, l'auteur ne s'est pas fixé pour objectif de faire la publicité des produits et de déclarer cette approche du test de bout en bout la seule vraie manière.