Warum wir QF-Test Squish vorgezogen haben?

Evaluationsbericht der R.J. Lee Group

Das QF-Test Team hat mich gefragt, wie wir QF-Test ausgewählt haben und wie wir es hier bei der RJ Lee Group verwenden. Ich habe ungefähr ein Dutzend GUI Testing Programme angesehen; nur QF-Test und Squish schienen unseren Anforderungen gerecht zu werden. Ich lud die Evaluationsversionen der beiden herunter, konfigurierte beide für unser System und schrieb ein paar Tests. Ich erklärte beide unserer manuellen Testerin und ließ sie sie ausprobieren. Ich zeigte sie auch unserem leitenden Entwickler. Dann diskutierten wir drei diese beiden Tools und kamen zu dem Entschluss, dass beide unseren technischen Anforderungen stand hielten, dann entschied sich aber jeder von uns unabhängig für QF-Test und nicht für Squish.

Hier sind die Gründe:

• Ich konnte QF-Test ohne eine einzige technische Support E-Mail installieren, da es eine bessere Dokumentation und Code Qualität hat. (Das Handbuch ist immer noch sehr hilfreich für mich, da es einfach zu durchsuchen ist, wenn ich etwas nachschlagen möchte.
• Die Widget/Komponenten Datenbank ist organisierter von QF-Test als die von Squish und sie erlaubt eine einfachere Überarbeitung der Widget Namen. Das war für uns wichtig, denn unsere Anwendung hat viele Felder mit Namen und Funktionen, die sich ändern, wenn sich Prozessabläufe verändern.
• Unserem Teamleiter gefiel, dass die Scripting Sprachen in QF-Test JVM Sprachen waren anders als bei Squish.
• Unsere damalige manuelle Testerin, jetzt Automatisierungs- und Exploringtesterin, fühlte sich wohler mit dem QF-Test Interface, um Klicks aufzunehmen.
• Der größte Entscheidungsgrund war, dass QF-Test nur bei Bedarf dem SUT den Fokus gab. Niemand mochte, dass Squish die geskripteten Events zu irgendeinem Fenster sendete, das gerade den Fokus vom OS erhalten hatte. Mit QF-Test konnten wir andere Dinge tun, während das Skript im Hintergrund lief.

Wir automatisieren unsere Tests schneller als neue Funktionalitäten hinzugefügt werden, so wachsen unsere Tests mit jedem Release. Das ist viel besser, als dass unser Dokument zum manuellen Testen mit jedem Release länger wurde :)

Ich nutzte Jython Skripte, um Aktionen wie Suchen, Öffnen von Datensätzen und dem Start der Anwendung zu messen. Die Messergebnisse (mit build-Nummer & Host) werden in einer Datenbank gespeichert, so dass wir die Geschwindigkeit viel granularer messen können. Wir nutzen auch Schleifenaktionen, um Ressourcenlecks zu finden.

Mir gefällt Scripting in der JVM sehr. Den Inhalt eines Textfeldes einer Variable für spätere Checks zuzuweisen ist super. Genauso gut ist zu wissen, wie viele Posten in einer Tabelle waren, bevor und nachdem ein Filter angewendet wird. Dadurch, dass QF-Test sich in unserer Entwicklungsumgebung immer mehr etabliert, verbringe ich mehr Zeit damit, Tests in Jython zu schreiben. Das ist Thema, bei dem ich denke, dass QF-Test noch etwas mehr Feinschliff benötigen könnte. Ich bin begeistert davon, was ich jetzt tun kann – aber können eure Entwickler die Scripting Integration noch dazu bringen, andere coole Dinge zu tun? Ich mache Dinge wie: Öffnen einer Serie von Aufnahmen, um die durchschnittlichen Zeit der Vorgänge herauszufinden, jedes Feldes in einem Formular ändern und Exceptions im Protokoll überprüfen. Außerdem versuche ich die Filter an ihre Grenzen zu bringen, indem ich Permutationen von Suchbegriffen laufen lasse usw.

Ihr macht ein großartiges Tool. Danke,

Logan White Stack der R.J. Lee Group