Letzte Woche habe ich mit einem meiner Kollegen über einen Tester in seinem Team gesprochen. Er erzählte mir, dass der Tester sich langweilte, weil er nichts zu tun hatte. Alle Entwickler schrieben und führten ihre Tests selbst aus. Das macht Sinn, denn der Tester 2.0 versucht, das Team testinfiziert zu machen.
Was passiert also, wenn jeder Entwickler im Team den Testivus hat? Sind Sie im Continuous Delivery-Zug noch relevant?
Nehmen Sie an der Diskussion in der Open Kitchen Test Automation teil : Sind Sie noch relevant?
Tester 1.0
Erinnern Sie sich noch an die Zeiten, als Softwaretester zu Rate gezogen wurden, nachdem alles gebaut und zum Testen freigegeben worden war. Testen war eine große, fette QA-Phase, die ein Projekt für sich war. Die QA-Abteilung bestand aus Testmanagern, die zunächst die Anforderungen analysierten. Es wurden logische Testfälle erstellt und den Testausführenden unterstellt, die physische Testfälle erstellten und sie manuell ausführten. Die Tester entdeckten widersprüchliche Anforderungen und schwerwiegende Probleme in den technischen Implementierungen. Was natürlich gut ist. Sie wollen keine minderwertige Software liefern. Richtig?
Also verzögerten sich die Produktveröffentlichungen und die QA-Abteilung dokumentierte alles in einem dicken, fetten Testbericht. Und wir alle wussten es: Nach der nächsten Veröffentlichung musste die QA-Abteilung alles noch einmal machen.
Ich erinnere mich daran, dass ich zu dieser Zeit Testerin war. Ich habe mich immer gefragt: Warum bin ich immer der Letzte, der darüber nachdenkt, wie man das System brechen kann? Weiß der Entwickler, wie leicht diese Funktion gebrochen werden kann? Weiß der Produktmanager, dass diese Anforderung überhaupt keinen Sinn macht?
Alle hassten unsere QA-Abteilung. Wir wurden als langsam dargestellt, weil wir immer schlechte Nachrichten lieferten und den Lieferzyklus verzögerten. Aber das Problem war nicht die Übermittlung der schlechten Nachrichten. Es lag am Timing.
Die Arbeitsweise musste geändert werden.
Tester 2.0
Wir haben mit der Ausbildung von Testern begonnen, um agilen Teams dabei zu helfen, während der Entwicklung qualitativ hochwertige Software zu liefern: Die Geburt des Testers 2.0 - Der Agile Tester.
Diese Tester beherrschen das Agile Manifest, die Prozesse und Methoden, die damit einhergehen. Zusammenarbeit in Sachen Qualität ist hier der Schlüssel. Agiles Testen ist eine Denkweise. Und jeder ist für die Qualität des Produkts verantwortlich. Die Tester 2.0 haben den Teams geholfen, (mehr) Testinfizierte zu bekommen. Sie dachten wie ein Forscher, anstatt wie ein Qualitätssicherer. Sie wurden Teil der Softwareentwicklungs- und -lieferungsteams und suchten nach Möglichkeiten, die Testarbeit zu beschleunigen. So praktizierten sie verschiedene explorative Testtechniken. Sie konzentrierten sich auf sinnvolle und erforderliche Tests angesichts der Beschränkungen eines Sprints.
Wenn wir auf verschiedene agile Teams zurückblicken, die ein gemeinsames Verständnis von agilem Testen hatten, sahen wir, dass viele multidisziplinäre Teams zu zwei getrennten Teams wurden: Eines für Entwickler und das andere für QA/Tester.
Ich persönlich habe mich in diesen Teams nie wohl gefühlt. Tester in eine Gruppe von Entwicklern zu stecken, ist kein agiles Testen. Die Entwickler überließen das Testen immer noch den Testern, und die Tester warteten passiv darauf, dass die Entwickler etwas zum Testen bereitstellten. Irgendwann wurden die Tester wieder zum Engpass und man investierte in die Testautomatisierung. So wurden Tester zu Testautomatisierern und erstellten ihren eigenen Testcode in einer vom Entwicklungscode getrennten Codebasis. Die Testautomatisierer wählten außerdem Tools, die die Verantwortung des Teams nicht förderten. Daher wurde die Testautomatisierung vollständig von der Produktentwicklung getrennt. Wir fanden Wege, um Testern, Testautomaten und Entwicklern die Zusammenarbeit zu erleichtern, indem wir den Prozess verbesserten. Aber damit wurde nur das Symptom des Problems behandelt. Die Entwickler übernahmen keine Verantwortung für die automatisierten Tests. Und die Tester halfen den Entwicklern nicht dabei, testbare Software zu entwerfen.
Wir möchten, dass Testautomatisierer und Entwickler zu denselben Personen werden.
Tester 3.0
Wenn Sie Ihr Geschäft beschleunigen wollen, müssen Sie iterativ vorgehen und so schnell wie möglich einen Mehrwert für die Produktion liefern, indem Sie Continuous Delivery richtig umsetzen. Wir brauchen also multidisziplinäre Teams, um die Feedback-Schleifen zu verkürzen, die aus verschiedenen Blickwinkeln kommen.
Tester 3.0 sind daher gefordert, das Geschäft zu beschleunigen, indem sie in den folgenden Bereichen arbeiten:
Anforderungsprüfung: Das Richtige bauen
Der Tester 3.0 versucht, das geschäftliche Problem der Anforderungen durch die Beschreibung von Beispielen zu verstehen. Es ist wichtig, ein gemeinsames Verständnis zwischen dem geschäftlichen und dem technischen Kontext zu erreichen. Der Tester prüft sie also so schnell wie möglich und verwendet sie als Input für die Testautomatisierung und setzt BDD als Technik ein, bei der eine menschenlesbare Sprache gefördert wird. Diese Tester arbeiten so schnell wie möglich an automatisierten Akzeptanztests.
Testautomatisierung: Förderung des Softwareentwicklungsprozesses
Wenn ein gemeinsames Verständnis erreicht ist und das Entwicklungsteam bereit ist, die gewünschte Funktion zu implementieren, benötigt der Tester Programmierkenntnisse, um die Akzeptanztests in einem sauberen Codezustand durchzuführen. Der Tester 3.0 verwendet geeignete Acceptance Test Driven Development Tools (wie Cucumber), die vom gesamten Team unterstützt werden. Aber der Tester hält Ausschau nach besseren, schnelleren und einfacheren Frameworks für automatisierte Tests, um das Team zu unterstützen.
Auf dem Xebia Craftsmanship Seminar (vor ein paar Monaten) fragte mich jemand, ob Tester lernen sollten, wie man Code schreibt.
Ich sagte ihm, dass niemand in allem gut ist. Aber der Tester 3.0 hat gute Testfähigkeiten und genug technisches Rüstzeug, um automatisierte Akzeptanztests zu schreiben. Continuous Delivery-Teams haben eine gemeinsame Verantwortung und automatisieren alle langweiligen Schritte wie manuelle Testskripte, Leistungs- und Sicherheitstests. Es ist sehr wichtig, dass Sie wissen, wie man automatisiert, sonst bremsen Sie das Team aus. Sie werden genauso behandelt wie jeder andere im Entwicklungsteam.
Die Tester 3.0 versuchen, die Entwickler dazu zu bringen, über sauberen Code nachzudenken und eine hohe Codequalität zu gewährleisten. Sie befassen sich mit gängigen Entwicklungsframeworks (und halten sich auf dem Laufenden) und gehen auf die Testbarkeit ein. Sogar der Testcode wird kontinuierlich auf Qualitätsmerkmale geprüft. Er braucht die gleiche Liebe und Sorgfalt wie der Code, der in die Produktion geht.
Lebendige Dokumentation: Tests als Spezifikationen behandeln
Irgendwann haben Sie eine riesige Menge an automatisierten Tests, die Ihnen sagen, dass alles in Ordnung ist. Der Tester 3.0 behandelt diese Tests als Spezifikationen und versucht, ein lebendiges Dokument zu erstellen, das für die langfristige Anforderungserfassung verwendet wird. Niemand wird sich über diese Tests beschweren, wenn sie alle grün und erfolgreich sind. Das Problem beginnt, wenn die Tests fehlschlagen und niemand weiß, warum. Tester 3.0 denken an ihre Kollegen, wenn sie eine Spezifikation oder einen Test schreiben. Sie müssen klar spezifizieren, was getestet werden soll, und zwar in einer für den Menschen verständlichen Sprache.
Sie sind es gewohnt, Anforderungen und Spezifikationen zu ändern. Und sie machen keine große Sache draus. Sie wissen, dass die Beteiligten ihre Meinung ändern können, sobald ein Produkt zum Leben erweckt wird. Der Tester sorgt also dafür, dass wichtige Entscheidungen, die bei der Prüfung und Entwicklung neuer Anforderungen getroffen werden, gespeichert und verstanden werden.
Relevante Testergebnisse: Qualität in den Prozess einbauen
Tester 3.0 konzentrieren sich darauf, extrem schnelles Feedback zu erhalten, um die Softwarequalität von Softwareprodukten jeden Tag zu bestimmen. Jede Nacht. Jede Sekunde. Tester wollen immer öfter neue funktionierende Softwarefunktionen in die Produktion einbringen. Also tun sie alles, was nötig ist, um eine qualitativ hochwertige Pipeline aufzubauen, die die Zeit für Qualitätsfeedback während der Entwicklung verkürzt.
Jeder in Ihrem Unternehmen verdient es, jederzeit Vertrauen in die Softwareauslieferungspipeline zu haben. Tester 3.0 denken darüber nach, wie sie diese Art von Feedback an das Unternehmen weitergeben. Sie bieten Möglichkeiten, diese Testergebnisse über Qualitätsattribute automatisch zu melden. Tester 3.0 bitten das Unternehmen, Qualität zu definieren. Wie können sie messen, ob sie das Richtige gebaut haben, wenn sie wissen, dass alles richtig gebaut wurde? Was müssen wir messen, wenn das Produkt in Produktion ist?
Wie Sie als Tester relevant bleiben
Was passiert also, wenn alle Ihre Teamkollegen sich voll und ganz auf qualitativ hochwertige Software mit Hilfe von Automatisierung konzentrieren?
Testen erfordert nicht, dass Sie langweilige, geskriptete Testschritte manuell anklicken, kopieren und einfügen, die Sie von vornherein nicht machen wollten. Sie wurden eingestellt, um skeptisch zu sein und sicherzustellen, dass alle Risiken berücksichtigt werden. Es ist trotzdem wichtig, dass Sie weiterhin als Forscher für Ihr Team tätig sind und Ihre Neugierde entsprechend testen.
Sie müssen nicht nur neugierig und analytisch sein und über gute Kommunikationsfähigkeiten verfügen, sondern auch lernen, wie man programmiert. Arbeiten Sie nicht härter. Arbeiten Sie intelligenter, indem Sie analysieren, wie Sie all die langweiligen Prüfungen automatisieren können, damit Sie mehr Zeit haben, andere Dinge zu entdecken, indem Sie Ihre Neugier nutzen.
Da das Testen die Softwareentwicklung vorantreibt und nicht länger als separate Phase im Entwicklungsprozess behandelt werden sollte, ist es wichtig, dass Teams die Testautomatisierung in den Mittelpunkt aller Designentscheidungen stellen. Denn wir brauchen die Testautomatisierung, um die Bereitstellung von Software durch den Aufbau von Qualitätssensoren in jedem Schritt des Prozesses zu fördern. Jeden Tag. Jede Nacht. Jede Sekunde!
Möchten Sie dieses Thema mit anderen Testers 3.0 diskutieren? Nehmen Sie an der Open Kitchen teil : Testautomatisierung und steigen Sie auf den Continuous Delivery-Zug auf!
Qxperts. Wir befähigen Unternehmen, zuverlässige und hochwertige Software zu liefern. Haben Sie Fragen? Wir sind für Sie da! www.qxperts.io
Verfasst von
Cristiana
Some bio goes here
Unsere Ideen
Weitere Blogs
Contact
Let’s discuss how we can support your journey.



