Testmanagement und Softwaretest

Der Softwaresteht besteht aus mehreren Phasen. Ein definierter effizienter Testprozess verbessert die Abläufe und erhöht die Softwarequalität.Der idealtypische Testprozess kann wie in Abb. 1.1 dargestellt werden.Das Testmanagement erstreckt sich von der Testplanung über die Erstellung der Testspezifikation und Durchführung der Tests bis hin zur Protokollierung der Testergebnisse und der Auswertung der Tests.Das Testmanagement organisiert, koordiniert und überwacht die entsprechenden Aktivitäten durch: Incident Management: organisatorischer und technischer Prozess der Reaktion auf erkannte oder vermutete Störungen in IT‐Bereichen sowie hierzu vorbereitende Maßnahmen und Abläufe.Problem Management: ermitteln, bewerten und Korrektur aufgetretener Fehler.Change Management: Bearbeitung zusätzlicher oder geänderter Anforderungen während des Projektablaufs.Release Management: Planung und Konfiguration der einzelnen Software Releases.Ein definierter Testprozess dient dazu, die einzelnen Testaktivitäten voneinander abzugrenzen, Ablaufpläne zu verfeinern und inhaltliche und zeitliche Abhängigkeiten der einzelnen Testaktivitäten aufzuzeigen.Der weltweit verbreitete ISTQB‐Testprozess unterscheidet folgende Aktivitäten: Planung und Steuerung,Analyse und Design,Realisierung und Durchführung,Auswertung und Bericht,Abschluss.Die einzelnen Aktivitäten des Testprozesses sind nicht strikt nacheinander abzuarbeiten, eine zeitliche Überlappung wird sich in der Praxis weder vermeiden lassen noch ist sie unbedingt erforderlich.

Es gibt einige generelle Leitlinien für Softwaretester, eine Testphilosophie die allen Softwaretest‐Aktivitäten zugrunde liegt und als gemeinsame Richtschnur in jedem Testprojekt, ob groß oder klein, vorhanden sein sollte. Diese Grundsätze verhelfen zu einem gemeinsamen Verständnis und einer richtigen Einordnung der Testaktivitäten.

Normen bringen einen hohen betriebs‐ und volkswirtschaftlichen Nutzen, da sie gemeinsame Standards schaffen und damit eine Voraussetzung bilden für den erfolgreichen Wettbewerb unterschiedlicher Unternehmen. Normen leisten einen wichtigen Beitrag zur Deregulierung, indem sie den Staat von technischen Detailregelungen entlasten. Auf der Grundlage der Normen der IEEE und ISO arbeitet das ISTQB an der Standardisierung von Systemtests. Ziel ist die Standardisierung und Vergleichbarkeit von Testprozessen. Der erste Standard für Software‐Systemtests war der „IEEE‐Standard 829 – Test Documentation“. Dieser Standard wurde 1983 eingeführt und in den Jahren 1987 und 2008 überarbeitet. Die Norm mit dem Titel „Standard for Software and System Test Documentation“ beschreibt den Systemtestprozess und der Testdokumentation. Als Systeme werden dabei nicht nur die Software, sondern auch darunterliegende Hardware‐Plattformen verstanden.Ein voll ausgebauter Testprozess besteht im Sinne des ANSI/IEEE Standard 829 aus folgenden Teilprozessen: Testplanung,Testfallspezifikation,Testentwurf (Design der Testabläufe),Testdatenerstellung (Ist und Soll),Testausführung,Testauswertung,Testabnahme.Allerdings ist es nur selten möglich und sinnvoll, den gleichen Testprozess für mehrere Projektarten zu verwenden. Dafür sind die einzelnen Aufgabenstellungen zu unterschiedlich. Jedes Projekt erfordert eine eigene Ausprägung des Prozesses. Das Tailoring der Testprozessmodelle gehört zu den wesentlichen Aufgaben eines Testmanagers.

In einem Testprojekt sind für bestimmte Aktivitäten definierte Rollen festgelegt. Von Projekt zu Projekt sind diese Rollen abhängig von den verfügbaren Mitarbeitern jeweils neu festzulegen. Es sind dabei auch Mischformen möglich oder die Vereinigung mehrerer Rollen in einer Person, aber genauso gut die Aufteilung der Verantwortlichkeiten einer Rolle auf mehrere Mitarbeiter.

