Die Entwicklungsansätze in den letzten zehn Jahren haben sich grundlegend geändert, und auch die Anforderungen an Tester (QS, QE, Qualitätsingenieure) haben sich geändert. Aber nicht alle Tester sind bereit, ein ganz neues Level zu betreten. Gestern war es möglich, von der Straße zu kommen, um in den Beruf einzusteigen. Um heute ein gefragter Spezialist zu werden, müssen Sie Ingenieur sein.
Zu Beginn einer Karriere wurde in den Kursen eine Präsentation gezeigt, die die Notwendigkeit von Tests untermauert. Die Signatur auf der Folie lautete: "Je früher Sie einen Fehler im Lebenszyklus des Produkts finden, desto billiger ist die Behebung." Die Testraten sind niedriger als bei Programmierern. Wir stellen Tester ein → stellen Qualität sicher und sparen bei der Entwicklung. Profit!
Tester waren Insektenjäger. Programmierer schreiben Funktionen, eine Veröffentlichung wird vorbereitet, die Veröffentlichung durchläuft die QS-Phase. Zu dieser Zeit setzte der Tester den Hut eines echten Benutzers auf und begann, typische Szenarien auszuführen. Es wurde angenommen, dass eine Person ohne technischen Hintergrund für diese Position geeignet wäre.
Die Entwicklungsgeschwindigkeit moderner Projekte hat zugenommen. Das Konzept von CI / CD erschien. Niemand ist von den täglichen Release-Projekten überrascht. Unternehmen haben erkannt, dass manuelle Überprüfungen nicht skalierbar sind. Die Tester befassten sich mit der Automatisierung von Abnahmetests unter Verwendung von Selen oder ähnlichen Frameworks. Die Änderung der Innenseiten ist verborgen, wenn nur das Frontend mit den erforderlichen Locators verbleibt.
Und so war es auch. Für Manager ist die Testautomatisierung mit einer Fähigkeit verbunden: der Arbeit mit Selen. Auf der Suche nach einer Silberkugel sahen sie in ihm die Antwort auf alle Fragen. Der Markt hat sich an die Nachfrage angepasst.
Wir haben lange nach QA-Automatisierung zum Testen von Webdiensten gesucht. Ich habe ein paar hundert Lebensläufe durchgesehen und Dutzende von Interviews geführt. Wenn man die Eindrücke zusammenfasst, können drei Hauptprobleme unterschieden werden, die oft verhindern, dass man eine Person anstellt.
1. Tester haben keine Ahnung von der Architektur des Projekts
Mit Architektur meine ich hier eine allgemeine Beschreibung der Wechselwirkungen von Systemkomponenten. Herkömmlicherweise werden die Daten durch „Pipes“ geleitet, wo sie gespeichert werden und wie sie verwendet werden.
Während des Interviews kann der Kandidat Einwände erheben, sie sagen, wir brauchen keine Kenntnisse der Architektur. Wir arbeiten mit einer Black Box. Warum sich um die interne Struktur kümmern?
Ich glaube nicht, dass der Ingenieur mit einem solchen Ansatz alle möglichen Testszenarien entwickeln wird. Wenn Sie die interne Struktur des Produkts kennen und den Code lesen, können Sie doppelte Tests auf hohen Ebenen der Testpyramide vermeiden.
Pyramidenvariante von Martin Fowler
Bei Black-Box-Tests gibt es dieselbe Falle wie bei der Sicherheit durch Dunkelheit . Sie können sich nicht nur auf diese Art von Tests verlassen. Das Produkt kann die angegebenen Anforderungen erfüllen und gleichzeitig eine große Anzahl versteckter Fehler enthalten. In Analogie zur Sicherheit durch Dunkelheit besteht die einzige Qualitätsgarantie in unserer Unkenntnis darüber, wie das System im Inneren angeordnet ist.
Der Vorteil von Black-Box-Tests besteht darin, dass die Tests unabhängig von der Implementierung sind. Wow. Diese künstliche Einschränkung sollte jedoch das Verständnis der Innenseiten nicht beeinträchtigen. Wenn der Tester weiß, wie das Produkt funktioniert:
- Angesichts eines Fehlers kann es das Problem lokalisieren und keine Hypothesen aufstellen.
- Bei der Diskussion einer neuen Funktion ist er bereit, Feedback zu geben, da er versteht, wie sich die neue Funktion in vorhandene Komponenten integriert.
Malewitsch bewegt sich, um die Black Box zu testen
Wahrscheinlich führte die gleiche Liebe zur Black Box zum zweiten Problem.
2. Tester verstehen nicht, was im Browser passiert
Oft gibt es eine Situation, in der ein Kandidat, dessen Selen als Hauptwerkzeug im Lebenslauf angegeben ist, nicht versteht, wie der Browser und das HTTP-Protokoll funktionieren. Das Testen für solche Automatoren besteht hauptsächlich in der Erstellung von Skripten mit Benutzeraktionen. Ein oberflächlicher Ansatz, der unnötige Einschränkungen schafft.
Die meisten Antragsteller nennen Beispiele für HTTP-Codes und Arten von HTTP-Anforderungen. Die nächste Frage ist oft verwirrend.
Es gibt eine Anmeldeseite. Der Benutzer gibt die richtigen Daten für die Autorisierung ein und klickt auf die Anmeldeschaltfläche. Was passiert gerade im Browser? Warum erfordern die nachfolgenden Aktionen mit der Site keine erneute Autorisierung?
Wenn der Tester diese Fragen nicht beantwortet hat, schleicht sich ein Zweifel an seiner Kompetenz ein. Dies legt nahe, dass der Kandidat:
- kann ein Produkt ohne Benutzeroberfläche nicht testen;
- Weiß nicht, wie man Entwicklertools in einem Browser verwendet;
- Ich bin es nicht gewohnt, die Ursache des Fehlers herauszufinden (Frontend oder Backend).
Für den Entwickler ist es einfacher, den Fehler zu beheben, wenn er mit technischen Details beschrieben wird.
3. Nachlässige Haltung gegenüber dem Testcode
"Mein Code wird nicht produziert. Warum sollte man sich um Qualität kümmern?"
Ich sehe dies als einen Versuch, die Sandkästen zu teilen. Lassen Sie die Entwickler auf die Sauberkeit des Codes achten, aber wir können.
Denken Sie daran, dass es im Kaskadenmodell nach der Entwicklung eine Verifizierungsphase gab? Während der Zeit der Wasserfallmethode wurde die Verantwortung für die Qualität auf die Testabteilung übertragen. Es hat zu nichts Gutem geführt. Programmierer haben nicht über die Bereitschaft der Funktion nachgedacht und erwartet, dass die Qualitätssicherung Probleme meldet. Ping-Pong zwischen den Abteilungen führte zu einer Verlangsamung der Entwicklung. Dies ist der Preis für die Aufteilung der Verantwortung.
Mit dem Aufkommen von Agile haben sich die Teams konsolidiert. Fehlende "wir" und "sie". Das Team ist für das Endergebnis verantwortlich. Und da technische Praktiken mittlerweile üblich sind, sollten die Anforderungen für den Testcode dieselben wie für den Produktcode sein.
Um Kandidaten auszuschalten, haben wir eine Testaufgabe ohne Frist gesendet:
Java http://todomvc.com/examples/react/
Liste der häufigsten Fehler
Zusätzliche Komplikationen
Ein Stapel von Abstraktionen, Wrappern über Klassen und Boilerplate-Code innerhalb der Tests.
Testmethoden werden am besten so kurz wie möglich gehalten. Hierbei helfen Hilfsfunktionen und das Trennen des Setups von Aktionen für Objekte und Überprüfungen.
Verletzung von Konventionen zur Benennung von Klassen, Methoden, Variablen
CamelCase mit Unterstrichen verwechselt. Also tragen sie es jetzt nicht. Linter- und IDE-Hinweise speichern.
Hardcode-Hilfspfade
String exePath = "Chrome_driver/chromedriver.exe"; System.setProperty("webdriver.chrome.driver", exePath);
Der Klassiker "funktioniert auf meiner Maschine."
Speicherung von Binärdateien im Repository
Es gibt git-lfs , um dieses Problem zu lösen.
Mangelnde Konsistenz der Methoden
In einer Lösung beschrieb der Kandidat Methoden zum Löschen und Markieren von „erledigt“ wie folgt:
public void DeleteTask(String task) ... public void CompleteTask(int taskno)
Bei der ersten Methode wird der Aufgabentext übertragen, bei der zweiten der Index in der Liste. Die Verwendung einer solchen API ist schmerzhaft.
System.out.println() für die Protokollierung
Es enthält keine unterstützenden Informationen darüber, in welcher Klasse das Ereignis aufgetreten ist.
Verwenden von Thread.sleep
Um dieses Problem zu lösen, gibt es eine Wartebibliothek . Es hilft, Feedback zur Erwartung der Erfüllung der notwendigen Bedingung hinzuzufügen.
Allgemeine Ausnahmen statt asert
Beispiel: Ein Test fügt der Liste der Aufgaben mehrere Elemente hinzu und markiert alle Elemente als erledigt. Die Idee ist, dass bei Problemen die findElement Methode eine NoSuchElementException und der Test NoSuchElementException . Wenn Sie sich später die Ergebnisse des Testlaufs NoSuchElementException , ist NoSuchElementException irreführend: Es ist nicht klar, ob der Test wirklich gefallen ist oder der Code der Testkurve. Bei einem Testfehler muss eine Warnung mit einer eindeutigen Fehlermeldung verwendet werden.
Missbrauch von Bertic Acerts
assertTrue oder assertFalse wird für alles in einer Reihe verwendet:
assertTrue("One To Do item should be added", toDosPage.getToDoListCount(false) == 1);
Es ist besser, assertEquals hier zu verwenden, um den Kontext zu haben, wenn der Test abstürzt.
Es gibt keine Parametrierung zum Ausführen von Tests
Beispiel: Die Site-URL zum Testen ist in Code eingebettet.
Wir sollten auch erwähnen, mit git . Meistens wurde die Aufgabe in einem einzigen Commit gesendet. Das Schreiben verständlicher Commit-Nachrichten und das Aufteilen einer großen Aufgabe in mehrere separate Nachrichten ist eine notwendige Fähigkeit, insbesondere in der Teamarbeit.
Schlussfolgerungen
Die oben beschriebenen Probleme sind meine persönlichen Erfahrungen und Eindrücke nach den Interviews. Beobachtungen zufolge korreliert die Erfahrung des Bewerbers nicht mit der Anzahl der Lücken. Vermeiden Sie homöopathische Tester und investieren Sie Zeit in das Pumpen der technischen Fähigkeiten der Mitarbeiter. Tester können von Entwicklern etwas lernen und umgekehrt. Möge Gewalt mit denen kommen, die Ingenieurkultur aufbauen und gegen den Strom schwimmen.
Ich werde froh sein, falsch und glücklich zu sein, wenn in Ihrer gemieteten Firma alles anders ist.
UPD 11/02/20 : Beim Webinar „Porträt eines Testers“ teile ich meine Meinung darüber, wie ich den Beruf von innen sehe.
- Warum braucht ein Unternehmen Tester?
- Die Rolle des Testers im Team
- Manuelle VS automatisierte Tests
- Attraktive Aspekte des Berufs und der Preis für Erfahrung
- Notwendige Hard / Soft Skills
- Fehler im Lebenslauf von Anfängern
- Devops beim Testen
- Karrierewachstum