Dazu fand ich letzten Samstag auf dem Methodentag Projektmanagement 2011 am Zentrum für Weiterbildung und Wissenstransfer (ZWW) der Uni Augsburg Gelegenheit. Veranstalter waren das pm-forum Augsburg, eine lokale Community mit Fokus auf die Themen Projektmanagement und regionalen Wissenstransfer, in Kooperation mit der Gesellschaft für Arbeitsmethodik e.V. und der GPM, einem Fachverband für Projektmanagement, die Infostände zu ihren Aktivitäten im Bereich Projektmanagement und PM-Zertifizierungen anboten.

Eröffnet wurde die Veranstaltung mit einer Keynote von Erik Händeler zum Thema „Warum der Wohlstand in Zukunft vom Sozialverhalten abhängt“. Darin erläuterte er die Auswirkungen langer Entwicklungsphasen in der Wirtschaft (Kondratieff-Zyklen) und stellte die These auf, der nächste Kondratieff-Zyklus werde die Notwendigkeit zunehmender Kooperation von Menschen zum Gegenstand haben, da der fähige und wissende Mensch als solcher immer knapper werde. Dadurch werde die Bedeutung des Sozialverhaltens, d.h. die Fähigkeit mit anderen Menschen zusammenarbeiten zu können, an Bedeutung weiter zunehmen.

Ich belegte anschließend gemäß aktueller beruflicher Interessen Vorträge zu den Themen Kommunikation im Projekt, Multiprojektmanagement sowie Projektumfeld- und Stakeholderanalysen. Jeweils gehalten von kompetenten Referenten aus dem Umfeld des pm-forums Augsburg. Aber auch Themen wie das Erstellen von Projektstrukturplänen, webbasierte Projektmanagementtools, Präsentationstechniken, Projektkennzahlsysteme, systemische Organisationsaufstellungen sowie das Nutzbarmachen von Lernerfahrungen für Folgeprojekte waren im Angebot, so dass das mir das Auswählen schwer fiel. Zu Vorträgen, die man nicht besuchen konnte, kann man aber immerhin die Zusammenfassung im Tagungsband nachlesen, den jeder Teilnehmer erhielt.

Eine alles in allem runde und stimmige Veranstaltung, die ich gerne wieder besuche, sobald sie wieder stattfindet.

Wie kommen eigentlich die Bugs in die Software?

Statistisch gesehen machen selbst erfahrene Entwickler in etwa drei Fehler pro tausend Zeilen Code. Zieht man nun in Betracht, dass größere Anwendungen mehrere Hunderttausend, Betriebssysteme gar etliche Millionen Zeilen Code umfassen können, erscheint es naheliegend, dass sich darin (mindestens) Dutzende, wenn nicht Hunderte von gravierenden Fehlern befinden müssen.

Daher ist es so wichtig, Software ausführlich und methodisch zu testen. Das umfasst auch wieder- und weiterverwendeten Code sowie alle Bibliotheken, aus denen etwas übernommen wurde.

An einem Softwareentwicklungsprojekt sind zahlreiche Menschen beteiligt und dies i.d.R. in verschiedenen Rollen mit ganz unterschiedlicher Handlungsmotivation. Neben Entwicklern auch IT-Architekten, Projektleiter, Führungskräfte in Lenkungskreisen, Controller oder Fachanwender.

Das Testen von Software kann ihnen aus ganz unterschiedlichen Gründen quer kommen. Und so ist es mit Aufgabe des Testmanagers, diese Widerstände im Projekt aufzudecken und abzubauen, um so am Ende mit dazu beizutragen, dass durch das Projekt ein gutes und qualitätsgesichertes Ergebnis abgeliefert wird.

Entwickler sehen sich oftmals durch Tester bloßgestellt, wenn sie gefundene Fehler als eigene Fehlleistungen auffassen. Und das, obwohl Fehler oftmals auf unzureichend spezifizierte Anforderungen, Analysefehler, in der Softwarearchitektur übersehene Details oder Defekte in übernommenen Codeteilen zurückführbar sind. Außerdem macht das Streben nach innovativem und effektivem Arbeiten auch Freiräume zum Fehlermachen und Lernen erforderlich. Man muss nur sicherstellen, dass „zum Schluss auch aufgeräumt wird“ bevor das Produkt dem Kunden übergeben wird. Eine Aufgabe für Tester und Qualitätssicherer als festen Bestandteil im Team.

Anwender betrachten das Testen von Zwischenständen der Software oftmals als zusätzliche Belastung. Insbesondere, wenn sie sich diese Aufgabe zusätzlich und ohne geregeltes Zeitbudget neben ihren eigentlichen Aufgaben „eingefangen“ haben. Andererseits kommt man in Softwareentwicklungsprojekten nicht umhin, die fachlichen Wissensträger in die Testphase zu integrieren. Agile Vorgehensmodelle wie Scrum setzen eine (arbeits)intensive Beteiligung des Kunden am Projekt geradezu voraus. Das macht es erforderlich, die Testaufwände für die Fachtester zu kalkulieren und mit den Fachabteilungen zum Zwecke der vorausschauenden Kapazitätsplanung abzustimmen. Andererseits kann diese Aufgabe für die Fachtester auch eine Herausforderung sein. Sie werden dadurch zu ausgewählten Key-Usern, erhalten die Möglichkeit Aspekte ihres zukünftigen Arbeitsumfeldes mitzugestalten und können später u.U. ihren Wissensvorsprung als Referent im Rahmen innerbetrieblicher Schulungsprogramme weitergeben und sich so für höherwertige Aufgaben positionieren.

