Wer ist verantwortlich für die Qualität?

Hallo, Habra!

Wir haben ein neues wichtiges Thema – die qualitativ hochwertige Entwicklung von IT-Produkten. Wir sprechen oft auf HighLoad++, darüber, wie man belastbare Dienste schnell macht, und auf der Frontend Conf – über großartige Benutzeroberflächen, die nicht ruckeln. Regelmäßig haben wir Themen über Testing und bei DevOpsConf über die Integration verschiedener Prozesse, einschließlich Testing. Was die Qualität als Ganzes betrifft und wie man wirklich umfassend daran arbeitet – darüber gibt es nichts.

Wir werden das ändern in QualityConf – wir werden die Kultur fördern, über die Qualität des Endprodukts für die Benutzer in jeder Phase der Entwicklung nachzudenken. Die Gewohnheit, sich nicht nur auf das eigene Verantwortungsbereich zu beschränken, und Qualität nicht nur mit Testern zu assoziieren.

Im Folgenden sprechen wir mit der Vorsitzenden des Programmkomitees, der Leiterin der Testing-Abteilung bei Tinkoff.Biz, der Schöpferin der russischsprachigen QA-Community Anastasia Aseeva-Nguyen über den Zustand der QA-Branche und die Mission der neuen Konferenz.

– Nastya, hallo. Erzähl bitte etwas über dich.

Anastasia: Ich leite das Testing bei der Bank und bin verantwortlich für eine sehr große Mannschaft – wir sind über 90 Personen. Wir haben eine wichtige Geschäftslinie, wir sind verantwortlich für das Ökosystem für juristische Personen.

Ich habe Mathematik und Mechanik studiert und wollte ursprünglich Programmiererin werden. Aber als ich ein interessantes Angebot bekam, habe ich mich entschieden, es als Testerin auszuprobieren. Merkwürdigerweise stellte sich heraus, dass das meine Berufung war. Jetzt sehe ich meine gesamte Arbeit genau in dieser Branche.

Ich bin ein überzeugter Verfechter der Quality Assurance-Disziplin. Mir liegt es am Herzen, welche Produkte erstellt werden, wie zur Qualität im Unternehmen, im Team und im Allgemeinen im Entwicklungsprozess steht.

Es ist mir offensichtlich, dass die Community in diesem Bereich nicht ausreichend reif ist, zumindest in Russland. Nicht immer verstehen wir, dass Qualitätssicherung nicht nur das Testen der Anwendung auf die Einhaltung der Anforderungen ist. Ich möchte diese Situation ändern.

– Du verwendest die Begriffe Quality Assurance und Testing. In den Augen der Öffentlichkeit überschneiden sich diese beiden Begriffe sehr oft. Wo liegt der Unterschied, wenn man tiefer gräbt?

Anastasia: Im Wesentlichen unterscheiden sie sich nicht. Testing ist ein Teil der Disziplin Qualitätssicherung, es ist eine unmittelbare Aktivität – die Tatsache, dass ich etwas teste. Es gibt tatsächlich sehr viele Arten des Testens, und für die verschiedenen Arten des Testens sind ganz unterschiedliche Personen verantwortlich. Aber in Russland, als die Welle von Outsourcern kam, die Tester in Unternehmen lieferten, reduzierte sich das Testen auf eine einzige Art.

In den meisten Fällen beschränkt man sich nur auf funktionales Testen: Man überprüft, ob das, was die Entwickler programmiert haben, der Spezifikation entspricht und das war's.

— Erzähle bitte, welche anderen Disziplinen der Qualitätssicherung es noch gibt? Was gehört außer dem Testen noch dazu?

Anastasia: Qualitätssicherung dreht sich in erster Linie um die Schaffung eines qualitativ hochwertigen Produkts. Das heißt, wir stellen uns die Frage, welche Qualitätsmerkmale unser Produkt haben sollte. Wenn wir das verstehen, können wir feststellen, wer diese Qualitätsmerkmale beeinflusst. Es spielt keine Rolle, ob Entwickler, Projektmanager oder Produktverantwortlicher — das ist die Person, die das Produkt, sein Backlog und seine Strategie beeinflusst.

