Janusz Gorycki setzt sich bei AgileSoftwareDevelopment.com (Englisch) mit den Tücken und Fallstricken des Unit Tests auseinander:

(1)  Unit Test dienen nicht zur Systemdokumentation!
(2) Ein erfolgreicher Unittest sagt nichts darüber, ob das Gesamtsystem auch „gesund“ ist.
(3) Testmodellen zu vertrauen ist falsch.
(4) Zu langsame Unit-Tests sind wertlos.

Ein Leser-Feedback bestätigt mich in meiner Einschätzung:

Wir setzen seit einiger Zeit zur Verbesserung der Klarheit und Entwicklung der Fachanforderungen ein Tool ein, das sich sehr bewährt. Das ist m.E.

erheblich wichtiger, als ein Testtool, von dem ich – auch nach langen Jahren – je nach SW (die ja heute hochgradig konfigurierbar ist und de facto strukturbildende Wirkungen für Unternehmen und alle damit verbundenen Org-Einheiten hat) nur wenig halte. Es ist nichts schlimmer, als wenn die Fachbereiche nach langwierigen Prozessen der Definition der Fachanforderungen irgendwann selbst nicht mehr wissen, wer was wann und warum angefordert hat und ob und wie diese Anforderung von wem in Absprache mit wem wann geändert worden ist – was ist dann getestet worden – und wie bekomme ich meine Migrationsaufträge? Dann kann ich mir das Testen im Grunde komplett sparen.

In meinem aktuellen Beitrag für das Projektmagazin habe ich u.a. auf die Rolle des Anforderers bei Test und Abnahme hingewiesen. Hierzu passend eine Meldung des CIO-Magazins: Die Deutsche Bank lagert ihr Software-Testing aus und rechtfertigt das mit Prozessorientierung und Industralisierung der IT.

Ein externes Testing ist legitim, darf aber den Anforderer nicht aus seiner Verantwortung für Qualitätssicherung und Abnahme entlassen. Ein IT-Dienstleister mag durchaus die erforderlichen IT-Prozesse für Software-Entwicklung und Test besser beherrschen, aber kann er auch das erforderliche Business-Know How mitbringen? Weiß er, was Banker wünschen?

In der aktuellen Ausgabe des Projektmagazins (Abodienst) findet sich ein Beitrag zum Thema Testmanagement in IT-Projekten. Als Autor des Artikels kann ich die Lektüre natürlich nur empfehlen…

Im ersten Teil  des Beitrags werden die Grundzüge des Testmanagements und der Testorganisation anhand der immer wiederkehrenden gemeinsamen Fragen skizziert, die vor der Durchführung eines Tests zu beantworten sind:

1. Wann wird getestet?
2. Was wird getestet?
3. Wie wird getestet?
4. Wer testet?
5. Womit und wo wird getestet? 

Teil 2 des Beitrags mit einem ausführlichen Excel-Template ist derzeit in der Schlußredaktion.

Danny Quick hat einen lesenswerten Beitrag des Linux-Magazins ausgegraben, in dem versucht wird Methoden und Vorgehen agiler Softwareentwicklung auf Betriebsthemen zu übertragen. Wie bei allen „agilen“ Themen braucht es dafür gleich einen neuen Namen: Agile Software Administration.

Für ITIL/Governance geprägte Welten mag sich das Gedankentum zunächst anarchistisch/revolutionär anhören, letztlich setzt es aber, wie alle agilen Ansätze, auf einer gestärkten Kommunikation und Eigenverantwortung auf – zwei Dinge, die noch keiner Betriebsorganisation geschadet haben.

Sven Rimbach erzählt frustriert die Anekdote, wie man zu einem „effektivem“ Testmanagement gelangt:

Der einfachste Weg ist es, die Fehlerdatenbank zu löschen…

Matt Grommes läßt seine Leser in einer bemerkenswerten Artikelserie auf AgileSoftwareDevelopment.com an seinem ersten agilen Projekt mit SCRUM teilnehmen und berichtet über seine Erfahrungen (Englisch):

My First Agile Project Series
Part 1: Doing 80%
Part 2: Inception & Planning
Part 3: Viral Videos and Bad Jokes in Scrum Demos
Part 4: How to lose credibility and jeopardize your project with lack of management buy-in
Part 5: Our Top 5 Agile Mistakes
Part 6: The First End of Our Project
Part 7: Adventures in Agile Testing
Part 8: 9 Things We Disliked (and Liked) about ScrumWorks
Part 9: Choosing A New Tool – VersionOne
Part 10: 5 Important Issues For Teams
Part 11: A Tale of Two Dark Clouds
Part 12: The Good, The Bad, and The Ugly – Our Retrospectives
Part 13: Reflecting on The Decline of Agile
Part 14: Did We Need A Coach? Does Anyone?
Series Review: So It’s Come To This – The Year In Review
Part 15: The Last Mile
Part 16: Go-Live – The Final Frontier

In den CIO-Nachrichten findet sich ein Beitrag: Schlechtes Anforderungsmanagement. IT versteht das Business nicht. Die Aussage wird belegt mit einer Umfrage des IT-Beraters Arcway.

Diese These deckt sich durchaus mit meiner Erfahrung, aber ich würde darüber hinaus noch viel weiter gehen: Das Unverständnis besteht häufig nicht nur zwischen Auftraggeber und Auftragnehmer, sondern zieht sich durch alle Schichten der Stakeholder eines Projektes. Als Projektmanager finde ich mich regelmäßig in der Rolle des Übersetzers zwischen den verschiedenen Beteiligten. Die Verständigungsschwierigkeiten fangen schon auf Kundenseite über die verschiedenen Hierarchiestufen (vom Top-Management bis zum Enduser) an. Aber selbst auf der reinen IT-Seite besteht dieses Problem, denn ein IT-Architekt ist noch näher am Business und spricht eine andere Sprache als ein  Nerd, der die letzten Bits einer Schnittstelle programmiert. Darüber hinaus gibt es noch so Themen wie IT-Betrieb, etc., die wiederum mit einem anderen Verständnis (und anderen Anforderungen) ausgestattet sind. Da wollen wir noch gar nicht vom Brückenschlag von der Fachabteilung zur IT hin reden…

Die Überwindung solcher Verständnisschwierigkeiten ist nach meiner Überzeugung einer der wichtigsten Erfolgsfaktoren für Projekte.

Wer schon immer „alles“ über agile Softwareentwicklung mit Scrum wissen wollte und das noch in weniger als zehn Minuten, sei auf folgendes englische Youtube-Video hingewiesen.

Wer es gerne etwas ausführlicher hätte, dem kann ich Roman Pichler, Scrum – Agiles Projektmanagement erfolgreich einsetzen. Heidelberg 2008 (Amazon Affiliate Link) nahelegen, das ich hier auch schon das eine oder andere mal zitiert habe.

Und für alle die, deren Interesse an Scrum nun geweckt worden ist, hier noch via agilesoftwaredevelopment.com eine Seite mit Excel-Templates und zugehörigen Video-Tutorials.

heise online und die Computerwoche zitieren eine Gartner-Studie zum Thema Open Source-Einsatz in Unternehmen. Fast überall ist zumindest in Randbereichen bereits heute Open Source-Software im Einsatz, vor allem bei der IT-Infrastruktur, aber zunehmend auch bei Business Anwendungen.