Selen und nicht technische Teammitglieder

Ich arbeite in einem Team, das eine Website mit einer großen Anzahl von Seiten entwickelt. Der QA-Mitarbeiter im Team führt derzeit alle Tests manuell durch. Ich denke daran, dass er eine Reihe von Selenium-Skripten erstellt. Ich glaube nicht, dass er alle Tests automatisieren kann, aber er könnte viele davon automatisieren.

Wie schwierig wird es für ihn sein, eine Reihe von Selenium-Skripten zu erstellen und zu verwalten, da er keinen Programmierhintergrund hat? Bei welchen Problemen wird er Hilfe brauchen?

Ich denke, Selen als eigenständiges Tool zum Aufzeichnen und Wiedergeben ist ideal für nicht technische Benutzer. Die Redewendung, meinen Pfad aufzuzeichnen und dann wiederzugeben, ist intuitiv, und die Benutzeroberfläche ist zwar offensichtlich auf Nicht-Neulinge ausgerichtet, aber nicht zu einschüchternd.

Selen 2 / Selen RC ist offensichtlich eine höhere Komplexitätsordnung, und ich glaube nicht, dass Sie einen Nicht-Programmierer bitten können, sich damit zu verbinden. (Ich war frustriert über das Fehlen einer vollständigen Benutzeroberfläche für Nicht-Java-Sprachen. Ich weiß, dass die aktuelle Version vorübergehend ist, aber ich könnte jetzt wirklich eine vollständige PHP-Lösung verwenden, nicht in einer mythischen zukünftigen Version. Aber das ist es nicht was du fragst.)

Ich denke, wenn Ihr Tester noch nichts über Selen weiß, wird er Sie direkt auf den Mund küssen, weil Sie ihm davon erzählt haben.

Selen-IDE wurde entwickelt, um von Nicht-Programmierern verwendet zu werden. Ich habe jedoch die Erfahrung gemacht, dass die auf diese Weise erstellten Skripte (mit generiertem XPath) sehr spröde sind.

Das Erstellen in ihnen sollte also überhaupt kein Problem sein. Die Verwaltung ist nicht so schlecht, wenn Ihre Anwendung ziemlich stabil ist. Oder fast unmöglich, wenn sich Ihre Anwendung in der Entwicklung befindet und / oder sich häufig ändert.

Selenium-RC ist ein reines Entwicklerwerkzeug.

Ich empfehle Ihnen dringend, diese Frage auf der Beta-Site für Software Quality Assurance & Testing zu stellen oder nach ähnlichen Fragen zu suchen, die dort bereits gestellt wurden. Sie werden viel mehr Erfahrung mit der Verwendung von Selen für die Qualitätssicherung bei Aufzeichnung und Wiedergabe haben.

Erics Antwort ist die Erfahrung der meisten QS-Ingenieure, die Aufnahme- und Wiedergabetools verwendeten: Die resultierenden Tests waren spröde und schwer zu warten. Ein Entwickler kann Seitenobjekte mit Selenium RC verwenden, um eine weitaus wartbarere UI-Testsuite zu erstellen, und ist eine bessere Option, wenn sie verfügbar ist.

Dies bedeutet nicht, dass Selenium IDE für Ihren Tester nicht nützlich ist. Der Nutzen (und das Potenzial, die Testbemühungen eher zu beeinträchtigen als zu helfen) hängt jedoch stark davon ab, wie fest die Benutzeroberfläche ist. Mit Aufnahme und Wiedergabe erzielen Sie die besten Ergebnisse, wenn die Benutzeroberfläche zu Beginn des Entwicklungszyklus eingefroren werden kann. Möglicherweise müssen Sie dem Tester beibringen, wie Sie neue XPaths erhalten, wenn die alten XPaths defekt sind, und wie Sie feststellen können, ob der Test aufgrund einer Änderung der Benutzeroberfläche (weil der XPath nicht mehr gültig ist) oder aufgrund eines Funktionsfehlers fehlschlägt.