Der Tester beginnt, seine Rolle besser zu erkennen. Er versteht, dass seine Aufgabe nicht nur darin besteht, auf Übereinstimmung mit den Anforderungen zu testen, sondern auch die Anforderungen zu testen, die Formulierungen zu hinterfragen, die vom Produktverantwortlichen kommen, alle nicht-expliziten Anforderungen und Erwartungen des Kunden aufzudecken. Wenn wir unserem Kunden neue Funktionalitäten bieten, müssen wir wirklich seine Erwartungen erfüllen und sein Problem lösen. Wenn wir an alle Qualitätsmerkmale denken, wird der Kunde zufrieden sein und verstehen, dass das Unternehmen, dessen Produkt er nutzt, tatsächlich an seinen Interessen interessiert ist und nicht nach dem Prinzip „hauptsache eine Funktion herausbringen“ arbeitet.

— Es scheint, dass das, was du gerade beschrieben hast, die Aufgabe des Produktverantwortlichen ist. Das betrifft im Grunde nicht das Testen und nicht die Qualität – das ist ganz allgemein das Produktmanagement, oder?

Anastasia: Unter anderem. Qualitätssicherung ist keine Disziplin, für die eine bestimmte Person verantwortlich ist. Aktuell gibt es einen populären Ansatz im Testen, der als Agile Testing. In seiner Definition steht ausdrücklich, dass es sich um einen teamorientierten Ansatz für das Testen handelt, der einen bestimmten Satz von Praktiken umfasst. Die Verantwortung für die Umsetzung dieses Ansatzes liegt beim gesamten Team, es ist nicht unbedingt erforderlich, dass ein Tester im Team ist. Das gesamte Team ist darauf ausgerichtet, dem Kunden einen Mehrwert zu bieten, und dass dieser Mehrwert seinen Erwartungen entspricht.

— Das bedeutet, dass die Qualität nahezu alle umliegenden Disziplinen berührt und Rahmenbedingungen für alles um uns herum setzt?

Anastasia: Richtig. Wenn wir darüber nachdenken, ein qualitativ hochwertiges Produkt zu schaffen, beginnen wir, über verschiedene Qualitätsattribute nachzudenken. Zum Beispiel, wie wir überprüfen können, dass wir wirklich eine Funktion umgesetzt haben, die unserem Kunden benötigt.

Hier kommt eine Art von Testen ins Spiel, die UAT (User Acceptance Testing) genannt wird. Leider wird dies in Russland selten praktiziert, ist aber manchmal in SCRUM-Teams als Demo für den Endkunden vorhanden. In ausländischen Unternehmen ist dies eine weit verbreitete Testform. Bevor wir die Funktionalität für alle Kunden freigeben, führen wir zuerst UAT durch, das heißt, wir laden den Endverbraucher ein, der das Testen durchführt und sofort Feedback gibt – ob das Produkt wirklich den Erwartungen entspricht und ein Problem löst. Erst danach erfolgt das Scaling für alle anderen Kunden.

Das heißt, wir orientieren uns am Geschäft, am Endkunden, aber dabei vergessen wir nicht die Technologie. Auch die Technologie hat einen großen Einfluss auf die Qualität des Produkts. Wenn wir eine schlechte Architektur haben, können wir keine Funktionen schnell veröffentlichen und den Erwartungen des Kunden entsprechen. Es kann viele Fehler geben, wenn wir versuchen zu skalieren, oder beim Versuch, Refactoring durchzuführen, können wir etwas kaputtmachen. Das alles wird sich auf die Zufriedenheit des Kunden auswirken.

Aus dieser Sicht sollte die Architektur so beschaffen sein, dass wir sauberen Code schreiben können, der es uns ermöglicht, schnell Änderungen vorzunehmen und keine Angst zu haben, dass wir alles zerbrechen. Damit die Iterationen der Überarbeitung sich nicht über mehrere Monate hinziehen, nur weil wir so viel Legacy haben und lange Testphasen erforderlich sind.

— Also sind bereits Entwickler, Architekten, Produktmanager, Product Owner, die Tester selbst, eingebunden. Wer ist noch am Prozess der Qualitätssicherung beteiligt?

Anastasia: Stellen wir uns vor, dass wir das Feature bereits an den Kunden geliefert haben. Es ist offensichtlich, dass die Qualität des Produkts überwacht werden muss, auch wenn es bereits in der Produktion eingesetzt wird. In dieser Phase können Situationen mit nicht offensichtlichen Szenarien, die sogenannten Bugs, auftreten.

Die erste Frage ist: Wie gehen wir mit diesen Bugs um, nachdem wir das Produkt bereits veröffentlicht haben? Wie reagieren wir zum Beispiel auf Lasten? Der Kunde wird nicht sehr zufrieden sein, wenn die Seite länger als 30 Sekunden lädt.

