Alexey Barantsev ist wahrscheinlich einer der bekanntesten Menschen im russischen Testen: Er ist sowohl durch
software-testing.ru als auch durch selenium2.ru und nicht nur durch die Teilnahme an Selenium WebDriver bekannt. Gleichzeitig ist er einer der erfahrensten: bereits seit 1994 im Test. Und als bekannt wurde, dass er auf unserer Heisenbug-Konferenz mit dem
Bericht „Probleme in Selenium WebDriver“ sprechen würde, wollten wir einen solchen Redner fragen. Wir begannen mit Fragen darüber, wie sich das Testen in den 90er Jahren von heute unterschied, und gingen dann zu modernen Realitäten über.
- Unter den Lesern des Interviews befinden sich möglicherweise Personen, die noch nicht einmal geboren wurden, als Sie bereits mit dem Testen begonnen haben. Sagen Sie, wie war dann alles anders als in unseren Tagen?- Wenn wir über einige Grundlagen des Testens sprechen (Theorie, Schlüsseltechniken), gibt es keine besonderen Änderungen. Gleichzeitig ändert sich die Testautomatisierung natürlich ständig. Neue Entwicklungstechnologien erscheinen und verschwinden, und mit ihnen entstehen oder verschwinden die Technologien und Werkzeuge zum Testen von Software. Wie kann man die Prüfung dessen vergleichen, was damals war und was heute ist? Zum Vergleich, was besser ist - früher gab es SOAP, jetzt REST. Dann haben wir Webdienste getestet, die mit SOAP geschrieben wurden, und jetzt diejenigen, die mit REST geschrieben wurden. Welchen Unterschied macht es?
- Nun, einige Technologien sind nicht nur „aufgetaucht und verschwunden“, sondern wurden zu einer Technologie, ohne die es heute schwer vorstellbar ist: „Wie haben wir überhaupt ohne Git gelebt?“- Sie lebten normal ohne Git. Es gab CVS, wir haben gut damit gelebt, dann gab es Subversion, dann Git. Das ist alles nicht so interessant, aber was sich wirklich sehr verändert hat, ist die Geschwindigkeit. Die Geschwindigkeit der Entwicklung und damit die Geschwindigkeit des Testens. Es geht nicht einmal um kurze Iterationen, Agile, den Ansatz zur Organisation der Arbeitszeiten. Genau die Geschwindigkeit der Produktentwicklung hat sich geändert.
Als wir Mitte der 90er Jahre anfingen zu arbeiten, hatten wir Projekte mit einer Laufzeit von sechs Monaten, einem Jahr und zwei Jahren. Entwicklung und Erprobung. Dann begannen diese Projekte auf drei Monate, zwei zu sinken. Tatsächlich wurde in zwei Monaten dasselbe entwickelt wie früher in einem Jahr. Und jetzt passiert: Die Leute kommen zum Hackathon, entwickeln an einem Tag ein funktionierendes Produkt, testen es und starten es. Es ist klar, dass dies immer noch ein Prototyp ist, aber dennoch für einen Tag. Das konnte man sich nicht vorstellen.
Warum passiert das? Natürlich entwickeln sich Werkzeuge weiter. Aber es geht nicht einmal um Tools, einige schreiben immer noch Code in vi oder emacs. Noch wichtiger ist, dass bereits viel vorgefertigter Code geschrieben wurde. Es gibt gute Bibliotheken, die gründlich getestet wurden. Irgendwo müssen Sie noch viel Code schreiben, einzigartige Algorithmen entwickeln und alles dauert dort noch lange. In anderen Situationen können Sie jedoch vorgefertigte Komponenten entnehmen, von denen Sie schnell wie von einem Designer das fertige Produkt zusammenbauen können. Dementsprechend ist es auch einfacher, es zu testen, da wir es bereits aus zuverlässigen, getesteten Komponenten zusammenbauen. Das hat sich sehr verändert.
- Und was hat sich in der Weltanschauung der Menschen geändert - wie sehen wir das Testen / Entwickeln und was erwarten wir von ihnen?- In den 90er Jahren hatten sowohl Entwickler als auch Tester mehr Vertrauen in Standards. Eigentlich ist Agile nicht von Grund auf neu entstanden, sondern nur wegen Enttäuschungen bei all diesen Standards.
Erstens gab es die Idee, dass die Standards uns vor Code von schlechter Qualität bewahren: Wir werden alles in Übereinstimmung mit den Standards schreiben und alles wird sich gut integrieren und funktionieren. Vielleicht stimmt das sogar, nur die Standards werden sehr langsam entwickelt, und alles läuft sehr schnell vorwärts und wird veraltet, bevor die Standards akzeptiert werden.
Zweitens bestand die Zuversicht, dass es möglich sein würde, Diagramme gemäß UML-Diagrammen formal zu zeichnen, Softwareanforderungen zu beschreiben und automatisch Quellcode zu generieren, und all dies würde funktionieren und es wäre nicht einmal notwendig, Tests durchzuführen. Es wurde angenommen, dass Entwickler bald aufhören würden, Code zu schreiben, stattdessen UML-Diagramme zeichnen und Bedingungen in einer höheren Sprache beschreiben würden. Es ist nicht gestartet, es hat nicht geklappt. Obwohl auf dieser Party, auf der ich mich umdrehte, sehr große Wetten darauf abgeschlossen wurden.
Jetzt hat wahrscheinlich eine Art neue Welle begonnen: Künstliche Intelligenz sprießt von überall her von überall her, und wieder entsteht die Idee, dass Entwickler bald keinen Code mehr schreiben werden. Stattdessen werden einige künstliche Intelligenzsysteme trainiert und alles wird von selbst funktionieren. Dementsprechend müssen Tester nichts tun. Die Entwickler werden künstliche Intelligenz trainieren und er wird alles tun. Mal sehen, wie es sein wird. Vielleicht klappt es wie beim letzten Mal.
- Gehen wir weiter zu unserer Zeit. Sie verwenden software-testing.ru. Für diejenigen, die ihm nicht aktiv folgen: Was passiert dort?- Wir veröffentlichen viele Inhalte, jetzt besteht der Hauptteil aus übersetzten Inhalten. Denn ehrlich gesagt ist es in Russland sehr schwierig, Autoren zu finden, die über Tests schreiben. Ich weiß nicht, warum es passiert ist: Es gab einen Moment, in dem viele Leute auf Russisch geschrieben haben und dann entweder der Treibstoff ausgegangen ist oder aus irgendeinem Grund nicht genügend Blogs und Artikel in RuNet vorhanden waren. Und im englischsprachigen Teil des Internets blüht das alles immer noch, dort sind viele Artikel geschrieben.
Die Kommunikation verlagerte sich allmählich in Chatrooms, dh die Leute schreiben keine Texte, sondern kommunizieren. Dies bedeutet nicht, dass wir diesen Trend sehr genau verfolgen. Wir nehmen an Chats teil, versuchen aber nicht, diesen Trend zu führen. Wir verhalten uns immer noch altmodisch und versuchen, den Menschen genau den Inhalt zu geben, und sie werden einen Platz für Kommunikation finden.
- Jetzt wechseln die Leute auch von Texten zum Video-Bloggen - aber gibt es so etwas beim Testen?- Beim Testen ist dieser Trend fast unsichtbar. Es gibt buchstäblich ein oder zwei Video-Blogger, Einzelfälle.
- Es gibt einen Ausdruck "Wenn Sie etwas wirklich verstehen wollen - versuchen Sie es anderen zu erklären." Und wenn Sie die Texte anderer Leute systematisch bearbeiten, beginnen Sie, das Thema besser zu verstehen, einschließlich der Ecken, in denen Sie selbst nicht hinschauen würden? Ist es für einen Tester nützlich, auch Redakteur zu sein?- Die redaktionelle Arbeit unterscheidet sich stark vom Leser. Die Aufgabe des Herausgebers besteht nicht darin, zu verstehen, was im Text geschrieben steht, sondern die Fehler nicht zu übersehen. Ehrlich gesagt trägt dies nicht zu einem ganzheitlichen Erscheinungsbild bei. Wenn wir Material auswählen, betrachte ich es eher als Leser: Ist es interessant zu lesen oder nicht? Im Moment bin ich noch kein Redakteur. Wenn wir uns aber den übersetzten Text ansehen und uns auf die Veröffentlichung vorbereiten, dann in diesem Fall als Herausgeber. Damit während der Bearbeitung, während der Vorbereitung auf die Veröffentlichung etwas verstanden wird - das passiert nicht. Es gibt also verschiedene Modi: Ein Modus ist der Editor, der andere ist der Leser.
- Indiskrete Frage. Es gibt Bannerwerbung auf software-testing.ru, aber im Journalismus ist es schwierig, damit Geld zu verdienen - ist es beim Testen besser oder kompensiert es nicht Ihre Arbeit und die Website existiert für die Liebe zur Kunst?- Keine Werbeeinnahmen kompensieren nicht die Arbeit auf der Website. Es existiert, um ein Bild zu erstellen, ein Bild, um unsere Präsenz im Netzwerk aufrechtzuerhalten. Und das Schulungszentrum verdient von uns.
- Die nächste Frage betrifft nur das Training. Sie haben anderen schon seit vielen Jahren das Testen beigebracht, aber wie wirkt sich das darauf aus, wie Sie sich selbst testen?- Hier funktioniert das Prinzip, das Sie etwas früher erwähnt haben: Während Sie jemandem etwas erklären, werden Sie selbst etwas verstehen. Es hilft wirklich, besser zu verstehen, zu verstehen. Wenn Sie zum ersten Mal ein Thema erzählen, scheint alles klar zu sein. Und dann schauen Sie sich Ihre Vorträge an, Sie verstehen, was Sie besser sagen können, wiederholen, einige neue Dinge erscheinen. Danach schreibe ich manchmal einige zusätzliche Artikel: Zuerst bereiten Sie das Material für den Kurs vor und dann verstehen Sie, dass Sie etwas anderes hinzufügen müssen, um es klarer zu machen. Und natürlich ist es noch interessanter, Feedback zu erhalten. Die Leute erzählen auch etwas Interessantes. Ihnen wird eine plötzliche Frage gestellt, und nur hier verstehen Sie, dass Sie nicht verstehen. Und dass ich überhaupt nicht daran gedacht habe, dass ich darüber nachdenken sollte. Das ist wertvoll.
- Wenn Sie viele Menschen unterrichten, bemerken Sie einige Fehler, die für viele Menschen typisch sind. Können Sie einen allgemeinen „typischen Testerfehler“ formulieren?- Ein typischer Fehler im Allgemeinen ist, dass die meisten IT-Mitarbeiter versuchen, alles aus eigener Erfahrung zu lernen und alle Rechen zu durchlaufen. Aus meiner Sicht ist es logischer, sich anders zu bewegen: etwas zu studieren und erst danach mit der Arbeit fortzufahren.
In dieser Hinsicht bin ich eine atypische Person. Wenn ich Haushaltsgeräte kaufe, setze ich mich zuerst hin und lese die Anweisungen. Daher ist es für mich ziemlich schwierig, meine eigenen psychologischen Erfahrungen auf andere Menschen zu übertragen. Ich verstehe, dass ja, die meisten Leute nicht so handeln, sie gehen zuerst um den Rechen herum und beginnen dann herauszufinden, wie sie dies vermeiden können. Ich glaube, dass dies falsch ist, und sie glauben, dass es richtig ist.
- Jetzt möchte ich nach Selen fragen. Wie kommen die Selenium Driver-Community und das gesamte Ökosystem um sie herum in die Community? Gibt es irgendwelche Schritte und Erfolge? Beispiel: "Führen Sie zehn Pull-Anforderungen aus und fahren Sie mit dem nächsten Schritt fort."- Es gibt kein Standardverfahren, keine Vorschriften, keine spezifischen Auswahlkriterien. Alles ist ganz individuell. Wenn Sie sehen, dass eine Person bereits beteiligt ist, erhält sie nach und nach mehr Rechte. Dieser Anmeldevorgang verläuft für alle unterschiedlich. Jemand beginnt Fehler zu korrigieren und sendet Pull-Anfragen. Und jemand beginnt, auf Benutzer in der Mailingliste zu antworten: Wir haben eine Person, die für die Arbeit mit Benutzern verantwortlich ist, die nicht einmal ein einziges Commit für den Code haben, aber tatsächlich die Mailingliste führen. Jemand schreibt Dokumentation -
Dies ist eine Aufgabe, die auch das Arbeiten mit dem Quellcode umfasst, aber natürlich nehmen die meisten Menschen die Teilnahme am Projekt speziell mit Pull-Anfragen wahr.
Es gibt ein organisatorisches Problem mit Pull-Anfragen, das damit zusammenhängt, dass wir nicht genügend Mitarbeiter haben. Pull-Anfragen können also sehr lange lügen, und niemand berücksichtigt sie. Daher müssen Sie hartnäckig sein, um bemerkt zu werden. Sie müssen nicht nur eine Pull-Anfrage senden, sondern diese auch durchbrechen. Diejenigen, die diesen Filter durchbrechen, schaffen es dann, schrittweise in das Projekt einzutreten.
- Und an wen soll man schreiben, um durchzubrechen?- Ja, schreibe an alle. Bitten Sie im IRC-Chat, die Pull-Anforderung auszuwerten. Im Allgemeinen gibt es nichttechnische Filter, durch die eine Person allmählich eindringt. Und wenn Sie eine Pull-Anfrage gestellt haben und warten, bis Sie zum Projekt eingeladen werden, dann werden sie dies nicht tun.
- Ich möchte intuitiv davon ausgehen, dass ein bei Testern sehr beliebtes Tool entwickelt wird, das selbst viel gründlicher getestet wurde als ein durchschnittliches IT-Projekt. Bestätigt das Selen-Beispiel dies oder nicht?- Ich weiß nichts über das "durchschnittliche Projekt", aber Selen wird wirklich ziemlich gründlich getestet. Es gibt viele Tests, Tests funktionieren ständig, sie finden ständig Fehler, einschließlich Regressionsfehler, einschließlich Regressionsfehler in Browsern. Ich schreibe regelmäßig Fehlerberichte an Browserentwickler.
Es scheint mir, dass die Situation mit den Tests ziemlich gut ist, obwohl ich nicht sagen kann, dass die Tests überall vollständig systematisch geschrieben sind: Schließlich sind auch sie in den letzten zwanzig Jahren organisch gewachsen. Wenn Sie anfangen, sie von Grund auf neu zu schreiben, nehmen Sie die Spezifikation und entwerfen Sie sie sorgfältig. Dann ist es wahrscheinlich besser, viele Tests auf andere Weise zu schreiben. Bisher gab es jedoch keinen Gedanken daran, sich zu setzen und einen Teil der Tests vollständig neu zu schreiben. Tests aus biologischem Anbau bewältigen ihre Aufgabe.
- Oft gibt es Streitigkeiten darüber, „welcher Browser besser ist“, und da Sie ihnen Fehlerberichte senden, ist es interessant, von der nicht standardmäßigen Seite zu vergleichen: Welche Browser reagieren am besten auf Fehlerberichte und welche sind schlechter?- Ich würde niemanden beleidigen wollen, also werde ich niemanden kritisieren, aber ich kann loben. Firefox-Entwickler reagieren am besten. Sie sind am involviertesten und am aktivsten in Bezug auf die Arbeit mit Fehlerberichten. Was vielleicht einfach zu ihrem Open-Source-Geist passt.
Am ärgerlichsten ist nicht die Reaktion der Teams auf Fehlerberichte. Dies ist, was Unternehmen, die Browser mit geschlossenem Code entwickeln (Microsoft, Apple), einen geschlossenen Bug-Tracker haben. Das heißt, wenn Sie auf einen Fehler stoßen, können Sie nicht sehen, ob bereits jemand einen solchen Fehlerbericht gesendet hat. Ist dies ein bekannter Fehler?
- Vor einigen Jahren haben Sie gesagt, dass die Aufgabe von Selen darin besteht, ein Webstandard zu werden. Er wurde und was dann? Was ist der nächste große Meilenstein?- Erfassen Sie die Welt angesichts von Automatisierungstools. Das heißt, wir müssen sicherstellen, dass all dieser neue Standard unterstützt wird.
- Das heißt, ein integriertes Modul für alle anderen neuen UI-Automatisierungstools zu werden?- Ja. Das heißt, sie können zehn weitere Module verwenden, aber sie sollten alle in der Lage sein, das Standardprotokoll zu verarbeiten.
In Selenium gibt es die folgende wichtige Aufgabe, die zuerst durch einige Prototyp-Implementierungen und dann im Rahmen des Standards gelöst wird. Das HTTP-Protokoll ist im Grunde genommen einseitig, dh eine Seite sendet Anforderungen, die andere verarbeitet sie und es gibt praktisch keine Rückmeldung. Und das ist nicht sehr gut, und genau hier weisen die Wettbewerber sehr aktiv darauf hin und üben Druck auf diesen wunden Punkt aus, weil ich grob gesagt Rückrufe haben möchte. Wenn einige Ereignisse im Browser auftreten, möchte ich einige Benachrichtigungen darüber erhalten. Dies ist noch nicht im Selenium-Tool enthalten. Aber wir wollen das wirklich hinzufügen. Vielleicht finden also Kardinaländerungen statt, eine Protokolländerung ist möglich. Ohne dies wird es schwierig sein. Wir brauchen ein Zwei-Wege-Protokoll.
"Sie und Simon Stewart sind die Hauptverantwortlichen von Selenium, oder?"- Dies gilt für den Java-Teil.
"Soweit ich weiß, hast du dich nie getroffen." Wie ist es passiert? Selen-Entwickler haben keine "Corporate"?- „Firmenfeiern“ haben wir in Form von Tagungen auf Konferenzen, aber separat - nein. Und im Falle von Konferenzen kam Simon letztes Jahr sogar nach Moskau, Heisenbug, aber ich war zu diesem Zeitpunkt nicht in Moskau, also haben wir uns nicht gekreuzt.
Aber ehrlich gesagt leben wir jetzt in einer solchen Welt, dass es in Ordnung ist, wir kommunizieren immer noch ständig.
- Endlich die letzte Frage. Was wird Ihrer Meinung nach die Zukunft der Testautomatisierung im Allgemeinen und der Benutzeroberfläche im Besonderen sein?- Ich mache keine Prognosen, weil sie fast nie wahr werden. Das Testen steht mit einer gewissen Verzögerung hinter der Entwicklung. Daher diktieren die Entwickler die Mode: Sie sind einvernehmlich in JS eingebrochen - auch beim Testen sind alle einvernehmlich in JS eingebrochen. Und wir müssen mit den Änderungen Schritt halten. Und was Entwickler haben werden - wer weiß.
Alexey wird am 6. und 7. Dezember im Moskauer Heisenbug auftreten - und neben ihm werden Dutzende weiterer Redner anwesend sein. Auf der Heisenbug-Website können Sie das vollständige Programm sehen und ein Ticket kaufen.