Die QS-Fibel http://www.qsfibel.de Qualitätssicherung in Web-Projekten Sun, 22 Feb 2015 10:04:46 +0000 en hourly 1 http://wordpress.org/?v=3.1.3 Qualität in kleinen Projekten sicherstellen http://www.qsfibel.de/artikel/qualitaet-in-kleinen-projekten-sicherstellen/ http://www.qsfibel.de/artikel/qualitaet-in-kleinen-projekten-sicherstellen/#comments Mon, 04 Jun 2012 19:42:47 +0000 Alexander http://www.qsfibel.de/?p=195 Neulich kam ich mit dem Betreiber einer kleinen NGO-Website ins Gespräch über die Qualitätssicherung von Websites. Er wollte wissen, wie er mit einem kleinen Budget etwas systematischer sicherstellt, dass sich keine Fehler auf seiner Website einschleichen.
Meine spontane Antwort war dann, dass das Bewusstsein fürs Testen schon der erste Schritt zur Vermeidung von sehr vielen banalen Problemen sein kann. Tatsächlich gab es auch bei ihm schon Probleme, die bei einem einfachen Blick auf die Website aufgefallen wären.

Damit es aber gar nicht erst passieren kann, dass Fehler auf dem Produktivsystem sichtbar werden, ist im professionellen Umfeld die Verwendung von getrennten Test- und Produktivsystemen Standard.

Auch bei kleinen Websites oder Blogs sollten Code-, Konfigurationanpassungen oder Updates zunächst auf einem Testsystem vorgenommen werden. Für dieses Testsystem ist nicht unbedingt ein richtiger Server notwendig, sondern es reicht eine lokale Installation auf dem eigenen Rechner.
Wohlgemerkt: dieses Vorgehen ist allenfalls bei semiprofessionellem Betrieb zu empfehlen, und erübrigt sich sowieso wenn man mit mehreren Personen am Projekt arbeitet.

Auch die Updates an diesem WordPress-Blog und den Plugins führe ich zunächst auf einem Testsystem durch. Gerade bei diesem Zusammenspiel von verschiedenen Systemen (WordPress und Plugins) von verschiedenen Zulieferern (Plugin-Entwickler) kann man nicht sicher sein, dass alle Versionen problemlos miteinander funktionieren. Hinzu kommen vielleicht eigene Konfigurationsfehler. Ich prüfe also zunächst auf dem Testsystem, ob weiterhin alles korrekt läuft und meine Einstellungen korrekt sind. Erst dann ziehe ich die Änderungen auf dem Produktivsystem nach – und bin dabei auch meistens schneller, weil schon geübt.

Wenn man ein Projekt oder eine Website über einen längeren Zeitraum betreut, wird man viele Tests öfter durchführen, z. B. bei wiederholten Updates. Die zu prüfenden Funktionen sind jedes Mal die gleichen! Dafür sollte also zumindest eine Checkliste erstellt werden, die auflistet welche Punkte geprüft werden müssen. Das ist dann der Testfallkatalog aus dem Testkonzept. Erst wenn diese Punkte eine gewisse Komplexität haben, ist es erforderlich, dazu auch ausführliche Testfälle zu schreiben.

Fazit:

  • Auch vermeintlich kleine Änderungen können verheerende Auswirkungen haben, also: immer trotzdem testen!
  • Test- und Produktivsysteme verwenden
  • Checkliste für zu prüfende Funktionen
]]>
http://www.qsfibel.de/artikel/qualitaet-in-kleinen-projekten-sicherstellen/feed/ 0
Testfälle ermöglichen strukturiertes Testen http://www.qsfibel.de/artikel/testfaelle-ermoeglichen-strukturiertes-testen/ http://www.qsfibel.de/artikel/testfaelle-ermoeglichen-strukturiertes-testen/#comments Thu, 09 Feb 2012 06:47:52 +0000 Alexander http://www.qsfibel.de/?p=172 Strukturiertes Testen bedeutet vor allem, dass man die an das System gestellten Anforderungen gezielt abprüft, statt „mal kurz durch zu klicken“. Man nimmt also Konzept oder Anforderungsspezifikation als Basis und beschreibt in sich abgeschlossene Benutzerfunktionen, die das zu testende System bereitstellen muss. Diese Beschreibung enthält auch das erwartete Ergebnis und ermöglicht dem Tester, zu beurteilen ob der Test erfolgreich ist oder fehlschlägt.

