Meinung - Unmöglicherkeiten - Mercury Quality Center

Software-Tests entwickeln ist hart. Mit Mercury Quality Center wird es ungleich härter.

Nicht nur, dass man die Tests entwickeln muss, nein, man muss gegen die augenscheinliche komplette Unfähigkeit des Entwicklerteams von Mercury ankämpfen. Beispiel:

Das nenne ich Unmöglicherkeit. Wie kann es sein, dass ein Test-Tool genau die Fälle nicht unterstützt, die interessant sind (wie eben jene mit Sonderzeichen)?

Wer meint, diese Zeichen wären in Parametern zu Templates selten, der irrt. Mein erster überhaupt jemals in Mercury erfasster Testcase (sic!) hatte schon im ersten Step (sic!) diese verbotenen Sonderzeichen, weil ich das Suchkriterium "<>0" für Access eingeben musste. Ich habe mir das nicht ausgesucht, das ist einfach nur SQL. Mercury kann also nicht behaupten, dass Seltenheit ein Grund sei die Zeichen nicht zu unterstützen.

Vielleicht gibt es in den Tiefen der Mercury-Dokumentation - etwas, das mir hier im Projekt nicht zur Verfügung steht - ein Hinweis wie man in so einem Fall verfahren muss. Eine brauchbare Software würde solch einen Hinweis in keiner Dokumentation verstecken müssen. Indes, eine Google-Suche nach "Parameter name or value cannot contain any of the following characters" ergibt keinen einzigen Hit.

Ich habe mich mit der Eingabe von &lt;&gt;0 abgeholfen, weiß aber nicht, ob Mercury diese Entitäten dann passend bei der Anzeige umschreibt. Denn, wieder so eine Unmöglicherkeit, darf ich als Testentwickler nicht sehen, wie der Testcase am Ende für den Tester aussieht.

Und was extrem störend auffällt ist, dass die Nachricht irgendwie total schräg daherkommt, ja fast selber schon als BUG bezeichnet werden muss. Sie hat keine Fehler-ID, so dass man im Internet nach einem Workaround suchen könnte, es wird keine Hilfe eingeblendet die auf Ersatzmöglichkeiten hinweist, und obwohl ihre Aussage irgendwie klar ist wundert man sich, warum die Entwickler die Nachricht in dieser Form hingefrickelt haben. Denn genau diesen Eindruck erweckt sie: Unprofessioneller Bastelcode der schlimmen Sorte. Ich für meinen Teil erwarte selbst von untalentierten Hobbyprogrammierern dass sie besseren Code anliefern.

In meinem Fall würde es nicht helfen, kein Template zu verwenden. Es handelt sich um eine Struktur, die ich geradezu zillionenfach brauchen werde. Denn am Anfang eines Test steht immer die Suche nach den zu testenden Daten. Und da die Tests aussagekräftig sein sollen ist getreu der Mengenlehre ein Ausschlusskriterium notwendig. Und dafür braucht SQL nun einmal genau die Sonderzeichen die Mercury nicht zulässt.

Das zeigt mal wieder:

Teure Software muss weder gut noch brauchbar sein. Gar nicht selten ist sie Schrott der schlimmsten Sorte. Zu diesem rechne ich ab sofort auch Mercury Quality Center.

Meine Empfehlung:

Bitte, denkt an eure Angestellten, verschont sie und lasst die Finger weg von Mercury Quality Center!

Und wer diesen Rat nicht beherzigt der weiß wenigstens, was er ist.

-Tino
PS: Ich habe keine Ahnung welche Version von MQC hier eingesetzt wird. Will ich gar nicht wissen und brauche ich gar nicht zu wissen. Denn alleine dass sich Mercury erdreistet hat so eine Einschränkung auf die Menschheit loszulassen reicht zur permanenten Disqualifikation. (Ich bin bereit meine Meinung über Mercury zu revidieren, wenn sie diesen Fehler ausmerzen. Das bedeutet insbesondere dass dieser Bug beseitigt worden sein muss und die gesamte Kette der Entscheidungsträger über dem untersten Verantwortlichen bis ganz ganz nach oben auf nimmerwiedersehen unter Entzug aller Privilegien und ohne Abfindung wegen offensichtlicher Unfähigkeit gefeuert werden. Von dem untersten Verantwortlichen hingegen - ich bin eben sehr verständnisvoll - reicht mir eine öffentliche, weltweite permanent im Web veröffentlichte Entschuldigung, in ihr sein Eingeständnis seiner Unfähigkeit und sein Gelöbnis zur Besserung sowie sein Versprechen solchen Mist nie wieder zu bauen; Natürlich nur im Falle dass es der erste derartige Mist war den er gebaut hat.)