Projektleiter sind häufig mit den Unwägbarkeiten des Projektgeschäfts konfrontiert. Da werden zugesagte Mittel gekürzt oder gestrichen, Anforderungen geändert oder ohnehin zu knapp gesetzte Meilensteintermine noch weiter verengt. Gerne wird da auf „projektinterne Sparschweinchen“ zurückgegriffen, um mit der veränderten Lage klarzukommen. Darunter fallen alle im Prinzip disponiblen Positionen in der Projektplanung. Und dazu zählen meist auch Aufwände für Qualitätssicherungsmaßnahmen. Zumal der dafür zuständige Testmanager im Projekt ohnehin oft die A-Karte ziehen muss, wenn im Projekt-Jourfix alle Teilprojekte „grün“ melden, während die Tester als Ergebnis ihres Schaffens mit langen Bugreports aufzuwarten haben, die zu Meilensteinverzögerungen und „roten“ Teilprojektstatusmeldungen führen und so wirken, als hätten andere Projektbeteiligte Mist gebaut.

Dabei können Defizite in der Projektplanung bzgl. des Testens bereits sehr früh erkannt werden, wenn sich darin z.B. sinnfreie Aussagen wie „Wir testen bis zum Quartalsende“ oder „Wir testen bis das dafür vorgesehene Budget aufgebraucht ist“ finden. Eine OP wird auch nicht beendet, wenn ein bestimmter Zeitpunkt erreicht wurde, sondern wenn alles Notwendige getan, das Instrumentarium noch vollständig vorhanden und der Patient wieder zugenäht ist.

Testen ist eben keine disponierbare Größe im Kampf gegen projektierte Budget- und Terminprobleme. Zahlreiche langwierige juristische Konflikte im Nachgang gescheiterter oder zumindest nicht plangemäß gelaufener Projekte ihren Ursprung meist im Verstoß gegen diese Regel haben. Die Historie staatlicher IT-Großprojekte wie dem Autobahn-Mautsystem Toll-Collect, der elektronischen Krankenkassenkarte oder dem digitalen Polizeifunk zeigt das ganz deutlich.

Führungskräfte in Lenkungskreisen sehen Testen oftmals nicht als integralen Bestandteil des Softwareentwicklungsprozesses sondern als eine Art überflüssigen Extraaufwand, den man am besten vermeidet, indem man einfach keine Fehler macht. Kein Witz – diese Art der Inkompetenz ist einer der Gründe dafür, dass man in der produzierenden Industrie im Laufe der Zeit dazu übergegangen ist, Aufgaben, die fundierte Kenntnisse in der Methodik des Qualitätsmanagements erfordern, mit Personen zu besetzen die etwas Einschlägiges gelernt oder studiert haben. Dieser Teil der Industrialisierung der Softwareentwicklung wurde allerdings im Bereich der IT noch nicht vollständig nachvollzogen, da er mit Kosten verbunden ist, die zunächst nur indirekt und eher schwer messbar darzustellen sind und keinen ihnen direkt zurechenbaren return-on-invest bringen.

Auch wenn der Druck hinsichtlich Qualitätsfragen über Normungs-, Zertifizierungs- und Compliance-Anforderungen gerade aus hochregulierten Branchen wie der Finanzwirtschaft, dem Gesundheitswesen, der Luft- und Raumfahrt oder der Energieversorgung immer mehr zunimmt. Also aus den Bereichen, die für einen Großteil der Aufträge an IT-Systemhäuser verantwortlich sind.

Fehlertoleranz und organisationale Lernprozesse sind für alle Beteiligte eines Softwareentwicklungsprojekts wichtig. Ermöglichen sie es doch, die Kommunikation an der oft heikelsten Stelle im Projekt zu verbessern: Am Austausch zwischen den fachlichen technischen Experten sowie mit den Stakeholdern des Projekts.

Auf Dauer wird dies einen Beitrag zu besserer und sicherer Software leisten, so wie auch andere Produkte des täglichen Bedarfs auf diese Weise verbessert wurden.

Eine Rechtspraxis, die ich mir zurückwünsche, wenn ich Artikel wie „Die Technikmafia“ von Marcus Rohwetter auf zeit.de lese. In ihm erklärt er eine zunehmende Praxis von Unternehmen, durch bewusste Verschlechterung von Produkten, durch den Einbau sog. „Antifeatures“ (gebrauchswertmindernde Produkteigenschaften) sowie durch das Vorsehen vorzeitiger Alterung bereits beim Produktentwurf Zusatzprofite durch raschere Abnutzung und Ersatzkauf zu ergaunern. Von „erwirtschaften“ will ich aus Respekt von ehrbaren Kaufleuten und Unternehmern dabei bewusst nicht sprechen.

Ein klarer Fall von „defective by design“ (Kaputt von Anfang an – nicht umsonst auch der Name einer Kampagne gegen DRM-Systeme), also des bewussten Produzierens von Ausschussware für die Müllkippe, die aber vor der Entsorgung bitte noch verkauft und bezahlt werden soll. Und ein klares Signal für mich, dass die Produkthaftungsgesetze und Qualitätsauflagen durchaus noch nachgeschärft werden können, auch wenn Wirtschaftslobbyisten dann wieder über Bürokratie und Kosten klagen dürften. Selbst verschuldet – Dummheit und dumme Gier sollten hart bestraft werden.

Eine Vorgehensweise, für die der Begriff der geplanten Obsoleszenz (künstliche Veralterung oder Verschlechterung) geprägt wurde.

Schon aus Gründen der Ressourceneffizienz sollten solche auf Verschwendung und Betrug basierende Geschäftskonzepte sanktioniert werden. Zunächst über die Kosten des Ressourcenverbrauchs. Und dann über den Boykott der Kunden, sobald bekannt wird, welche Unternehmen (gerade im Bereich der Hard- und Softwareentwicklung, des Elektroniksektors oder in der Automobilindustrie) so arbeiten. Wofür entsprechende Kampagnenwebsites im Internet sorgen könnten. Und nicht zuletzt auch über gesetzliche Auflagen und persönliche Haftungen der zuständigen Entscheidungsträger auch ins Privatvermögen.

