Kritische Testfälle im Softwaretest - Beispiel Login

Immer wieder liest man von Fällen, dass der E-Mail Zugang oder auch andere Login-Mechanismen nicht korrekt funktionieren. Dies sind extrem kritische Fälle. Wenn eine Übersicht oder eine Auswertung nicht korrekt angezeigt wird, so ist das für den Anwender sehr unschön (manchmal auch kritisch), aber der Zugang zu einem Cloud-Dienst ist ein sehr wichtiger Testfall. Nachfolgend ein paar Beispiele, in denen die Softwaretests nicht ausreichend waren:

1. Dropbox (Cloud-Dienst zur Ablage von Dateien/Dokumenten) akzeptierte vier Stunden lang beliebige PasswörterHeise Online Artikel (21.06.2011)
2. Amazon erlaubt das Login bei älteren Accounts mit fehlerhaften Passworten
   Blog-Artikel auf Netzgezwitscher (27.01.2011)
3. Facebook erlaubt die Veränderung der Passworte von Hotmail-Usern
   Blog-Artikel auf Datenschutzberatung.org (21.04.2011)
4. Im Fantasy-MMO Rift gab es eine Sicherheitslücke im Login
   Blog-Artikel auf buffed.de (Spieleportal)

Allen diesen Fällen ist gemeinsam, dass dies nicht in der ersten Version der Software aufgetreten ist. In diesem Fall waren die Tests wohl ausreichend. Immer sind die Fehler aufgetreten, nachdem Änderungen oder Erweiterungen an der Software durchgeführt wurden. Das lässt folgende Rückschlüsse zu:

1. Kein ausreichendes Testfallmanagement
   Es müsste klar sein, welche Testfälle nach Änderung der Software auszuführend sind
2. Keine Traceability
   Durch die Organisation der Anforderungen an die Software, müsste der Bezug zwischen Anforderung und den auszuführenden Testfällen vorhanden sein.
3. Kein risikobasiertes Testen
   Wenn bewertet wird, welche Tests nach Änderung durchzuführen sind, komme ich wegen des hohen Risikos des Login-Zugangs darauf, dort Tests durchzuführen

Dies zeigt, dass Schwächen im Testmanagement vorhanden sind. Solch kritische Probleme führen auch dazu, dass die Kunden überdenken, ob sie diesen Anbietern weiterhin ihr Vertrauen schenken. Ob man unternehmenskritische Daten bei so einem Dienst ablegt - wohl eher nicht. Und ob andere aus diesen Fällen lernen... Ich bin gespannt auf den nächsten Fall...

Überblick über CMMI 1.3

Unternehmen, die Software entwickeln, führen nicht nur umfangreiche Maßnahmen zum Softwaretest an sich durch, sondern versuchen die Prozesse der Softwareentwicklung zu optimieren. Zur Überprüfung der Vorgehensweise in der Entwicklung gibt es Reifegradmodelle wie CMMI oder SPICE, die beschreiben, welche Schritte/Aktivitäten im Entwicklungsprozess durchgeführt werden sollen. Im Jahr 2010 wurde die Version 1.3 von CMMI veröffentlicht. Diese enthält einige Veränderungen gegenüber der Version 1.2. Die nachfolgende Grafik stellt die fünf Level von CMMI dar und zeigt auf, in welchen Prozessgebieten Aktivitäten anfallen, damit ein bestimmter Level erfüllt wird.



CMMI 1.3 for Development

Wie die Tätigkeiten im einzelnen aussehen und welche Tools zur Erfüllung der Aufgaben eingesetzt werden können, lässt das Reifegradmodell offen. Dies muss die Organisation selber festlegen.

Informationen im Web zum Softwaretest

Gute Zeiten für Menschen, die sich mit dem Thema Softwaretest beschäftigen. Immer mehr Webseiten beschäftigen sich auf professionelle Weise mit dem Softwaretest, dem Testmanagement und Verfahren der Qualitätssicherung. Einige Links habe ich im Blog in einer Linklist aufgenommen. Die wachsende Vielfalt spiegelt auch eine immer stärker werdende Professionalisierung der Disziplin Softwaretest wieder.


Es gibt auch ein paar Zeitschriften, die regelmäßig publiziert werden. Teilweise ist die Online-Version (PDF) sogar kostenlos.

• Testing Experience
  (sehr umfangreiche englischsprachige Zeitschrift, die zweimonatlich erscheint - Online kostenlos)
• Professional Tester
  (englischsprachige Zeitschrift, die zweimonatlich erscheint - Online kostenlos)