Für die Aktivitäten zum Softwaretest müssen im Unternehmen konkrete Abläufe und Arbeiten organisiert werden. Dafür ist ein definiertes Testmanagement verantwortlich. Ob das Testmanagement von einem Testkoordinator oder einem eigenen Testmanager durchgeführt wird, ist letztlich nachrangig, entscheidend ist, dass überhaupt ein Testmanagement vorhanden ist. Diese Erkenntnis hat sich in den letzten Jahren mehr und mehr in den Unternehmen durchgesetzt, ganz selbstverständlich ist es aber noch nicht.Mehr als jeder zweite Softwarefehler, der nach einer Änderung entdeckt wird, entsteht durch Mängel im Testmanagement. Das ergab eine aktuelle Studie von „Steria Mummert Consulting“. Daran erkennt man das gewaltige Potential, das in einer Verbesserung des Testmanagements liegt.Oftmals mangelt es an einem systematischer Vorgehenskatalog für das Testen von Software. Der Testfallkatalog ist nicht oder nur teilweise vorhanden. Immer noch entscheiden viele Verantwortliche erst am Projektende, welche Funktionen der Software überprüft werden sollen und führen lediglich unsystematische Stichprobentests durch. Häufig fallen Tests auch dem Termindruck oder dem Rotstift zum Opfer. IT‐Firmen folgen dem Wunsch ihrer Kunden und unterbieten sich gegenseitig mit immer kürzeren Release‐Zyklen. Gleichzeitig stellen enger getaktete Umsetzungsfristen bei Gesetzesanpassungen die IT‐Abteilungen auf die Probe.

Von den Hochschulen Bremen und Bremerhaven, die Fachhochschule Köln, die ANECON Software Design und Beratung GmbH, das German Testing Board (GTB) und das Swiss Testing Board (STB) wurde im Jahre 2012 eine anonyme Online‐Umfrage zum Thema „Softwaretest in der Praxis“ (Abb. 6.1) im deutschsprachigen Raum durchgeführt. Der Befragung lagen drei rollenspezifische Fragebögen zugrunde. Ihr Ziel war einerseits die Ermittlung des aktuellen Stands der Qualitäts‐ und Testaktivitäten in der Praxis, andererseits sollte der Handlungsbedarf für Forschung, Ausbildung und Beratung im Testen analysiert werden.Die Umfrage hatte regen Zuspruch, was die Aktualität und Wichtigkeit der Softwarequalitätssicherung unterstreicht. Die Teilnehmer zeichnen sich durch eine gute Ausbildung und langjährige Berufserfahrung aus. Unterschiedliche Rollen (Tester, Entwickler und Manager) wurden in der Umfrage zu unterschiedlichen Schwerpunkten befragt, die Antworten lassen dadurch rollenspezifische Sichtweisen zu.Schon zum Zeitpunkt der Umfrage gab es einen nennenswerten Zuspruch zum agilen Vorgehensmodell. Man kann davon ausgehen, dass dieser Ansatz inzwischen noch wesentlich stärkere Verbreitung in der Praxis gefunden hat.Im Rahmen dieses Interviews wurden die Teilnehmer u. a. nach ihrer Einschätzung bezüglich der Effektivität ihrer Qualitätsmaßnahmen befragt. Sie sollten angeben, wie viele schwerwiegende Fehler nach Auslieferung der Software beim Kunden auftreten. Abbildung 6.2 zeigt die Unterschiede zwischen den Vorgehensweisen.

Bevor man mit der Testdurchführung starten kann, sind strategische Überlegungen, Planungsaktivitäten und konkrete Vorbereitungsmaßnahmen erforderlich. Einige grundlegende Fakten sind unternehmensweit zu klären. Sie gelten in der Regel komplett oder zumindest teilweise für alle beteiligten Projekte des Unternehmens. Auch wenn diese Aspekte nicht in jedem Projekt neu bewertet werden müssen, ist es wichtig, dass in jedem einzelnen Projekt das grundlegende Verständnis dafür vorhanden ist.