Was aber haben Antifeatures, Obsoleszenz und „defective by design“ mit Softwarequalität zu tun?

Ganz einfach: Die meisten Antifeatures sind überhaupt nur mit Hilfe von Software möglich. Da wird ein Chip schneller, wenn man gegen Aufpreis einen Softwarepatch einspielt (ist an sich gegen jede informationstechnische Logik). Ein gekauftes Produkt kann erst gegen erneut zu zahlende Preisaufschläge überhaupt in Betrieb genommen werden. Für Downloadmusik ist ein Aufpreis zu zahlen, damit sie in gebräuchlichen, DRM-freien Datenformaten ausgeliefert wird. Digitalkameras und Fotohandys verschlechtern das aufgenommene Bild künstlich oder entladen eingesetzte Akkus schneller, wenn diese nicht vom Hersteller stammen. Und Drucker erkennen Tonerpatronen anderer Marken und drucken damit nur in schlechterer Auflösung.

Was im Bürgerlichen Gesetzbuch (BGB) schlicht als Mangel bzgl. Leistungsstörung bezeichnet wird und nach Mängelrüge und Nachbesserungsversuch letztlich zur Rückabwicklung des Kaufvertrags berechtigt, hat sich zwischenzeitlich zum Geschäftsmodell entwickelt. Denn Käufer bekommen es oftmals gar nicht sofort mit, dass man sie abgezockt hat. Denn zunächst funktioniert das Produkt ja (halbwegs) und die Mängelbeseitigung wird als „Upgrade“ oder „Freischaltung besserer Leistung“ verkauft.

Rohwetter bringt es auf den Punkt:
„Dem Irrsinn liegt ein völlig neues Wachstumsverständnis zugrunde. Bekamen wir Kunden für mehr Geld früher bessere Leistungen, bezahlen wir heute zunehmend für den Abbau von zuvor künstlich errichteten Hindernissen. Womöglich wenden die Konzerne einen großen Teil der Innovationskraft ihrer Forschungsabteilungen längst nicht mehr für die Optimierung von Produkten auf, sondern für die Verfeinerung von Verschlechterungssystemen.“

Es ist daher an der Zeit, der Wirtschaft schmerzhaft in die Weichteile zu treten. Sehr wirksam geht das in der ubiquitären Öffentlichkeit des Social Web. Aber auch über Kampagnenwebsites wie www.defectivebydesign.org (Software), www.abgespeist.de (Lebensmittel) oder den Verbraucherschutz. Imagekampagnen kosten richtig viel Geld und bringen oftmals wenig bis nichts. Für Unternehmen ist es daher sehr schmerzhaft, wenn man ihren Namen mit Schrottprodukten, minderwertiger Ware und betrügerischen Geschäftspraktiken in Verbindung bringt. Gehen dann erstmal Umsätze zurück und Aktienkurse in den Keller, während sich Verbands- und Sammelklagen in mehreren Ländern häufen und entsprechende Rückstellungen die Bilanzen belasten, ist auch mit angenehmen Boni für die Vorstandschaft bald Schluss.

Es muss klar werden, dass die Bevölkerung (und dann entsprechend angeschoben die Politik) den Unternehmen auf Betrug und Minderleistung basierende Geschäftsmodelle auf Dauer nicht durchgehen lassen. Unternehmen die so arbeiten sind überflüssig, werden zu Ballastexistenzen der Volkswirtschaft und sollten daher rasch in die Insolvenz getrieben und abgewickelt werden.

Wer es jedoch mit Software zu tun hat, könnte zu dem Eindruck gelangen dass der Qualitätsaspekt allzu häufig auf dem Altar der Kostenminimierung und raschen Produktplatzierung am Markt geopfert wird. Wir sind es mittlerweile gewohnt, alle paar Tag Updates und Bugfixes für das Betriebssystem, die diversen Medienplayer und Dokumentenviewer, Runtime-Komponenten, Browser und sonstigen Anwendungen herunterzuladen und einzuspielen. Bugtracker-Listen und CERT-Warnmeldungen werfen täglich mal mehr, mal weniger Meldungen zu publizierten Schwachstellen in verbreiteten Standardanwendungen aus und geben erste Hinweise, was zu tun ist, um das Loch zu stopfen. Und da geht es nur um solche Fehler in Programmen, die zum einen bereits entdeckt wurden und die zum anderen aus Sicht von Fachleuten ein Sicherheitsrisiko darstellen.

Programme auf Fehler und Schwachstellen abzuklopfen ist für manchen Informatiker zu einem lukrativen Nebenjob, wenn nicht gar zum Hauptberuf geworden. Jeder Anbieter von Sicherheitssoftware beschäftigt zahlreiche Leute, die nach Bugs suchen, Code reengineeren, Exploits schreiben und Systeme aller Art zu hacken versuchen. Und lässt sich von Freiberuflern zuarbeiten. Besonders wertvoll sind „frische“, noch unbekannte (Zero-Day-Level) Fehler, die in Form von Exploits an Firmen wie Zero Day Initiative (ZDI) oder iDefense Security Intelligence Services verkauft oder am Datenschwarzmarkt zur bestimmt nicht legalen Weiterverwendung veräußert werden können.

Wie aber kommt es zu diesem „Markt für das Recycling der Fehler anderer Leute“? Zumal Informatiker bereits seit mehr als zwei Jahrzehnten in zunehmendem Umfang mit Methoden der Softwarearchitektur, der IT-Architektur, mit Vorgehensmodellen für komplexe Entwicklungsprojekte, kurz des systematischen ingenieurhaften Entwickelns von Software vertraut gemacht werden.

