Ganzheitliche Software Qualitaet (PDF) - Software Quality Lab

software.quality.lab.com

Ganzheitliche Software Qualitaet (PDF) - Software Quality Lab

10it-security software-qualität09/2012 computerwelt+ computerwelt+ 12/2012Ganzheitliche Software-QualitätEs gibt drei Arten von Organisationen: Die einen bewirken, dass etwas geschieht; die anderen beobachten, dassetwas geschieht; und wieder andere fragen sich, was geschehen ist. Ein Leitfaden für mehr Qualität.In der Welt der Software-Qualität ist dieGruppe jener, die bewirken, dass etwasgeschieht, noch in der Minderheit. Jedochhat es in den letzten zehn Jahren einedeutliche Verschiebung zugunsten dieserengagierten Organisationen gegeben.Immer mehr Ausbildungsinstitutionen(Universitäten, Fachhochschulen etc.) nehmenSoftware-Qualitätsthemen in das Ausbildungsprogramm,und die Absolvententragen dieses Wissen hinaus in die Unternehmen.Wo früher in den Software-Organisationennur Entwickler gearbeitet haben, sind heuteauch schon einige Tester zu finden. Währenddiese früher diejenigen waren, die zudieser Aufgabe »abgeschoben« wurden,weil sie nicht gut genug programmierenkonnten, sind Software-Tester heute oft höherqualifiziert als Entwickler und befindensich in einer Schlüsselrolle zwischen Produktmanagement,Kunden und Entwicklung.Viele Software-Organisationen machensich zudem Gedanken über Prozesse und– jedoch leider weniger oft – werden dieseauch systematisch definiert und weiterentwickelt.Zumindest der Trend geht in dierichtige Richtung.»Man sollte auch auf den Hausverstand vertrauen und pragmatische Wege gehen«, sagtJohannes Bergsmann, Gründer und geschäftsführender Gesellschafter von Software Quality Lab.Ausrichtung auf Qualitätbedeutet VeränderungOft verharren Entwicklungsorganisationenin Selbstzufriedenheit. Mit Sätzen wie »Wirsind der Marktführer – die Besten«, »Dasist nur eine Konjunkturkrise«, »Bei uns istdas alles ganz anders« oder »Den anderengeht es auch nicht besser« beruhigt undrechtfertigt man sich selbst. Leider gilt auchoft das Sprichwort »Nachdem wir das Zielaus den Augen verloren hatten, verdoppeltenwir unsere Anstrengungen.«Nur, was kann man tun, um sich weiter zuentwickeln? Etablierte Denkgewohnheitenund Sichtweisen müssen in Frage gestelltwerden. Das Erzeugen von Aufbruchsstimmungund das Denken in neue Richtungen– zum Beispiel durch eine mit dem Managemententwickelte gemeinsame Vision– sind in diesem Fall sehr hilfreich und zielführend.Weiterer Tipp: Gewohnte Gruppenstrukturenaufbrechen. Dies kann auchphysisch, z.B. in Form von Job-Rotationzwischen Entwicklern und Testern, passierenoder durch die Bildung von interdisziplinärenTeams wie etwa in der agilen Entwicklung.Ein weiterer entscheidenderPunkt ist das Vorleben von Veränderungendurch das Management. Es reicht oft schon,wenn das vorerst nur in einem eingeschränktenOrganisations- oder Themenbereichpassiert.Wichtig: Software-Qualität setzt sich nichtnur aus Testen und Qualitätssicherung zusammen.Entscheidend ist, dass alle beteiligtenPersonen inklusive dem verantwortlichenManagement über Veränderungnachdenken und sich bewusst werden, dassVeränderungen notwendig sind.Viele Themen sind in diesem Zusammenhangwichtig und gehen oft Hand in Hand.Beispiele dafür sind: Requirements-Engineering,Change-Management, Code-Qualität,Risikoeinschätzungen, angemesseneProzesse, Automatisierung, Vorgehensweisen,Tools und deren Integration.RequirementsIn fast jeder Entwicklungsorganisation istdas Thema Anforderungen ein Dauerbrennerund das schon seit Jahrzehnten.Die Langzeitbeobachtung lässt befürchten,dass dieser zentrale Aspekt in vielen Organisationenauch in den nächsten Jahrzehntennicht nachhaltig gelöst werden wird.Viele Betroffene tappen hier ziemlich imDunkeln. Nicht nur, was die Inhalte derRequirements an sich betrifft, sondern es© Wolfgang Franzsind in den meisten Fällen noch viele Fragestellungenoffen. Zum Beispiel die Unterscheidungzwischen »was« und »wie«.Oft werden Lösungsbeschreibungen(»wie« etwas umgesetzt wird) und die Anforderungenaus der Kundensicht (»was«der Kunde gerne haben möchte) vermischt.In den heute üblichen iterativen Vorgehensweisenist es notwendig, zwischendem »Was« und dem »Wie« einen ständigenAbgleich und Konsens zu schaffen.Wenn Der Chef oder derAuftraggeber drängenIn vielen Unternehmen ist es ein Bewusstseinsthemanach dem Motto »Wieso wirddenn hier so viel geschrieben? Wäre esnicht besser, wenn endlich gearbeitetwird?« In derartigen Organisationen hatdas Thema Requirements-Spezifikationkeinen Stellenwert.In vielen Fällen ist es aber auch der Zeitdruck,der oft aus einer falschen Aufwandsschätzungund Planung resultiert.Es wird dann einfach zu wenig Zeit fürgute Spezifikation eingeplant oder auchbei guter Planung kann es dem Auftraggeberoder Chef oft nicht schnell genuggehen, bis er endlich etwas Vorzeigbaressieht. Meist passiert dies dann auf Kostender Qualität.


