Als Anwendungstester musst du doch gar nicht herausfinden warum etwas so ist sondern sollst nur berichten dass es so ist. Mit dem Warum muss sich dann der Programmierer beschäftigen der den Fehler beheben soll.
Grundsätzlich gäbe ich dir Recht. Theoretisch machen wir vorzugsweise "blackbox-testing".Praktisch sind es jedoch eher mehr "greybox-tests", s.h. wir schauen da auch gelegentlich in den code rein etc.
Grund: Es sind neben der im Ursprungsposting als fehlerhaft beschriebenen Applikation noch zig andere Sachen im Einsatz (von anderen Firmen entwickelt) und da kann sich schon mal was kneifen: Der eine verlangt ein Java 1.4.2-11 im Internet explorer Plugin, der ander eine Java standalone Runtime 1.5.x, der eine möchte irgendwelche Java-abhängigen Environment-Variablen auswerten, die ihm der andere evtl. verbogen hat.
Die Entwicklerfirma hat ihre "klinisch reine" Entwicklungsumgebung bei sich, und bei uns im Betrieb klappts dann meistens "etwas anders". Die Entwicklerfirma liefert nur die eigentlichen jar-Bibliotheken für eine lokale Installation aus, so ist der Auftrag. Die eigentliche Integration in der vorhandenen Umgebung findet so gesehen nicht statt, bzw. man erwartet wohl irgendwie, das sich alles von alleine zueinander fügt.
Darüber hinaus: Das Softwaredeployment erfolgt bei uns via Microsoft-Distributionsmechanismen. Die verteilscripte sind manchmal etwas rabiat, und zerschießen uns dann eine Umgebung, so daß eine andere Umgebung nicht läuft.
Wir müssen daher in der QS nicht nur funktional testen, siondern gelegentlich auch noch Applikations-übergreifend identifizieren (und vorselektieren) wenns irgendwo kneift und zwickt.
Die "störrische" Applikation ist ca. 8 Jahre alt, wurde seinerzeit auf AWT-Klassen aufgebaut. Bestimmte automatisierte Tests ließen sich mit AWT nicht abbilden. Also wurden sukzessive die AWT Klassen durch Swing-Klassen ersetzt bzw. ergänzt. Möglicherweise ist das ein Henkel, wo ich anpacken kann.
Ein anderer Verdacht besteht darin, daß Klassen erst zur Laufzeit kompiliert werden etc. In diesem Umfeld ließen sich auch einige Fehler provozieren, da sind wir auch auf der Spur. Irgendwelche Threads führen möglicherweise zu einem deadlock, weil sie deswegen auf andere Threads warten.
Für mich sieht es so aus als wenn überhaupt kein ordentliches Layout benutzt wurde und da ist es nicht weiter verwunderlich wenn da hin und wieder mal nichts ordentliches bei rauskommt.
Naja, Ergonomie stand da am Anfang dieser Entwicklung nicht vollständig im Vordergrund. Bestimmte Layout- und designeinschränkungen sind auch möglicherwseise auf die gemischte AWT / Swing Nutzung zurückzuführen. Eigentlich war es eine eher Batch-orientierte Anwendung, welche nach und nach GUI-Funktionalität verpasst bekam. Nun ist die Anwendung "im hohen Rentenalter", da wird nix mehr komplett auf den Kopf gestellt werden, sondern eher durch ein Standard-Produkt ersetzt werden