Ich denke, die Verwendung von Selenium IDE ist für jedes Projekt mit einer allgemein stabilen Benutzeroberfläche besser als gar keine Automatisierung. Das Ausführen von Hunderten von manuellen Tests auf einer stabilen Benutzeroberfläche bei jeder geringfügigen Änderung ist eine echte Zeitsenke. Stellen Sie die Erwartungen einfach entsprechend ein und stellen Sie fest, dass das Ändern der Benutzeroberfläche einen erheblich größeren Einfluss auf den QS-Zeitplan hat, sobald Sie die Automatisierung von Aufzeichnung und Wiedergabe für diese Benutzeroberfläche verwenden. Ihr Tester möchte möglicherweise die Bereiche auswählen, die er mit Bedacht automatisiert.

Ich hatte keine Probleme damit, Nicht-Programmierer darin zu schulen, Selenium-Tests mit relativen XPaths in Java / JUnit zu schreiben. Der Programmierer richtet es ein und schreibt eine grundlegende Testvorlage. Der Tester entwickelt weitere Tests - indem er sie aufzeichnet und dann optimiert. Wenn der Tester etwas Bestimmtes benötigt, bittet er den Programmierer, es zu schreiben. Der Tester muss über ein grundlegendes Verständnis von HTML und XPath verfügen und ein wenig Hilfe beim Erlernen der Selenium-API (sowie des Selenium-Plugins für Firefox und Firebug) benötigen.

Das Lustige ist, dass ich zuerst über etwas Besonderes wie Gurke oder ähnliches nachgedacht habe, aber diese Selen / JUnit-Kombination erwies sich als gut genug und einfach genug. Seltsamerweise hatten Tester ohne Java-Vorkenntnisse keine ernsthaften Probleme beim Schreiben von JUnit-Tests. Das einzig Wichtige ist, dass ein erfahrener Programmierer den Test einrichtet, sodass der Tester im Grunde nur neue Tests erstellen und Selenium-Methoden aufrufen muss.

Erwägen Sie die Verwendung eines schlüsselwortgesteuerten Testframeworks. Die Idee ist, dass Entwickler Schlüsselwörter auf hoher Ebene entwickeln (oder Sie die in einer Bibliothek enthaltenen verwenden) und der Tester diese Schlüsselwörter einfach zu Testfällen auf hoher Ebene zusammensetzt.

Die Teams, in denen ich in den letzten Jahren war, haben durch diesen Ansatz eine Menge Meilen gesammelt. Wir verwenden das Roboter-Framework, aber es gibt auch andere wie Gurke (von mehreren Sprachen unterstützt) und Specflow (eine Gurkenimplementierung für .net).

Mit diesem Ansatz könnte Ihr Tester beispielsweise einen Test schreiben, der folgendermaßen aussieht:

| Login with valid credentials
| | Go to page | LoginPage
| | Login as a normal user
| | The current page should be | DashboardPage

Diese Schlüsselwörter können wie folgt in Python (oder Java oder einer .NET-Sprache) geschrieben werden:

class LoginPage(PageObject):
    def login_as_a_normal_user(self):
        username = self.browser.find_element_by_id("username")
        username.send_keys(DEFAULT_USER)
        password = self.browser.find_element_by_id("password")
        password.send_keys(DEFAULT_PASSWORD)
        ... and so on...

Es gibt eine vorgefertigte Bibliothek für Roboter mit generischen Schlüsselwörtern, die auf Selen basieren ("Zur Seite gehen", "Seite sollte enthalten", "Klick-Schaltfläche" usw.), mit denen der Tester sofort produktiv werden kann.