Das Requirements Engineering dient zum systematischen Management und Verfahren der Anforderungsanalyse und Anforderungsverfolgung und stellt die Grundlage erfolgreicher Softwareprojekte dar. Effiziente und fehlerarme Systeme benötigen klar beschriebene, nicht widersprüchliche und vollständige Anforderungen. Requirements Engineering umfasst die Ermittlung, Analyse, Spezifikation und Validierung der Eigenschaften und Rahmenbedingungen eines Softwaresystems, die über seinen gesamten Lebenszyklus gewünscht werden bzw. relevant sind.

Der Test eines komplexen Softwaresystems wird in mehrere Phasen (Teststufen) unterteilt. Die Einordnung der Teststufen (auch Testzyklen genannt) folgt häufig dem Entwicklungsstand des Systems. Es geht dabei darum, dass der Test einer bestimmten Funktionalität so früh wie möglich erfolgen soll. Da aber nicht jeder Test in jeder Teststufe schon möglich ist, muss man diese Teststufen eindeutig abgrenzen und prüfen, welcher Test in welchem Testzyklus sinnvoll ist.

Ein Test mit allen möglichen Eingabedaten und deren Kombination wäre grundsätzlich ein möglicher Test. Das ist aber wegen der großen Zahl von möglichen Eingabewerten und Kombinationen unrealistisch, wäre viel zu langwierig und zu teuer. Man muss also eine sinnvolle Untermenge an Testfällen definieren. Zur Auswahl der wichtigsten aus den möglichen Testfällen gibt es mehrere sinnvolle Verfahren.

Fehler gehören zum Menschsein. Fehler sind Teil der menschlichen Existenz und ein entscheidender Grund für seine enorme Entwicklung. Die Geschichte der Menschheit ist geprägt von Neugier, Wagemut und Irrtümern. Menschen machen kleine und große Fehler, bzw. Fehler mit kleinen und großen Auswirkungen. Wenn Christoph Columbus nicht den Fehler begangen hätte zu glauben, er müsse von Spanien nach Richtung Westen segeln um Indien zu erreichen, wäre Amerika nicht entdeckt worden. Von J. W. von Goethe stammt das Zitat „Wenn Du nicht irrst, kommst Du nicht zu Verstand“.Beim Test von Software werden Fehler bemerkt. Diese Fehler müssen erfasst, beschrieben, teilweise mit unterschiedlichen Projektmitarbeitern besprochen, behoben und nachgetestet werden. Für diese Tätigkeiten muss ein Prozess definiert sein. Dabei geht es darum, Fehler vollständig zu beheben und die Kosten und die Bearbeitungszeit für die Fehlerbehebung so kurz wie möglich zu gestalten. Zu einem konstruktiven Umgang mit Fehlern sollte man Fehler nicht als Versagen oder Scheitern, sondern als notwendige Investition auf dem Weg zu besseren Lösungen betrachten.

In der Testplanung werden Methoden, Strukturen und Werkzeuge für den Test definiert. Es wird definiert, welche Tools für die Testbeschreibung, die Fehlerverwaltung, die Beschreibung der Anforderungen und die Automatisierung verwendet werden. In diesem Zusammenhang muss das grundsätzliche Vorgehen beschrieben werden, wenn eine neue Software von der Entwicklung geliefert wird, also die Prozesse einschließlich der Schnittstellen zu anderen Abteilungen, das Testreporting, die Einbeziehung der Stakeholder und der zeitliche Rahmenplan.Teilweise (vor allem bei Industriefirmen) müssen parallel mechanische oder elektronische Hardwarekomponenten entwickelt und getestet werden, die teilweise Voraussetzung für bestimmte Testschritte sind. Es ist wichtig, dass diese Testphasen mit den Testphasen des Softwaretests korrespondieren. Verzögerungen bei der Hardwareentwicklung haben schon so manche Anwendung um Monate zurückgeworfen.

