1. Testen ist das Ausführen der Software mit dem Ziel, Fehler zu finden
2. Testen kann daher nur von Personen ordentlich gemacht werden, die nicht selbst der/die Entwickler sind
3. Testen ist daher eine eigene wichtige Disziplin, gleichwertig auf der Ebene der Softwareentwicklung und bedarf eigener Methoden und Experten

Interessanterweise unterstreicht Meyers in der dritten Auflage von 2011 diese Thesen. Sie haben in den 1990er und 2000er Jahren dazu geführt, dass einem ordentlichen Entwicklungsteam ein ordentliches dediziertes Testteam gegenübergestellt wurde. Das Berufsbild des Testers hat sich entwickelt, die Zusammenarbeit zwischen Entwicklungsteam und Testteam musste unter Zuhilfenahme von Süßigkeiten immer wieder neu aufgebaut werden und weil es keine andere Möglichkeit zur Automatisierung gab, wurde alles über die Oberfläche automatisiert.

Ohne diese bewegten Zeiten wüssten wir heute nicht: „Das Konzept hat nicht funktioniert“!

• Die Zusammenarbeit zwischen Entwicklungs- und Testteam war immer schwierig
• Entweder testeten die Entwickler gar nicht mehr selbst, „das macht ja eh das Testteam“
• Oder die Entwickler fühlten sich kontrolliert/bevormundet von den „Profi“-Testern, die vom Entwickeln im Regenfall keine Ahnung hatten
• Das Testteam fungierte oft als Projektbremse: „so lange wir das nicht ‚„fertig“ getestet haben, können wir nicht ausliefern“
• Oder das Testteam erstellte Unmengen von Bugs – ohne dabei die wirklich kritischen Bugs zu finden

Diese Erfahrung mussten viele Unternehmen machen, die z. B. ihr Testing an Crowdtestingplattformen auslagerten und ihre Tester pro Bug bezahlten. Sie bekamen viele Bugs.

Wobei, es lag nicht nur am getrennten Testteam. Die ganze Softwareentwicklung hat sich in den 1990ern und 2000ern in die falsche Richtung entwickelt. Alle propagierten die industrielle Softwareentwicklung in Anlehnung an Auto-Fertigungsstraßen. Modellgetriebene Softwareentwicklung, CASE-Tools, Software-“Generatoren“, es gab unzählige Ansätze, in diese Richtung zu gehen. Das Wasserfallmodell tat sein übriges und es kam wie es kommen musste, unzählige Softwareentwicklungsprojekte scheiterten. Sie scheiterten bei der Zeit, sie scheiterten beim Scope, sie scheiterten beim Budget, aber, und das spricht nicht für Meyers Ansatz, sie scheiterten vor allem bei der Qualität.

Die agile Revolution

Die Welt der Softwareentwicklung konnte so nicht weitermachen und immer mehr alternative Methoden und Entwicklungsprozesse erblickten die Welt. Extreme Programming (XP) brachte viele neue Konzepte mit sich, wie z. B. Unit Tests, Test Driven Development, User Stories, Story Points, etc. Feature Driven Development, DSDM, Kanban, Scrum, alle diese Methoden entstanden zu dieser Zeit aus dem Fakt heraus, dass so viele Projekte scheiterten.

Was danach kam, ist Geschichte: Die agilen Methoden wurden unter dem „Agile Manifesto“ zusammengebracht und traten ihren Siegeszug bis heute an.

Was blieb dabei auf der Strecke? Sie haben es sicher erraten: die Qualität und das Testen

Ein großer Teil des Problems ist dabei die ultrakonservative und traditionelle Sicht des Softwaretestens in diversen Zertifikaten wie z. B. dem ISTQB Certified Tester Foundation Level. Z. B. die beim Foundation Level zugrunde liegenden Prozessmodelle wie z. B. der „fundamentale Testprozess“ erheben universalen Gültigkeitsanspruch unabhängig vom Entwicklungsprozess.

Die Gegenbewegung zu den traditionellen Zertifikaten waren Bücher wie „Agile Testing“ oder „More Agile Testing“ von Janette Gregory und Lisa Crispin oder auch die Certified Agile Tester Zertifizierung, die insbesondere von 2011 an den Markt dominierte.

All diese Entwicklungen zeigten die Schwächen von Meyers Konzepten auf. Das Testing wanderte wieder zurück in das agile Team und auch unser Produktportfolio entwickelte sich weiter: Mit unserem Agile Quality Coaching ^[1] helfen wir agilen Teams die gesamte Qualitätssicherung besser in ihren Entwicklungslifecycle zu integrieren und mit unseren Remote Testing Services ^[2] erweitern wir die Testingkapazitäten unseres Kunden direkt in den agilen Prozess eingebettet.