In anderen Ingenieursdisziplinen werden ja auch Einkaufszentren, Flugzeugträger, Passagierjets oder Industrieanlagen gebaut, ohne dass zwei Tage nach der Inbetriebnahme die ersten Teile wieder abgeschraubt und ausgetauscht werden müssen, weil sonst der Kessel explodieren oder das Schiff untergehen könnte.

So kam die Hamburger Management- und IT-Beratungsfirma Steria Mummert Consulting in einer Untersuchung kürzlich zu der fast schon trivial anmutenden Erkenntnis, dass fast jeder zweite Softwarefehler, der nach Produktivschaltung einer Änderung entdeckt wird, auf Mängeln im Test-Management beruht. Und diese Mängel auf Zeitdruck und „Wir Sparen, koste es was es wolle!“ zurückgeführt werden können. „Husch, husch – time to market – Profit, Profit“ ist da allzu oft die Devise, schnell und schlampig ist oft erwünschter aus ausgereift und funktionierend.

„Die Prognose ist wenig aufbauend. Denn aufgrund regulatorischer Vorgaben werden die IT-Aufwendungen und damit auch der Termindruck in den kommenden Jahren ansteigen“, so Testing-Experte Lars Hinrichsen von Steria Mummert Consulting in einem Interview mit der Computerwoche. Unternehmen versuchen sich auf Kundendruck hin an immer kürzeren Releasezyklen ihrer Produkte. Gleichzeitig stellen enger getaktete Umsetzungsfristen bei Gesetzesanpassungen die IT-Abteilungen auf die Probe. Bei eingespielten Testverfahren wird gespart und stattdessen oft irgendwas improvisiert und das dem eiligen Kunden dann als „agiles Vorgehen“ verkauft.

Das diese Herangehensweise auch richtig voll danebengehen kann, bekommen jedoch immer mehr Firmen zu spüren. So z.B. Neofonie, die 2010 das WeTab als eines der ersten Konkurrenzprodukte zu Apples iPad auf den Markt warfen. Die Software war unausgereift, die Hardware wurde der Eile wegen zusammengestrichen, zahlreiche angekündigte Eigenschaften sollten erst nach Kauf des Tablet-PCs schrittweise nachgeliefert werden. Der Kunde sollte also ein „Bananenprodukt“ erwerben – „Kaufen Sie jetzt ein neues Auto, nächste Woche gibt es das Lenkrad, übernächste Woche dann die hinteren Räder und im nächsten Monat dann den Tank …“. Entsprechend kritisch fielen die Kritiken der ersten Nutzer sowie der Fachpresse aus. Das WeTab verschwand in der Versenkung und wurde nach wenigen Monaten durch ausgereiftere Tablet-PCs anderer Anbieter vom Markt verdrängt. Die darin investierten Gelder dürften daher i.W. verloren sein.

Meiner Ansicht nach liegt das hauptsächlich daran, dass es im Softwarebereich so gut wie keine wirksame Produkthaftung gibt, wie bei Produkten in der realen Welt. Software wird immer noch eher als „geistiges Eigentum“ (ein Kampfbegriff der Verwerterlobby) betrachtet, dass allenfalls „lizenziert“ also wie ein feudales Privileg zuerkannt oder verliehen wird, anstatt als Produkt, das gekauft oder gemietet wird und das so zu funktionieren hat, wie es in der Werbung versprochen und im Vertrag vereinbart wurde.

Allenfalls in hochregulierten Bereiche wie der Finanzwirtschaft, dem Medizinsektor oder der Luftfahrt gelten strengere Anforderungen an die Qualität der Software in Produkten, die von den Herstellern dann auch einschlägig nachzuweisen sind. Weshalb dort auch mehr für Qualitätssicherung und Testmanagement ausgegeben wird und Produkte im Zweifel eher später als defekt auf den Markt kommen.

Was an sich dafür spräche, strengere Standards zur Produktqualität und Produkthaftung auch für „Allerweltsprodukte“ aus dem IT-Bereich festzuschreiben.

Referenten wie Thomas Roßner von imbus und Helmut Götz von Siemens stellten vor, was mit modellbasiertem Testen möglich ist und wie Unternehmen dabei vorgehen können. Testen kostet in erster Linie Zeit und Geld. Da beides in Projekten regelmäßig knapp ist, wird das Testen gerne zum Sparschwein für projektbezogene Unwägbarkeiten „umgenutzt“, was man an den mittlerweile im Wochentakt bekanntwerdenden Sicherheitslücken populärer Software-Produkte und Internetdiensten mitverfolgen kann.

Daher drehen sich zahlreiche methodische Innovationen im Testing-Bereich um das Thema Kostensparen bei gleichbleibender oder gar steigender Testabdeckung und Testqualität. Hierbei kann modellbasiertes Testen einen bedeutenden Fortschritt bewirken, da sich damit beträchtliche Einsparungen bei der Testspezifikation sowie z.T. auch bei der Testautomation erreichen lassen.

Modellbasiertes Testen bedeutet, dass der Kern der Arbeiten bzgl. Testplanung und Testspezifikation an einem grafischen Modell des zu testenden Systems stattfindet. Und das Testfälle, Testfallskripte für Testautomationstools sowie der größte Teil der Testdokumentation automatisch aus diesem zentralen Modell generiert wird. Dieses Modell bildet einen logischen Zwischenschritt zwischen Anforderungsmanagement und Testen der Software, da bereits aus Anforderungen Modellinhalte und Testfälle gebildet werden können. Es wird i.d.R. auf der Basis von UML-Diagrammen (Use-Case-, Activity- und Sequenz-Diagramme) sowie spezifischen Anpassungen der grafischen Elemente gebildet. Erfahrungen aus der bisherigen Praxis zeigen, dass so bereits in einer frühen Phase konzeptionelle Defizite des geplanten Softwaresystems aufgedeckt werden können, die mit „traditionellen“ Methoden erst sehr spät oder auch gar nicht bemerkt würden, wenn sie nicht zu fehlernhaften Tests führen.