Das Thema „Testumgebung“ wird in IT‐Projekten häufig unterschätzt. Zwar heißt es dann in den meisten Testkonzepten allgemein, eine hohe Produktionsnähe solle erreicht werden, was das aber genau heißt, bleibt häufig unklar.

Ein Testkonzept beschreibt für ein spezifisches Projektvorhaben die vorgegebenen und zu erfüllenden Mindestanforderungen für die geplante Testvorgehensweise, die Zuständigkeiten, die Verantwortlichkeiten und Abhängigkeiten. Des Weiteren werden die Rahmenbedingungen (z. B. Testumgebung, Konfiguration des Testsystems, Testvoraussetzungen), Ziele des Testvorgehens, die zu verwendenden Testmethoden und Testverfahren sowie der Umfang der durchzuführenden Testaktivitäten festgelegt.

Betriebliche Entscheidungen hängen in den meisten Fällen von Zahlen ab. Zahlen begründen Entscheidungen oder regen sie an. Insofern ist es nachvollziehbar, dass Entscheidungsträger in Unternehmen mit einer ständig steigenden Zahlenmenge und einer permanenten Informationsflut konfrontiert werden. Moderne Informationssysteme (Big Data) ermöglichen zahlreiche Auswertungen und Zahlen. Entscheidungen, die aus Zahlen abgeleitet werden, müssen nicht immer richtig sein, wenn Zahlen nur einen Teil der Wirklichkeit abbilden. Auch Zahlen können in die Irre führen. Zahlen verleiten stärker als Worte dazu, ihnen zu vertrauen. Das ist ein Risiko beim Arbeiten mit Zahlen.Der wachsenden Zahlenmenge durch immer komplexere DV‐Anlagen und gestiegene Verarbeitungskapazitäten steht eine konstante Verarbeitungskapazität der Entscheidungsträger gegenüber. Neue Verfahren mögen die Datenmenge steigern, aber nicht in gleichem Tempo immer mehr Daten in Entscheidungen einbinden. Es gibt zwar immer mehr Metriken, aber oft werden gerade aufgrund der Informationsflut die Tragweite und die Bedeutung von Zahlen nicht richtig erkannt.

Bevor man mit der Testdurchführung loslegen kann, muss man genaue Überlegungen anstellen, was alles zu den Testvoraussetzungen gehört. Welche Hardware, also welcher Prozessor, welches Betriebssystem, welche technische Ausstattung sind zu verwenden? Welche Umgebungsvariablen sind entscheidend – das Wetter, die Tageszeit. Gibt es saisonale Schwankungen?Am besten ist es, in einem Brainstorming die Testvoraussetzungen zu sammeln und dann zu klassifizieren. Danach muss die Konfiguration des Testsystems exakt definiert werden.Alle Testergebnisse beziehen sich später auf bestimmte Laborbedingungen und können bei anderen Umgebungsvariablen vollkommen anders sein. Es empfiehlt sich, immer wieder während der Testbeschreibung und der Testdurchführung daran zu denken, das Kapitel „Testvoraussetzungen“ permanent zu prüfen, zu hinterfragen und ggf. zu überarbeiten. Manchmal wird das nämlich erst während der Testdurchführung bewusst.

Systematische Softwaretests im Rahmen der Qualitätssicherung erfordern eine strukturierte Testdokumentation. Diese Dokumentation spezifiziert die korrekte Planung, das Testvorgehen und die Umgebungsvariablen beim Softwaretest. Standardisierte Templates helfen dem Tester bei Erstellung der Spezifikation und Beschreibung der Testprozeduren.

Softwaretests werden oft als analytische Maßnahmen, die erst nach Erstellung des Prüfgegenstandes durchgeführt werden können, definiert. Diese Testmethoden werden beim Softwaretest angewendet. Einige ausgewählte Testmethoden werden in diesem Kapitel beschrieben.

