Salut, Habr !
Nous avons un nouveau sujet important : le développement de produits IT de qualité. Nous parlons souvent lors de HighLoad++ de la manière de rendre les services lourds rapides, et lors de Frontend Conf, d'une interface utilisateur géniale qui ne ralentit pas. Nous avons régulièrement des sujets sur les tests, et DevOpsConf aborde l'intégration de divers processus, y compris les tests. Mais en ce qui concerne ce que l'on peut appeler la qualité dans son ensemble et comment y travailler de manière globale - il n'y a rien.
Nous allons corriger cela à — nous allons développer la culture de penser à la qualité du produit final pour l'utilisateur à chaque étape du développement. L'habitude de ne pas se focaliser uniquement sur sa zone de responsabilité, et d'associer la qualité non seulement aux testeurs.
En dessous, nous discuterons avec la présidente du comité de programme, responsable des tests chez Tinkoff.Business, créatrice de la communauté QA russophone Anastasia Aseeva-Nguen sur l'état de l'industrie QA et la mission de la nouvelle conférence.
— Nastya, bonjour. Parle-moi un peu de toi.
Anastasia: Je dirige les tests dans la banque, j'ai la responsabilité d'une très grande équipe - nous sommes plus de 90 personnes. Nous avons une ligne d'affaires importante, nous sommes responsables de l'écosystème pour les personnes morales.
J'ai étudié à la faculté de mathématiques et j'avais initialement l'intention de devenir programmatrice. Mais quand une offre intéressante m'est parvenue, j'ai décidé de me tourner vers le métier de testeur. Étrangement, cela s'est avéré être ma vocation. Actuellement, je vois tout mon travail précisément dans cette industrie.
Je suis une fervente adepte de la discipline Quality Assurance. Je me soucie de quels produits sont créés, de la manière dont la qualité est perçue dans l'entreprise, dans l'équipe et, en général, dans le processus de développement.
Il m'est évident que la communauté dans ce domaine n'est pas encore assez mature, du moins en Russie. Nous ne comprenons pas toujours que l'assurance qualité n'est pas seulement le simple fait de tester une application pour voir si elle répond aux exigences. J'aimerais changer la situation.
— Tu utilises les mots Quality Assurance et test. Dans l'esprit du commun des mortels, ces deux termes se chevauchent très souvent. En quoi diffèrent-ils, si l'on creuse profondément ?
Anastasia: Ils ne diffèrent probablement pas. Les tests sont une partie de la discipline de l'assurance qualité, c'est une activité directe - le simple fait que je teste quelque chose. En réalité, il existe de nombreux types de tests, et différentes personnes sont responsables de ces divers types de tests. Mais en Russie, avec l'apparition de la vague d'outsourcers fournissant des testeurs aux entreprises, le test est devenu un type unique.
Dans la plupart des cas, ils se limitent uniquement aux tests fonctionnels : ils vérifient que le code écrit par les développeurs correspond aux spécifications et c'est tout.
— Peux-tu me parler des autres disciplines de l'assurance qualité ? Qu'est-ce qui entre dans ce domaine à part les tests ?
Anastasia: L'assurance qualité concerne avant tout la création d'un produit de qualité. Nous nous posons donc la question de quels attributs de qualité notre produit doit posséder. Par conséquent, si nous comprenons cela, nous pouvons établir qui influence ces attributs de qualité. Peu importe, développeur, chef de projet ou responsable produit — c'est une personne qui influence le développement du produit, son backlog, sa stratégie.
Le testeur commence à mieux comprendre son rôle. Il réalise que sa tâche n'est pas seulement de tester la conformité aux exigences, mais aussi de tester les exigences, de remettre en question les formulations provenant du producteur, de déceler toutes les exigences implicites et les attentes du client. Lorsque nous livrons une nouvelle fonctionnalité à notre client, nous devons vraiment répondre à ses attentes et résoudre son problème. Si nous pensons à tous les attributs de qualité, le client sera satisfait et comprendra que l'entreprise dont il utilise le produit se soucie réellement de ses intérêts, et ne travaille pas selon le principe de « sortir une fonctionnalité, peu importe comment ».
— Il semble que ce que tu viens de décrire soit la tâche du responsable produit. Cela ne concerne pas vraiment les tests ni la qualité, n'est-ce pas ? C'est en fait du management de produit, non ?
Anastasia: En partie. L'assurance qualité n'est pas une discipline dont est responsable une seule personne. Il existe actuellement une approche populaire dans les tests, appelée Agile TestingDans sa définition, il est clairement indiqué qu'il s'agit d'une approche collaborative pour le test, qui implique un ensemble de pratiques spécifiques. L'ensemble de l'équipe est responsable de cette approche, il n'est pas nécessaire d'avoir un testeur dans l'équipe. L'orientation de l'équipe est de fournir de la valeur au client, et que cette valeur soit conforme à ses attentes.
— Donc, on peut dire que la qualité croise presque toutes les disciplines environnantes, imposant des limites à tout ce qui nous entoure ?
Anastasia: Exactement. Quand nous réfléchissons à la création d'un produit de qualité, nous commençons à penser à différents attributs de qualité. Par exemple, comment vérifier que nous avons réellement créé une fonctionnalité dont notre client a besoin.
Ici, un type de test émerge, tel que UAT (test d'acceptation utilisateur). Malheureusement, il est rarement pratiqué en Russie, mais on le voit parfois dans des équipes SCRUM, comme une démo pour le client final. Dans les entreprises à l'étranger, c'est un type de test relativement courant. Avant d'ouvrir la fonctionnalité à tous les clients, nous faisons d'abord un UAT, c'est-à-dire que nous invitons l'utilisateur final qui effectue le test et donne immédiatement un retour d'information — si le produit correspond réellement aux attentes et résout un problème. Ce n'est qu'après cela que nous étendons à tous les autres clients.
C'est-à-dire que nous nous concentrons sur le business, sur le client final, mais en même temps nous ne perdons pas de vue la technologie. La qualité du produit dépend également beaucoup de la technologie. Si nous avons une mauvaise architecture, nous ne pourrons pas livrer rapidement des fonctionnalités et répondre aux attentes du client. Il peut y avoir de nombreux bugs lors de la tentative de mise à l'échelle, ou lors d'un refactoring, nous pouvons casser quelque chose. Tout cela affectera la satisfaction du client.
Dans cette optique, l'architecture doit être telle que nous puissions écrire un code propre, ce qui nous permettra d'apporter rapidement des modifications sans craindre de tout casser. Afin que les itérations de perfectionnement ne s'étendent pas sur plusieurs mois juste parce que nous avons trop de legacy, et qu'il faille effectuer de longues phases de test.
— En gros, les développeurs, les architectes, les chefs de produits, les chefs de projet et les testeurs sont déjà impliqués. Qui d'autre est impliqué dans le processus d'assurance qualité ?
Anastasia: Maintenant, imaginons que nous avons déjà livré la fonctionnalité au client. Il est évident qu'il faut surveiller la qualité du produit, même une fois qu'il est en production. À ce stade, des situations peuvent apparaître avec des scénarios non évidents, appelés bugs.
La première question est : comment travaillons-nous avec ces bugs après avoir déjà sorti le produit ? Comment réagissons-nous, par exemple, à la charge ? Le client ne sera pas très satisfait si la page met plus de 30 secondes à se charger.
C'est là qu'intervient l'exploitation ou, comme on l'appelle aujourd'hui, DevOps. En fait, ce sont des personnes qui sont responsables de l'exploitation du produit une fois qu'il est en production. Cela inclut différents types de surveillance. Il existe même un sous-type de tests - le test en production, où nous nous permettons de ne pas tester quelque chose avant le déploiement et de le tester immédiatement en production. Ce sont une série d'actions en matière d'organisation de l'infrastructure, qui permettent de réagir rapidement à un incident, d'y faire face et de le corriger.
L'infrastructure est également importante. Il arrive souvent qu'il soit impossible de s'assurer, pendant le test, que nous avons réellement tout ce que nous souhaiterions donner au client. Nous déployons en production et commençons à repérer des situations non évidentes. Tout cela parce que l'infrastructure en test ne correspond pas à l'infrastructure en production. Cela conduit à un nouveau type de test - le test d'infrastructure. Ce sont différentes configurations, réglages, migration de bases de données, etc.
D'où se pose la question - peut-être que l'équipe doit utiliser l'infrastructure comme code.
Je crois que l'infrastructure influence directement la qualité du produit.
J'espère qu'il y aura une présentation à la conférence avec un cas réel. Écrivez-nous si vous êtes prêts à partager votre expérience sur la façon dont l'infrastructure comme code influence la qualité. L'infrastructure comme code permet de vérifier plus facilement tous les réglages et de tester ce qui serait autrement simplement impossible. Ainsi, le processus de développement d'un produit de qualité implique également l'exploitation.
— Et qu'en est-il de l'analytique et de la documentation ?
Anastasia: Cela concerne davantage les systèmes d'entreprise. Quand nous parlons des entreprises, des personnes comme les analystes et les analystes systèmes viennent immédiatement à l'esprit. Parfois, on les appelle des rédacteurs techniques. Ils reçoivent des missions pour rédiger des spécifications et les accomplissent, par exemple, en un mois.
Il a été prouvé à maintes reprises que la rédaction d'une telle documentation entraîne de très longues itérations de développement et des itérations prolongées de retouche, car des bugs sont révélés lors du processus de test, ce qui entraîne des retours. En conséquence, cela crée de nombreuses boucles qui augmentent le coût du développement. De plus, cela peut introduire des vulnérabilités. Nous avons apparemment écrit un code de référence, mais ensuite nous avons apporté des modifications qui brisent une architecture parfaitement conçue.
En fin de compte, cela donne un produit pas tout à fait de qualité, car l'architecture présente déjà des réparations, le code est insuffisamment couvert par des tests à certains endroits, parce que les délais sont serrés, il faut corriger tous les bugs plus rapidement. Tout cela parce que dans la spécification initiale, tous les points nécessaires à la réalisation n'ont pas été pris en compte.
Les développeurs ne sont pas des malfaiteurs et n'écrivent pas intentionnellement un code avec des erreurs.
Si nous avions d'abord réfléchi à la spécification, dans laquelle tous les points nécessaires auraient été éclaircis, tout aurait été réalisé exactement comme il le fallait. Mais c'est une utopie.
Il est probablement impossible d'écrire une spécification parfaite de 100 pages. Donc, il faut réfléchir à des méthodes alternatives pour rédiger la documentation,spécifier, poser des tâches qui nous rapprocheraient de ce que le développeur doit réellement faire.
Des approches issues d'Agile viennent en tête - des récits utilisateurs avec des critères d'acceptation. Cela est plus applicable aux équipes qui progressent par petites itérations.
- Qu'en est-il des tests d'utilisabilité, de la convivialité du produit, du design ?
Anastasia: C'est un point très important, car l'équipe compte des designers. Le plus souvent, les designers sont utilisés comme un service - soit un département de designers, soit un designer en sous-traitance. Il arrive souvent que le designer ait apparemment écouté le chef de produit et ait fait ce qu'il a compris. Mais lorsque nous entamons l'itération, il s'avère que ce n'est pas du tout ce que nous attendions : le designer a oublié quelque chose, n'a pas suffisamment réfléchi au comportement, soit parce qu'il n'est pas dans l'équipe et pas dans le contexte, soit le développeur front-end n'a pas entièrement compris son maquette. Cela peut nécessiter plusieurs itérations juste à cause d'un problème de compréhension du design par le développeur front-end.
De plus, il y a un autre problème. Les systèmes de design gagnent en popularité. Ils sont à la mode, mais les bénéfices qu'ils apportent ne sont pas tout à fait évidents.
Je suis confronté à l'avis selon lequel les systèmes de design, d'un côté, simplifient le développement, mais de l'autre côté, imposent de nombreuses restrictions sur l'interface.
En fin de compte, nous réalisons non pas la fonctionnalité que le client veut obtenir, mais celle qui nous convient, car nous avons déjà certains éléments à partir desquels nous pouvons la créer.
Il me semble qu'il vaut la peine de réfléchir à ce sujet et de se demander si, en essayant de simplifier le travail de conception, nous répondons vraiment à la douleur du client.
— Il en résulte un étonnamment grand nombre de thèmes liés à l'assurance qualité. Existe-t-il une conférence en Russie où tout cela peut être discuté ?
Anastasia: Il existe la plus ancienne conférence sur les tests, qui aura lieu cette année pour la 25e fois et s'appelle tout simplement – la Conférence sur l'assurance qualité SQA Days. Elle traite principalement des outils et des approches spécifiques aux tests pour les testeurs fonctionnels. En général, les rapports lors des SQA Days examinent en profondeur des domaines spécifiques dans la zone de responsabilité des testeurs eux-mêmes, mais pas des événements complexes.
Cela aide beaucoup à comprendre les différents outils et approches pour tester des bases de données, des API, etc. Mais d'une part, cela ne motive pas à impliquer dans la création d'un produit de meilleure qualité pas seulement les tests. Et d'autre part, les testeurs ne deviennent pas plus impliqués dans le processus pour réfléchir à l'objectif global du produit et à ses aspects commerciaux.
Je dirige un grand département, je mène de nombreux entretiens qui permettent vraiment de représenter l'état de l'industrie dans son ensemble. En général, nos gars travaillent dans l'entreprise et ont une zone de responsabilité claire. Les collègues qui travaillent sur des projets à l'étranger utilisent différents types de tests: ils peuvent réaliser des tests de charge, des tests de performance, et parfois des tests de sécurité, car ils aident vraiment l'équipe à assurer la qualité du produit.
J'aimerais que nos gars en Russie commencent aussi à réfléchir au fait que l'industrie ne se limite pas aux tests fonctionnels.
— Nous organisons cette nouvelle conférence QualityConf, qui est dédiée à la qualité en tant que discipline intégrale. Peux-tu en dire plus sur l'idée, quel est l'objectif principal de la conférence ?
Anastasia: Nous souhaitons créer une communauté de personnes intéressées à réaliser des produits de qualité. Proposer un espace où elles pourront venir, écouter des présentations et repartir avec une compréhension concrète de ce qu'elles doivent changer pour améliorer la qualité.
J'entends souvent des demandes du secteur du conseil sur ce qu'il faut faire lorsqu'il y a des problèmes avec les tests, avec la qualité. Quand on commence à discuter avec les équipes, on voit que le problème ne se situe pas au niveau des testeurs eux-mêmes, mais dans la manière dont le processus est structuré. Par exemple, lorsque les développeurs pensent qu'ils sont responsables uniquement de l'écriture du code, leur responsabilité s'arrête exactement au moment où ils transmettent la tâche aux tests.
Tout le monde ne réalise pas qu'un code mal écrit avec une mauvaise architecture peut poser de gros problèmes pour le projet. Ils ne pensent pas au coût des erreurs, au fait que des bugs qui atteignent la production peuvent entraîner de lourdes pertes pour l'entreprise et l'équipe. Il n'y a pas de culture pour réfléchir à cela. Je veux que lors de la conférence, nous commencions à la propager.
Je comprends que ce n'est pas une innovation. Edward Deming, auteur des 14 principes de la qualité, parlait déjà du coût de l'erreur au siècle dernier. Ce livre est à la base de l'assurance qualité en tant que discipline, mais malheureusement, le développement moderne oublie cela.
— Allez-vous aborder des sujets directement liés aux tests et aux outils ?
Anastasia: J'admets qu'il y aura des présentations sur les outils. Il existe des outils suffisamment universels grâce auxquels les entreprises et les équipes peuvent influencer le produit.
Toutes les présentations seront globalement unies par une mission commune : faire comprendre au public qu'avec cette approche, cet outil, cette méthode, ce processus, ce type de test, nous avons influencé la qualité du produit et amélioré la vie du client.
Nous n'aurons certainement pas de présentations sur les outils pour le simple plaisir d'en parler. Toutes les présentations qui entreront dans le programme seront unies par un objectif commun.
— Qui sera intéressé par ce dont tu parles, qui envisages-tu en tant qu'invités de la conférence ?
Anastasia: Nous aurons des présentations pour les développeurs qui se soucient de l'avenir de leur projet, produit, système. Cela intéressera également les testeurs et, à mon avis, surtout les managers. Par managers, j'entends les personnes qui prennent des décisions et peuvent influencer l'avenir et le développement du produit, du système, de l'équipe en même temps.
Ce sont des personnes qui se posent la question - comment améliorer la qualité du produit, du système. Lors de notre conférence, elles découvriront divers ensembles d'événements et pourront comprendre ce qui ne va pas actuellement, ce qu'il faut changer.
Je pense que le critère principal est de comprendre qu'il y a un problème avec la qualité et d'avoir envie d'y remédier. Il est probable qu'il ne sera pas facile de convaincre du premier coup ceux qui pensent que tout va bien.
— Que penses-tu, l'industrie dans son ensemble est-elle prête à parler non seulement de tests, mais de la culture de la qualité ?
Anastasia: Je pense que oui. Actuellement, de nombreuses entreprises s'éloignent de l'approche traditionnelle en cascade (Waterfall) vers le développement agile (Agile). L'orientation client est de mise et les membres des équipes commencent vraiment à réfléchir à la manière de créer un produit de qualité. Même dans les entreprises de grande taille, il y a une réorientation vers l'amélioration de la qualité.
À en juger par le nombre de demandes qui émergent dans la communauté, je pense qu'il est grand temps. Je ne suis pas certaine qu'il s'agisse d'une révolution de grande envergure, mais j'aimerais que ce changement de mentalité se produise.
— D'accord ! Nous allons inculquer une culture et transformer les mentalités.
Conférence sur le développement de produits informatiques de qualité aura lieu à Moscou le 7 juin. Vous savez de quelles étapes se compose un produit de qualité, nous avons des cas de lutte réussie contre les bugs en production, et nous avons testé les méthodes populaires dans notre propre pratique — nous avons besoin de votre expérience. vos candidatures avant le 1er mai, et le Comité de programme aidera à concentrer le thème pour une cohérence générale de la conférence.
Rejoignez le , où nous discutons des questions de qualité et de la conférence, abonnez-vous à , pour rester informé des nouvelles du programme.
Source : habr.com