So stellte Referent Götz mehrere Entwicklungsprojekte im industriellen Umfeld vor, in denen Siemens das selbst entwickelte Tool Tedeso für modellbasiere Tests eingesetzt und damit beträchtliche Einsparungen bei der Durchführung und Dokumentation von Tests erzielen konnte.

Auswirkungen von Anforderungsänderungen, geplanten Bugfixes und Implementierungsvarianten auf das Projekt lassen sich mit Hilfe des modellbasierten Testens leichter transparent machen, da entsprechende Tools auch „Was wäre wenn“-Szenarien durch Veränderungen am zu testenden Modell ermöglichen.

Grundsätzlich werden beim modellbasierten Testen deutlich mehr Testfälle generiert als bei herkömmlicher Testautomation. Allerdings lassen sich methodisch Filter setzen, um z.B. die Testabdeckung bestimmter Bereiche der zu testenden Software zu optimieren oder um die Ergebnisse bereits vorangegangener Tests mit zu berücksichtigen.

Den Abschluss der Veranstaltung bildete eine Podiumsdiskussion unter dem Motto „Where 2 go 2“, die Möglichkeiten zum raschen Anpacken des Themas im Unternehmen aufzeigen sollte.

Vortragsbegleitend konnte man sich an Testinstallationen der TestBench von imbus sowie der neu hinzugekommenen Komponente tedeso von Siemens ansehen, wie die Toolunterstützung von modellbasiertem Testen in der Praxis aussieht. So lassen sich z.B. Testfälle in der TestBench als „Prosatext“ oder als Objekte (Interaktionen und Datentypen) anlegen, parametrisieren oder auch gleich in Testskripte zur Ansteuerung eines Testautomationstools umwandeln. Das Arbeiten an einem Modell anstatt an einzelnen Interaktionen stellt daher für die TestBench-Nutzer i.W. nur einen neue Art des Zugangs zu ihren Tests da. Ähnlich dürfte es sich bei vergleichbaren Testmanagementumgebungen verhalten.

•    Mittleres und höheres Management
•    Projektleiter, Testmanager, Qualitätssicherungsbeauftragte und Tester
•    Fachanalysten, Softwareentwickler, Betriebsspezialisten und sonstige.

Die Umfrage läuft noch bis zum 31.05.2011. Es soll dadurch ermittelt werden, was sich in den letzten Jahren im Bereich Softwarequalität konkret verändert hat und wo Nutzen und Defizite in der Praxis liegen. Technisch und methodisch waren die letzten Jahre von zahlreichen Entwicklungen wie testgetriebene Entwicklung, ISTQB-Zertifizierungen, TTCN-3 und Testautomation generell, agiles Testen, modellbasiertes Testen, exploratives Testen und Testen mit Frameworks wie JUnit geprägt.

Dadurch sollen Grundlagen für ein Benchmarking gewonnen und Impulse für eine praxisorientierte Ausrichtung der Forschung sowie der Aus- und Weiterbildung im Bereich der Software-Technik gesetzt werden. Die Teilnehmer der Online-Befragung erhalten die Ergebnisse und damit die Möglichkeit, selbst einzuschätzen, wo das eigene Unternehmen in Bezug auf Belange der Softwarequalität und des Testens steht. Die Ergebnisse der Studie sollen im Herbst veröffentlicht werden.

Das 140seitige Heft ist für 9,90 € erhältlich. Es ist inhaltlich in vier Teilbereiche gegliedert: Design & Usability, Spezifikation & Test, Wartung & Wiederverwendung sowie Standards & Normen.

Darin finden sich Artikel zu grundlegenden Bereichen der Softwarequalität wie Testqualität, Teststufen, Softwarelebenszyklus, modellbasiertes Testen, Testdokumentation oder Tests funktionaler Sicherheit. Ebenso aber zu Themen wie Usability Engineering, Barrierefreiheit, Continuous Integration, Prozessqualitätssteuerung mit Automotive SPICE oder Normen wie ISO 26262 als Gütekriterien zur Bestimmung von Softwarequalität.

Dem Heft liegt eine DVD bei, auf der sich aktuelle Versionen gängiger kommerzieller Testing-Tools (Testversionen mit begrenzter Laufzeit) befinden. Hier wären mehr Programme aus dem Open-Source-Bereich wünschenswert gewesen, die es ja zweifelsohne gibt (z.B. als Erweiterungen der Eclipse-Entwicklungsumgebung). Sowie ein oder zwei Artikel speziell zum Thema Arbeiten mit quelloffenen Testing-Tools.

Meiner Erfahrung nach sind diese Sonderhefte meist rasch ausverkauft. Das letzte zum Thema Projektmanagement wurde der enormen Nachfrage wegen sogar ein zweites Mal aufgelegt. Wer eine Papierausgabe haben will, sollte sich also beeilen. Der eBook-Leser kann dagegen noch warten, bis das PDF für den Tablet-Reader erhältlich ist.

In den letzten Jahren haben sich unter dem Oberbegriff der agilen Softwareentwicklung zahlreiche neue Vorgehensmodelle, Methoden und Strategien etabliert, welche durch Veränderungen der Arbeitsorganisation die Softwareentwicklung schneller, besser, für die Beteiligten erfüllender und nicht zuletzt auch effizienter machen sollen – agil eben.

