Requirements Engineering & Software Test
Eine leistungsstarke Kombination Nach mehr als 40 Jahren Erfahrung im Software-Engineering werden immer noch zu viele Projekte überzogen oder...
Korrekt nach der Lehre haben wir in unzähligen Workshops unsere fachlichen Anforderungen an ein Testautomatisierungswerkzeug erhoben. Alle Anforderungen sind ordentlich und strukturiert in Excel gepackt (weil das ja jeder irgendwie bedienen kann – vom Tester bis zum Geschäftsführer). Dank Plattformen wie Testtool Review lassen sich die in Frage kommenden Tools dann komfortabel finden. Tja, und was machen wir jetzt mit den 10 verbleibenden Werkzeugen?
Wie wäre es mit einem Zählreim?
“10 kleine Testing Tools können sich jetzt freu’n,
eins kann man nicht ausprobieren, da warens nur noch neun”
Wir arbeiten mit Standard-Technologie, programmieren in einer Standard-Programmiersprache und verwenden eine Standard-GUI ohne viel Schnick-Schnack. (Auch damit kann man spannende Projekte machen, ehrlich!) Da ist nicht nachvollziehbar, warum wir ein Werkzeug dann nicht selbst evaluieren können, sondern dieses vom Hersteller “einrichten” und “anpassen” lassen müssen und dafür vielleicht noch zahlen sollen.
“9 keine Testing Tools laufen über Nacht.
Eins ist zu oft abgestürzt, da waren’s nur noch acht.”
Es wäre schon fast bei der Installation aus dem Finale geflogen, da es sich partout nicht installieren lies (auch hier wieder ein langweiliger, frisch aufgesetzer Standard-PC). Nun, der Support war nett und so klappte es dann doch. Aber es lief nicht stabil, auf keinem der 3 verwendeten Arbeitsplätze. Darüber tröstet auch der freundliche Support nicht hinweg.
“8 kleine Testing Tools, wir woll’n uns nicht verbiegen,
eins passt nicht in den Prozess, da waren’s nur noch sieben.”
Wir passen unsere Prozesse gerne an – wenn es einen Grund dafür gibt. Ein Werkzeug kann auch ein Grund dafür sein. Denn jeder Hersteller hat sich wohl auch etwas dabei gedacht, wie der Workflow und die Funktionen implementiert sind. Und da kann man schon viel Erfahrung des Herstellers voraussetzen. Es muss aber argumentierbar sein. Ist es das nicht, dann passt es nicht.
“7 kleine Testing Tools, was prüfen wir zunächst?
Support, Vertrieb und Angebot, jetzt sind sie noch zu sechst.”
Bei der Anschaffung eines Werkzeuges geht man immer auch eine Partnerschaft ein. So ein Engagement ist meist langfristig und da muss die Beziehung auch passen. Eine Vertriebs-Weihnachtskarte (so ganz analog, vielleicht sogar handgeschrieben) ist eine schöne Aufmerksamkeit. Wenn aber nach dem Download der Evaluations-Version täglich (!) der Vertrieb anruft (“Haben Sie noch Fragen? Können wir helfen?”) und dazu noch Mails schreibt, wird es penetrant und selbst wenn man eine Frage hat, will man sie gar nicht mehr stellen. Da hilft auch die Freude auf die Weihnachtskarte nicht. Ebenso wünscht man sich beim Support und bei der Auswahl von Schulungen, etc. eine faire “Partnerschaft”. Das liefert leider nicht jeder…
“Mit 6 kleinen Testing Tools spielen wir jetzt frei.
Viere hab’n wir nicht verstanden, da warens nur noch zwei.”
Testautomatisierungswerkzeuge können komplex und nur mit tief gehender Schulung meisterbar sein. Müssen sie aber nicht. Wenn gestandene Software-Entwickler und -Tester über die Dokumentation und ihre Erfahrung nicht in der Lage sind, ein Werkzeug zu bedienen, ist es fraglich, ob es sich im täglichen Einsatz bewähren kann. Und: Es geht auch anders, wie die beiden verbliebenen Werkzeuge beweisen. Beide sind so intuitiv bedienbar, dass es eine richtige Freude ist, mit ihnen zu arbeiten. Hinter vorgehaltener Hand hört man sogar, es mache den Teammitgliedern richtig Spaß, damit Tests zu implementieren.
“2 kleine Testing-Tools bleiben nun zur Wahl,
‘Eines wirds, das andre nicht’ ist klar auf jeden Fall.”
Kopf an Kopf liegen die beiden Finalisten. Jetzt müssen beide zeigen was sie können. Die finale Entscheidung wird Anfang 2014 getroffen. Bis dahin freue ich mich über die Weihnachtskarten.
Eine leistungsstarke Kombination Nach mehr als 40 Jahren Erfahrung im Software-Engineering werden immer noch zu viele Projekte überzogen oder...
Die Planung eines anforderungsbasierten Systemtests setzt voraus, dass der Testaufwand anhand der Anforderungen kalkulierbar ist. Wenn Test-Points...
Letzte Woche war ich zu einem Podcast-Interview zum Thema Agilität und Zukunftstechnologien eingeladen. Das Gespräch wickelte sich rasch um die Idee,...