Wenn die Testfälle beschrieben sind soweit es aufgrund der Spezifikationen sinnvoll möglich ist und die Software in testbarem Zustand vorhanden ist, kann mit der Durchführung der Softwaretests gestartet werden. Nun sollte man die Testanweisung exakt durchgehen und so testen, wie es in der Testanweisung beschrieben ist.Hin und wieder kommt es vor, dass die Testspezifikation noch nicht in dem Zustand ist, wie sie eigentlich vor Testbeginn sein sollte, und die Software trotzdem bereits zur Verfügung steht. Das deutet darauf hin, dass mit den vorbereitenden Testaktivitäten zu spät begonnen wurde oder zu wenige Ressourcen dafür zur Verfügung standen. In diesem Fall sollte mit dem Test gestartet werden, um den Terminverzug nicht noch fortzuführen und nicht andere Projektbeteiligte auszubremsen. Die Entwickler benötigen schließlich ein zeitnahes Feedback über die Testergebnisse. Während der Testdurchführung sind die Testspezifikationen dann nachträglich zu erstellen.Im Einzelfall ist zu klären, ob besser ein Teil des zur Verfügung stehenden Testpersonals die Testkonzeption erweitert und andere Tester die Testdurchführung starten oder ob alle Tester sobald das Testobjekt vorhanden ist mit der Testdurchführung beginnen und die Testspezifikation während der Testdurchführung überarbeiten. Das hängt von der bereits erreichten Qualität der Testspezifikation, den vorhandenen Testressourcen und der individuellen Projektsituation ab.

Der Testbericht (Testreport) fasst die Ergebnisse der Testdurchführung zusammen. Er zeigt den Handlungsbedarf auf, der zur Nachbesserung erforderlich ist und gibt Aufschluss über die durchgeführten Testmaßnahmen und die Qualität der Software.

Neueinführungen oder Wartungsprojekte können in unterschiedlichen Methoden produktiv eingeführt werden. Das hängt einerseits vom betrieblichen Risiko der betroffenen IT‐Systeme und Prozesse ab, andererseits von der technischen und fachlichen Realisierbarkeit. Ob die Produktivnahme der Anwendung sukzessive, also etwa im Rahmen von Wartungsaufträgen, oder als gebündelte Gesamteinführung in Form eines Release stattfindet, ist von der Art der Einführung abhängig, von den damit verbundenen Risiken und den zur Verfügung stehenden Ressourcen. Ein Release‐Management kann die Einführung oder die Bündelung von Wartungsaufträgen zentral priorisieren und steuern.Die in Tab. 21.1 dargestellten Möglichkeiten der Produktivnahme stehen zur Verfügung.Die Bedeutung von Wartungsmaßnahmen wird einem bewusst, wenn man den Umfang von COBOL‐Programmen, die vor allem in Banken und Versicherungen zur Verwaltung großer Dateibestände nach wie vor im Einsatz sind, betrachtet: Man geht von ca. 240 Milliarden Zeilen Programmcode aus, ein Upgrade auf eine neuere Programmiersprache würde ca. 960 Milliarden Euro kosten, ein Betrag den selbst die Finanzwirtschaft nicht ohne weiteres aufbringen kann. Die schätzungsweise 10 Milliarden Euro pro Jahr, die deutschlandweit für Pflege und Maintenance von COBOL‐Programmen erforderlich sind, nehmen sich demgegenüber ziemlich bescheiden aus.

Wichtige Entscheidungen sollten nicht allein vorbereitet und kritische Entscheidungen hinterfragt werden, um das Risiko von Fehlern oder Missbrauch im Unternehmen zu reduzieren. Das gilt auch in besonderem Maße für den Testprozess, weil der Softwaretest ja gerade Fehler minimieren und die Qualität des Endprodukts steigern soll. Deshalb ist ein Vier‐Augen‐Prinzip zu empfehlen, das sich beim Testprozess durch Reviews umsetzen lässt.

Tools für das Testmanagement bieten Mechanismen zur komfortablen Erfassung, Organisation und Steuerung der Prioritäten von Testfällen. Dadurch kann der Status der Testaktivitäten überwacht, dokumentiert und statistisch ausgewertet werden. Es wird ersichtlich, welche Testfälle durchgeführt wurden und welches Ergebnis bei welchem Testfall erwartet wurde und tatsächlich auftrat. Das Testmanagement ist auf die Unterstützung von Testtools angewiesen, um den Testfortschritt jederzeit zu messen, eine stringente Testplanung und ein klares Testreporting durchführen zu können.Testmanagementwerkzeuge sollen anforderungsbasiertes Testen unterstützen und daher Systemanforderungen (Requirements) erfassen oder aus Requirements‐Management‐Tools mit denjenigen Tests verknüpfen können. Dadurch wird ersichtlich, ob die entsprechende Anforderung erfüllt ist.