Das hat natürlich auch Auswirkungen auf die Arbeit von (entwicklernahen) Softwaretestern und QA-Spezialisten. Und darum ging es auch bei dem vorgestellten Projekt.

Bereits die klassischen Vorgehensmodelle der Softwareentwicklung wie z.B. das V-Modell XT sehen iterative Vorgehensweisen sowie in den Entwicklungsprozess integrierte Phasen der Qualitätssicherung vor. Diese im „agilen Manifest“ 2001 erstmals ausformulierten Denkansätze werden in den meisten agilen Vorgehensmodellen weiter ausgebaut. So ist z.B. das Kernelement der Entwicklungsplanung nach Scrum der sogenannte Sprint: ein überschaubarer Zeitabschnitt (einige Tage bis max. Wochen) innerhalb dessen inkrementell an vorab festgelegten Aufgaben gearbeitet wird; der mit einem auslieferungsfähigen Zwischenergebnis endet und innerhalb dessen zu implementierende Anforderungen nicht geändert oder umpriorisiert werden.

In Scrum gibt es drei grundlegende Rollen: den Scrum Master (Projektleiter und Methodenspezialist), den Product Owner (Kunde, Produktmanager bzw. Facharchitekt) sowie das Scrum Team (Entwickler). Eine gesonderte Teamleitung ist oftmals gar nicht mehr vorgesehen, da das Team viele Aufgaben der operativen Planung und Steuerung selbst mit Hilfe bestimmter Instrumente wie Daily Scrums (tägliche Kurzbesprechungen), Planning Game (ein Verfahren zur Aufwandsabschätzung in Gruppen) oder Vorschlägen für zu implementierende Anforderungen für die nächsten Sprints übernimmt. Oftmals übernehmen aber auch Projektleiter oder der Scrum Master die Aufgabe der Teamleitung. Die wichtigste Aufgabe eines Scrum-Teamleiters, so vorhanden, besteht darin, Störungen von seinen Entwicklern fernzuhalten, damit diese pünktlich und zuverlässig das geplante Teilergebnis abliefern.

Die schrittweise und an verwendbaren Zwischenergebnissen orientierte Vorgehensweise bringt es mit sich, dass auch das Testen der Zwischenergebnisse agil organisiert werden muss, um so eine wirksame Zusammenarbeit aller Projektbeteiligten zu erreichen.

Agiles Arbeiten soll ja gerade nicht zu Arbeitsverdichtung, mangelhafter Dokumentation, unzureichender Qualitätssicherung und allgemeiner Schlamperei bei der Softwareentwicklung führen. Die Veränderungen der Arbeitsorganisation sollen dem gerade entgegenwirken, in dem sie Freiräume schaffen, den Beschäftigten mehr Handlungs- und Entscheidungsspielräume geben, Mikromanagement ohne Ergebnisbeitrag abbauen und Kunden direkter beteiligen. Außerdem fördert das agile Arbeiten ein partizipatives Denken nach dem Pareto-Prinzip: Das Wichtigste und Ergebniswirksamste zuerst, den Rest später, Schnickschnack ohne konkreten Nutzen gar nicht.

Im Rahmen des bereits erwähnten Organisationsentwicklungsprojektes bei der British Telecom wollte man vom V-Modell XT hin zu Scrum wechseln. Ursächlich dafür waren ständige Termin- und Qualitätsprobleme sowie Schwierigkeiten mit unflexiblen Abläufen, die man nicht in den Griff bekam. Und bei denen man sich mit dem Wechsel hin zur agilen Methodenwelt substanzielle Verbesserungen versprach.

Anforderungen (z.B. in Form von User Stories), Entwicklungszwischenstände und Dokumente werden in Scrum nicht zu fixen Phasen sondern kontinuierlich prozessbegleitend getestet und abgenommen. Daher spielen abschließende Akzeptanz- und Abnahmetests eine eher geringe Rolle.

Trotzdem gilt es in vielen Organisationen flexibel zu bleiben und keine Methodenorthodoxie der reinen Lehre zu betreiben. So wurde z.B. im Verlauf des BT-Projektes ein externes Testing-Team eingerichtet, dass die Systemtests, Regressionstests, die Testautomation sowie andere qualitätssichernde Maßnahmen wie z.B. Defect Tracking und Stabilitätstests übernahm. Auch wenn „reines Scrum“ so etwas an sich nicht vorsieht. So wurde unter Beibehaltung des Mehraugenprinzips eine kontinuierlich zunehmende Produktqualität erreicht. Allerdings galt es organisatorische Probleme zu lösen. So konnten Tester z.B. zunächst nur das testen, was Entwickler im vorangegangenen Sprint entwickelt hatten. Gaben die Tester dann den Entwicklern Rückmeldung über gefundene Probleme, waren diese schon wieder im nächsten Sprint gebunden und konnten sich erst in folgenden Sprints um die gefundenen Probleme kümmern. Der Gleichlauf zwischen beiden Teams (das „mitsprinten“ der Tester) musste erst entsprechend geplant und organisiert werden.

Zudem erfordert eine solche Zusammenarbeit mehrerer Teams auch, dass alle mit gleichen Tools auf eine gleiche Datenbasis zugreifen. Wenn Entwickler Testfälle in Excel-Listen verwalten, während Tester hierfür eine Testmanagementumgebung verwenden, wird es früher oder später zu Inkonsistenzen im Testfallbestand kommen. Zumal rasche Rückmeldungen über Teiltestergebnisse an die Entwickler oft wichtiger sind als ausgefeilte Testkonzepte.