Sehr oft sind diese generischen Schlüsselwörter ausreichend, aber die Verwendung des Konzepts von Seitenobjekten und seitenspezifischen Schlüsselwörtern ist eine leistungsstarke Methode zum Schreiben von Tests. Ihre Entwickler können für jede Seite in Ihrer App eine Klasse erstellen und für jede Seite spezielle Schlüsselwörter schreiben, damit sich der Tester mehr auf die logische Funktion der Seite als auf die physische Implementierung konzentrieren kann.

Hier sind ein paar Blog-Beiträge, die ich geschrieben habe und die sich eingehender mit der Verwendung von Seitenobjekten mit Roboter-Framework befassen:

• Robot Framework-Seitenobjekte
• Verwenden von Mixins mit Seitenobjekten

Tatsächliche Erfahrung von nicht-technischen Teammitgliedern beim Schreiben von Selenium-Code: Es lief nicht gut

Wir hatten genau diese Situation, in der wir ein nicht technisches Teammitglied hatten (in diesem Fall eine SQA ohne Programmierhintergrund). Das lief leider nicht sehr gut.

Durch Aufzeichnen und Abspielen wurden nicht wartbare Tests erstellt

Zuerst hatte unser Team die Aufnahme- und Spielwerkzeuge ausprobiert, aber wie andere gesagt haben, sind die Tests, die es generiert, sehr spröde und schwer zu warten. Unsere SQA geriet schließlich in das Muster, einen Test jedes Mal neu aufzuzeichnen, wenn er sich änderte, was nicht wirklich so effizient war, insbesondere wenn eine Änderung die meisten unserer Tests durchbrach (wir hatten eine Änderung an der Hauptseite unserer Website, die ungefähr 60 durchbrach % unserer Tests).

Ohne die Hilfe von Personen mit Programmierhintergrund war der manuell geschriebene Code schrecklich

Wir haben unsere Selenium-Tests in Java geschrieben und die SQA hatte Java noch nie zuvor verwendet, also lernte er es selbst. Wir haben festgestellt, dass die Tests mit einigen wirklich schlechten Programmierpraktiken abgeschlossen wurden:

• Verwendung öffentlicher statischer Variablen, wenn es sich eigentlich um private Instanzvariablen handeln sollte
• Codeblöcke haben, die nichts bewirken
• Viele Thread.sleep () anstelle von WebDriverWait, da er nicht herausfinden konnte, wie benutzerdefinierte Bedingungen geschrieben werden
• Wirklich umständlicher Unit-Test: Ich habe einige assertTrue(false)Zeilen gesehen, um einen Test zu beenden
• Schlechte Variablennamen
• Unterdrückung von Ausnahmen, die hätten behandelt werden sollen (oder von vornherein verhindert werden sollten)
• Tests, die unabhängig von der verwendeten Eingabe bestanden wurden
• Ein Code, den wir nie herausgefunden haben und den wir gerade neu geschrieben haben

Als ich im Team ankam, war die ursprüngliche SQA gegangen und das Ausführen eines Tests führte zu einer Reihe von Konsolenausnahmen, die wir einfach ignorieren sollten. Danach haben wir Entwickler involviert und einen Großteil des Codes massiv neu geschrieben, damit er tatsächlich richtig funktioniert und wartbar und leicht verständlich ist.

Wenn nicht-technische Mitarbeiter Selen-Code schreiben sollen, lassen Sie sich von einer technischen Person helfen

Ich denke, dass einige dieser Probleme vermieden worden wären, wenn wir jemanden gehabt hätten, der technisch versiert war, um ihnen zu helfen. Wenn sie erklärt hätten, warum öffentliche statische Variablen stattdessen private Instanzvariablen sein sollten, wie JUnit funktioniert, wie WebDriverWait verwendet wird oder warum es schlecht ist, Thread.sleep () überall zu verteilen, hätten wir möglicherweise besseren Code.

Aber so wie es ist, haben wir Code gefunden, der letztendlich nicht zu warten war, und am Ende haben wir nur das meiste neu geschrieben, was zu einer großen Zeit- und Geldverschwendung geführt hat.