Hier kommt der Betrieb ins Spiel oder, wie man heute sagt, DevOps. Tatsächlich sind das die Personen, die für den Betrieb des Produkts verantwortlich sind, wenn es schon in der Produktion ist. Dazu gehört eine Vielzahl von Monitoring-Methoden. Es gibt sogar eine Unterkategorie des Testens – das sogenannte Testing in der Produktion, bei dem wir uns erlauben, etwas nicht bis zur Veröffentlichung zu testen und es sofort in der Produktion testen. Dies umfasst eine Reihe von Maßnahmen aus Sicht der Infrastrukturorganisation, die es ermöglichen, schnell auf einen Vorfall zu reagieren, darauf Einfluss zu nehmen und ihn zu beheben.

Die Infrastruktur ist ebenfalls wichtig. Oft gibt es Situationen, in denen es während der Tests nicht möglich ist zu überprüfen, dass wir tatsächlich alles haben, was wir dem Kunden zur Verfügung stellen wollten. Wir rollen es in der Produktion aus – und beginnen, nicht offensichtliche Situationen zu erkennen. Das liegt daran, dass die Infrastruktur im Test nicht der Infrastruktur in der Produktion entspricht. Daraus ergibt sich eine neue Art des Testens – Infrastruktur-Testing. Dazu gehören verschiedene Konfigurationen, Einstellungen, Migration von Datenbanken usw.

Daraus ergibt sich die Frage – vielleicht muss das Team Infrastruktur als Code verwenden.

Ich glaube, dass die Infrastruktur einen direkten Einfluss auf die Qualität des Produkts hat.

Ich hoffe, dass es auf der Konferenz einen Vortrag mit einem echten Fallbeispiel geben wird. Schreiben Sie uns, wenn Sie bereit sind, aus Ihrer eigenen Erfahrung zu erzählen, wie Infrastruktur als Code die Qualität beeinflusst. Infrastruktur als Code ermöglicht es, alle Einstellungen einfacher zu überprüfen und das zu testen, was andernfalls einfach unmöglich wäre. Daher wird auch der Betrieb in den Prozess der Entwicklung eines hochwertigen Produkts einbezogen.

– Und was ist mit der Analyse und Dokumentation?

Anastasia: Das bezieht sich mehr auf Enterprise-Systeme. Wenn wir über Enterprise sprechen, kommen sofort solche Personen wie Analysten und Systemanalysten in den Sinn. Manchmal werden sie auch technische Schriftsteller genannt. Sie erhalten den Auftrag, eine Spezifikation zu schreiben, und setzen diesen beispielsweise innerhalb eines Monats um.

Es wurde immer wieder nachgewiesen, dass das Schreiben solcher Dokumentationen zu sehr langen Entwicklungszyklen und ausgedehnten Überarbeitungen führt, weil im Testprozess Bugs entdeckt werden und Rückgaben anfangen. Infolgedessen gibt es sehr viele Schleifen, die die Entwicklungskosten erhöhen. Außerdem kann dies Sicherheitsanfälligkeiten einführen. Wir haben scheinbar den Referenzcode geschrieben, aber dann Änderungen vorgenommen, die die perfekt durchdachte Architektur brechen.

Das Ergebnis ist ein nicht ganz qualitativ hochwertiges Produkt, weil die Architektur bereits Patches aufweist, der Code an einigen Stellen nicht ausreichend getestet ist, weil die Fristen drängen und alle Bugs schneller behoben werden müssen. Das liegt daran, dass in der ursprünglichen Spezifikation nicht alle Aspekte berücksichtigt wurden, die implementiert werden müssen.

Entwickler sind keine Übeltäter und schreiben nicht absichtlich fehlerhaften Code.

Hätten wir die Spezifikation von Anfang an durchdacht, in der alle notwendigen Aspekte beleuchtet worden wären, dann wäre alles genau so umgesetzt worden, wie es nötig ist. Aber das ist eine Utopie.

Wahrscheinlich ist es unmöglich, eine ideale Spezifikation auf 100 Seiten zu schreiben. Deshalb müssen wir über alternative Möglichkeiten nachdenken, Dokumentation, Spezifizierung und Aufgabenstellung zu schreiben, die uns näher bringen, dass der Entwickler genau das macht, was nötig ist.

Hier fallen einem Ansätze aus Agile ein – User Stories mit Akzeptanzkriterien. Das ist eher für Teams geeignet, die in kleinen Iterationen arbeiten.

– Was ist mit Usability-Tests, der Benutzerfreundlichkeit des Produkts, dem Design?