Testfälle kann man mithilfe von Testmanagement-Tools verwalten, oder man erstellt sie einfach in einer Tabelle. Tools unterstützen die Verwaltung der Testfälle und bieten meist Funktionen zur Ausführung und Dokumentation der Testfälle. Für den Einsteig – und um das Prinzip zu erläutern – verzichte ich erst mal auf ein konkretes Tool und begnüge mich mit einer Testfallbeschreibung in Tabellenform.

Testfall IDBeschreibungAktionSoll-Verhalten
 
 
 

Beispiel:
Eine Website verfügt über einen geschlossenen Bereich, den man nur nach Login mit Benutzername und Passwort aufrufen kann. Gibt man nicht die korrekten Zugangsdaten ein, soll der Login fehlschlagen und eine entsprechende Fehlermeldung angezeigt werden.

Testfall IDBeschreibungAktionSoll-Verhalten
TF_001Login mit falschem PasswortEinen gültigen Benutzernamen sowie ein falsches Passwort eingeben und auf ,Login‘ klicken.Der Login schlägt fehl. Es wird folgender Hinweis ausgegeben: „Login fehlgeschlagen! Bitte überprüfen Sie Benutzernamen und Passwort“
TF_002Login mit ungültigem BenutzernamenEinen ungültigen Benutzernamen sowie ein beliebiges Passwort eingeben und auf ,Login‘ klicken.Der Login schlägt fehl. Es wird folgender Hinweis ausgegeben: „Login fehlgeschlagen! Bitte überprüfen Sie Benutzernamen und Passwort“
TF_003Login mit korrektem PasswortEinen gültigen Benutzernamen sowie das dazugehörige richtige Passwort eingeben und auf ,Login‘ klicken.Der Login ist erfolgreich. Es wird die Startseite des geschlossenen Bereichs angezeigt.

Unter Umständen erfordern manche Funktionen des Systems gewisse Vorbedingungen, die auch der Tester kennen muss, damit er diese vor Ausführung des Tests herstellen kann. Beispiel: Login mit einem gesperrten Benutzer soll fehlschlagen.
Dazu kann man die Tabelle um eine Spalte erweitern:

Testfall IDBeschreibungVorbedingungAktionSoll-Verhalten
TF_004Login mit gesperrtem Benutzergesperrter Benutzer im System vorhandenDen gesperrten Benutzernamen sowie das dazugehörige richtige Passwort eingeben und auf ,Login‘ klicken.Der Login schlägt fehl. Es wird folgender Hinweis ausgegeben: „Benutzer gesperrt. Wenden Sie sich an den Administrator“

Die Testfälle sollten unmissverständlich die auszuführenden Schritte beschreiben, so dass der Tester den Testfall bei jeder Ausführung gleich ausführt und vergleichbare Ergebnisse erhält. Dem entgegen steht der Aufwand, der für Erstellung und Pflege sehr detaillierter Testfälle erforderlich ist. Für die Abwägung der optimalen Detailtiefe können u.a. folgende Aspekte hilfreich sein: Wie erfahren ist der Tester? Müssen die Testfälle auch für Projektfremde verständlich sein? Worauf genau legt man den Fokus beim Testen (vgl. Anforderungen!)?

Ausführung und Dokumentation

Obige Tabelle kann um zwei Spalten „Testergebnis“ und „Bemerkung“ erweitert werden und dann zur Testdokumentation dienen: Erfolgreiche Tests werden abgehakt oder grün markiert; fehlgeschlagene Tests werden rot markiert, wobei die genaue Fehlerwirkung dann im Bemerkungsfeld erfasst werden kann (oder ID/Verweis auf Bugtracking-System).