Auch muss eine gemeinsame „Definition of Done“, also eine prüfbare Festlegung der zu erbringenden Aktivitäten, Ergebnisse und Qualitäten gefunden werden, aus denen hervorgeht, wann genau etwas fertig ist. Ohne feste Abnahmekriterien ist sonst ein „Overengineering“ oder umgekehrt das Abliefern von unausgereifter „Bananensoftware“ auch auf agilem Weg genauso gut möglich wie mit traditionellen Softwareentwicklungsmethoden.

Im Bereich des agilen Testens spielen bestimmte Methoden eine größere Rolle als bisher. Dazu zählen Unit Tests, frühzeitiges Testen und testgetriebene Entwicklung, bei der erst die Testfälle und dann der zu testende Code implementiert werden. Ebenso Komponententests, Testautomation, das Refactoring umfangreicher Testfälle sowie bereits das Testen auf Anforderungsebene.

Eine weitere Methode ist das Pair Testing (analog zum Pair Programming) bei dem ein Tester mit einem Entwickler, einem Anwender, dem Product Owner oder einem weiteren Tester zusammen testet.

Scrum hat sich in den letzten Jahren zum „Toyota Production System“ der Softwareentwicklung gemausert, das gerade von kleinen und mittleren Softwarehäusern, zunehmend aber auch von Konzernen wie z.B. Microsoft eingesetzt wird. Dabei stellen sich häufig Fragen nach der Kombination mit bzw. der Ablösung von anderen Ansätzen der Arbeitsorganisation im Entwicklungsbereich. Somit werden sich auch für Softwaretester und QA-Spezialisten die Tätigkeitsschwerpunkte und Arbeitsmethoden inhaltlich verschieben, wenn ihre Arbeitgeber oder Kunden Methoden und Vorgehensmodelle aus dem agilen Spektrum einführen.

Derzeit kann die Tücke des Objekts Arbeitnehmer treffen, die gerade ihre Steuererklärung für 2010 abgabefertig machen. Denn die Lohnsteuerbescheinigungen für 2010 enthalten für freiwillig gesetzlich versicherte Beschäftigte nicht vollständig ausgewiesene Beiträge zur Kranken- und Pflegeversicherung. Das kann zu Problemen führen, wenn man diese steuerlich geltend machen will, wie die Süddeutsche Zeitung gestern berichtete.

In den Zeilen 24 bis 26 der Lohnsteuerbescheinigung werden Sozialversicherungsbeiträge sowie Arbeitgeberzuschüsse zur freiwilligen Kranken- und Pflegeversicherung erfasst und unter bestimmten Voraussetzungen unvollständig zusammengerechnet. Durch die falsche Addition verlieren Arbeitnehmer so vielleicht ihren Entlastungsanspruch, da das Finanzamt diese Daten parallel zur Bescheinigung erhält und nicht auf Plausibilität zu prüfen scheint (so dass auch manuelle Korrekturen zwecklos sind und die Bescheinigung daher neu ausgefertigt werden sollte).

Hier macht sich ein spezielles Branchenproblem der Anbieter für Steuer- und Lohnabrechnungssoftware bemerkbar. Denn jedes Jahr gibt es Mitte bis Ende Dezember ein Jahressteuergesetz, dass i.d.R. zahlreiche Details im Steuerrecht verändert. Für DATEV & co. heißt es dann, diese in sehr kurzer Zeit zu durchschauen, zu implementieren und zu testen, so dass zum Jahresanfang korrekt rechnende Programme für Lohnabrechnung, Sozialversicherung und Steuerfragen verfügbar sind.

Das klappt nicht immer reibungslos, zumal die inhaltlichen Abstimmungsprozesse zwischen Finanzverwaltung, Unternehmen und Softwareanbietern nicht immer ganz reibungslos zu verlaufen scheinen. Auch diesmal gibt es wieder Schuldzuweisungen zwischen Softwareanbietern („unklare Informationen“) und Finanzverwaltung („nachfragen wenn was nicht verstanden wurde“).  Oder es wird aufgrund von Zeitdruck an der Qualitätssicherung gespart. Und manch ein Rechenfehler wird auch erst bemerkt, wenn sich die dahinter stehende Steuergesetzgebung erneut ändert.

Wo zwei sich streiten, tragen also auch mal Dritte den Schaden davon. Und Vierte können davon profitieren. So weist z.B. das International Software Quality Institute (iSQI) in einer Pressemeldung darauf hin, wie wichtig eine fundierte, standardisierte Aus- und Weiterbildung von Softwareexperten, konkreter Zertifizierungen in den Bereichen Testing, Anforderungsmanagement oder sichere Softwareentwicklung sein kann, wie sie von den iSQI-Partnerfirmen angeboten werden.

Da wird der Bug in der Lohnabrechnung zum willkommenen Werbegag.

Das macht das Anforderungsmanagement zu einer wichtigen Disziplin für all jene, die sich mit Aspekten der Informationssicherheit oder der Qualität von Softwareprodukten befassen. Anforderungen sind die Grundlage für alle Eigenschaften des späteren Produkts (zumindest sollten sie es sein). Anforderungen können Gegenstand späterer Prüfungen des Produktes sein und bilden die Grundlage für das Testmanagement zur Erstellung und Auswahl von Teststrategien und Testfällen. Im Bereich der Produktdokumentation bilden die Anforderungen den Kern des später zu Dokumentierenden und sind Basis für Anwenderschulungen. Auch die spätere Wartung und Weiterentwicklung des laufenden IT-Systems ist auf gut dokumentierte Anforderungen angewiesen.

Daher kann man sich bereits seit geraumer Zeit im Bereich des Anforderungsmanagements nicht nur fortbilden sondern auch ein Fachzertifikat, den „Certified Professional for Requirements Engineering (CPRE)“ mit Prüfung und Siegel erwerben, das auf einem Lehrplan basiert, der vom International Requirements Engineering Board (IREB) e.V. entwickelt wurde. Einem Verband, der sich mit der Kodifizierung von etablierten „best practices“ in diesem Teilbereich der Softwareentwicklung beschäftigt.

