Alexey Barantsev est probablement l'une des personnes les plus célèbres dans les tests russes: il est connu à la fois pour
software-testing.ru et pour
selenium2.ru , et pour sa participation à Selenium WebDriver, et pas seulement. Dans le même temps, il est également l'un des plus expérimentés: en essais déjà depuis 1994. Et quand on a appris qu'il prendrait la parole lors de notre conférence à Heisenbug avec le
rapport «Troubles in Selenium WebDriver», nous avons voulu demander à un tel orateur. Nous avons commencé par des questions sur la façon dont les tests dans les années 90 différaient d'aujourd'hui, puis nous sommes passés aux réalités modernes.
- Parmi les lecteurs de l'interview, il peut y avoir des personnes qui ne sont même pas nées lorsque vous avez déjà commencé le test. Dis, comment alors tout était différent de nos jours?- Si nous parlons de certains fondements des tests (théorie, techniques clés), il n'y a pas de changements particuliers. Mais en même temps, l'automatisation des tests, bien sûr, est en constante évolution. De nouvelles technologies de développement apparaissent et disparaissent, et avec elles les technologies et les outils conçus pour tester les logiciels apparaissent ou disparaissent. Comment comparer les tests de ce qui était alors et de ce qui est maintenant? Quoi qu'il en soit, pour comparer, ce qui est mieux - il y avait autrefois SOAP, maintenant REST. Ensuite, nous avons testé les services Web écrits en utilisant SOAP, et maintenant ceux écrits en utilisant REST. Quelle différence cela fait-il?
- Eh bien, certaines technologies non seulement «sont apparues et ont disparu», mais sont devenues une sans laquelle il est maintenant difficile d'imaginer l'industrie: «Comment avons-nous même vécu sans Git?»- Ils vivaient normalement sans Git. Il y avait CVS, nous avons bien vécu avec, puis Subversion, puis Git. Ce n'est pas si intéressant, mais ce qui a vraiment changé, c'est la vitesse. La vitesse de développement, et avec elle la vitesse des tests. Il ne s'agit même pas de courtes itérations, Agile, l'approche de l'organisation des heures de travail. C'est la vitesse de développement des produits qui a changé.
Lorsque nous avons commencé à travailler, au milieu des années 90, nous avions des projets d'une durée de six mois, un an, deux ans. Développement et test. Puis ces projets ont commencé à décliner à trois mois, deux. En fait, en deux mois, la même chose s'est développée que plus tôt dans l'année. Et maintenant ce qui se passe: les gens viennent au hackathon, développent un produit fonctionnel en une journée, le testent et le lancent. Il est clair que ce n'est encore qu'un prototype, mais néanmoins, pour une journée. Il était impossible d'imaginer cela.
Pourquoi cela se produit-il? Bien sûr, les outils évoluent. Mais ce n'est même pas une question d'outils, certains écrivent encore du code dans vi ou emacs. Plus important encore, beaucoup de code prêt à l'emploi a déjà été écrit; il existe de bonnes bibliothèques qui ont été minutieusement testées. Quelque part, vous devez encore écrire une grande partie de votre code, développer des algorithmes uniques, et tout y prend encore beaucoup de temps. Mais dans d'autres situations, vous pouvez prendre des composants prêts à l'emploi, rapidement, comme chez un concepteur, assembler le produit fini. Et, en conséquence, il est également plus facile de le tester, car nous l'assemblons déjà à partir de composants fiables et testés. Cela a beaucoup changé.
- Et qu'est-ce qui a changé dans la vision du monde des gens - dans la façon dont nous considérons les tests / le développement et qu'attendons-nous d'eux?- Dans les années 90, les développeurs et les testeurs avaient davantage confiance dans les normes. En fait, Agile n'est pas né de zéro, mais simplement à cause des déceptions de toutes ces normes.
Premièrement, il y avait une idée que les normes nous sauveraient d'un code de mauvaise qualité: nous écrirons tout conformément aux normes, et tout s'intégrera bien, fonctionnera. C'est peut-être même vrai, juste les normes sont développées très lentement, et tout va très vite et devient obsolète avant que les normes ne soient acceptées.
Deuxièmement, il était certain qu'il serait possible de dessiner formellement des diagrammes selon des diagrammes UML, de décrire les exigences logicielles et de générer automatiquement le code source, et tout cela fonctionnerait, et il ne serait même pas nécessaire de tester. On supposait que les développeurs cesseraient bientôt d'écrire du code, au lieu de cela ils dessineraient des diagrammes UML et décriraient les conditions dans un langage de haut niveau. Ça n'a pas décollé, ça n'a pas marché. Bien que dans cette soirée où je me suis tourné, de très gros paris aient été faits à ce sujet.
Maintenant, une sorte de nouvelle vague a probablement commencé: l'intelligence artificielle germe de partout et de partout, et encore une fois, cette idée se pose que les développeurs n'écriront pas de code bientôt. Au lieu de cela, certains systèmes d'intelligence artificielle seront formés et tout fonctionnera de lui-même. Par conséquent, les testeurs n'auront rien à faire. Les développeurs formeront l'intelligence artificielle, et il fera tout. Voyons comment ça va être. Peut-être que cela fonctionnera comme la dernière fois.
- Passons à notre temps. Vous utilisez software-testing.ru. Pour ceux qui ne le suivent pas activement: que se passe-t-il là-bas?- Nous publions beaucoup de contenu, maintenant la partie principale est le contenu traduit. Parce que, franchement, en Russie, il est très difficile de trouver des auteurs qui écrivent sur les tests. Je ne sais pas pourquoi cela s'est produit: il y a eu un moment où beaucoup de gens ont écrit en russe, puis soit leur carburant s'est épuisé, soit pour une raison quelconque, il n'y avait pas assez de blogs et d'articles dans RuNet. Et dans la partie anglophone d'Internet, tout cela fleurit encore, il y a beaucoup d'articles écrits là-bas.
La communication s'est progressivement déplacée vers les forums de discussion, c'est-à-dire que les gens n'écrivent pas de textes mais communiquent. Cela ne veut pas dire que nous suivons cette tendance très attentivement. Nous participons à des chats, mais n'essayons pas de diriger cette tendance. Nous agissons toujours à l'ancienne, en essayant de donner aux gens exactement le contenu, et ils trouveront un endroit pour la communication.
- Maintenant, les gens s'éloignent des textes pour les blogs vidéo - mais y a-t-il une telle chose dans les tests?- Lors des tests, cette tendance est presque invisible. Il y a littéralement un ou deux blogueurs vidéo, des cas isolés.
- Il y a une expression "Si vous voulez vraiment comprendre quelque chose - essayez de l'expliquer aux autres." Et lorsque vous modifiez systématiquement les textes des autres, commencez-vous à mieux comprendre le sujet, y compris les coins, où vous ne regarderiez pas vous-même? Est-il utile qu'un testeur soit également éditeur?- Le travail éditorial est assez différent du lecteur. La tâche de l'éditeur n'est pas de comprendre ce qui est écrit dans le texte, mais plutôt de ne pas manquer les défauts. Honnêtement, cela ne contribue pas à un aspect holistique. Lorsque nous sélectionnons du matériel, je le regarde davantage en tant que lecteur: est-ce intéressant à lire ou non. En ce moment, je ne suis pas encore éditeur. Mais quand nous regardons le texte traduit et préparons la publication, alors dans ce cas, en tant qu'éditeur. Pour que lors de l'édition, lors de la préparation de la publication, quelque chose soit compris - cela ne se produit pas. Il existe donc différents modes: l'un est l'éditeur, l'autre le lecteur.
- Question indiscrète. Il y a des bannières publicitaires sur software-testing.ru, mais en journalisme, il est difficile de les monétiser - est-ce mieux dans le cas de tests, ou cela ne compense-t-il pas votre travail et le site existe pour l'amour de l'art?- Aucun revenu publicitaire ne compense le travail sur le site. Il existe pour créer une image, une image, afin de maintenir notre présence sur le réseau. Et le centre de formation gagne de nous.
- La question suivante concerne uniquement la formation. Vous enseignez aux autres à tester depuis de nombreuses années, mais comment cela affecte-t-il votre façon de vous tester vous-même?- Voici le principe que vous avez évoqué un peu plus tôt: pendant que vous expliquez quelque chose à quelqu'un, vous comprendrez vous-même quelque chose. Cela aide vraiment à mieux comprendre, comprendre. Lorsque vous racontez un sujet pour la première fois, il semble que tout soit clair. Et puis vous regardez vos conférences, vous comprenez ce que vous pouvez mieux dire, refaites, de nouvelles choses apparaissent. Après cela, j'écris parfois des articles supplémentaires: d'abord vous préparez le matériel pour le cours, puis vous comprenez que vous devez ajouter autre chose pour le rendre plus clair. Et, bien sûr, il est encore plus intéressant d'obtenir une sorte de rétroaction. Les gens racontent aussi quelque chose d'intéressant. On vous pose une sorte de question soudaine, et seulement ici vous comprenez que vous ne comprenez pas. Et que je ne pensais pas du tout que je devais y penser. C'est précieux.
- Lorsque vous enseignez à beaucoup de gens, vous commencez à remarquer des erreurs typiques de beaucoup de gens. Pouvez-vous formuler une «erreur typique de testeur» générale?- Une erreur typique en général de toute personne est que la plupart des informaticiens essaient d'apprendre tout de leur propre expérience, de passer par tous les râteaux. De mon point de vue, il est plus logique de se déplacer d'une manière différente: étudier quelque chose, et ensuite seulement continuer le travail.
À cet égard, je suis une personne atypique. Lorsque j'achète des appareils électroménagers, je m'assois d'abord et je lis les instructions. Par conséquent, transférer ma propre expérience psychologique à d'autres personnes est assez difficile pour moi. Je comprends que oui, la plupart des gens n'agissent pas comme ça, ils font d'abord le tour du râteau, puis ils commencent à comprendre comment éviter cela. Je crois que c'est faux et ils croient que c'est juste.
- Maintenant, je veux poser des questions sur le sélénium. Comment la communauté Selenium Driver et l'ensemble de l'écosystème qui l'entoure entrent-ils dans la communauté? Y a-t-il des étapes et des réalisations? Par exemple, «effectuez dix demandes d'extraction et passez à l'étape suivante».- Il n'y a pas de procédure standard, pas de réglementation, pas de critères de sélection spécifiques. Tout est complètement individuel. Lorsque vous voyez qu'une personne est déjà impliquée, elle obtient progressivement plus de droits. Ce processus de connexion se déroule différemment pour tout le monde. Quelqu'un commence à corriger les bogues et envoie des demandes de tirage. Et quelqu'un commence à répondre aux utilisateurs de la liste de diffusion: nous avons une personne chargée de travailler avec des utilisateurs qui n'ont même pas un seul commit sur le code, mais il détient en fait la liste de diffusion. Quelqu'un écrit de la documentation -
c'est une tâche qui implique également de travailler avec le code source, mais, bien sûr, la plupart des gens perçoivent la participation au projet spécifiquement avec les demandes de tirage.
Il y a un problème d'organisation avec les pull pulls lié au fait que nous n'avons pas assez de travailleurs, donc les pull pulls peuvent durer très longtemps et personne ne les considère. Par conséquent, vous devez être persistant pour être remarqué. Vous devez non seulement envoyer une demande d'extraction, vous devez la traverser. Ceux qui franchissent ce filtre parviennent alors à entrer progressivement dans le projet.
- Et à qui écrire pour percer?- Oui, écris à tout le monde. Dans le chat IRC, demandez d'évaluer la demande de tirage. En général, il existe des filtres non techniques à travers lesquels une personne pénètre progressivement. Et si vous avez fait une pull request et attendez d'être invité au projet, alors non, ils ne le feront pas.
- Je veux intuitivement supposer que si un outil très populaire parmi les testeurs est en cours de développement, il a lui-même été testé de manière beaucoup plus approfondie que le projet informatique moyen. Est-ce que l'exemple du sélénium le confirme ou non?- Je ne connais pas le "projet moyen", mais Selenium est vraiment testé assez minutieusement. Il existe de nombreux tests, les tests fonctionnent constamment, ils trouvent constamment des bogues, y compris des bogues de régression, y compris des bogues de régression dans les navigateurs. J'écris régulièrement des rapports de bogues aux développeurs de navigateurs.
Il me semble que la situation avec les tests est assez prospère, même si je ne peux pas dire que les tests sont partout écrits de manière complètement systématique: après tout, eux aussi ont grandi de manière organique au cours des vingt dernières années. Si vous commencez à les écrire à partir de zéro, prenez la spécification et concevez-la soigneusement, alors, il serait probablement préférable d'écrire de nombreux tests d'une manière différente. Mais jusqu'à présent, il n'était pas question de s'asseoir et de réécrire complètement une partie des tests, les tests issus de l'agriculture biologique font face à leur tâche.
- Il y a souvent des litiges «quel navigateur est le meilleur», et puisque vous leur envoyez des rapports de bogues, il est intéressant de comparer du côté non standard: quels navigateurs ont la meilleure réponse aux rapports de bogues et lesquels sont pires?- Je ne voudrais offenser personne, donc je ne critiquerai personne, mais je peux faire l'éloge. Les développeurs de Firefox réagissent le mieux. Ils sont les plus impliqués, les plus actifs pour travailler avec les rapports de bugs. Ce qui correspond peut-être à leur esprit open source.
Et le plus ennuyeux n'est pas la réaction des équipes aux rapports de bugs. C'est ce que les entreprises développant des navigateurs à code fermé (Microsoft, Apple) ont un tracker de bogues fermé. Autrement dit, lorsque vous rencontrez un bug, vous ne pouvez pas voir si quelqu'un a déjà envoyé un tel rapport de bug, est-ce un bug connu.
- Il y a quelques années, vous avez dit que la tâche de Selenium était de devenir une norme Web. Il est devenu, et puis quoi? Quelle est la prochaine grande étape?- Capturez le monde face aux outils d'automatisation. Autrement dit, nous devons nous assurer que toute cette nouvelle norme est prise en charge.
- Autrement dit, pour devenir un module intégré pour tous les autres nouveaux outils d'automatisation de l'interface utilisateur?- Oui. Autrement dit, ils peuvent utiliser dix autres modules supplémentaires, mais ils devraient tous être en mesure de travailler via le protocole standard.
À l'intérieur de Selenium, il y a la tâche importante suivante, qui sera d'abord résolue par certaines implémentations de prototypes, puis dans le cadre de la norme. Le protocole HTTP est essentiellement à sens unique, c'est-à-dire qu'un côté envoie des demandes, l'autre les traite, et il n'y a pratiquement aucun retour. Et ce n'est pas très bon, et c'est précisément ici que les concurrents le signalent très activement, faisant pression sur ce point sensible, car je voudrais grosso modo avoir des rappels. Lorsque certains événements se produisent dans le navigateur, j'aimerais que des notifications à ce sujet arrivent. Ce n'est pas encore dans l'outil Selenium. Mais nous voulons vraiment ajouter ceci. Donc, peut-être, des changements cardinaux auront lieu, un changement de protocole est possible. Sans cela, ce sera difficile. Nous avons besoin d'un protocole bidirectionnel.
"Vous et Simon Stewart êtes les principaux contributeurs de Selenium, non?"- Cela est vrai en ce qui concerne la partie Java.
"Pour autant que je sache, vous ne vous êtes jamais rencontrés." Comment est-ce arrivé? Les développeurs de Selenium n'ont pas de "corporate"?- «Parties d'entreprise» que nous avons sous forme de réunions lors de conférences, mais séparément - non. Et dans le cas des conférences, Simon est même venu à Moscou l'an dernier Heisenbug, mais je n'étais pas à Moscou à ce moment-là, donc nous ne nous sommes pas croisés.
Mais, franchement, nous vivons maintenant dans un monde tel que ça va, nous communiquons toujours en permanence.
- La dernière question, enfin. Selon vous, quel sera l'avenir du test de l'automatisation en général et de l'interface utilisateur en particulier?- Je n'aime pas faire de prévisions, car elles ne se réalisent presque jamais. Les tests sont à l'origine du développement avec un certain retard; Par conséquent, les développeurs dictent la mode: ils se sont introduits à l'amiable dans JS - lors des tests, tous se sont également introduits à l'amiable dans JS. Et nous devrons suivre les changements. Et ce que les développeurs auront - qui sait.
Alexey se produira au Moscow Heisenbug les 6 et 7 décembre - et à côté de lui, il y aura des dizaines d'autres intervenants. Sur le site Web de Heisenbug, vous pouvez voir le programme complet et acheter un billet.