Voraussetzung für eine erfolgreiche Qualitätssicherung ist ein einheitliches Verständnis der Grundbegriffe „Qualität“ und „Qualitätssicherung“, sowie die damit notwendigerweise verbundenen Aktivitäten. Qualität wird im internationalen Standard ISO 9126-1 [1] definiert als „Gesamtheit aller Merkmalswerte eines Produktes oder einer Dienstleistung, die sich auf deren Eignung beziehen, festgelegte oder vorausgesetzte Erfordernisse zu erfüllen.“ Diese Definition enthält leider keine konkret anwendbaren Bestimmungen darüber, wie eine Software zu einer Software hoher Qualität wird. Sie besagt im Kern nur, dass Qualität den Erfüllungsgrad der Anforderungen darstellt, die an ein Software-Produkt gestellt werden. Werden also z.B. alle Anforderungen eines Benutzers vollständig erfüllt, hat das Software- Produkt aus seiner Sicht mindestens eine gute Qualität. Wie steht es aber z.B. mit dem Administrator, der für Installation und Pflege verantwortlich ist? Erst wenn auch seine Anforderungen erfüllt werden, hat das Produkt für ihn eine gute Qualität. So muss ein Software-Produkt die Anforderungen aller Stakeholder erfüllen oder übererfüllen, um eine hohe Qualität zu erreichen. Unter den Begriff Qualitätssicherung fallen dabei die Aktivitäten, die sicherstellen und nachweisen sollen, dass ein Produkt die Anforderungen aller Stakeholder erfüllt – Qualitätssicherung beginnt also schon beim Anforderungsmanagement.
Qualitätssicherung als Bestandteil des Software Lifecycles
Qualität kann nicht am Ende einer Software-Entwicklung in einer „abschließenden Testphase“ in die Software „hinein getestet“ werden. Vielmehr muss die Qualität von Beginn an und während des gesamten Software Lifecycles bewusst betrachtet und gesichert werden. Die Entwicklung erfolgt dazu idealerweise nach einem iterativ, inkrementellen Entwicklungsprozess, in dem bereits das Testen integraler Bestandteil ist, und sich jeder Projektbeteiligte für die Qualität verantwortlich fühlt. Es ist jedoch empfehlenswert, einen Verantwortlichen im Team zu definieren, der alle qualitätssichernden Maßnahmen koordiniert und kontrolliert. Denn so kann insbesondere das Risiko missverstandener Anforderungen durch regelmäßig überprüfte Software-Versionen minimiert werden.
Die Qualität einer Software kann nur dann sicher und langfristig erreicht werden, wenn neben dem Erfüllungsgrad der Anforderungen auch die Qualität des Sourcecodes sichergestellt wird. Die Vorgehensweise beim Entwickeln und die dabei erstellten Artefakte (z.B. Spezifikationen, Software-Design, Sourcecode, Testcode) müssen ebenfalls von der Qualitätssicherung erfasst werden. Im Laufe des Software Lifecycles sind also vielfältige Aktivitäten zur Sicherstellung der Qualität notwendig. Viele davon können und sollten während der Entwicklung durch geeignete Werkzeugunterstützung automatisiert werden, um – möglichst jederzeit – die Qualitätsmerkmale zu überwachen und im Zweifel korrigierend in die Entwicklung eingreifen zu können. Ohne Werkzeugunterstützung ist das Sammeln und Aufbereiten der vielfältigen Daten für ein zeitnahes Überwachen und Eingreifen in die Entwicklung, speziell bei komplexen Produkten, nicht praktikabel.
Auf dem Markt existiert dazu eine Vielzahl unterschiedlicher Werkzeuge für die unterschiedlichsten Aufgaben: Werkzeuge für Anforderungsmanagement, Testautomatisierung, Build-Automatisierung, Versionskontrolle, Änderungsmanagement, Performance-Analyse und viele weitere Bereiche. Microsoft Visual Studio Team System (VSTS) verspricht vielfältige integrierte Features, die die Qualitätssicherung vereinfachen sollen. Aus diesem umfangreichen Themengebiet der Qualitätssicherung werden die Autoren im Folgenden ausgewählte Aspekte beleuchten und deren Unterstützung durch Visual Studio Team System betrachten.
Der Entwicklungsprozess
Ein Entwicklungsprozess ist die Grundlage für eine optimale Qualitätssicherung. Ein solcher Prozess definiert z.B. Entwicklungsphasen, Rollen, Aktivitäten und Artefakte, die während der Software- Entwicklung benötigt bzw. erstellt werden. Mittlerweile setzen sich zunehmend iterative, inkrementelle Vorgehensweisen durch, die durch regelmäßig gelieferte Software-Versionen die Überprüfung der bis dahin erreichten Ergebnisse ermöglichen. Durch diese Herangehensweise soll sichergestellt werden, dass die Anforderungen tatsächlich so umgesetzt wurden, wie sie von den Stakeholdern „gemeint“ waren. Gleichzeitig werden die Aufgaben in der Weise priorisiert, dass die risikoreichen (z.B. Verwendung neuer Technologie) und wichtigen Aspekte so früh wie möglich adressiert werden. Die notwendigen Bestandteile eines Entwicklungsprozesses sind in hohem Maße vom Einsatzgebiet abhängig. Während die Entwicklung kurzer Projekte mit kleinen, eingespielten Teams „wenig“ dokumentierten Prozess benötigt, muss die Entwicklung komplexer Projekte, die im regulierten Bereich mit unterschiedlichen und verteilten Teams stattfinden, mit umfangreicheren Prozessen stattfinden. Der internationale Standard ISO 12207 [2] definiert wesentliche Anforderungen an einen Entwicklungsprozess und kann bei der eigenen Prozessauswahl bzw. -definition hilfreich sein.
Dass es Microsoft mit einer prozessorientierten Software-Entwicklung ernst meint, fällt schon beim Anlegen eines neuen Team-Projektes mit dem Team Foundation Server (TFS) auf. Ohne die Auswahl einer Prozessvorlage kann es nicht angelegt werden. Standardmäßig werden zwei Prozessvorlagen angeboten, die auf einer iterativen, inkrementellen Vorgehensweise aufbauen: MSF for Agile Software Development und MSF for CMMI Process Improvement. Der erste Prozess konzentriert sich auf die wesentlichen Elemente der Entwicklung, der zweite bietet darauf aufbauend zusätzlich formale Elemente, wie z.B. Reviews. Die Prozessbeschreibung ist Bestandteil des TFS-Portals und kann über den Team-Explorer direkt aus der Entwicklungsumgebung erreicht werden. Damit entfällt die sonst übliche Suche der passenden Prozessbeschreibung in einer tief verschachtelten Verzeichnisstruktur auf einem Server des Qualtitätsmanagements, oder – schlimmer noch – in einem vielleicht nicht aktuellen Ausdruck des Qualitätshandbuches der Abteilung. Es ist nicht zwingend, ausschließlich die mitgelieferten Prozessvorlagen zu nutzen. Microsoft hat eine Anpassung oder Neuerstellung von Prozessvorlagen ausdrücklich vorgesehen. Das Erstellen bzw. Anpassen einer Prozessvorlage wird in der aktuellen Version jedoch nicht durch eine integrierte, benutzerfreundliche Konfigurationsoberfläche unterstützt, sondern muss in weiten Teilen noch umständlich in XML-Dateien definiert und mit separat ...