Schwierig wird dieses dateibasierte System ab einer gewissen Projektgröße, wenn mehrere Leute daran arbeiten oder wenn sich Anforderungen und Testfälle im Projektverlauf häufig ändern. Dann sollte man ggf. überlegen, auf ein Tool zur Testfallverwaltung zurückzugreifen.

]]>
http://www.qsfibel.de/artikel/testfaelle-ermoeglichen-strukturiertes-testen/feed/ 0
Was muss ins Testkonzept? Beispiele aus der Praxis. http://www.qsfibel.de/artikel/was-muss-ins-testkonzept-beispiele-aus-der-praxis/ http://www.qsfibel.de/artikel/was-muss-ins-testkonzept-beispiele-aus-der-praxis/#comments Sat, 10 Dec 2011 21:17:35 +0000 Alexander http://www.qsfibel.de/?p=162 In meinem letzten Artikel habe ich geschrieben es sei optimal, wenn das Testkonzept schon vor der Testphase erstellt wird. Jetzt denke ich, es ist nicht nur optimal, es sollte sogar Pflicht sein! Viele Dinge machen einfach nur Sinn, wenn man sie früh genug aufschreibt und damit die Richtung vorgibt.

Hierzu zwei Beispiele:

Test-Benutzeraccounts:
Angenommen, für das Testen eines Systems werden Benutzeraccounts in verschiedenen Rollen benötigt. Der Entwickler legt für seine lokalen Tests Accounts dafür an. Nach dem Deployment muss der Tester ebenfalls die verschiedenen Accounts auf dem Testsystem anlegen. Der Tester meldet einen Fehler, der Entwickler will ihn nachvollziehen. Leider kennt der Entwickler Benutzernamen und Passwort des Accounts, mit dem der Fehler aufgetreten ist, nicht.

Lösung: Der Testmanager gibt bereits im Testkonzept vor, welche Benutzernamen und Passwörter für die Tests verwendet werden sollen. In abgesicherten Testumgebungen kann auch für alle Testbenutzer das gleiche einfache Passwort verwendet werden. Dieses Passwort ist dann allen im Team bekannt und erleichtert so das Testing.

Testumgebungen:
Für Entwicklung und Test werden mehrere Umgebungen aufgesetzt, um die verschiedenen Entwicklungsstände testen zu können. Benennung und Verwendung dieser Systeme sollte allen geläufig sein, damit es nicht zu Missverständnissen kommt.

Folgende Fragen sollten im Testkonzept festgelegt werden:

  • Wie werden die verschiedenen Stufen der Testumgebungen genannt?
  • Welches System für welchen Zweck?
  • Auf welchem System kann der Kunde testen; ist der Zugriff von außen gewährleistet?
  • Hostnamen definieren und Systeme darüber verfügbar machen: dev.projektname.de und test.projektname.de lassen sich leichter merken als IP-Adressen.

Man erspart sich damit später im Projektverlauf unter Umständen, dass diese Dinge unter Zeitdruck festgelegt werden müssen, dass eine benötigte Testumgebung nicht zur Verfügung steht, dass jeder andere Bezeichnungen für die gleiche Umgebung benutzt usw…