Anastasia: Das ist ein sehr wichtiger Punkt, denn im Team gibt es Designer. Oftmals werden Designer als Service genutzt – entweder eine Designerabteilung oder ein Designer im Outsourcing. Es kommt häufig vor, dass der Designer scheinbar den Produktmanager gehört hat und das gemacht hat, was er verstanden hat. Aber wenn wir mit der Iteration beginnen, stellt sich heraus, dass tatsächlich nicht das gemacht wurde, was erwartet wurde: Der Designer hat etwas vergessen, das Verhalten nicht bis ins Detail durchdacht, weil er nicht im Team und nicht im Kontext ist, oder der Frontend-Entwickler hat sein Layout nicht ganz verstanden. Möglicherweise sind mehrere Iterationen notwendig, nur weil es ein Problem mit dem Verständnis des Designs durch den Frontend-Entwickler gibt.

Außerdem gibt es ein weiteres Problem. Derzeit gewinnen Designsysteme an Popularität. Sie sind im Trend, aber ihr Nutzen ist nicht ganz offensichtlich.

Ich stoße auf die Meinung, dass Designs, einerseits, die Entwicklung vereinfachen, andererseits aber auch sehr viele Einschränkungen für die Schnittstelle auferlegen.

Letztendlich entwickeln wir nicht die Funktion, die der Kunde möchte, sondern die, die uns bequem ist, weil wir bestimmte Bausteine bereits haben, aus denen wir sie erstellen können.

Ich denke, dass es sich lohnt, auf dieses Thema zu achten und darüber nachzudenken, ob wir wirklich die Kundenprobleme lösen, wenn wir versuchen, die Arbeit am Design zu vereinfachen.

— Es gibt erstaunlich viele Themen, die mit Qualitätssicherung verbunden sind. Gibt es in Russland eine Konferenz, bei der man all dies besprechen kann?

Anastasia: Es gibt die älteste Konferenz zur Testung, die in diesem Jahr zum 25. Mal stattfindet und einfach "SQA Days" heißt. In erster Linie werden dort Werkzeuge und spezifische Ansätze zum Testen für funktionale Tester diskutiert. In der Regel werden auf den SQA Days spezifische Bereiche im Verantwortungsbereich der Tester detailliert behandelt, aber keine umfassenden Veranstaltungen.

Es hilft sehr, sich in verschiedenen Werkzeugen und Ansätzen wie der Testung von Datenbanken, APIs usw. zurechtzufinden. Aber andererseits motiviert es nicht dazu, mehr Leute in die Schaffung eines qualitativ hochwertigen Produkts einzubeziehen, nicht nur durch das Testen. Und andererseits werden Tester nicht motivierter, über die globale Produktziele und dessen Geschäftsaspekte nachzudenken.

Ich leite eine große Abteilung, führe viele Interviews, die es tatsächlich ermöglichen, den Zustand der Branche insgesamt zu beurteilen. In der Regel arbeiten unsere Leute im Enterprise-Bereich und haben einen klaren Verantwortungsbereich. Kollegen, die an internationalen Projekten arbeiten, nutzen verschiedene Arten des Testens: sie können Lasttests, Leistungstests und sogar manchmal Sicherheitstests durchführen, weil sie wirklich dem Team helfen, die Produktqualität zu gewährleisten.

Ich wünschte mir, dass unsere Leute in Russland auch anfangen würden, darüber nachzudenken, dass die Branche nicht mit funktionalen Tests endet.

— Zu diesem Zweck organisieren wir die neue Konferenz QualityConf, die sich der Qualität als ganzheitlicher Disziplin widmet. Erzähl mir mehr über die Idee, was ist das Hauptziel der Konferenz?

Anastasia: Wir möchten eine Gemeinschaft von Menschen schaffen, die daran interessiert sind, qualitativ hochwertige Produkte zu entwickeln. Eine Plattform anbieten, wo sie kommen, Vorträge hören und nach der Konferenz mit einem konkreten Verständnis gehen können, was sie ändern müssen, um die Qualität zu verbessern.

Ich höre oft Anfragen aus dem Consulting, was zu tun ist, wenn es Probleme mit dem Testen und der Qualität gibt. Wenn man beginnt, mit den Teams zu kommunizieren, sieht man, dass das Problem nicht bei den Testern selbst liegt, sondern darin, wie der Prozess aufgebaut ist. Zum Beispiel, wenn Entwickler glauben, dass sie nur für das Schreiben des Codes verantwortlich sind, endet ihre Verantwortung genau in dem Moment, in dem sie die Aufgabe zum Testen übergeben.