Als Testabdeckung bezeichnet man das Verhältnis an tatsächlich getroffenen Aussagen eines Tests gegenüber den theoretisch möglich treffbaren Aussagen bzw. der Menge der gewünschten treffbaren Aussagen. Die Testabdeckung dient als Gradmesser für die Qualitätssicherung und wird häufig in Metriken verwendet.Die Testabdeckung lässt sich durch eine Erhöhung der Messungen und Testfälle optimieren, sie wird in der Praxis aber durch die Kosten, die für die Testaktivitäten verbunden sind, begrenzt.Das folgende Beispiel zeigt, dass ein komplettes „Austesten“ eines Programmes so gut wie unmöglich ist: Es gibt genau x Möglichkeiten ein Programm auszuführen und wenn alle x Möglichkeiten im Test getestet werden, ist das Programm komplett ausgetestet.Angenommen, eine Prozedur erwartet 2 Integer‐Werte als Eingabedaten.Bei 32 Bit Länge ergeben sich bereits 232 × 232 Kombinationen von Eingabewerten (ungefähr 1,8 × 1019).Selbst wenn ein automatischer Testtreiber in 1 ms einen Testfall ausführen kann, dauert der vollständige Test aller Eingabewerte ca. 570 Millionen Jahre!

Man muss in jedem Projekt immer genügend Zeit dazu vorsehen, um das Wesentliche übersichtlich und vergleichbar in Reports darzustellen. Das betrifft auch die Präsentation der Ergebnisse der Testaktivitäten.Für ein klares Testreporting empfiehlt sich der Einsatz von Testmetriken. Beim Reporting sind alle Mitarbeiter nach ihren Ergebnissen zu befragen. Metriken helfen dabei, Vergleichbarkeit herzustellen: Wer ist für welchen Test verantwortlich?Was wurde getestet?Welche Aufgaben wurden erledigt?Wo liegen die größten Probleme?Stockt der Softwaretest gerade und warum?Metriken sind gängige Instrumente, die mittels Kennzahlen versuchen, den Softwareprozess kontrollierter ablaufen zu lassen. Sie können für die Testüberwachung eingesetzt werden.Mit Metriken kann man z. B. erstellen: Prozentsatz bereits beschriebener Anforderungen,Prozentsatz bereits getesteter Testfälle,Anzahl gefundener Fehler.Es ist dabei wichtig, keine der Metriken absolut zu behandeln, sondern im Zusammenhang zu sehen.

Tests, die wiederholt ablaufen, können automatisiert werden. Das verhilft zu höherer Testabdeckung, einer verlässlichen Reproduzierbarkeit, spart Zeit und Kosten. Wenn man 1000 Kombinationen von Testfällen manuell testen will, ist man damit ein paar Wochen beschäftigt. Ein Roboter der dafür ein Skript abarbeitet, schafft das in wenigen Stunden.Sich wiederholende, stupide Testtätigkeiten lässt man sicherer und günstiger mit einem automatisierten Skript ablaufen und setzt den Faktor Mensch gezielt dort ein, wo er einen wesentlichen Beitrag liefern kann und jedem Testroboter überlegen ist: beim kreativen Design auf Basis bereits ausgeführter Testfälle, beim explorativen Testen, bei der Ermittlung zusätzlicher Testabdeckung.Die Automatisierung betrifft dabei in der Regel die Testdurchführung. In Einzelfällen können auch die Erstellung der Testfälle und das Testreporting automatisiert ablaufen, eine abschließende Interpretation und Bewertung der Ergebnisse wird aber immer der Testexperte durchführen müssen.Der Aufwand für Qualitätssicherung steigt mit der Komplexität der Anwendung. Manchmal ist es rein zeitlich gar nicht anders möglich, um zahlreiche Kombinationen abzutesten als mit einer effizienten Automatisierung, den nötigen Qualitätsbedarf zu erreichen.