Es geht wirklich nicht darum, das Testkonzept um seiner selbst Willen zu schreiben. Es soll nicht schön zu lesen sein, sondern auf den Punkt Dinge festlegen. Einmal eingeschliffene Gewohnheiten sind schwer zu ändern, deshalb frühzeitig schreiben! Das Testkonzept kann so später auch Nachschlagewerk für alte und neue Teammitglieder sein und dem Projektleiter zuviel individuellen Einweisungsaufwand ersparen.

]]>
http://www.qsfibel.de/artikel/was-muss-ins-testkonzept-beispiele-aus-der-praxis/feed/ 0
Testkonzept als Grundlage für die Testplanung http://www.qsfibel.de/artikel/testkonzept-als-grundlage-fuer-die-testplanung/ http://www.qsfibel.de/artikel/testkonzept-als-grundlage-fuer-die-testplanung/#comments Thu, 21 Jul 2011 19:33:02 +0000 Alexander http://www.qsfibel.de/?p=130 Mit einem Testkonzept kann man einen ersten einfachen Schritt hin zu einer strukturierten Testphase machen. Die Testfallspezifikation kann im zweiten Schritt darauf aufbauen. In der Testkonzeption geht es aber vor allem darum, den Überblick über die Testphase nicht zu verlieren. Man kann frühzeitig entgegenwirken, dass Besonderheiten und kritische Funktionen des Systems oder wichtige Tätigkeiten beim Testen nicht übersehen werden.
Optimal ist, wenn das Dokument schon vor der Testphase erstellt wird; sobald die Anforderungsdefinition abgeschlossen ist, kann mit der Testplanung begonnen werden. Dann stehen die Erkenntnisse noch während der Entwicklungsphase zur Verfügung und der Projektleiter kann vielleicht schon in der Programmierung gezielt Problemen vorbeugen, z. B. durch intensivere (Unit-)Tests in der Entwicklung.

Was steht im Testkonzept?

ThemaErläuterung
Beschreibung des zu testenden SystemsWas ist das für eine Website, was sind die Hauptfunktionen? Architektur, eingesetztes CMS, spezielle Anforderungen (Flash-Plugin wird benötigt)
Definition der TestumgebungWas braucht der Tester, z. B. Java-Client und bestimmte Version?
Werden bestimmte Testdateien gebraucht, z. B. zum Testen einer Upload-Funktion?
Vorbereitung der TestsE-Mail-Versand an echte Nutzer-Adressen vermeiden, besser Testadressen einsetzen
Verantwortlichkeiten, Aufgaben des TestersVerantwortliche Personen benennen; Wie soll der Tester seine Ergebnisse dokumentieren (Bugtracking-Tool)?
zu testende Eigenschaften, nicht zu testende EigenschaftenKein Augenmerk auf redaktionelle Inhalte, wenn es sich nur um Testinhalte (Texte, Bilder) handelt; eingebundene Fremd-Applikationen, die vom Zulieferer getestet werden.
Definition der Testobjektez. B. das Modul "Vertragsmanagement" oder das „Registrierungsformular“; Maske zum Ändern des Passworts; Navigation der Website; Funktion zum Vergrößern der Schrift
TestfallkatalogSchlagwortartige Auflistung der Testfälle über alle zu testenden Bereiche; dabei nicht ins Detail gehen sondern hohe Abdeckung sicherstellen.
Risikobetrachtung, PriorisierungAnmerkungen zu kritischen oder besonders wichtigen Bereichen einer Website; Hinweis, dass bestimmte Funktionen oder Sichten ggf. weniger Augenmerk benötigen, weil sie nur einem beschränkten Nutzerkreis zugänglich sind.
Zeit-/Ressourcenplanung; Reihenfolge der AktivitätenSobald eine Komponente fertig programmiert ist, kann sie getestet werden. Unfertige Sachen nicht testen (unnötiger Aufwand weil erneutes Testen notwendig)

Tipp: Das Testkonzept muss kein Dokument sein. Es kann auch sehr praktisch sein, dafür eine Seite im Projekt-Wiki anzulegen. So ist es auch leichter zugänglich als eine auf dem Fileserver in den Ordnern versteckte Datei.

]]>
http://www.qsfibel.de/artikel/testkonzept-als-grundlage-fuer-die-testplanung/feed/ 0
Strukturiert testen http://www.qsfibel.de/artikel/strukturiert-testen/ http://www.qsfibel.de/artikel/strukturiert-testen/#comments Sat, 09 Jul 2011 12:35:47 +0000 Alexander http://www.qsfibel.de/?p=126 Selbst wenn man darauf achtet, die Testaufgaben in der Projektplanung zu berücksichtigen, kann folgendes passieren: Man macht sich erst nach dem Abschluss der Entwicklung Gedanken über das Testen. Dann hat man für Planung keine Zeit mehr und testet drauf los oder delegiert das Ganze gleich an einen Praktikanten. Ergebnis:

  • Bereiche der Website oder einzelne Funktionen werden vergessen und nicht getestet.
  • Der Tester übersieht einen Fehler, weil er denkt, das beobachtete Verhalten der Website oder Web-Anwendung ist korrekt.
  • Unwichtige Kleinigkeiten werden zuerst getestet (weil man schneller merkt, was man schafft…) und am Ende fehlt die Zeit für kritische Bereiche der Website.
  • Wenn mehrere Leute testen, werden ggf. einige Funktionen mehrfach getestet, andere Bereiche („Da geht ja eh alles.“) weggelassen.