Nun, was hat das alles mit Shift Left Testing zu tun?

Shift Left Testing ist die konsequente Weiterentwicklung der agile testing Konzepte, die sich in den letzten 10 Jahren entwickelt haben.

Eine Auswahl der wichtigsten Eckpunkte des Shift Left Testings sind:

1. Mache Qualität zu einem Querschnittsmindset. Qualität betrifft jede einzelne Aktivität im gesamten Softwareentwicklungsprozess
2. Nutze Quality Gates wie Definition of Ready und Definition of Done im Prozess, um den Level der notwendigen Qualität zu fixieren und abzusichern
3. Sichere die Qualität bei der Anforderungserhebung durch bessere Kommunikation
4. Sichere die Qualität auf Ebene der Anforderungsbeschreibung durch Reviews
5. Sorge für Wartbarkeit und Lesbarkeit und damit für langfristige Werthaltigkeit des Codes bereits in der Entwicklungsumgebung durch Einsatz entsprechender Tools (Beautifier, Coding Style Guide, etc.)
6. Sichere die Qualität durch statische Code Analyse bereits in der Entwicklungsumgebung ab
7. Tracke technische Schulden, am besten toolgestützt
8. Erhebe und beobachte Codequalitätsmetriken wie Duplication, Cyclomatic Complexity oder Code Smells
9. Sichere die Qualität auf Codeebene mit Unit Tests
10. Strebe die richtigen 100% an Unittestabdeckung an
11. Nutze alle Möglichkeiten ohne UI zu testen, z. B. durch Consumer Driven Contract Tests oder API-Tests
12. Vermeide so weit wie möglich automatisierte UI-Tests und nutze sie nur für die wichtigsten End 2 End Regressionstests
13. Führe alle weiteren regressiven Qualitätssicherungsschritte automatisiert über die Continuous Integration/Delivery/Deployment Pipeline aus
14. Konzentriere manuelle Testaktivitäten auf die kreativen und wichtigen Tests
15. Nutze Session Based Testing und Timeboxing so früh wie möglich im Prozess
16. Wende die Grundsätze der Softwareentwicklung auch auf Testartefakte an (Versionierung, keine Redundanzen, Modularisierung, Klasse statt Masse, usw.)
17. Dokumentiere alle Testaktivitäten automatisiert durch Testevidenzen
18. Nutze Testmethoden wie z. B. Grenzwertanalyse, Äquivalenzklassen oder Pairwise Testfallreduktion auf allen Ebenen (was bedingt, das alle im Team diese Techniken kennen)
19. Reporte den Qualitätszustand automatisiert in Echtzeit
20. Mache alle Testaktivitäten transparent und auch für den Kunden einsehbar

Die Auswahl zeigt, Shift Left Testing führt das Testen wieder dorthin zurück, wo es einst war: zu den Anforderungen und in das Umsetzungsteam. Testing ist immer und überall und die Teammitglieder sollten dazu in der Lage sein, jederzeit in die Testrolle zu schlüpfen, genauso wie in die einer Programmiererin, des Architekten oder eines Requirement Engineers. AI wird jeden einzelnen der oben genannten Punkte in Zukunft erleichtern und unterstützen können.

Schlussfolgerung: Alles wird technisch

Shift Left Testing bildet einen Trend ab, der sich in den letzten Jahren immer mehr verstärkt hat und nun durch AI nochmals einen großen Boost bekommen hat: Testen wird immer technischer und ein guter Tester zu sein, ist ohne Entwicklungsskills nur noch im sehr eingeschränkten Umfeld des Abnahmetestens z. B. für den Fachbereich des Kunden möglich. Die Mitarbeit in einem agilen Team erfordert in jedem Fall die entsprechenden technischen Skills um den Weg des Shift Lefts mitgehen zu können. Das hat natürlich entscheidende Auswirkungen auf das Berufsbild des Softwaretesters. Die veraltete Form, die z. B. Meyers propagiert hat, wird mittelfristig keinerlei Relevanz mehr haben.

Dann ist wieder vereint, was nicht getrennt hätte werden dürfen. Doch ein großer Vorteil der temporären Trennung von Entwicklung und Test ist, dass sich Testing damit trotzdem stark weiterentwickelt hat und das neue gemeinsame Ganze „Shift Left“ ist damit deutlich stärker, als es die Softwareentwicklung 1979 je hätte sein können. 

Quellen und weiterführende Informationen

Meyers 1979, 2004, 2011
https://malenezi.github.io/malenezi/SE401/Books/114-the-art-of-software-testing-3-edition.pdf

https://agilemanifesto.org/

^[1]Agile Quality Coaching: https://www.seqis.com/de/leistungen/methodology-tools

^[2]Remote Testing Services: https://www.seqis.com/de/leistungen/remote-testing-services