Zu den „Klassikern“ der Probleme beim Umgang mit Anforderungen zählen ungenaue, unvollständige, in sich widersprüchliche oder auch gar nicht vorhandene Anforderungen. Beispielsweise weil bei der Produktplanung wichtige Beteiligte übergangen wurden. Weil Dinge als selbstverständlich vorausgesetzt und daher nicht weiter erwähnt wurden. Weil das mit dem Produkt zu lösende Problem nicht wirklich verstanden wurde. Oder weil man es mal wieder zu eilig hatte – „husch husch – time to market – profit profit“ – und daher zu wenig in die konzeptionellen Vorarbeiten der Produktentwicklung investiert hatte. Daher gibt es auch regelmäßig Studien (wie z.B. den sog. „Chaos Report“ der Standish Group), die sich mit den Erfolgs- und Misserfolgsfaktoren in IT-Projekten beschäftigen und dabei regelmäßig die Bedeutung guten Anforderungsmanagements und guten Projektmanagements unterstreichen.

Grundsätzlich hat ein Anforderungsmanager vier Aufgaben, denen er sich zu widmen hat. Er soll Anforderungen erheben, dokumentieren, sie prüfen und mit den Beteiligten abstimmen sowie sinnvoll verwalten und verfügbar machen. Dort wo es die Rolle des Anforderungsmanagers nicht in Reinform gibt, fallen diese Aufgaben den Entwicklern, IT-Architekten, Projektleitern, Produktverantwortlichen etc. zu, was häufig nicht unbedingt zu ihrer vollständigen und zufriedenstellenden Erledigung beiträgt. Zumal ein Anforderungsmanager eigentlich weniger ein technischer Spezialist als ein Experte im Gebiet der Schlüsselqualifikationen und der Methodenkompetenz ist. Denn ihm fallen die „menschlichen Aspekte“ der Produktplanung zu: Er soll die Beteiligten des Vorhabens ausfindig machen, mit ihnen reden und sich so ein Gesamtbild des zu entwickelnden Softwareproduktes verschaffen. Und es so aufbereiten, dass die Entwickler darauf basierend etwas Brauchbares entwickeln können.

Anforderungsmanagern fällt somit die „Verwaltungswirtschaft“ der Softwareentwicklung zu, da ein Großteil ihrer Arbeit aus dem bereits erwähnten Erheben, Dokumentieren, Prüfen und Abstimmen sowie dem Verwalten der Anforderungen, mithin also aus dokumenten- und personenorientierter Arbeit besteht.

Dort wo Softwareentwicklung aber vom „Handwerk“ zur Ingenieurstätigkeit werden soll, also einem Industrialisierungsprozess unterliegt, kommt man um das Anforderungsmanagement ebenso wenig herum wie um das Plänezeichnen und Prototypenbauen im Automobilbau.

Zumal vollständige, konsistente und genau spezifizierte Anforderungen wie bereits erwähnte die Grundlage für testbare Produkte und prüfbare Prozesse zu deren Entwicklung bilden – somit also die Basis der Qualitätssicherung bilden. Zumal so aus Anforderungen auf dem Papier ausführbarer Testfallcode oder die Grundlage einer sicherheitstechnischen Bewertung des fertigen Softwareproduktes werden kann.

Do wo genau findet das Anforderungsmanagement denn statt?

Bei „klassischen“ Vorgehensmodellen der Softwareentwicklung wie z.B. dem V-Modell XT ist das Anforderungsmanagement eine klar definierte Phase, die der Entwicklung vorangeht und die Basis des zu entwickelnden Systems bildet. Zu einem bestimmten, vorab festgelegten Zeitpunkt wird der Stand der Anforderungen „eingefroren“ und bildet die Ausgangsbasis der weiteren Entwicklungsphasen. Später noch hinzukommende Änderungswünsche werden als genau das behandelt: Änderungswünsche, welche zu nachträglichen Änderungen der Planung und Kostenkalkulation führen können.

Im Gegensatz dazu ist das Anforderungsmanagement bei „agilen“ Vorgehensmodellen wie SCRUM ein Begleitprozess der Entwicklung und es werden nur jeweils die erforderlichen Anforderungen für den nächsten Teilabschnitt in der Entwicklung durch iteratives Vorgehen, inkrementelle Fortschreibung und Präzisierung abschlussfertig ausgearbeitet und umgesetzt.

Doch das Anforderungsmanagement trägt auch auf weitere Weise zu einer besseren Softwarequalität bei. So gilt es z.B. auch die Anforderungen an sich hinsichtlich Inhalt, Abgestimmtheit und Dokumentation qualitätszusichern und dabei Methoden des Qualitätsmanagements wie Beteiligung der Betroffenen, Mehraugenprinzip, Trennung von Fehlersuche und Fehlerkorrektur oder auch Prüfung aus unterschiedlichen Perspektiven anzuwenden. Nicht nur Code sondern bereits die dokumentierten Anforderungen an das spätere System lassen sich durch formale Methoden wie Audits, Inspektionen, Walkthroughs oder Reviews prüfen.

Doch woher kann man als im Bereich IT-Sicherheit und / oder Softwarequalität Tätiger das Know-how zu diesem breiten Thema nehmen? Beginnen kann man mit einschlägiger Fachliteratur, für ein tieferes Eindringen in das Thema Anforderungsmanagement kann ein entsprechendes Seminar oder eine Zertifizierung wie das bereits erwähnte IREB-Zertifikat sinnvoll sein. Letztlich entscheidend dürften dann aber die Erfahrungen der gelebten Projektpraxis „im Feldeinsatz“ werden.