Hé Habr !
Nous avons un nouveau sujet important : le développement de haute qualité de produits informatiques. Chez HighLoad++, nous parlons souvent de la façon de rendre rapides les services occupés, et chez Frontend Conf, nous parlons d'une interface utilisateur sympa qui ne ralentit pas. Nous avons régulièrement des sujets sur les tests et DevOpsConf sur la combinaison de différents processus, y compris les tests. Mais sur ce que l'on peut appeler la qualité en général et comment y travailler de manière globale - non.
Réparons cela en — nous développerons une culture de réflexion sur la qualité du produit final pour l'utilisateur à chaque étape du développement. L'habitude de ne pas se concentrer sur votre domaine de responsabilité, et d'associer la qualité non seulement aux testeurs.
En dessous de la coupe, nous discuterons avec le chef du comité de programme, responsable des tests chez Tinkoff.Business, créateur de la communauté russophone d'assurance qualité Anastasia Aseeva-Nguyen sur l'état de l'industrie de l'assurance qualité et la mission de la nouvelle conférence.
- Nastia bonjour. Parlez-nous de vous.
Anastasia: Je gère les tests dans une banque, je suis responsable d'une très grande équipe - nous sommes plus de 90 personnes. Nous avons un métier important, nous sommes responsables de l’écosystème des personnes morales.
J'ai étudié la mécanique et les mathématiques et je voulais au départ devenir programmeur. Mais lorsque j'ai reçu une offre intéressante, j'ai décidé de m'essayer en tant que testeur. Curieusement, cela s’est avéré être ma vocation. Maintenant, je vois tout mon travail dans cette industrie.
Je suis un fervent adepte de la discipline Assurance Qualité. Je ne suis pas indifférent aux produits créés, à la manière dont la qualité est traitée dans l'entreprise, dans l'équipe et, en principe, dans le processus de développement.
C'est évident pour moi que la communauté dans ce sens n'est pas assez mature, du moins en Russie. On ne comprend pas toujours que l’assurance qualité ne consiste pas seulement à tester la conformité d’une application aux exigences. J'aimerais changer cette situation.
— Vous utilisez les mots assurance qualité et tests. Aux yeux du citoyen moyen, ces deux termes se chevauchent très souvent. En quoi diffèrent-ils si vous creusez profondément ?
Anastasia: Au contraire, ils ne sont pas différents. Les tests font partie de la discipline d'assurance qualité ; c'est une activité directe - le fait même que je teste quelque chose. Il existe en fait de nombreux types de tests, et diverses personnes sont responsables de différents types de tests. Mais ici, en Russie, lorsqu'est apparue une vague de sous-traitants fournissant des testeurs aux entreprises, les tests ont été réduits à un seul type.
Dans la plupart des cas, ils se limitent uniquement aux tests fonctionnels : ils vérifient que ce que les développeurs ont codé est conforme à la spécification et c’est tout.
— Veuillez nous indiquer quelles autres disciplines d'assurance qualité existent ? Qu'est-ce qui est inclus ici, à part les tests ?
Anastasia: L'assurance qualité consiste avant tout à créer un produit de qualité. Autrement dit, nous nous demandons quels attributs de qualité notre produit devrait avoir. En conséquence, si nous comprenons cela, nous pouvons comparer qui influence ces attributs de qualité. Cela n'a pas d'importance, développeur, chef de projet ou spécialiste produit est une personne qui influence le développement d'un produit, son backlog et sa stratégie.
Le testeur devient plus conscient de son rôle. Il comprend que sa tâche n'est pas seulement de tester le respect des exigences, mais aussi de tester les exigences, de remettre en question les formulations émanant du spécialiste produit et de révéler toutes les exigences et attentes implicites du client. Lorsque nous livrons de nouvelles fonctionnalités à nos clients, nous devons véritablement répondre à leurs attentes et résoudre leurs problèmes. Si nous réfléchissons à tous les attributs de la qualité, le client sera satisfait et comprendra que l'entreprise dont il utilise le produit se soucie vraiment de ses intérêts et ne travaille pas selon le principe « juste pour publier une fonctionnalité ».
— Il semble que ce que vous venez de décrire relève de la tâche d'un spécialiste produit. En principe, il ne s’agit pas de tests ni de qualité – il s’agit généralement de gestion de produits, non ?
Anastasia: Y compris. L'assurance qualité n'est pas une discipline dont une seule personne est responsable. Il existe désormais une direction populaire en matière de tests, une approche appelée Test agile. Sa définition indique clairement qu'il s'agit d'une approche de test en équipe, qui comprend un certain ensemble de pratiques. Toute l’équipe est responsable de la mise en œuvre de cette démarche ; il n’est même pas nécessaire qu’il y ait un testeur dans l’équipe. Toute l’équipe se concentre sur la fourniture de valeur au client et veille à ce que cette valeur réponde à ses attentes.
— Il s'avère que la qualité recoupe presque toutes les disciplines environnantes, imposant un cadre à tout ce qui l'entoure ?
Anastasia: Droite. Lorsque nous réfléchissons à la manière dont nous voulons créer un produit de qualité, nous commençons à réfléchir aux différents attributs de la qualité. Par exemple, comment vérifier que nous avons réellement créé la fonctionnalité dont notre client a besoin.
C’est là qu’intervient ce type de tests : UAT (tests d'acceptation des utilisateurs). Malheureusement, il est rarement pratiqué en Russie, mais est parfois présent dans les équipes SCRUM en démonstration pour le client final. Il s'agit d'un type de test assez courant dans les entreprises étrangères. Avant d'ouvrir la fonctionnalité à tous les clients, nous effectuons d'abord l'UAT, c'est-à-dire que nous invitons l'utilisateur final à tester et à donner immédiatement son avis - si le produit répond réellement aux attentes et résout le problème. Ce n'est qu'après cela que la mise à l'échelle vers tous les autres clients a lieu.
Autrement dit, nous nous concentrons sur le business, sur le client final, mais en même temps n'oubliez pas la technologie. La qualité du produit dépend également en grande partie de la technologie. Si nous avons une mauvaise architecture, nous ne pourrons pas publier rapidement des fonctionnalités et répondre aux attentes des clients. Il peut y avoir beaucoup de bugs lors de la tentative de mise à l'échelle, ou lorsque nous essayons de refactoriser, nous pouvons casser quelque chose. Tout cela affectera la satisfaction du client.
De ce point de vue, l'architecture doit être telle que l'on puisse écrire du code propre qui nous permettra d'apporter des modifications rapidement et de ne pas avoir peur de tout casser. Pour que les itérations de révision ne s'étendent pas sur plusieurs mois simplement parce que nous avons tellement d'héritage et que nous devons faire de longues étapes de tests.
— Au total, les développeurs, les architectes, les scientifiques produits, les chefs de produit et les testeurs eux-mêmes sont déjà impliqués. Qui d’autre est impliqué dans le processus d’assurance qualité ?
Anastasia: Imaginons maintenant que nous ayons déjà livré la fonctionnalité au client. Évidemment, la qualité du produit doit être surveillée même lorsqu’il est déjà en production. À ce stade, des situations avec des scénarios non évidents, appelés bugs, peuvent apparaître.
La première question est de savoir comment gérer ces bugs après avoir déjà publié le produit ? Comment réagissons-nous, par exemple, au stress ? Le client ne sera pas très content si la page met plus de 30 secondes à se charger.
C'est là qu'intervient l'exploitation ou, comme on l'appelle maintenant, DevOps. En fait, ce sont ces personnes qui sont chargées de faire fonctionner le produit lorsqu’il est déjà en production. Cela inclut différents types de surveillance. Il existe même un sous-type de tests : les tests en production, lorsque nous nous permettons de ne pas tester quelque chose avant le déploiement et de le tester immédiatement en production. Il s'agit d'un ensemble de mesures du point de vue de l'organisation des infrastructures qui permettent de réagir rapidement à un incident, de l'influencer et de le corriger.
Les infrastructures sont également importantes. Il arrive souvent que lors d'un test, il soit impossible de s'assurer que l'on a vraiment tout ce que l'on aimerait donner au client. Nous le déployons en production et commençons à détecter les situations non évidentes. Et tout cela parce que l'infrastructure en test ne correspond pas à l'infrastructure en production. Cela conduit à un nouveau type de tests - tests d'infrastructures. Il s'agit de diverses configurations, paramètres, migration de bases de données, etc.
Cela soulève la question : peut-être que l'équipe doit utiliser l'infrastructure comme code.
Je crois que l'infrastructure affecte directement la qualité du produit.
J'espère qu'il y aura un rapport à la conférence avec un cas réel. Écrivez-nous si vous êtes prêt à nous raconter, à partir de votre propre expérience, comment l'infrastructure en tant que code affecte la qualité. L'infrastructure en tant que code facilite la vérification de tous les paramètres et teste des choses qui autrement ne seraient tout simplement pas possibles. L’exploitation participe donc également au processus de développement d’un produit de qualité.
— Qu'en est-il de l'analyse et de la documentation ?
Anastasia: Cela s'applique davantage aux systèmes d'entreprise. Lorsque nous parlons d’entreprise, des personnes telles que les analystes et les analystes de systèmes viennent immédiatement à l’esprit. Ils sont parfois appelés rédacteurs techniques. Ils reçoivent une tâche pour rédiger un cahier des charges et le compléter, par exemple, pendant un mois.
Il a été prouvé à plusieurs reprises que l'écriture d'une telle documentation entraîne de très longues itérations de développement et de longues itérations de raffinement, car pendant le processus de test, des bogues sont identifiés et les retours commencent. En conséquence, de nombreuses boucles augmentent les coûts de développement. De plus, cela peut introduire des vulnérabilités. Il semble que nous ayons écrit du code de référence, mais nous avons ensuite apporté des modifications qui cassent l'architecture parfaitement pensée.
Le résultat final n'est pas un produit entièrement de haute qualité, car des correctifs sont déjà apparus dans l'architecture, le code à certains endroits n'est pas suffisamment couvert par les tests, car les délais sont comptés, tous les bugs doivent être corrigés rapidement. Et tout cela parce que la spécification originale n'a pas pris en compte tous les points qui doivent être mis en œuvre.
Les développeurs ne sont pas des nuisibles et n’écrivent pas volontairement du code contenant des erreurs.
Si nous avions initialement réfléchi à un cahier des charges qui couvrirait tous les points nécessaires, alors tout aurait été mis en œuvre exactement comme nécessaire. Mais c'est une utopie.
Il est probablement impossible de rédiger un cahier des charges parfait de 100 pages. C'est pourquoi il faut réfléchir à des façons alternatives de rédiger la documentation, des spécifications, la définition de tâches qui nous rapprocheraient de la garantie que le développeur fait exactement ce qui est nécessaire.
Ici, les approches Agile viennent à l'esprit - des témoignages d'utilisateurs avec des critères d'acceptation. Ceci est plus applicable aux équipes qui se développent en petites itérations.
— Qu'en est-il des tests d'utilisabilité, de l'utilisabilité du produit, de la conception ?
Anastasia: C'est un point très important, car il y a des designers dans l'équipe. Le plus souvent, les designers sont utilisés en tant que service – soit par un département de design, soit par un designer externalisé. Il arrive souvent que le concepteur ait écouté le spécialiste produit et ait fait ce qu'il avait compris. Mais lorsque nous commençons l'itération, il s'avère que ce qui a été réellement fait n'était pas ce qui était attendu : le concepteur a oublié quelque chose, n'a pas complètement réfléchi au comportement, car il ne fait pas partie de l'équipe et n'est pas dans le contexte, ni devant -le développeur final n'a pas complètement compris sa disposition. Cela peut prendre plusieurs itérations simplement parce qu'il y a un problème avec le développeur front-end qui comprend la conception.
De plus, il y a un autre problème. Les systèmes de conception gagnent désormais en popularité. Ils sont à la mode, mais leurs avantages ne sont pas tout à fait évidents.
J'ai l'impression que les systèmes de conception, d'une part, simplifient le développement, mais d'autre part, ils imposent de nombreuses restrictions sur l'interface.
En conséquence, nous ne réalisons pas la fonctionnalité souhaitée par le client, mais celle qui nous convient, car nous disposons déjà de certains cubes à partir desquels nous pouvons la réaliser.
Je pense que c'est un sujet qui mérite d'être examiné et de se demander si en essayant de faciliter la conception, nous résolvons réellement un problème du client.
— Il existe un nombre surprenant de sujets liés à l'assurance qualité. Existe-t-il une conférence en Russie où tous ces sujets pourraient être discutés ?
Anastasia: Il y a la conférence de test la plus ancienne, qui aura lieu pour la 25e fois cette année et s'appelle la conférence sur l'assurance qualité des SQA Days. Il traite principalement des outils et des approches de test spécifiques pour les testeurs fonctionnels. En règle générale, les rapports des SQA Days examinent en profondeur des domaines spécifiques relevant de la responsabilité des testeurs eux-mêmes, mais pas des activités complexes.
Cela aide beaucoup à comprendre les différents outils et approches, comment tester les bases de données, les API, etc. Mais en même temps, d’une part, cela ne motive pas à impliquer plus que de simples tests dans la création d’un meilleur produit. En revanche, les testeurs ne s’impliquent pas davantage dans le processus de réflexion sur l’objectif global du produit et de sa composante métier.
Je dirige un grand département et je mène de nombreux entretiens qui donnent un véritable aperçu de l’état de l’industrie dans son ensemble. En règle générale, nos gars travaillent dans des entreprises et ont un domaine de responsabilité clair. Les collègues qui travaillent sur des projets à l'étranger utilisent différents types de tests : ils peuvent eux-mêmes faire des tests de charge, des tests de performances et même parfois des tests de sécurité, car ils aident vraiment l'équipe à garantir la qualité du produit.
J’aimerais que les Russes commencent également à penser que l’industrie ne s’arrête pas aux tests fonctionnels.
— À cet effet, nous organisons une nouvelle conférence, QualityConf, dédiée à la qualité en tant que discipline à part entière. Parlez-nous de l’idée, quel est l’objectif principal de la conférence ?
Anastasia: Nous voulons créer une communauté de personnes intéressées par la fabrication de produits de qualité. Offrez une plateforme où ils peuvent venir, écouter les rapports et repartir après la conférence avec une compréhension précise de ce qui doit être changé pour améliorer la qualité.
De nos jours, j'entends souvent des demandes de consultants sur ce qu'il faut faire en cas de problèmes de test et de qualité. Lorsque vous commencez à communiquer avec les équipes, vous constatez que le problème ne vient pas des testeurs eux-mêmes, mais de la façon dont le processus est structuré. Par exemple, lorsque les développeurs estiment qu’ils sont uniquement responsables de l’écriture du code, leur responsabilité prend fin au moment précis où ils confient la tâche aux tests.
Tout le monde ne pense pas qu'un code mal écrit et de mauvaise qualité avec une architecture médiocre menace de gros problèmes pour le projet. Ils ne pensent pas au coût des erreurs, au fait que les bugs qui se retrouvent en production peuvent entraîner des coûts importants pour l'entreprise et l'équipe. Il n’y a pas de culture pour penser à cela. Je veux que nous commencions à le distribuer lors de la conférence.
Je comprends qu'il ne s'agit pas d'une innovation. Edward Deming, l'auteur des 14 principes de la qualité, a écrit sur le coût d'une erreur au siècle dernier. L'assurance qualité en tant que discipline est basée sur ce livre, mais malheureusement le développement moderne l'oublie.
— Envisagez-vous d'aborder des sujets directement liés aux tests et aux outils ?
Anastasia: J'avoue qu'il y aura des rapports sur les outils. Il existe des outils assez universels avec lesquels les entreprises et les équipes peuvent influencer le produit.
Tous les rapports seront globalement unis par une mission commune : transmettre au public qu'avec l'aide de cette approche, outil, méthode, processus, type de test, nous avons influencé la qualité du produit et amélioré la vie du client.
Nous n’aurons certainement pas de rapports sur un outil pour le plaisir d’un outil. Tous les rapports inclus dans le programme seront unis par un objectif commun.
— Qui sera intéressé par ce dont vous parlez, qui considérez-vous comme les invités de la conférence ?
Anastasia: Nous aurons des rapports pour les développeurs soucieux du sort de leur projet, produit, système. De même, cela intéressera les testeurs et, me semble-t-il, surtout les managers. Par managers, j'entends les personnes qui prennent des décisions et peuvent également influencer le sort et le développement d'un produit, d'un système, d'une équipe.
Ce sont des personnes qui se demandent comment améliorer la qualité d’un produit ou d’un système. Lors de notre conférence, ils découvriront différents ensembles de mesures et seront en mesure de comprendre ce qui ne va pas chez eux actuellement et ce qui doit être changé.
Je pense que le critère principal est de comprendre que quelque chose ne va pas avec la qualité et de vouloir l'influencer. Nous ne pourrons probablement pas atteindre les personnes qui pensent que cela suffira du premier coup.
— Pensez-vous que l'industrie dans son ensemble est prête à parler non seulement de tests, mais aussi d'une culture de la qualité ?
Anastasia: Je pense que j'ai mûri. Aujourd’hui, de nombreuses entreprises s’éloignent de l’approche traditionnelle Waterfall pour se tourner vers Agile. Il y a une orientation client, les membres des équipes commencent vraiment à réfléchir à la manière de créer un produit de qualité. Même les entreprises se recentrent sur l’amélioration de la qualité.
À en juger par le nombre de demandes qui surgissent dans la communauté, je crois qu'il est temps. Je ne suis bien sûr pas sûr qu’il s’agisse d’une révolution à grande échelle, mais j’aimerais que cette révolution des consciences se produise.
- Convenu! Nous inculquerons la culture et changerons les consciences.
Conférence sur le développement de haute qualité de produits informatiques tenue à Moscou le 7 juin. Vous savez quelles étapes constituent un produit de haute qualité, nous avons des cas de lutte réussie contre des bugs en production, nous avons testé des méthodes populaires dans notre pratique - nous avons besoin de votre expérience. leur candidatures avant le 1er mai, et le comité du programme aidera à cibler le thème pour l'intégrité globale de la conférence.
Connectez-vous à , dans lequel nous discutons des problèmes de qualité et de la conférence, abonnez-vous à pour rester informé de l'actualité du programme.
Source: habr.com