Mit einem strukturierten Vorgehen kann man diese Situationen und Probleme vermeiden. Die Grundidee ist hierbei, dass alle relevanten Informationen, die bei der Formulierung der Anforderungen im Konzept zusammengetragen wurden, auch in die Testplanung mit einfließen und dem Tester zur Verfügung stehen. Darüber hinaus sollen die Aktivitäten gesteuert und die Schritte und Rahmenbedingungen festgelegt werden.

Basis ist das Fachliche Konzept mit einer möglichst detaillierten Anforderungsdefinition. Wichtige Werkzeuge die das systematische Testen unterstützen, sind Testkonzept und Testfallspezifikation (siehe Abbildung).

© www.qsfibel.de

Das Testkonzept ist das Planungsdokument für die Testaktivitäten im Projekt und Informationsquelle für alle Beteiligten. Es fasst die Informationen über das Projekt zusammen und beschreibt das zu testende System. Hier steht auch stichwortartig drin, was getestet werden soll und was ggf. nicht. Auch eine erste Risikobewertung und Priorisierung von zu testenden Funktionen ist möglich. Letztendlich sollte man sich auch darüber Gedanken machen, wann man denn eigentlich aufhört zu testen (Testendekriterien).

In der Testfallspezifikation beschreibt man detailliert die auszuführenden Tests. Prinzipiell sollten alle Anforderungen durch Testfälle abgedeckt werden (Ausnahmen können nach einer Risikobewertung gemacht werden). Die im Testkonzept getroffenen Vorgaben werden bei der Testfallerstellung berücksichtigt. Das Dokument ist damit Anleitung für den Tester und gibt ihm die benötigten Informationen (z. B. Testdaten, erwartetes Ergebnis) für die Testausführung.

]]>
http://www.qsfibel.de/artikel/strukturiert-testen/feed/ 0
QS oder Testen – eine Begriffsklärung http://www.qsfibel.de/artikel/qs-oder-testen-eine-begriffsklaerung/ http://www.qsfibel.de/artikel/qs-oder-testen-eine-begriffsklaerung/#comments Fri, 01 Jul 2011 12:35:50 +0000 Alexander http://www.qsfibel.de/blog/?p=45 Die Voraussetzungen sind gegeben, dann könnten wir eigentlich loslegen mit der Qualitätssicherung… oder mit dem Testen. Mit was denn jetzt eigentlich? In meinen letzten Beiträgen bin ich etwas sorglos mit diesen Begriffen umgegangen, habe mal diesen und mal jenen benutzt. Hier jetzt mal eine Begriffsklärung, an die ich mich zukünftig halten werde.

Qualitätssicherung:

Das Projekt Magazin definiert den Begriff der Qualitätssicherung im allgemeinen Sprachgebrauch folgendermaßen:

„Qualitätssicherung ist Bestandteil des Qualitätsmanagements. Zur Qualitätssicherung gehören alle operativen Tätigkeiten, die vorbereitend, begleitend und prüfend die definierte Qualität eines Produktes oder einer Dienstleistung gewährleisten sollen.“