12software-qualität12/2012 computerwelt+Requirements-Engineeringin agilen ProjektenAufgrund der Verbreitung der agilen Vorgehensweisenwird die Anforderungsspezifikationimmer mehr zum Thema, da diemeisten agilen Vorgehen leider nicht ausreichenddarauf eingehen. User-Stories undandere agile Requirements-Artefakte werdenzwar erwähnt, aber oft nur sehr oberflächlichbeschrieben. Daher muss sich jedeOrganisation, die agile Vorgehensweisenanwendet, auch Gedanken darüber machen,wie mit Requirements umgegangenwird.Die passenden werkzeugeverwendenDas meist verwendete Tool in diesem Bereichist nach wie vor die Textverarbeitungoder Tabellenkalkulation. Diese sind zwarflexibel bei der Erstellung von Anforderungen,jedoch beinahe unbrauchbar, wenn esum die Änderungsverfolgung, Versionierung,Attributierung und andere wichtigeThemen im Requirements-Managementgeht.Es muss klar getrennt werden zwischen derinhaltlichen Darstellung und Strukturierungvon Anforderungen, die idealerweisedurch geeignete Requirements-Management-Toolserfolgen, und der Steuerungder Umsetzung der Anforderungen, wofürsich dann Tracking-Tools wieder recht guteignen.Testen auf Basis genaudefinierter GrundlagenDas Testen an sich muss heute kaum mehrargumentiert werden. Es gibt aber auch hiereinige Themen, die immer wieder hinterfragtwerden müssen: Lässt sich ohneGrundlage testen? Das muss natürlich klarverneint werden.Es stellt sich jedoch häufig die Frage, wasdie passende Testgrundlage ist. Testen dieVerantwortlichen das, was die Entwicklerihnen sagen? Testen sie nach den Vorgaben,die ihnen die Entwickler geben? Oder habendie Tester angemessene Anforderungsspezifikationen,Qualitätsrichtlinien, Definitionsof Done, vordefinierte Guidelinesund Checklisten, an denen sie sich bei derTestfallerstellung und Durchführung orientierenkönnen?Ein Software-Tester ohne Grundlagen istwie ein Wanderer ohne Karte und Ziel. Erwird herumirren und eventuell zufälligoder mit seinem Hausverstand und Fachwissenden einen oder anderen Fehler finden,insgesamt jedoch meist ziemlich ineffizientarbeiten.Manche Unternehmen betreiben Unit-Tests in der Entwicklung recht umfangreichund sind der Ansicht, dass das Testen damiterledigt sei. Das ist jedoch ein Irrtum, damit den Unit-Tests nur ein bestimmter Teilder benötigten Aufgaben abgedeckt werdenkann. Abhängig von der Art des entwickeltenSystems sind das zum Beispiel zwischen30 und 60 Prozent der notwendigen Tests.Je nach Komplexität des Systems sind jedenfallsauch Integrationstests und Systemtestsdurchzuführen, die typischerweiseandere Sichtweisen als die Unit-Tests abdeckenund daher nicht weggelassen werdendürfen.Was hat der Tester eigentlich in der Organisationzu sagen? Welche Verantwortungträgt er und welche Befugnisse hat er? Sinddie Tester in die Entwicklung integriertoder sind sie eigenständig von den Entwicklernorganisiert? Die Tester sollten mitder Entwicklung eng zusammenarbeiten –schließlich sitzen ja alle im selben Boot undhaben dasselbe Ziel, nämlich den Kundendurch gute Software zufrieden zu stellen.Wenn der Tester nur als notwendiges Übeloder als »Feigenblatt der Qualität« in derEntwicklung betrachtet wird, dann läuftetwas falsch. Der Tester bzw. Testmanagersollte entsprechend seiner Verantwortungauch angemessene Befugnisse haben.Sie sollten jedoch so eigenständig in ihrerRolle und organisatorischen Position sein,dass sie ihre Verantwortung und Aufgabenauch effektiv erfüllen können und das Vier-Augen-Prinzip der Qualitätssicherung gewahrtbleibt.Test-AutomatisierungTestautomatisierung ist heute für eineeffiziente Durchführung des Testens unumgänglich.Die Entwickler werden dadurchauch »mutiger« und das laufendeRefactoring eines Systems wird einfacher.Testautomatisierungs-Tools & Frameworksliefern eine gute Basis. Jedoch ist zu beachten,dass die Auswahl eines Testwerkzeugsallein noch keine Test-Strategie darstellt.Achtung: Auch (Unit-Test-)Entwickler undTestautomatisierungs-Fachtester müssenentsprechend ausgebildet und unterstütztwerden, damit Testautomatisierung effektivund effizient durchgeführt werden kann.RisikoManagementRisikomanagement wird oft nicht oder nurhalbherzig betrieben. Selbst in sehr großenund risikoreichen Projekten besteht dies oftnur aus einem einmaligen kurzen Brainstormingals »Feigenblatt« am Anfang desProjekts, damit die Verantwortlichen auchdieses Thema abhaken können.Dabei ist Risikomanagement, wenn esernsthaft betrieben wird, ein sehr gutes Instrumentfür die Erreichung einer effektivenVorgehensweise in der Entwicklung.Durch die Risikoeinstufung können praktischsämtliche Aktivitäten im Projekt differenziertbetrachtet und vom Aufwand hergesteuert werden. Eine gezielte Anwendungkann hier, ohne dass auf eine strukturierteund nachvollziehbare Vorgehensweise verzichtetwird, viel Aufwand und Geld sparen.Agile MethodenEs gibt praktisch kaum eine Software-Entwicklungsorganisation, die sich nichtmit agilen Methoden auseinandersetzt.Abhängig vom Umfeld passiert dies in derPraxis jedoch mit mehr oder weniger Erfolg.Da agile Methoden oft nur einen rechtkleinen Ausschnitt der Realität betrachten(zum Beispiel Scrum-primär: Projektmanagementund Projektcontrolling, Kanban-primär:das Ressourcenmanagement),ist es notwendig, die agilen Methoden immerim Kontext der gesamten Organisation,der Projekte und der restlichen Prozessthemenzu betrachten.Eine dogmatisch isolierte Behandlung deragilen Ansätze führt in den meisten Organisationenerfahrungsgemäß bald zur Ineffizienzoder sogar zum Scheitern deragilen Methoden.Alle genannten Themenbereiche sind in dieWelt der Software-Qualität eingegliedert.Die Themen sind komplex und miteinandervernetzt und sollten nicht isoliert betrachtetwerden. Das Gesamtoptimum fürdie Organisation sollte im Fokus stehen.Dazu ist es wesentlich, sich nicht nur aufein Thema zu konzentrieren, sondern dasProzesssystem als Ganzes zu betrachten,zu analysieren und dann passende Maßnahmenzu definieren. Die Umsetzungfällt leichter, wenn sie Schritt für Schritterfolgt.Einen Prozess- und Quality-Manager inder Organisation zu etablieren, wird fürdie nachhaltige Etablierung des Qualitäts-Gedankens förderlich sein.Prozesse und das Umfeld ändern sich laufend,daher ist es sehr wesentlich, ständigan deren Anpassung und Verbesserung zuarbeiten.Zu guter Letzt: Es ist nicht alles schwarzoder weiß. Interessierte sollten die periodischauftauchenden dogmatischen Publikationenkritisch hinterfragen. Am bestenist man bedient, wenn man sich aufden eigenen Hausverstand verlässt unddurchaus pragmatische Wege geht.Johannes Bergsmann ist Firmengründer undgeschäftsführender Gesellschafter von SoftwareQuality Lab.