Nicht jeder denkt darüber nach, dass schlecht geschriebener, minderwertiger Code mit schlechter Architektur große Probleme für das Projekt mit sich bringen kann. Sie denken nicht über die Kosten von Fehlern nach, darüber, dass Bugs, die in die Produktion gelangen, zu hohen Kosten für das Unternehmen und das Team führen können. Es gibt keine Kultur, darüber nachzudenken. Ich möchte, dass wir auf der Konferenz anfangen, diese Kultur zu verbreiten.

Ich verstehe, dass dies keine Innovation ist. Edward Deming, der Autor der 14 Qualitätsprinzipien, schrieb bereits im letzten Jahrhundert über die Kosten von Fehlern. Auf diesem Buch basiert die Qualitätssicherung als Disziplin, aber leider vergisst die moderne Entwicklung oft darüber.

— Werden Sie auch Themen direkt zum Testen und zu Tools behandeln?

Anastasia: Ich gehe davon aus, dass es Vorträge über Tools geben wird. Es gibt ausreichend universelle Werkzeuge, mit denen Unternehmen und Teams Einfluss auf das Produkt nehmen können.

Alle Vorträge werden global durch eine gemeinsame Mission vereint: der Zielgruppe zu vermitteln, dass wir durch diesen Ansatz, dieses Werkzeug, diese Methode, diesen Prozess, diese Art des Testens die Qualität des Produkts beeinflusst und das Leben des Kunden verbessert haben.

Wir werden definitiv keine Vorträge über Werkzeuge halten, nur um der Werkzeuge willen. Alle Vorträge, die ins Programm kommen, werden ein gemeinsames Ziel verfolgen.

— Wer wird an dem, was du sagst, interessiert sein, wen siehst du als Gäste der Konferenz?

Anastasia: Wir werden Präsentationen für Entwickler haben, denen das Schicksal ihres Projekts, Produkts oder Systems nicht gleichgültig ist. Auch Tester und, wie ich denke, insbesondere Manager werden interessiert sein. Mit Managern meine ich die Personen, die Entscheidungen treffen und das Schicksal sowie die Entwicklung des Produkts, Systems und der Teams beeinflussen können.

Das sind Menschen, die sich fragen, wie sie die Qualität des Produkts oder Systems steigern können. Auf unserer Konferenz erfahren sie mehr über verschiedene Maßnahmenpakete und können verstehen, was jetzt nicht stimmt und was geändert werden muss.

Ich denke, das Hauptkriterium ist, zu erkennen, dass mit der Qualität etwas nicht stimmt, und den Wunsch zu haben, etwas zu ändern. Wahrscheinlich wird es uns nicht gelingen, beim ersten Mal durchdringen zu den Menschen, die denken, dass alles schon in Ordnung ist.

— Was denkst du, hat die Branche insgesamt den reifen Zustand erreicht, um nicht nur über Tests, sondern über eine Kultur der Qualität zu sprechen?

Anastasia: Ich denke schon. Viele Unternehmen entfernen sich derzeit vom traditionellen Wasserfallansatz hin zu Agile. Es erfolgt eine Orientierung am Kunden, und die Menschen in den Teams beginnen wirklich darüber nachzudenken, wie man ein qualitativ hochwertiges Produkt schafft. Selbst in Unternehmen der Enterprise-Klasse gibt es eine Umorientierung hin zur Verbesserung der Qualität.

Anhand der Anzahl der Anfragen, die in der Community auftauchen, denke ich, dass es bereits an der Zeit ist. Ich bin mir nicht sicher, ob das eine umfassende Revolution sein wird, aber ich würde mir wünschen, dass dieser Bewusstseinswandel stattfindet.

— Vereinbart! Wir werden die Kultur vermitteln und das Bewusstsein verändern.

Konferenz über qualitativ hochwertige Entwicklung von IT-Produkten QualityConf stattfinden in Moskau am 7. Juni. Sie wissen, aus welchen Phasen ein qualitativ hochwertiges Produkt besteht, es gibt erfolgreiche Fallstudien zur Bekämpfung von Bugs in der Produktion, und in unserer eigenen Praxis haben wir beliebte Methoden überprüft – wir benötigen Ihre Erfahrungen. Schicken Sie Ihre Anmeldungen bis zum 1. Mai, und das Programmkomitee wird helfen, das Thema für die Gesamtheit der Konferenz zu fokussieren.

Treten Sie dem Chatbei, in dem wir Fragen zur Qualität und zur Konferenz besprechen, und abonnieren Sie Telegram-Kanal, um über Neuigkeiten zum Programm informiert zu bleiben.

Quelle: habr.com