Übertragen auf die Webentwicklung bedeutet das, dass die geforderte Qualität auch schon in Vorbereitung oder während der Entwicklung sichergestellt werden kann. Zu den qualitätssichernden Maßnahmen zählt vor allem die Review von Dokumenten wie Anforderungsdefinition, Konzept und Systementwurf. Bereits in diesen Dokumenten können sich Fehler oder Ungenauigkeiten einschleichen, die sonst erst spät beim Testen des Systems auffallen.

Beispiele:

  • Die Anforderungen wurden falsch oder ungenau formuliert und sind daher nicht wie eigentlich vom Kunden gewünscht im Konzept beschrieben.
  • Widersprüchliche Anforderungen im Konzept werden von verschiedenen Entwicklern umgesetzt und führen zu schwer nachvollziehbaren Fehlern in der Web-Anwendung.
  • Mangelnde Abstimmung des Konzepters mit den Entwicklern führt zur Vorgabe von nicht oder nur schwer umsetzbaren Funktionen.

Oft werden beim Testen nicht nur Bugs gefunden, sondern es stellt sich auch heraus, dass Anforderungen nicht korrekt oder gar nicht umgesetzt wurden. Durch frühzeitige Prüfung von Dokumenten und Absprachen im Team kann das verhindert werden.

Testen:

Als prüfende operative Tätigkeit zählt auch das Testen zur Qualitätssicherung und ist damit ein Bestandteil der Qualitätssicherung. Unter Testen versteht man die Überprüfung eines Systems um festzustellen, ob die im Konzept definierten Anforderungen erfüllt werden. Dabei können Fehler im zu testenden System gefunden werden – jedoch kann die Abwesenheit von Fehlern nicht bewiesen werden. Dazu müssten alle Funktionen in jeder möglichen Kombination von Eingabedaten und Benutzeraktionen geprüft werden, was – außer in trivialen Systemen – praktisch unmöglich ist.

Strukturiertes Testen erfordert immer die Erstellung von Testfällen. Ein Testfall enthält alle Angaben, die für die Überprüfung einer Funktion oder Eigenschaft des Systems notwendig sind. Dazu gehören (in Kürze): Vorbedingungen, (Nutzer-)Aktion und Eingabedaten, erwartete Reaktion und Ausgabedaten des Systems.

Die am meisten angewendete Testmethode ist das Black-Box-Testing. Der Tester prüft dabei „von außen“ die definierten Anforderungen an das zu testende System. Als Grundlage für seine Testfallspezifikation verwendet er die Projektdokumentation, also z. B. das Inhaltliche Konzept. Er verfügt darüber hinaus über keinerlei Kenntnisse über den Aufbau des zu testenden Systems, sondern verwendet es nur so wie für einen normalen Benutzer vorgesehen.

White-Box-Tests werden zumeist von Entwicklern durchgeführt. Sie kennen den inneren Aufbau des Systems (also den Systementwurf, den Programmcode) und können darauf abgestimmt spezielle Tests durchführen.

Bei den angesprochenen Testverfahren wird das System beim Testen ausgeführt, daher nennt man dies dynamisches Testen. Von statischem Testen spricht man z. B. bei der Analyse von Programmcode, der sogenannten „Code-Review“.

In Literatur und bei Wikipedia findet man zahlreiche weitere Testmethoden, die hier aber nicht weiter beschrieben werden sollen.

Fazit:

