Est-il possible d'automatiser quelque chose? Ensuite, nous licencierons tous les testeurs, bien sûr. Pourquoi sont-ils nécessaires maintenant, il n'y a plus de test «manuel». Après tout?
Il s'agit d'une histoire sur l'avenir des tests en termes de DevOps. Il y aura des chiffres concrets et des conclusions purement pratiques, comment il se trouve que les bons spécialistes ont toujours du travail. (Ou pas de travail! Regardez la photo de Shakespeare et ayez peur, votre sort sera décidé maintenant).
Le matériel est basé sur une transcription du rapport de Baruch
jbaruch Sadogursky, Developer Advocate chez JFrog. La version texte et la vidéo du rapport sont sous la coupe.
Bonjour à tous! Voir une citation de Shakespeare dans l'image juste au-dessus? Voici Henry VI, la proposition de tuer tous les avocats. Vous comprenez, depuis lors, nous avons plus de moyens végétariens de se débarrasser des mauvaises professions. Nous ne tuerons personne, prenez-le et tirez sur tout le monde.
Plus précisément, il existe une telle opportunité. Allons-nous renvoyer quelqu'un?
Voici Vasya. Un matin, il vient travailler et passe devant la salle de réunion principale. Et là, son patron accueille un nouveau consultant.
Un consultant en efficacité vient dans l'entreprise et déclare: «Nous ferons des DevOps comme dans netflix *. Nous nous sommes spécifiquement rendus dans la Silicon Valley pour une conférence, et là on nous a dit comment ils se débrouillaient sur netflix. »
* Avertissement: Netflix est souvent utilisé dans cet article comme l'idéal inaccessible de DevOps. Cette utilisation est un mot familier.
Une discussion pour savoir si Netflix a vraiment le DevOps parfait est au-delà de la portée de cet article (très probablement, non).
Ils installent Spinnaker, puis lancent Chaos Monkey, et tout est automatisé. Et nous le ferons et nous serons très efficaces.
Le patron demande ce qu'il en est des testeurs. «Et ici, comme dans netflix -
liberté et responsabilité . Les développeurs écriront eux-mêmes les tests. »
Et puis Vasya tombe malade, parce qu'il regarde sa carte de visite, et là ...
Vasya commence à s'inquiéter: la dernière fois qu'un consultant en efficacité est venu, son amie Natasha, qui travaillait en tant qu'administrateur système, a été licenciée. Parce que partout DevOps. Et puis il se rend compte que bientôt tout sera très mauvais.
Mais, bien sûr, Vasya se réveille.
Je m'appelle Baruch Sadogursky, je suis l'avocat des développeurs chez JFrog. L'éditeur de cet article a spécifiquement demandé d'écrire quelques paragraphes afin que personne ne doute de mon autorité pour nous dire comment nous allons licencier les testeurs.
JFrog est une startup de la Silicon Valley, notre dernière valorisation dépassait le milliard de dollars. Nous sommes officiellement
licorne et nous faisons l'automatisation DevOps. Nos produits -
Artifactory ,
Xray ,
Mission Control, etc. - des outils pour l'automatisation même qui transforme l'usine de transformation de la viande d'Omsk en netflix.
Je ne suis pas moi-même un testeur, alors, je vais peut-être dire des bêtises. Dans le programme de la conférence, à laquelle ce rapport a été lu à l'origine, il y a une désignation spéciale - une photo avec un cocktail Molotov. Ainsi, l'orateur va porter une sorte d'hérésie, et le public va brûler. C'est à propos de moi. Sur Twitter, je suis
@jbaruch . Comme vous l'avez déjà compris, je suis un gars très gai, j'ai un besoin urgent de suivre.
J'ai des nouvelles pour vous: 80% des développeurs écrivent des tests. Les développeurs sont satisfaits de toutes sortes de sondages. Eh bien, JetBrains est satisfait du très bon rapport sur l'
état de l'écosystème des développeurs . Ils demandent qui écrit les tests unitaires.
- 59% écrivent par eux-mêmes
- 11% voient les tests unitaires dans leur code et ne savent pas d'où ils viennent.
Au total, 70% des développeurs utilisent des tests unitaires. C'est génial.
Il y a une
étude plus approfondie
de Hubstaff sur les tests avec l'aide de développeurs, elle est un peu plus ancienne - 2014. Selon lui:
- 85% des développeurs écrivent des tests unitaires,
- 15% non;
- 40% travaillent selon une méthodologie de développement pilotée par les tests;
- bonne couverture - entre 34 et 66 parmi 31% des développeurs.
La grande majorité des développeurs affirment qu'ils testent également quelque chose avec des stylos. Ils mentent, bien sûr, mais les statistiques sont les suivantes.
Depuis 2011, notre citation préférée est:
«Chaque entreprise est une entreprise de logiciels» . Y compris, bien sûr, l'usine de viande d'Omsk où Vasya travaille. Partout il y a des logiciels et tout le monde sur ce logiciel essaie de gagner de l'argent. Que veulent les entreprises? Ramez le butin avec une pelle. D'où vient l'argent? De clients satisfaits. Que veulent les clients? De nouvelles fonctionnalités. Et quand veulent-ils de nouvelles fonctionnalités? Maintenant!
Le PDG de la bande dessinée Dilbert est le chef du patron de Vasya. Il a également écouté toutes sortes de rapports intéressants. Il pense que si les clients veulent de nouvelles fonctionnalités, ils doivent les publier plus souvent. Est logique. Pour ce faire, réduisez les frictions dans les équipes.
Dois-je sortir plus souvent? Par exemple, en 2017, Java est passé à des versions plus fréquentes, car tout le monde veut des fonctionnalités et, il semblerait, elles doivent être publiées plus rapidement. Tous les six mois, un nouveau Java sort. Mais personne ne l'utilise.
Nous avons récemment eu Joker, nous avons hébergé
Java Puzzlers dessus. Au début, nous demandons toujours qui est dans quel Java, afin de comprendre quelles pièces de puzzle demander.
La situation n'a pas changé: 80%, voire plus, sont encore assis sur Java 8, sorti il y a cent ans. Personne ne prend le neuvième, ni le dixième, ni le onzième.
Pour comprendre pourquoi ils ne l'utilisent pas, vous devez comprendre comment nous décidons de prendre ou non des mises à jour. Imaginons comment nous mettons toutes les mises à jour - le système d'exploitation, les applications, le navigateur - tout ce que vous voulez.
Comment mettons-nous les mises à jour
Une notification arrive que nous avons une mise à jour, installons un nouveau système d'exploitation. Le voulons-nous? Y a-t-il quelque chose d'utile là-bas, ou avons-nous une caisse enregistreuse qui fonctionne sur Windows 98 Embedded, et nous n'avons besoin de rien d'autre?
Si nous voulons cette mise à jour, la question suivante est de savoir à quel point elle est dangereuse. C'est une chose lorsque Facebook se met à jour, et nous avons le défilement, et nous ne pourrons pas aimer. C'est tout autre chose lorsque le système de survie est désactivé à l'hôpital. Si nous ne nous soucions pas des risques, mettons à jour. S'il y a des risques, alors la question est de faire confiance à celui qui déploie la mise à jour.
Il n'y avait aucun problème avec Apple auparavant: il y a un nouveau système d'exploitation - prenons-le. C'était avant, et maintenant nous avons peur d'être mis à jour, il n'y a plus d'ancienne confiance. Si nous faisons confiance - pas de problème, nous mettons à jour. Si nous ne faisons pas confiance, vous devez tester.
Nous faisons ce qu'on appelle des tests d'acceptation. Ici, ils nous disent: un nouveau Java est sorti, et par exemple, nous sommes Baidu. Highload, 100 500 serveurs, cloud, JVM partout. Nous prenons une partie des serveurs, commençons à changer Java. Un groupe d'ingénieurs doit faire quelque chose et tout vérifier. Une fois tous les trois ans, c'est normal, mais une fois tous les six mois ... Êtes-vous foutu? Nous ne le vérifierons que pendant six mois. Bien sûr, nous ne prendrons pas cela votre nouveau Java.
Par conséquent, si nous pouvons vérifier rapidement, cela vaut la peine d'être mis à jour. Mais si vous devez vérifier pendant longtemps, vous pouvez ignorer quelques versions. Rien ne se passera si nous passons de la huitième version immédiatement à la douzième.
Le problème est dans la confiance. Si nous ne faisons pas confiance, la mise à jour sera difficile. Si le problème d'approbation est résolu, les mises à jour ne posent aucun problème. Soit nous avons une fonctionnalité, soit nous n'en avons rien à foutre.
Prenez Chrome. Lui, à partir d'une version, met à jour sans demander à personne du tout. Les risques y sont faibles, mais toujours là. Mais d'un autre côté, nous faisons confiance à ceux qui écrivent Chrome. Plus souvent qu'autrement, lorsqu'une nouvelle version de Chrome sort, rien ne casse. En fait, nous n'avons aucun problème de confiance et nous sommes sur cette voie.
Nous avons une mise à jour, les risques ne sont pas importants, nous avons confiance - nous mettons à jour. Et ils ne nous demanderont pas si nous voulons ou non, donc nous mettrons toujours à jour. C'est exactement ce qui se fait.
Imaginez que Netflix lance une nouvelle mise à jour, et maintenant nous pouvons ignorer non seulement les sous-titres et les économiseurs d'écran, mais aussi tous les endroits ennuyeux. Cool update? Cool. Le voulons-nous? Nous voulons. Cela fonctionnera-t-il? Très probablement oui. Dans un cas extrême, nous irons sur YouTube, voir les dessins animés si netflix est cassé.
La question de la confiance est critique. Comment le résout-on? Le mot «nous» signifie les deux co-fondateurs de JFrog, Fred Simon (Fred Simon), Yoav Landman (Yoav Landman) et votre humble serviteur. Nous avons
écrit un livre qui explique comment résoudre ce problème.
Disons que nous avons convaincu notre PDG, qu'il a lu Liquid Software, et maintenant il comprend pourquoi il a besoin d'une mise à jour. Il demande au consultant comment nous mettrons à jour plus souvent. Agile! DevOps! Qu'est-ce que DevOps?
Devops
Permettez-moi de vous dire une petite théorie de ce qu'est DevOps, puisque nous gagnons de l'argent avec. Jetez un oeil à la photo, nous avions ces groupes, équipes, départements:
Il y a des développeurs, il y a des Ops - des administrateurs système qui prennent ce que les développeurs ont écrit et les jettent sur la prod. Et au milieu entre les développeurs Ops, il y a des QA qui testent. C'est-à-dire que les développeurs se sont assis, ont écrit, puis l'ont apporté aux testeurs, l'ont testé, attribué aux administrateurs système, et ils l'ont téléchargé sur le prod. Pour cela, nous avions des départements séparés.
La langue russe est belle: le département est toujours
séparé , c'est la racine du mot. En anglais, ce charme n'est pas, donc, ces différents départements sont appelés
silos . La meilleure traduction de ce mot en russe a été donnée par Anton Weiss, qui était le meilleur
orateur de DevOops . Il appelle les silos des «puits». Différents départements - puits profonds. Pour y charger du travail, vous devez descendre, puis retirer le travail à partir de là - levez-vous. Il est plus pratique de le faire en groupe. Comment regroupons-nous les choses que nous retirons du puits?
Naturellement, dans des seaux. Autrement dit, nous avons de tels «seaux de travail». Les développeurs ont écrit quelque chose dans le puits, nous l'avons chargé dans des seaux, nous l'avons sorti du puits, transporté les seaux aux testeurs et les leur avons déposés dans le puits.
De nombreuses actions sont effectuées pour transférer le travail entre différents puits. Lorsque nous regroupons des tâches pour économiser sur ce travail, nous commençons à charger ces compartiments. Bien sûr, plus le seau est grand, plus nous économiserons sur ce processus de transfert. Par conséquent, les seaux sont grands.
Quel est le problème avec les grands seaux? Le fait qu'ils se remplissent depuis longtemps. Par conséquent, lorsque nous avons des fonctionnalités importantes qui doivent être libérées d'urgence pour la production, car il existe une ligne de clients avec de l'argent, nous ne pouvons pas le faire. Nous avons des puits, nous allons mieux collecter plus dans un seau. Par conséquent, des fonctionnalités importantes attendent toutes les absurdités, tant que nous en avons assez pour bien le remplir. C'est mauvais, comme vous le comprenez. Ceci est résolu par le fait que nous obtenons et mélangons tous ces puits.
Ce n'est pas de ma faute! J'ai juste pris les trois couleurs originales, je les ai posées les unes sur les autres, et cette couleur s'est avérée. Maintenant, nous faisons tout. Nous avons de tels ingénieurs qui sont à la fois Shvets, Reapers et Dyuras. Ce sont Dev, QA et Ops. Il a écrit et testé le code, puis il a tout expliqué sur la production - une telle licorne.
Quel est le problème des licornes? Qu'elles n'existent pas. Et ceux qui existent, ils ont longtemps été embauchés par netflix. Il nous reste donc à faire le mélange.
Le mélange
Nous avons une culture commune, des objectifs communs. Nous avons quitté les puits, nous sommes tous ensemble maintenant, mais nous avons encore une profonde spécialisation. Un développeur est toujours plus un développeur qu'Ops, et un testeur est plus un testeur qu'un développeur. Néanmoins, ils comprennent tout. Ils comprennent ce qu'ils font, pourquoi ils le font et comment cela fonctionne.
Autrement dit, nous avons des gens en forme de T, "des gens sous la forme de la lettre T".
Ils ont une spécialisation approfondie, ils savent très bien ce qu'ils font. Ils savent très bien et tout le reste aussi. Par exemple, les développeurs comprennent un peu comment tester correctement, comment la mise en place des processus sur prod et ainsi de suite.
DevOps, c'est:
- La culture de ce que nous avons maintenant des objectifs communs, nous comprenons ce que nous faisons ensemble.
- Automatisation à libérer plus souvent.
Rapidité et qualité
Parlons de l'hypothèse qu'il existe une relation inverse entre la vitesse et la qualité. En gros, plus nous sortons rapidement, plus la qualité est mauvaise. Et vice versa: si nous ne sommes pas pressés, nous aurons le temps de tout tester à fond. Nous avons un compromis!
Afin de comprendre si cette dépendance existe réellement, tournons-nous vers les articles scientifiques et parlons
du rapport State of DevOps de l'organisation DORA. Je vous recommande fortement de lire attentivement ce rapport.
À quel point pouvez-vous lui faire confiance? Le rapport indique que plus de cinq mille personnes ont été interrogées en cinq ans, et en 2018 près de 2000 personnes. Il s'agit d'un très grand échantillon, et sur la base d'une telle quantité, par exemple, des prévisions sont faites aux élections américaines. Par conséquent, la recherche peut être fiable.
De plus, Nicole Forsgren, qui dirige DORA, contrairement à nous, est une scientifique, donc tout est sérieux là-bas. Voyons ce que DORA nous dit sur cette corrélation inverse.
Premièrement, ils ont divisé tous les répondants en trois groupes: les moins performants, les interprètes moyens et les très performants.
De plus, il y a Elite. Il s'agit de Netflix (en fait non, voir l'
avertissement ci-dessus).
Comme vous pouvez le voir, les proportions changent. Naturellement, il y a cinq ans, il y avait beaucoup plus de Low Performers, maintenant il y a beaucoup plus de High Performers, parce que nous commençons déjà à comprendre un peu ce que nous faisons.
C'est quelque peu étrange. Il s'avère que Medium est testé avec des poignées plus que Low. Pourquoi? Oui, car Low ne teste rien du tout.
Ils ont une tendance, un graphique appelé la courbe en J, qui montre la corrélation même ou la corrélation inverse entre la vitesse et la qualité. Et ici, tout est très étrange. À un certain point, nous voyons la confirmation de cette corrélation inverse. Autrement dit, plus nous publions rapidement, plus la qualité est faible.
Mais alors la corrélation n'est pas seulement non inverse, elle est directe. Plus nous sortons rapidement, meilleure est notre qualité. Disons que nous sommes moyens et testons avec des stylos. Tout n'est pas mal, mais lentement, car nous pensons que si nous ne sommes pas pressés, nous testerons tout mieux. Puis un consultant de DevOps vient et dit: «C'est tout, maintenant nous l'automatisons. Et nous n'avons pas besoin de testeurs. Tout va bien. "
Mais sans tests, c'est une sorte de non-sens. Après avoir réalisé qu'après tout quelque chose doit être testé et qu'il est nécessaire d'automatiser correctement, nous commençons à automatiser correctement et continuons à viser les hauteurs du ciel.
Cet échec, où il existe de nombreux bugs, doit être correctement surmonté. Comment y entrer, je pense qu'il n'y a pas de questions. La question est de savoir comment s'en sortir.
Nous devons répondre à la question de savoir comment vivre sans test manuel. La réponse est la même que la question de savoir comment vivre sans configurer de serveurs. Évidemment possible. Qu'est-ce qui change?
Auparavant, nous avions un administrateur système qui a déployé un produit pour prod. Il s'assit et attendit que les développeurs finissent d'écrire. Après cela, il a pris ce produit et est allé insérer le CD-ROM et coller les fils. Qu'arrive-t-il à tout le monde en ce moment? Tout le monde attend. Ceci est un goulot d'étranglement, plug.
Nous résolvons cela avec la bonne automatisation. Nous automatisons le processus, nous avons un pipeline préparé à l'avance, et maintenant le produit se déploie automatiquement dès qu'il a fini d'écrire. Est-ce à dire que maintenant ces gens ne sont plus nécessaires? Non. Cela signifie qu'ils sont nécessaires, mais ils font autre chose.
Même chose avec les tests. Nous avons des testeurs qui testent le produit. Ils attendent jusqu'à ce qu'ils écrivent un produit. Écrit - il est temps de tester. Que font les autres pendant le test? Ils ne font rien, ils attendent. Comment résout-on cela?
Encore une fois, la bonne automatisation. Nous construisons un processus. Il garantira la qualité du produit. Nous pouvons préparer ce processus à l'avance, puis le produit est testé automatiquement.
- Cela nécessite, par exemple, des équipes interfonctionnelles . Ici, nous nous sommes levés des puits et nous nous sommes assis ensemble. Nous avons maintenant un lion couché avec un mouton, et le testeur travaille avec le programmeur.
- Nous effectuons des tests en continu . C'est comme un test automatisé, mais plus intelligent.
- En cours de développement, des «tests cérébraux» sont effectués. C'est un terme plus correct que «test manuel», car le test manuel concerne le cerveau, pas les mains. Merci pour ce terme à mon jumeau sur Facebook Alexey Vinogradov. Les tests cérébraux ont lieu pendant le processus de développement. Dès que quelque chose apparaît, vous pouvez déjà vérifier son flux, vous pouvez déjà comprendre comment cela fonctionne, vous pouvez déjà commencer à décrire quelques cas d'angle, que nous automatiserons ensuite.
- Nous suivons maintenant le développeur. S'il n'a pas écrit le test au début, nous pouvons lui donner une claque au visage. Il s'agit du développement piloté par les tests .
- La rétroaction instantanée est importante. Nous devrions avoir un pipeline qui nous informe immédiatement dès que quelque chose se casse. Parce que nous devons aller tout de suite et le réparer instantanément.
- Participation à la conception . Il arrive que vous regardiez quelque chose et que vous pensiez comment nous allons maintenant tester cette merde. Mais excusez-moi, où étiez-vous quand tout le monde a décidé qu'il y aurait de la merde? Vous venez à la réunion et dites que vous n'êtes pas d'accord, vous devez le faire inconsciemment. Vous devez être impliqué dans la conception pour vous assurer de pouvoir le tester plus tard.
- Outils, harnais, supports - ce que beaucoup d'entre vous font aujourd'hui ne va nulle part. Au contraire, ce sera plus. En conséquence, quelqu'un devrait écrire ceci.
- Ingénierie du chaos . Vous avez toujours rêvé de lancer Chaos Monkey en production, surtout si vous avez un réseau de guichets automatiques sur Windows 95. Voici votre chance.
- Et enfin, vous devez apprendre à l'ignorant à concevoir des tests . Nous avons décidé que les développeurs affirment au moins qu'ils écrivent des tests. Maintenant, laissez-les écrire des tests, seulement nous devons leur apprendre à le faire. Qui leur enseignera, comment savent-ils comment passer des tests? . .
. , . , .
, , , 0 , 99999999999 , , -1 … , asdfgh, .
. , . , . . — , , .
, , , , . . , , , — , , , . , , , , , . , , , .
, , , . DevOps. , . T- — , .
, - . « », , . , , , . , Selenium . , .
, .
— . , , . . , , Ops- , , , , , , , .
Developers in test — , , . , . , ; — , ; TDD , , , , . , , .
« ». , , , , , — . , , , , , , , , , , Continuous Testing .
end-to-end , . , , DevOps, .
, - , . , 70- : « DevOps, ». , , .
. -, , , , , . : ( EVP Engineering, SignalFx) , , .
70- . . , , . , . , , , , . , , , , — , netflix .
, , , , , , , , , . . , .
, . . « , », — , , .
«, — . — : , , , . , , , , , . . , - , . ? Artifactory , ?!».
, — , . , . ? !
DORA: , , , .
New Work. , New Work Low — 30%, Medium — 40%, High Elite — 50%. ( , Low) , , .
.
Heisenbug 2018 Moscow, — 17-18 Heisenbug. , . , ( ).