Commençons par le doux et donnons des exemples de tests.
Imaginez une boutique en ligne prête à être lancée. Rien n'augure rien. Les spécialistes du marketing ont élaboré une stratégie de promotion, des articles ont été rédigés dans des ressources Internet spécialisées et la publicité a été payée. La direction prévoyait jusqu'à 300 achats par semaine. La première semaine passe, les gérants enregistrent 53 paiements. La direction du magasin est furieuse ...
Le chef de projet court à la recherche de raisons: le manque de réflexion sur l'utilisabilité? trafic inapproprié? autre chose? Nous avons commencé à comprendre, à étudier le système d'analyse de données. Il s'est avéré que 247 personnes ont atteint la caisse et seulement 53 ont payé.
L'analyse a montré que les autres ne pouvaient pas faire d'achat à cause de l'adresse e-mail!
Le test du bon de commande a été confié à un spécialiste débutant. Il a fait de son mieux, entré dans les champs "Nom", "Email", "Téléphone" toutes les options possibles et impossibles qui lui ont donné des générateurs en ligne. Une semaine plus tard, tous les bugs ont été trouvés et corrigés. La libération a eu lieu. Mais parmi les options envisagées, il n'y avait pas une seule adresse e-mail contenant moins de 8 caractères après @.
Ainsi, les heureux propriétaires de mails @ mail.ru, @ ya.ru (et similaires) n'ont pas pu entrer leur courrier et ont quitté le site sans magasiner. Les propriétaires ont reçu moins de 600 000 roubles, tout le budget publicitaire a été vidé dans le vide et la boutique en ligne elle-même a reçu de nombreuses critiques négatives.
Pensez-vous que ce soit un cas isolé? Alors voici une autre histoire d'horreur pour le client.
Dans le sillage de l'intérêt général pour les paiements sans numéraire, la société de prêt a décidé d'introduire une nouvelle façon de transférer des fonds - sur la carte bancaire de l'emprunteur. Nous avons implémenté le formulaire approprié dans le compte personnel du responsable, testé diverses options d'erreur dans les champs de saisie des données de carte, corrigé ces dernières et commencé à travailler. Un mois plus tard, la direction a appris que 24% des emprunteurs potentiels qui avaient déjà reçu l'approbation n'ont pas demandé de prêt avant la fin. Pourquoi? Ils ont fourni une carte bancaire, dont le nombre contenait 18 chiffres, au lieu de ceux promis et testés 16. Ni le système ni les gestionnaires n'ont pu enregistrer de telles cartes, et les clients sont partis sans rien.
Le projet pilote a été mis en œuvre dans 3 bureaux de la ville. Le nombre moyen de prêts mensuels dans trois bureaux était de 340. Résultat: l'organisation a perdu au moins 612 000 roubles. revenus.
Ce ne sont que quelques exemples où des données synthétiques peuvent entraîner de graves pertes sur un projet. De nombreux testeurs saisissent des données synthétiques afin de tester divers projets - des applications mobiles aux logiciels. Dans ce cas, les testeurs proposent eux-mêmes des situations de test, essayant de prédire le comportement des utilisateurs.
Cependant, le plus souvent, ils voient l'utilisateur non multidimensionnel, comme dans un cinéma avec des lunettes 3D, mais sommaire, comme si l'enfant peignait un petit homme sur une feuille d'album.
Cela conduit au fait que le testeur ne couvre pas toutes les situations de test possibles et ne peut pas travailler avec une grande quantité de données. Et, bien que les tests puissent être bien effectués, rien ne garantit que le système ne tombera pas lorsqu'un utilisateur réel (le plus souvent illogique et même imprévisible) commence à interagir avec le produit.
Aujourd'hui, nous allons parler des données à privilégier dans le processus de test: synthétiques ou réelles.
Nous comprendrons en termes
Chaque fois que nous effectuons un test, nous décidons quelles données de test nous utiliserons. Leurs sources peuvent être:
- Copies de la base de données de production sur le banc d'essai.
- Base de données de systèmes clients tiers pouvant être utilisés dans le système actuel.
- Générateurs de données de test.
- Création manuelle des données de test.
Les 2 premières sources nous fournissent de vraies données de test. Ils sont créés par des processus existants par les utilisateurs ou le système.
Par exemple, lorsque nous nous joignons à un projet de développement d'un produit Web pour une entreprise de fabrication, nous pouvons utiliser une copie de la base de données 1C existante pour les tests, qui depuis plusieurs années recueille et traite toutes les données sur les opérations et les clients. En utilisant le module pour générer et afficher des rapports sur les commandes terminées, nous obtenons des informations de 1C dans le format requis et travaillons avec des données de test réelles.
Nous appelons les sources des points 3 et 4 «données de test synthétiques» (un tel terme peut être trouvé dans des tests à l'étranger, mais il est rarement utilisé dans le segment de langue russe). Nous créons nous-mêmes ces données à des fins de développement et de test.
Par exemple, nous avons reçu une commande d'une nouvelle plate-forme de commerce électronique pour les achats par des organisations étatiques et municipales en vertu de 44 lois fédérales. Ici, des règles de protection des informations très strictes sont suivies, de sorte que l'équipe n'a pas accès aux données réelles. La seule issue pour les tests est de créer un ensemble complet de données de test à partir de zéro. Même les signatures numériques physiques qui sont uniquement destinées aux tests.
Dans notre pratique, un type de données est rarement utilisé, nous travaillons généralement avec une combinaison de celles-ci en fonction de la tâche.
Pour vérifier les limitations et exceptions dans le même système pour l'entreprise de fabrication, nous avons également utilisé des données synthétiques. Avec leur aide, nous avons vérifié le comportement du rapport s'il n'y a aucun produit dans l'une des commandes. Sur une plateforme de trading électronique, nous avons combiné des données synthétiques avec de vrais livres de référence OKPD2 et OKVED2.
Capacités de données synthétiques
Dans certaines situations, les données synthétiques ne peuvent tout simplement pas être supprimées! Voyons quelles tâches ils peuvent être utilisés dans l'arsenal du testeur:
1. Simplification et standardisation
Souvent, les données réelles sont des tableaux de données homogènes: imaginez que des milliers d'individus avec un ensemble d'attributs, des entités juridiques de différents types, des opérations standard et de nombreux autres types d'entités sont enregistrés dans le système. Alors pourquoi passer des heures à tester la même entrée, si vous pouvez les combiner en groupes et nommer un «représentant» pour chaque groupe?
Lors d'un des projets de l'année dernière, le client a décidé de renforcer l'équipe de testeurs avant la prochaine version, pour laquelle une équipe de nos spécialistes était impliquée. Le produit contenait un formulaire d'enregistrement modifié avec de nombreux champs. Nous avons présenté les formulaires de test pendant 30 minutes et avons passé environ le même temps. En parallèle, il a été révélé qu'un autre testeur avait déjà testé ce formulaire, après y avoir passé 7 heures. Pourquoi? Il vient de décider d'exécuter le test en fonction des données réelles de 12 employés de la liste du personnel et n'a pas tenu compte du fait que le test pour un employé couvre tous les attributs qui sont les mêmes pour chaque profil enregistré.
Bénéfice: 6 heures 30 minutes et ce n'est que sur un seul test.
2. Combinatoire et couverture des tests
Malgré la quantité souvent importante de données réelles, elles peuvent ne pas contenir un certain nombre de cas possibles. Afin de garantir l'opérabilité du système avec différentes combinaisons de données d'entrée, nous devons les générer nous-mêmes.
Revenons à l'exemple précédent. Le formulaire d'inscription dans la nouvelle version a été finalisé pour une raison. L'équipe client, basée sur les normes de la culture d'entreprise, a décidé de rendre obligatoire le deuxième prénom. En conséquence, tous les spécialistes étrangers de l'État ont soudainement eu un père - Ivan (quelqu'un a dit d'écrire Ivanovich jusqu'à ce qu'il le répare). L'affaire est drôle, mais si vous ne tenez pas compte de certaines listes de souhaits ou des paramètres de vos clients dans les tests, alors ne soyez pas offensé si ces personnes ne vous prennent pas en compte dans leurs coûts / avis.
3. Automatisation
Dans les tests automatisés, les données synthétiques sont indispensables. Même des modifications apparemment insignifiantes des données peuvent affecter le fonctionnement de tout un ensemble de tests.
Un exemple du secteur bancaire sera illustratif ici. Afin de vérifier si l'application inscrit correctement les numéros de compte bancaire dans les documents qu'elle génère, nous avons passé 120 personnes / heures à rédiger des autotests. Il n'y avait pas d'accès à la base de données, car le numéro de compte était indiqué dans l'autotest lui-même. Les tests ont montré d'excellents résultats et nous étions prêts à tirer 180% + ROI de l'automatisation dans le rapport. Mais une semaine plus tard, la base de données a été mise à jour avec un changement de numéro de compte. Tous les autotests, ainsi que nos efforts d'automatisation, se sont terminés en toute sécurité. Après révision des autotests, le ROI final est tombé à 106%. Avec le même succès, nous avons pu immédiatement commencer à tester avec nos mains.
4. Amélioration de la gérabilité
En utilisant des données synthétiques, nous savons (dans le pire des cas, nous supposons) quel type de réponse attendre du système. Si des modifications sont apportées à la fonctionnalité, nous comprenons comment la réponse aux mêmes données changera. Ou nous pouvons ajuster les données pour obtenir le résultat souhaité.
Dans l'un des projets, notre équipe a commencé à tester en utilisant des données réelles de la base de données des contreparties du client. La base de données a été activement affinée, mais à cette époque, elle a été compilée de façon extrêmement négligente. Nous avons perdu du temps à essayer de comprendre où se trouve l'erreur, dans la fonctionnalité ou dans la base de données. La solution était simple, composer une base de données synthétique, devenue plus courte, mais plus adéquate et plus informative. Le test de cette fonctionnalité a été effectué en 12 personnes / heure.
Quels sont donc les inconvénients?
Les données synthétiques peuvent sembler omnipotentes. Il en est ainsi, jusqu'à ce que vous rencontriez le facteur humain. Les données synthétiques sont créées intentionnellement par des personnes et c'est leur principal inconvénient. Nous ne pouvons physiquement pas réfléchir à tous les scénarios et combinaisons possibles de facteurs d'entrée (et personne n'a annulé la force majeure). Et ici, l'avantage reste pour les données réelles.
Les avantages de travailler avec des données réelles
Quels avantages voyons-nous à travailler avec des données réelles? 4 preuves de notre expérience:
1. Travaillez avec de grandes quantités d'informations
Le fonctionnement réel du système nous fournit des millions d'opérations. Répéter le travail simultané de milliers d'utilisateurs ou la génération automatique de données ne pourra pas à n'importe quelle équipe de spécialistes.
Preuve: nous avons créé une mini-base de données synthétique qui, il nous a semblé, répondait à tous les critères de la base existante du client. Avec une base synthétique, tout fonctionnait très bien, mais dès que vous exécutez des tests avec une vraie base, tout tombait. Conclusion: si vous ne pouvez pas prendre en compte toutes les nuances d'un véritable échantillon de données, ne perdez pas de temps à générer des données synthétiques.
2. Utilisation d'une variété de formats de données
Texte, son, vidéo, images, fichiers exécutables, archives - il est impossible de prédire ce que l'utilisateur décide de télécharger dans le champ du formulaire. Les conseils sur les formats acceptés peuvent être ignorés et l'interdiction de téléchargement peut ne pas être mise en œuvre par l'équipe de développement. En conséquence, les scénarios souhaités sont testés. Par exemple, que dans le domaine du téléchargement de son, il est en effet possible de télécharger un fichier mp3 et que le téléchargement d'un fichier exécutable ne nuira pas au système. Les données réelles nous aident à suivre les exceptions.
Preuve: nous avons testé le champ de téléchargement de photos dans le profil utilisateur. Nous avons essayé les formats graphiques les plus courants de la base de données, ainsi que plusieurs fichiers vidéo et texte. Compilation synthétique chargée parfaitement. En utilisation réelle, il s'est avéré que toute tentative de téléchargement d'un fichier son provoquait une erreur. Le formulaire d'inscription entier s'est écrasé sans possibilité de remplacer le fichier. Même une actualisation de page n'a pas été enregistrée.
3. Imprévisibilité du comportement des utilisateurs
Bien que de nombreux spécialistes de l'assurance qualité aient réussi à créer et à analyser des situations exceptionnelles, soyons honnêtes - nous ne pourrons jamais prédire avec précision le comportement d'une personne et les facteurs qui l'entourent. Et vous pouvez commencer par désactiver Internet au moment de l'opération et terminer par des opérations avec le code du programme et les fichiers internes.
Preuve: dans notre entreprise, chaque année, les employés sont certifiés, où ils évaluent, entre autres, leurs compétences dans un questionnaire spécial. Les estimations sont convenues avec le chef et sur la base de celles-ci, le grade (niveau) du spécialiste est calculé. Avant la sortie, le module était entièrement testé, tout fonctionnait comme une horloge. Mais une fois, au moment de l'enregistrement des résultats, une attaque ddos a été effectuée sur le système, à la suite de laquelle seule une partie des données a été enregistrée, et les tentatives ultérieures de sauvegarde n'ont fait que dupliquer les erreurs. Sans une situation réelle, nous n'aurions pas retracé une erreur aussi grave.
4. Mises à jour du système
Il est très important de comprendre comment le système se comportera pendant la mise à niveau, quels sont les risques possibles, ce qui peut «ne pas décoller». Dans des programmes tels que 1C, où un grand nombre de répertoires et de liens, le problème des mises à jour est particulièrement aigu. Et ici, la meilleure option serait d'avoir une nouvelle copie de la version de production, de tester la mise à jour sur celle-ci, puis de la publier.
Preuve: le cas est assez courant. Projet dans le domaine des services d'affacturage. La criticité de la perte et de la distorsion des données est écrasante, et tout soupçon de la pertinence des données reproduites par le système peut arrêter l'ensemble du bureau. Et ici, notre spécial déploie de manière tordue la prochaine mise à jour immédiatement pour le prod, sans capturer les 10 dernières versions des versions.
Ils ont été déployés à 18 h 00 le matin, à 11 heures. En raison de l'échec de la finalisation et de l'incompréhension des versions, le travail des divisions de l'entreprise a été complètement gelé pendant 2 heures. Les gestionnaires ne pouvaient pas traiter les contrats actuels et en enregistrer de nouveaux.
Depuis, nous travaillons avec trois stands sans faute:- Développer. Des améliorations sont décrites ici, l'anarchie et l'anarchie se poursuivent, appelés tests d'exception. Les ingénieurs QA travaillent principalement avec des données synthétiques, les vraies sont rarement infusées.
- Pré-libération. Lorsque toutes les améliorations sont implémentées et testées, elles vont dans cette branche. Une version avec une vente est également présentée de manière préliminaire ici. Ainsi, nous testons la mise à jour et le fonctionnement de nouvelles fonctions dans des conditions de combat conditionnelles.
- Production. Il s'agit d'une version de combat et fonctionnelle du système avec lequel les utilisateurs finaux travaillent.
Alors, quelles données et quand travailler?
Nous partageons 3 perspectives de notre travail avec des données réelles et synthétiques:
1. N'oubliez pas que le choix du type de données dépend des objectifs et du stade du test. Ainsi, en développant un nouveau système, nous ne pouvons fonctionner qu'avec des données synthétiques. Pour couvrir diverses combinaisons de conditions d'entrée, nous nous tournons également le plus souvent vers elles. Mais la reproduction d'une exception délicate liée au comportement de l'utilisateur nécessitera de vrais journaux. Il en va de même pour travailler avec des répertoires et des registres généralement acceptés.
2. N'oubliez pas d'optimiser votre travail avec des données de test. Dans la mesure du possible, utilisez des générateurs, créez des registres communs d'entités de base, enregistrez et utilisez des sauvegardes système à temps, en les déployant au bon moment. Alors la préparation du prochain projet ne sera pas pour vous une source de mélancolie et de morosité, mais une des étapes du travail.
3. N'allez pas du côté des synthétiques solides, mais ne vous concentrez pas sur des données réelles. Utilisez une approche combinée pour tester les données afin de ne pas manquer les erreurs, gagner du temps et afficher un maximum de résultats dans votre travail.
Malgré le fait que le synthétique prophétise un grand avenir et que les scientifiques ont vu dans les données synthétiques un nouvel espoir pour l'intelligence artificielle, le synthétique n'est pas une panacée pour les tests. Il s'agit simplement d'une autre approche pour générer des données de test qui peuvent vous aider à résoudre vos problèmes et en conduire à de nouveaux. Connaître les forces et les faiblesses des données réelles / synthétiques, ainsi que la capacité de les appliquer au bon moment, est ce qui vous protège contre les pertes, les temps d'arrêt ou les actions en justice. J'espère qu'aujourd'hui nous vous avons aidé à devenir un peu plus en sécurité. Ou pas?
Discutons. Dites-nous dans les commentaires sur vos cas de travail avec des données de test synthétiques et réelles. Voyons qui parmi nous est le plus: réaliste ou synthétique? ;)
Victoria Sokovikova.
Test Analyst chez Quality Laboratory