Wer seine Software testet und dies Qualitätssicherung nennt, liegt damit nicht falsch. Das Finden und anschließende Beheben von Fehlern sichert die Qualität des Systems vor dem Produktivbetrieb.
Der Begriff des Testens beschreibt jedoch etwas genauer die eigentliche Tätigkeit, nämlich das Prüfen des ausgeführten Systems, was entwicklungsbegleitend oder nach Abschluss der Entwicklung passieren kann.

]]>
http://www.qsfibel.de/artikel/qs-oder-testen-eine-begriffsklaerung/feed/ 1
Qualitätssicherung: Argumente dafür und Voraussetzungen http://www.qsfibel.de/artikel/qualitaetssicherung-argumente-dafuer-und-voraussetzungen/ http://www.qsfibel.de/artikel/qualitaetssicherung-argumente-dafuer-und-voraussetzungen/#comments Mon, 27 Jun 2011 15:40:09 +0000 Alexander http://qsfibel.de/blog/?p=36 Die wahrscheinlich wichtigste Voraussetzung für die Einführung von QS-Standards in einem Unternehmen: Das Bewusstsein, dass Qualitätssicherung und Testen notwendig oder zumindest ziemlich sinnvoll sind! Wer sich da noch nicht so sicher ist, kann sich ja noch einmal meine Argumente anschauen:

  • Wer nicht oder nur sporadisch testet, findet Fehler nur zufällig und meist zu spät.
  • Spät gefundene Fehler gefährden den Go-Live-Termin – Fehlerbehebung kostet Zeit.
  • Redakteure finden Fehler erst beim Einpflegen kurz vor Go-Live, oder sogar erst im Live-Betrieb.
  • Noch ärgerlicher ist, wenn der Kunde die Fehler selbst findet.
  • Der Aufwand erhöht sich: für den Redakteur, für den PM, der das dem Kunden beibringen muss, und es gibt nachträgliche Entwicklungsaufwände fürs Bugfixing.

  • Je nach Art und Einsatz der Anwendung können Fehler auch finanzielle Ausfälle beim Kunden oder Datenverlust zur Folge haben.
  • Testing bedeutet zunächst Aufwand, aber langfristig werden sich die Gesamtkosten reduzieren.

Das alles kann man nicht erwarten, wenn man zum ersten Mal eine strukturierte Qualitätssicherung durchführen will. Mit einem eingespielten und auf die Bedürfnisse (Unternehmen, Projekt) angepassten Prozess sollten die Vorteile aber zu spüren sein.

Was braucht man noch, wenn man strukturiert testen will? Um alles unter einen Hut zu bringen, braucht man einen Verantwortlichen. In Firmen (oder Teams) in denen die Qualitätssicherung nicht in Prozessen festgelegt oder zumindest als ungeschriebene Gewohnheit vorhanden ist, sollte der Projektleiter der Verantwortliche für das Thema sein – zumindest gilt das in kleinen Teams, in denen es keinen separaten Test-Manager oder ähnliches gibt.

Damit eine strukturierte Qualitätssicherung in einem Web-Projekt stattfinden kann, muss der Projektleiter die Aufgaben zur Qualitätssicherung in der Projektplanung berücksichtigen. Das Testen sollte als reguläres Arbeitspaket (neben bspw. Konzeption und Programmierung) behandelt und auch so im Projektplan vorgesehen werden. Nur so ist gewährleistet, dass die Maßnahmen nicht aufgrund von Zeitdruck unter den Tisch fallen oder am Ende “vergessen” werden.

Die Qualitätssicherung sollte keine Geheimaktion des Projektleiters sein. Wird sie zum ersten Mal in einem Unternehmen durchgeführt, sollten alle Projektbeteiligten – Vorgesetzte natürlich auch – in das Vorhaben mit einbezogen werden. Das gemeinsame Ziel ist, am Ende eine möglichst fehlerarme Website abzuliefern und zusammen für die Qualität zu arbeiten. Es darf keine Missstimmung im Team auftreten, zum Beispiel zwischen Testern und Entwicklern, die sich auf den Schlips getreten fühlen, wenn ihre Fehler gefunden werden. Es kann hilfreich sein, sich beim Vorgesetzten ein kleines Budget für die Begleitung und Dokumentation der Einführung des einheitlichen Vorgehens zu sichern.

]]>
http://www.qsfibel.de/artikel/qualitaetssicherung-argumente-dafuer-und-voraussetzungen/feed/ 0
Qualitätssicherung in Web-Projekten http://www.qsfibel.de/artikel/qualitaetssicherung-in-web-projekten/ http://www.qsfibel.de/artikel/qualitaetssicherung-in-web-projekten/#comments Sun, 26 Jun 2011 19:25:00 +0000 Alexander http://qsfibel.de/blog/?p=21 Als Projektleiter habe ich die Erfahrung gemacht, dass die Qualitätssicherung in Web-Projekten manchmal nicht die nötige Aufmerksamkeit bekommt. Es wird hier gerne mal “drübergeschaut” oder “durchgeklickt”, um zu prüfen, ob eine Website oder Webanwendung wie gewünscht funktioniert, aber es gibt keine systematischen Tests.
Bei einfachen Websites oder in Routineprojekten kann das funktionieren wenn der Tester einige Erfahrung hat und das Projekt gut kennt. In komplexen Projekten wird es aber schwierig, alle Funktionen durch Erfahrung oder Raten zu überprüfen und dort Fehler zu finden. Hier wird eine strukturierte und geplante Qualitätssicherung sinnvoll.

