Bonjour, Habr!
Nous avons un nouveau sujet important - le développement de haute qualité des produits informatiques. Nous discutons souvent dans HighLoad ++ sur la façon de rendre les services chargés rapides, et sur Frontend Conf - une interface utilisateur cool 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 à propos de la qualité que l'on peut appeler dans son ensemble et de la manière de travailler de manière globale, non.
Fixons-le sur
QualityConf - 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 vous accrocher à votre domaine de responsabilité et d'associer la qualité non seulement aux testeurs.
Sous la coupe, nous parlerons avec le chef du comité de programme, le chef des tests chez Tinkoff
Business , le créateur de la communauté russophone d'AQ
Anastasia Aseeva-Nguyen sur l'état de l'industrie de l'AQ et la mission de la nouvelle conférence.
- Nastya, bonjour. Veuillez parler de vous.
Anastasia : Je dirige les tests à la banque, je suis responsable d'une très grande équipe - nous sommes plus de 90. Nous avons un métier important, nous sommes responsables de l'écosystème des personnes morales.
J'ai étudié au mehmat et je voulais initialement devenir programmeur. Mais quand j'ai eu 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 ardent adhérent de la discipline de l'assurance qualité. Peu m'importe quels produits sont créés, comment ils sont liés à la qualité dans l'entreprise, dans l'équipe et, en principe, dans le processus de développement.
Il est évident pour moi que la
communauté dans ce sens n'est pas assez mûre , du moins en Russie. Nous ne comprenons pas toujours que l'assurance qualité n'est pas seulement le fait de tester une application pour la conformité aux exigences. Je voudrais changer cette situation.
- Vous utilisez les mots assurance qualité et tests. Aux yeux de l'homme moyen, ces deux termes se croisent 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 de l'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 différentes personnes sont responsables de différents types de tests. Mais en Russie, quand il y a eu une vague d'externalisateurs qui fournissent des testeurs à l'entreprise, les tests ont été réduits à une seule vue.
Dans la plupart des cas, ils sont limités uniquement aux tests fonctionnels: ils vérifient que ce que les développeurs ont compilé répond aux spécifications et c'est tout.
- Dites-moi, s'il vous plaît, quelles sont les autres disciplines de l'assurance qualité? En plus des tests, cela comprend-il autre chose?Anastasia : L'assurance qualité, c'est avant tout la création d'un produit de qualité. Autrement dit, nous nous demandons quels attributs de qualité notre produit devrait posséder. Par conséquent, si nous comprenons cela, nous pouvons comparer qui influence ces attributs de qualité. Peu importe, le
développeur, le chef de projet ou le chef de produit est une personne qui influence le développement d'un produit, son backlog, sa stratégie.
Le testeur est mieux conscient de son rôle. Il comprend que sa tâche n'est pas seulement de tester la conformité aux exigences, mais aussi de tester les exigences, de remettre en question le langage qui vient du technologue produit et de révéler toutes les exigences et attentes implicites du client. Lorsque nous livrons de nouvelles fonctionnalités à notre client, nous devons vraiment répondre à ses attentes et résoudre sa douleur. Si nous pensons à 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 fonctionne pas sur le principe «juste pour sortir une fonctionnalité».
- Il semble que ce que vous venez de décrire soit la tâche du technologue produit. En principe, cela ne concerne pas les tests et non la qualité - il s'agit généralement de la gestion des produits, non?Anastasia : Y compris. L'assurance qualité n'est pas la discipline dont une personne spécifique est responsable. Maintenant, il existe une direction populaire dans les tests, une approche appelée
Agile Testing . Dans sa définition, il semble simple qu'il s'agit d'une approche d'équipe pour les tests, qui comprend un certain ensemble de pratiques. Toute l'équipe est responsable de la mise en œuvre de cette approche, il n'est même pas nécessaire qu'un testeur soit dans l'équipe. Toute l'équipe se concentre sur la création de valeur pour le client, et pour que cette valeur réponde à ses attentes.
- Il s'avère que la qualité se croise avec presque toutes les disciplines environnantes, imposant un cadre à tout ce qui l'entoure?Anastasia : D'accord. Lorsque nous pensons à ce que nous voulons créer un produit de qualité, nous commençons à penser aux différents attributs de la qualité. Par exemple, comment vérifier que nous avons vraiment créé une fonctionnalité dont notre client a besoin.
Ce type de test apparaît comme
UAT (test d'acceptation utilisateur). Malheureusement, en Russie, il est rarement pratiqué, mais il est parfois présent dans les équipes de SCRUM, en tant que démonstration pour le client final. Dans les entreprises étrangères, il s'agit d'un type de test assez courant. Avant d'ouvrir la fonctionnalité à tous les clients, nous créons d'abord l'UAT, c'est-à-dire que nous invitons l'utilisateur final qui effectue les tests et donne immédiatement des commentaires - le produit répond-il vraiment aux attentes et résout-il la douleur? Ce n'est qu'après cette mise à l'échelle vers tous les autres clients.
Autrement dit, nous nous concentrons sur les entreprises, sur le client final, mais en même temps,
n'oubliez pas la technologie . La qualité des produits dépend également fortement de la technologie. Si notre architecture est médiocre, nous ne pourrons pas publier rapidement les fonctionnalités et répondre aux attentes des clients. Il peut y avoir de nombreux bugs lors de la mise à l'échelle ou lors de la refactorisation, nous pouvons casser quelque chose. Tout cela affectera la satisfaction du client.
De ce point de vue, l'architecture doit être telle que nous pouvons écrire du code propre qui nous permette d'apporter des modifications rapidement et de ne pas avoir peur de tout casser. Afin que les itérations de raffinement ne soient pas étirées pendant plusieurs mois simplement parce que nous avons tant d'héritage et que nous devons effectuer de longues étapes de test.
- Au total, les développeurs, architectes, experts produits, chefs de produit, testeurs eux-mêmes sont déjà impliqués. Qui d'autre est impliqué dans le processus d'assurance qualité?Anastasia : Imaginez maintenant que nous avons déjà livré une fonctionnalité à un client. De toute évidence, vous devez surveiller la qualité du produit et le moment où il est déjà en production. À ce stade, des situations avec des scénarios non évidents, les soi-disant bogues, peuvent apparaître.
La première question est de savoir comment travailler avec ces bogues après avoir déjà publié le produit? Comment réagissons-nous, par exemple, à la charge? Le client ne sera pas très satisfait si la page se charge pendant plus de 30 secondes.
C'est
là que l' exploitation ou, comme ils l'appellent maintenant,
DevOps entre en jeu. En fait, ce sont des personnes qui sont responsables du fonctionnement du produit lorsqu'il est déjà en vente. Cela comprend différents types de surveillance. Il existe même un sous-type de test - test sur la prod, lorsque nous nous permettons de ne pas tester quelque chose avant de le déployer et de le tester immédiatement sur la prod. Il s'agit d'une série de mesures du point de vue de l'organisation des infrastructures qui vous permettent de réagir rapidement à un incident, de l'influencer et de le corriger.
L'infrastructure est également importante. Souvent, il y a des situations où pendant le test, il est impossible de s'assurer que nous avons vraiment tout ce que nous aimerions donner au client. Nous passons à la prod - et commençons à attraper des situations non évidentes. Et tout cela parce que l'infrastructure du test ne correspond pas à l'infrastructure du prod. Cela conduit à un nouveau type de test:
le test d'infrastructure . Ce sont diverses configurations, paramètres, migration de base de données, etc.
Cela soulève la question - peut-être que l'équipe doit utiliser l'infrastructure comme code.
Je pense que l'infrastructure affecte directement la qualité des produits.
J'espère que la conférence aura un rapport avec un cas réel. Écrivez-nous si vous êtes prêt à dire 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 le test de quelque chose qui est autrement tout simplement impossible. Par conséquent, l'exploitation est également impliquée dans le 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 comme les analystes et les analystes système viennent immédiatement à l'esprit. Ils sont parfois appelés rédacteurs techniques. Ils reçoivent une tâche pour rédiger une spécification et la compléter, par exemple, 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 au cours du processus de test, des bogues sont détectés, les retours commencent. En conséquence, il existe de nombreuses boucles qui augmentent le coût du développement. De plus, cela pourrait introduire des vulnérabilités. Nous semblons avoir écrit le code de référence, mais ensuite apporté des modifications qui cassent l'architecture parfaitement pensée.
Le résultat est un produit de qualité médiocre, 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 épuisés, vous devez fermer tous les bogues plus rapidement. Et tout cela parce que dans la spécification d'origine, tous les points à mettre en œuvre n'ont pas été pris en compte.
Les développeurs ne sont pas des nuisibles et n'écrivent pas spécifiquement de code avec des erreurs.
Si nous pensions au départ une spécification dans laquelle tous les points nécessaires seraient couverts, alors tout serait implémenté exactement comme il se doit. Mais c'est de l'utopie.
Il est probablement impossible d'écrire une spécification parfaite de 100 pages. Par conséquent,
nous devons réfléchir à d'autres façons d'écrire de la documentation , de spécifier, de définir des tâches qui nous rapprocheraient du fait que le développeur fait exactement ce dont nous avons besoin.
Voici les approches Agile - des user stories 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é des produits, de la conception?Anastasia : C'est un point très important, car il y a des designers dans l'équipe. Le plus souvent, les concepteurs l'utilisent comme un service - soit le département de conception, soit le concepteur externalisé. Il y a souvent des situations où le concepteur semble avoir écouté le technologue produit et fait ce qu'il a compris. Mais lorsque nous commençons l'itération, il s'avère que ce qui était attendu n'a pas été fait: le concepteur a oublié quelque chose, n'a pas réfléchi au comportement parce qu'il n'était pas dans l'équipe ou dans le contexte, ou le développeur front-end n'a pas bien compris mise en page. Cela peut prendre plusieurs itérations uniquement parce qu'il y a un problème avec la compréhension de la conception par le développeur frontal.
De plus, il y a un autre problème. Les systèmes de conception gagnent en popularité. Ils sont sur le battage médiatique, mais leurs avantages ne sont pas entièrement évidents.
Je pense que les systèmes de conception, d'une part, simplifient le développement et, d'autre part, imposent de nombreuses restrictions à l'interface.
Par conséquent, nous ne faisons pas une telle fonctionnalité que le client souhaite recevoir, mais une fonctionnalité qui nous convient, car nous avons déjà certains cubes à partir desquels nous pouvons la créer.
Il me semble que vous devriez faire attention à ce sujet et vous demander si nous résolvons vraiment la douleur des clients dans une tentative de simplifier le travail de conception.
- Il s'avère étonnamment de nombreux sujets liés à l'assurance qualité. Y a-t-il une conférence en Russie au cours de laquelle tous peuvent être discutés?Anastasia : Il y a la plus ancienne conférence de tests, qui se tiendra pour la 25e fois cette année et s'appelle la SQA Days Quality Assurance Conference. Il traite principalement des outils et des approches de test spécifiques pour les testeurs fonctionnels. En règle générale, les rapports sur les journées SQA examinent en profondeur des domaines spécifiques dans le domaine de responsabilité des testeurs eux-mêmes, mais pas des événements complexes.
Cela aide beaucoup à comprendre divers outils et approches, comment tester des bases de données, des API, etc. Mais en même temps, d'une part, cela ne motive pas à impliquer non seulement les tests dans la création d'un meilleur produit. En revanche, les testeurs ne s'impliquent pas davantage dans le processus pour réfléchir à l'objectif global du produit et de sa composante métier.
Je dirige un grand département, mène de nombreuses interviews, ce qui nous permet en fait de présenter l'état de l'industrie dans son ensemble. En règle générale, nos gars travaillent en entreprise et ils ont un domaine de responsabilité clair. Les collègues qui travaillent dans des projets à l'étranger utilisent différents types de tests: ils peuvent eux-mêmes effectuer des tests de résistance, des tests de performances et même parfois des tests de sécurité, car ils aident vraiment l'équipe à fournir un produit de qualité.
J'aimerais que nos gars en Russie commencent également à penser que l'industrie ne s'arrête pas aux tests fonctionnels.
- Pour cela, nous organisons une nouvelle conférence QualityConf, dédiée à la qualité en tant que discipline holistique. 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 à fabriquer des produits de qualité. Offrez une plate-forme où ils peuvent venir, écouter les rapports et repartir après la conférence avec une compréhension concrète de ce qui doit être changé à leur place pour améliorer la qualité.
Souvent, j'entends maintenant une demande de consultation sur ce qu'il faut faire quand il y a des problèmes avec les tests, avec la qualité. Lorsque vous commencez à parler avec des équipes, vous voyez que le problème n'est pas avec les testeurs eux-mêmes, mais avec la façon dont le processus est construit. Par exemple, lorsque les développeurs estiment qu'ils ne sont responsables que de l'écriture de code, leur responsabilité prend fin exactement au moment où ils ont transféré la tâche aux tests.
Tout le monde ne pense pas qu'un code de mauvaise qualité mal écrit avec une architecture médiocre pose de gros problèmes pour le projet. Ne pensez pas au coût des erreurs, les bogues qui sont entrés en production peuvent entraîner des coûts importants pour l'entreprise et l'équipe. Aucune culture pour y penser. Je veux que nous commencions à le distribuer lors de la conférence.
Je comprends que ce n'est pas une innovation Edward Deming, auteur de 14 postulats de qualité, a écrit sur le coût de l'erreur au siècle dernier. Ce livre est basé sur l'assurance qualité en tant que discipline, mais, malheureusement, le développement moderne l'oublie.
- Envisagez-vous d'aborder directement des sujets sur les tests et les outils?Anastasia : J'avoue qu'il y aura des rapports sur les outils. Il existe des outils assez universels par lesquels les entreprises et les équipes peuvent influencer un produit.
Tous les rapports seront globalement unis par une mission commune: transmettre au public qu'avec 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 l'outil pour le plaisir. Tous les rapports qui entrent dans le programme seront unis par un objectif commun.
- Qui sera intéressé par ce dont vous parlez, que vous voyez comme les invités de la conférence?Anastasia : Nous aurons des rapports pour les développeurs qui ne sont pas indifférents au sort de leur projet, produit, système. Ce sera également intéressant pour les testeurs et, il me semble, surtout pour les managers. Par gestionnaires, 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 gens qui se demandent comment améliorer la qualité d'un produit, d'un système. Lors de notre conférence, ils découvriront différents complexes d'événements et pourront comprendre ce qui ne va pas 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. Probablement, la première fois pour tendre la main à des gens qui croient que cela fonctionnera, nous ne réussirons pas.
- Pensez-vous que l'industrie dans son ensemble a mûri afin de parler non seulement de tests, mais d'une culture de la qualité?Anastasia : Je pense que j'ai mûri. Maintenant, de nombreuses entreprises s'éloignent de l'approche traditionnelle de Waterfall vers Agile. Il y a une orientation client, les gens en équipe commencent vraiment à réfléchir à la façon de créer un produit de qualité. Même dans les entreprises-entreprises, il y a une réorientation vers l'amélioration de la qualité.
À en juger par le nombre de requêtes qui se posent dans la communauté, je pense qu'il est temps. Je ne suis pas sûr, bien sûr, que ce sera une révolution à grande échelle, mais j'aimerais que ce changement de conscience se produise.
- D'accord! Nous allons inculquer une culture et tourner l'esprit.Une conférence sur le développement de la qualité des produits informatiques QualityConf se tiendra à Moscou le 7 juin . Vous savez à quelles étapes se compose un produit de haute qualité, il y a des cas de lutte réussie avec des bogues dans le magasin en stock, nous avons testé des méthodes populaires dans notre pratique - nous avons besoin de votre expérience. Envoyez vos candidatures avant le 1er mai et le comité du programme vous aidera à cibler le sujet pour l'intégrité globale de la conférence.
Connectez-vous à un chat dans lequel nous discutons de problèmes de qualité et à une conférence, abonnez-vous à la chaîne Telegram pour rester au courant des nouvelles du programme.