Der Begriff Offshoring bezeichnet eine Form der Verlagerung unternehmerischer Funktionen und Prozesse ins Ausland. Auslöser für eine Offshoring‐Entscheidung sind in der Regel die im Ausland günstigeren Rahmenbedingungen. Da die IT‐Industrie bereits in den 90er Jahren Entwicklungsdienstleistungen ins Ausland verlagerte, folgte dem auch bald der Softwaretest. Das betraf anfangs vor allem Indien und osteuropäische Länder (Nearshoring).Beim Offshoring stand oft der Gedanke der Kosteneinsparung im Vordergrund: Wenn die Personalkosten in Indien oder Osteuropa geringer sind, dann kann man Kosten einsparen, wird schneller fertig oder kann die Testabdeckung erhöhen, gerade bei hohem manuellen Aufwand. Soweit die Theorie.

Für den Test von Internet‐Anwendungen gilt grundsätzlich dasselbe wie für den Test von Software‐Applikationen. Der wesentliche Unterschied ist, dass im Internet fehlerhafte Qualität viel schneller einer erheblich größeren Gruppe von Nutzern auffällt.Damit eine Web‐Applikation erfolgreich ist, sollte sie spätestens in drei bis sechs Monaten online gehen können. Das bedeutet, dass das Testprojekt hier wesentlich dynamischer arbeiten muss als bei einem typischen Software‐Entwicklungsprojekt. Beim Test von komplexen Anlagen in Maschinenbau oder bei Komponenten für die Automobilindustrie sind durchaus Testprojekte in der Dauer zwischen einem und zwei Jahren die Regel.Agile Ansätze empfehlen sich daher besonders für den Test von Internet‐Applikationen. Das Arbeiten nach dem V‐Modell ist für einen typischen Webtest zu starr und zu komplex.

Nachdem anfangs nur Daten, später auch Anwendungen auf Server in der Cloud verlagert wurden, werden inzwischen mehr und mehr menschliche Arbeiten in die Cloud erledigt. Genauso wenig, wie man als Unternehmen wissen muss, wo Daten abgespeichert sind, muss man wissen, welche Personen letztlich eine Arbeit erledigen. Entscheidend ist nur, dass sie „irgendwer“ erledigt und das Unternehmen möglichst wenig mit diesen virtuellen Mitarbeitern zu tun hat – solange die vorgegebenen Qualitätsstandards eingehalten und die geforderten Aufgaben erfüllt werden. Diese Verlagerung in die Cloud begann mit Entwicklungsdienstleistungen und hat inzwischen auch den Softwaretest erreicht.Die Industrialisierung von Testprozessen bedeutet also nicht unbedingt Testautomatisierung. Bei Last‐ oder Performancetests, bei denen gewisses Zugriffsverhalten simuliert wird und dadurch ein gewisses Lastverhalten synthetisch erzeugt wird, lässt sich die Cloud zur Testautomatisierung verwenden.Beim Test grafischer Benutzeroberflächen oder komplexer vernetzter Softwaresysteme, deren Test ein hohes Systemverständnis oder fachliche Hintergründe voraussetzt, sind die Einsatzmöglichkeiten für Cloud‐Lösungen eher begrenzt. Anders sieht es beim Test mobiler Apps oder intuitiv zu nutzenden Internet‐Anwendungen aus.

Smartphones und Tablets haben inzwischen viele Lebensbereiche erobert. Mobile IT‐Systeme bieten neue Anwendungsbereiche und gestatten von der einfachen App bis zur komplexen Shopping‐Lösung neue Möglichkeiten und mehr Flexibilität für den Nutzer. Mobile Anwendungen bedeuten neue Anforderungen für das Testmanagement.

Unter agilem Testen versteht man das Testen von Software im Rahmen eines agilen Entwicklungsprojekts. Daher muss sich der Test in einem agilen Entwicklungsprojekt auf die Unterstützung des Entwicklungsteams konzentrieren. Viele Eigenschaften von agilen Testern helfen dabei auch einem traditionellen Tester.