Wer also nicht nur auf gut Glück testen will, kann zum Beispiel die ISTQB-Leitlinien zur Unterstützung heranziehen. Das International Software Testing Qualifications Board (ISTQB) hat ein Qualifizierungsprogramm erarbeitet, in dem umfangreiche und gut strukturierte Lehrpläne für die Ausbildung zum Softwaretester angeboten werden. Hier werden sehr ausführlich sowohl das Basiswissen des Testens als auch weiterführende Management-Aufgaben vermittelt. Mit diesen Empfehlungen kann man eine umfangreiche Testplanung und -durchführung auf die Beine stellen, um große Software-Projekte zu testen. Viele Bücher beschäftigen sich mit diesen oder ähnlichen Qualitätsrichtlinien oder geben aus der Praxis abgeleitete Vorschläge für eine gute Qualitätssicherung.

© www.qsfibel.de

Der Haken ist: für Projektleiter, die nicht aus dem IT-Bereich kommen, ist diese Literatur nur schwer verständlich und vermutlich nicht ohne große Vorbereitung im Projekt umzusetzen. Viele Projektleiter in Internetagenturen oder Start-ups sind aber Quereinsteiger und in der Softwareentwicklung nicht einschlägig ausgebildet. Für die muss es eine leichter verständliche Möglichkeit geben, sich in das Thema Qualitätssicherung einzuarbeiten!

Abgesehen von den anspruchsvollen Büchern gibt es im Netz eine Vielzahl von Websites und Blogs, die sich mit dem Testen von Software befassen. Viele behandeln das Thema eher offen und schreiben über ganz verschiedene Themen, andere bieten umfangreiche Nachschlagewerke. Das klingt interessant, hilft aber nicht viel, wenn man in einer bisher unbedarften Umgebung eine Qualitätssicherung überhaupt erst etablieren will. In den meisten Artikeln habe ich die Sicht des Projektleiters vermisst, der das große Ganze im Auge behält und die Umgebungsvariablen eines Unternehmens berücksichtigt.

Mit diesem Blog will ich Abhilfe schaffen. Ich greife die ISTQB-Ansätze auf und passe sie an auf die Gegebenheiten in kleineren Projekten, beispielsweise Web-Projekten. Das Vorgehen muss möglichst flexibel bleiben, um auch in verschiedenartigen Projekten wiederverwendet werden zu können.
Der Projektleiter der sich entscheidet, mir zu folgen, kann damit “learning-by-doing” im Projekt ein einheitliches Vorgehen entwickeln und direkt zur Anwendung bringen. Der Aufwand ist initial zwar höher, ermöglicht dann aber, das Vorgehen bei zukünftigen Projekten ohne große Vorbereitung wieder aus der Tasche zu ziehen!

Mein Vorgehen werde ich in diesem Blog dokumentieren und auch mit Erfahrungen aus der Praxis anfüttern. Damit soll dieses Blog eine Hilfestellung für Projektleiter im Online-Bereich, in Start-ups oder für (selbstständige) Softwareentwickler sein.

]]>
http://www.qsfibel.de/artikel/qualitaetssicherung-in-web-projekten/feed/ 0