• SQ-Magazin vom ASQF
  (erscheint zweimonatlich in deutscher Sprache - zwei Exemplare kann man zur Probe bestellen)
• Testing Circus [Update]
  (englischsprachige Zeitschrift, die monatlich online erscheint)
• Online Magazin Software Testing Magazin [Update Juli 2012] 
  http://www.softwaretestingmagazine.com

Viel Spaß bei der Lektüre der vielen interessanten Artikel...

Wer noch interessante Links zum Thema kennt, die nehme ich gerne in die Linklist auf...

iqnite11 - Mein Fazit

Ich war dieses Jahr das erste Mal auf der iqnite (Link). Die Vielfalt des Vortrags-Angebotes war wirklich prima. Wir waren zu dritt auf der Konferenz, aber fast immer auf verschiedene Tracks verteilt. Es gab wenig Enttäuschungen und daher nach jeder Session viel zu diskutieren. Durch die vielen Vorträge zogen sich aus meiner Sicht folgende zwei Grundsätze:

• Der Kunde steht im Fokus - Konzentration auf seine Bedürfnisse ist angesagt
• Software nicht vergolden - die Business Prozesse der Kunden im Auge behalten

Persönlich fand ich den Track Testmanagement trifft Risikomanagement (Blog-Beitrag) sehr gut. Auch in den anderen Vorträgen/Tracks gab es gute Anregungen, die es nun gilt in die tägliche Arbeit zu übernehmen.

Zu der gelungenen Veranstaltung hat auch die Organisation der Konferenz viel beigetragen. Die Räumlichkeiten waren gut geeignet. Aussteller, Vortragsräume und der große Raum für die Keynotes waren dicht zusammen, was sehr angenehm war. Die Verpflegung und das Social Event, mit vielen Gesprächsmöglichkeiten, waren ebenfalls ausgezeichnet. Auch die Versuche die Teilnehmer stärker einzubinden, SMS-Voting und Open Space (Blog-Beitrag), konnten gefallen. 

Absolute Highlights waren die Keynotes. Allen Referenten ist es gelungen, interessante Ideen zu präsentieren und neue Perspektiven zu vermitteln. Allein die Keynote zur Visualisierung der statischen Projektinformationen (Blog-Beitrag) hätte den Besuch gelohnt.


Das Niveau der Veranstaltung war gut, so dass ich sicher nicht das letzte Mal auf der iqnite gewesen bin...

iqnite11 - Testmanagement trifft Risikomanagement

Einen hervorragenden Vortrag hielten die beiden Autoren Bernd Schindelasch und Claudia Gelhaus von der Telefongesellschaft EWE TEL GmbH. Beide stellten den Ansatz ihres Unternehmens zur Einführung eines Risikomanagements zur Steuerung von Produkt- und Projektrisiken vor.

Zu jedem Release wird ein QS-Plan erstellt, in dem alle Produkt- und Projektrisiken aufgeführt werden. Dazu wird neben FMEAs auch eine Risikomatrix genutzt, mit der alle Testfälle (strikte Ableitung aus den Anforderungen) bewertet werden. Nachfolgend sind einige Punkte (nicht vollständig) der Matrix

aufgezeigt:

1. Kritikalität des Geschäftsfalls
   (Auswirkung auf den Geschäftsprozess, betroffene Kunden, Anpassungshäufigkeit)
2. Fehler - Eintrittswahrscheinlichkeit
   (Veränderung des Geschäftsprozesses, Qualität der Konzepte, Häufigkeit Fehler in der Vergangenheit)
3. Komplexität der Anforderung
   (Bewertung anhand der Eingabedaten, Schnittstellen, des Prozesses)

Über die Matrix werden alle Testfälle bewertet, und eine Priorität für die Durchführung der Testfälle festgelegt. Dazu wird ein Werkzeug verwendet, mit dem alle Aufgaben des risikobasierten Testen durchgeführt werden. So hat der Testmanager jederzeit den Überblick über die Prioritäten, die Testdurchführung, den Testfortschritt und die Testergebnisse. Mit diesem Wissen können gute Entscheidungen ("data beats opinion") über den Auslieferungszeitpunkt, auch aufgrund der Testaufwandsplanung die mit dem Werkzeug durchgeführt wird, getroffen werden.

Zur Weiterentwicklung der Vorgehensweise werden TPI Assessments durchgeführt. Insgesamt ein sehr interessanter und schon reif wirkender Ansatz, den Test (und damit auch das Projekt) über ein Risikomanagement zu steuern.