Wer ist für die Qualität verantwortlich?

Hey Habr!

Wir haben ein neues wichtiges Thema – hochwertige Entwicklung von IT-Produkten. Bei HighLoad++ sprechen wir oft darüber, wie man ausgelastete Dienste schnell macht, und bei Frontend Conf sprechen wir über eine coole Benutzeroberfläche, die nicht langsamer wird. Wir haben regelmäßig Themen zum Thema Testen und auf der DevOpsConf über die Kombination verschiedener Prozesse, einschließlich Testen. Aber darüber, was Qualität im Allgemeinen genannt werden kann und wie man umfassend daran arbeiten kann – nein.

Lassen Sie uns das beheben QualitätsKonf — Wir werden eine Kultur des Nachdenkens über die Qualität des Endprodukts für den Benutzer in jeder Entwicklungsphase entwickeln. Die Angewohnheit, sich nicht auf den eigenen Verantwortungsbereich zu konzentrieren und Qualität nicht nur mit Testern zu assoziieren.

Unterhalb des Schnitts werden wir mit dem Leiter des Programmkomitees, dem Testleiter bei Tinkoff.Business, dem Gründer der russischsprachigen QS-Community, sprechen Anastasia Aseeva-Nguyen über den Stand der QS-Branche und die Mission der neuen Konferenz.

- Hallo Nastia. Bitte erzählen Sie über sich selbst.

Anastasia: Ich leite Tests bei einer Bank, ich bin für ein sehr großes Team verantwortlich – wir sind mehr als 90 Leute. Wir haben einen wichtigen Geschäftsbereich: Wir sind für das Ökosystem für juristische Personen verantwortlich.

Ich habe Mechanik und Mathematik studiert und wollte zunächst Programmierer werden. Aber als ich ein interessantes Angebot bekam, beschloss ich, mich als Tester zu versuchen. Seltsamerweise stellte sich heraus, dass dies meine Berufung war. Jetzt sehe ich alle meine Arbeiten in dieser Branche.

Ich bin ein leidenschaftlicher Anhänger der Qualitätssicherungsdisziplin. Es ist mir nicht gleichgültig, welche Produkte entstehen, wie mit Qualität im Unternehmen, im Team und grundsätzlich im Entwicklungsprozess umgegangen wird.

Das ist für mich klar Die Community ist in dieser Richtung noch nicht ausgereift genug, zumindest in Russland. Wir verstehen nicht immer, dass Qualitätssicherung nicht nur das Testen einer Anwendung auf Einhaltung der Anforderungen ist. Ich möchte diese Situation ändern.

— Sie verwenden die Wörter Qualitätssicherung und Prüfung. In den Augen des Durchschnittsbürgers überschneiden sich diese beiden Begriffe sehr oft. Wie unterscheiden sie sich, wenn man tiefer gräbt?

Anastasia: Vielmehr sind sie nicht anders. Das Testen ist Teil der Qualitätssicherungsdisziplin; es ist eine direkte Aktivität – die Tatsache, dass ich etwas teste. Tatsächlich gibt es viele Arten von Tests und unterschiedliche Personen sind für verschiedene Arten von Tests verantwortlich. Aber hier in Russland, als eine Welle von Outsourcern auftauchte, die Tester an Unternehmen lieferten, wurde das Testen auf einen einzigen Typ reduziert.

In den meisten Fällen beschränken sie sich nur auf Funktionstests: Sie prüfen, ob der Code der Entwickler mit der Spezifikation übereinstimmt, und das ist alles.

— Sagen Sie uns bitte, welche weiteren Qualitätssicherungsdisziplinen es gibt? Was ist hier außer dem Testen noch enthalten?

Anastasia: Bei der Qualitätssicherung geht es in erster Linie um die Schaffung eines Qualitätsprodukts. Das heißt, wir stellen uns die Frage, welche Qualitätsmerkmale unser Produkt haben sollte. Wenn wir dies verstehen, können wir vergleichen, wer diese Qualitätsmerkmale beeinflusst. Nicht wichtig, Entwickler, Projektmanager oder Produktspezialist ist eine Person, die die Entwicklung eines Produkts, seinen Rückstand und seine Strategie beeinflusst.

Der Tester wird sich seiner Rolle bewusster. Er versteht, dass seine Aufgabe nicht nur darin besteht, die Einhaltung der Anforderungen zu prüfen, sondern auch Anforderungen zu testen, die Formulierungen des Produktspezialisten zu hinterfragen und alle impliziten Anforderungen und Erwartungen des Kunden offenzulegen. Wenn wir unseren Kunden neue Funktionen liefern, müssen wir ihre Erwartungen wirklich erfüllen und ihre Probleme lösen. Wenn wir über alle Qualitätsattribute nachdenken, wird der Kunde zufrieden sein und verstehen, dass das Unternehmen, dessen Produkt er verwendet, sich wirklich um seine Interessen kümmert und nicht nach dem Prinzip „nur um eine Funktion freizugeben“ arbeitet.

— Es scheint, dass das, was Sie gerade beschrieben haben, die Aufgabe eines Produktspezialisten ist. Dabei geht es im Prinzip doch nicht um Tests und auch nicht um Qualität – es geht doch im Allgemeinen um Produktmanagement, oder?

Anastasia: Einschließlich. Qualitätssicherung ist keine Disziplin, für die eine bestimmte Person verantwortlich ist. Jetzt gibt es eine beliebte Richtung beim Testen, einen Ansatz namens Agiles Testen. Seine Definition besagt eindeutig, dass es sich um einen Teamansatz beim Testen handelt, der eine Reihe bestimmter Praktiken umfasst. Für die Umsetzung dieses Ansatzes ist das gesamte Team verantwortlich, es ist nicht einmal notwendig, dass es einen Tester im Team gibt. Das gesamte Team konzentriert sich darauf, dem Kunden einen Mehrwert zu bieten und sicherzustellen, dass der Wert den Kundenerwartungen entspricht.

— Es stellt sich heraus, dass sich Qualität mit fast allen umliegenden Disziplinen überschneidet und allem um sie herum einen Rahmen auferlegt?

Anastasia: Rechts. Wenn wir darüber nachdenken, wie wir ein Qualitätsprodukt herstellen wollen, beginnen wir, über die verschiedenen Qualitätsmerkmale nachzudenken. So können Sie beispielsweise überprüfen, ob wir wirklich die Funktion entwickelt haben, die unser Kunde benötigt.

Hier kommt diese Art von Tests ins Spiel: UAT (User Acceptance Testing). Leider wird es in Russland selten praktiziert, ist aber manchmal in SCRUM-Teams als Demo für den Endkunden vorhanden. Dies ist eine recht häufige Art der Prüfung in ausländischen Unternehmen. Bevor wir die Funktionalität für alle Kunden öffnen, führen wir zunächst eine UAT durch, das heißt, wir laden den Endbenutzer ein, der testet und sofort Feedback gibt – ob das Produkt wirklich den Erwartungen entspricht und die Probleme löst. Erst danach erfolgt die Skalierung auf alle anderen Clients.

Das heißt, wir konzentrieren uns auf das Geschäft, auf den Endkunden, aber gleichzeitig Vergessen Sie nicht die Technologie. Die Qualität des Produkts hängt auch stark von der Technologie ab. Wenn wir eine schlechte Architektur haben, können wir Funktionen nicht schnell veröffentlichen und die Erwartungen der Kunden erfüllen. Bei der Skalierung kann es zu vielen Fehlern kommen, oder bei der Umgestaltung kann es zu Fehlern kommen. All dies wirkt sich auf die Kundenzufriedenheit aus.

Unter diesem Gesichtspunkt sollte die Architektur so beschaffen sein, dass wir sauberen Code schreiben können, der es uns ermöglicht, schnell Änderungen vorzunehmen, ohne Angst haben zu müssen, dass wir alles kaputt machen. Damit sich Revisionsiterationen nicht über mehrere Monate erstrecken, nur weil wir so viel Legacy haben und lange Testphasen durchführen müssen.

— Insgesamt sind bereits Entwickler, Architekten, Produktwissenschaftler, Produktmanager und Tester selbst beteiligt. Wer ist sonst noch am Qualitätssicherungsprozess beteiligt?

Anastasia: Stellen wir uns nun vor, dass wir die Funktion bereits an den Kunden geliefert haben. Natürlich muss die Qualität des Produkts auch dann überwacht werden, wenn es bereits in Produktion ist. In dieser Phase können Situationen mit nicht offensichtlichen Szenarien, sogenannten Bugs, auftreten.

Die erste Frage ist, wie wir mit diesen Fehlern umgehen, nachdem wir das Produkt bereits veröffentlicht haben. Wie reagieren wir beispielsweise auf Stress? Der Kunde wird nicht sehr erfreut sein, wenn das Laden der Seite länger als 30 Sekunden dauert.

Hier kommt die Ausbeutung ins Spiel oder, wie sie es jetzt nennen, DevOps. Tatsächlich sind dies die Personen, die für den Betrieb des Produkts verantwortlich sind, wenn es bereits in Produktion ist. Dazu gehören verschiedene Arten der Überwachung. Es gibt sogar eine Unterart des Testens – Testen in der Produktion, wenn wir uns erlauben, etwas nicht vor der Einführung zu testen, sondern es sofort in der Produktion zu testen. Dabei handelt es sich um eine Reihe von Maßnahmen aus Sicht der Organisation der Infrastruktur, die es Ihnen ermöglichen, schnell auf einen Vorfall zu reagieren, ihn zu beeinflussen und ihn zu beheben.

Auch die Infrastruktur ist wichtig. Es gibt oft Situationen, in denen es während eines Tests unmöglich ist, sicherzustellen, dass wir wirklich alles haben, was wir dem Kunden geben möchten. Wir führen es in die Produktion ein und beginnen, nicht offensichtliche Situationen zu erkennen. Und das alles, weil die Infrastruktur im Test nicht der Infrastruktur in der Produktion entspricht. Dies führt zu einer neuen Art des Testens – Infrastrukturtests. Dies sind verschiedene Konfigurationen, Einstellungen, Datenbankmigration usw.

Dies wirft die Frage auf: 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 Bericht mit einem realen Fall geben wird. Schreiben Sie uns, wenn Sie bereit sind, uns aus eigener Erfahrung zu erzählen, wie sich Infrastructure as Code auf die Qualität auswirkt. Infrastructure as Code macht es einfacher, alle Einstellungen zu überprüfen und Dinge zu testen, die sonst einfach nicht möglich wären. Daher ist auch der Betrieb in den Prozess der Entwicklung eines Qualitätsprodukts eingebunden.

— Wie sieht es mit Analyse und Dokumentation aus?

Anastasia: Dies gilt eher für Unternehmenssysteme. Wenn wir über Unternehmen sprechen, kommen einem sofort Leute wie Analysten und Systemanalysten in den Sinn. Sie werden manchmal als technische Redakteure bezeichnet. Sie erhalten den Auftrag, beispielsweise einen Monat lang ein Pflichtenheft zu verfassen und dieses zu vervollständigen.

Es wurde wiederholt bewiesen, dass das Schreiben einer solchen Dokumentation zu sehr langen Entwicklungsiterationen und langen Iterationen der Verfeinerung führt, da während des Testprozesses Fehler identifiziert werden und Rückgaben beginnen. Dadurch entstehen viele Schleifen, die die Entwicklungskosten erhöhen. Darüber hinaus können dadurch Sicherheitslücken entstehen. Wir scheinen Referenzcode geschrieben zu haben, haben dann aber Änderungen vorgenommen, die die perfekt durchdachte Architektur zerstören.

Das Endergebnis ist ein nicht ganz hochwertiges Produkt, da in der Architektur bereits Patches erschienen sind, der Code an einigen Stellen nicht ausreichend durch Tests abgedeckt ist, weil die Fristen ablaufen und alle Fehler schnell geschlossen werden müssen. Und das alles, weil die ursprüngliche Spezifikation nicht alle Punkte berücksichtigte, die umgesetzt werden müssen.

Entwickler sind keine Schädlinge und schreiben nicht absichtlich Code mit Fehlern.

Hätten wir zunächst eine Spezifikation durchdacht, die alle notwendigen Punkte abgedeckt hätte, dann wäre alles genau so umgesetzt worden, wie es benötigt wurde. Aber das ist eine Utopie.

Es ist wahrscheinlich unmöglich, eine perfekte 100-seitige Spezifikation zu schreiben. Deshalb Sie müssen über alternative Wege zum Verfassen von Dokumentationen nachdenken, Spezifikationen, Festlegung von Aufgaben, die uns näher daran bringen würden, sicherzustellen, dass der Entwickler genau das tut, was benötigt wird.

Hier fallen mir Ansätze aus dem Agile ein – User Stories mit Akzeptanzkriterien. Dies gilt eher für Teams, die in kleinen Iterationen entwickeln.

— Wie sieht es mit Usability-Tests, Produkt-Usability und Design aus?

Anastasia: Das ist ein sehr wichtiger Punkt, denn es gibt Designer im Team. Am häufigsten werden Designer als Dienstleistung eingesetzt – entweder von einer Designabteilung oder von einem ausgelagerten Designer. Es gibt oft Situationen, in denen es den Anschein hat, als hätte der Designer dem Produktspezialisten zugehört und getan, was er verstanden hat. Aber als wir mit der Iteration beginnen, stellt sich heraus, dass das, was tatsächlich getan wurde, nicht den Erwartungen entsprach: Der Designer hat etwas vergessen, das Verhalten nicht vollständig durchdacht, weil er nicht im Team und nicht im Kontext oder an der Front ist Der Endentwickler hat das Layout nicht vollständig verstanden. Es kann mehrere Iterationen dauern, nur weil der Front-End-Entwickler ein Problem damit hat, das Design zu verstehen.

Außerdem gibt es noch ein weiteres Problem. Designsysteme erfreuen sich zunehmender Beliebtheit. Sie sind im Hype, aber die Vorteile, die sie mit sich bringen, sind nicht ganz offensichtlich.

Ich bin der Meinung, dass Designsysteme einerseits die Entwicklung vereinfachen, andererseits aber der Schnittstelle viele Einschränkungen auferlegen.

Daher erstellen wir nicht die Funktion, die der Kunde wünscht, sondern die, die für uns praktisch ist, da wir bereits über bestimmte Würfel verfügen, aus denen wir sie erstellen können.

Ich denke, das ist ein Thema, das es wert ist, näher betrachtet zu werden und sich zu fragen, ob wir durch den Versuch, das Design einfacher zu machen, tatsächlich ein Kundenproblem lösen.

— Es gibt überraschend viele Themen rund um die Qualitätssicherung. Gibt es in Russland eine Konferenz, auf der alle diskutiert werden können?

Anastasia: Es gibt die älteste Prüfkonferenz, die dieses Jahr zum 25. Mal stattfindet und den Namen SQA Days Quality Assurance Conference trägt. Es werden hauptsächlich Tools und spezifische Testansätze für Funktionstester besprochen. In der Regel befassen sich die Berichte der SQA Days vertieft mit einzelnen Bereichen im Verantwortungsbereich der Tester selbst, nicht jedoch mit komplexen Tätigkeiten.

Dies hilft sehr beim Verständnis verschiedener Tools und Ansätze, beim Testen von Datenbanken, APIs usw. Aber gleichzeitig ist es einerseits nicht motivierend, mehr als nur Tests in die Entwicklung eines besseren Produkts einzubeziehen. Andererseits werden Tester nicht stärker in den Prozess einbezogen, um über das globale Ziel des Produkts und seine Geschäftskomponente nachzudenken.

Ich leite eine große Abteilung und führe viele Interviews, die wirklich Einblick in die Lage der Branche als Ganzes geben. Unsere Jungs arbeiten in der Regel in Unternehmen und haben einen klaren Verantwortungsbereich. Kollegen, die in ausländischen Projekten arbeiten, nutzen unterschiedliche Arten von Tests: Sie können selbst Lasttests, Leistungstests und manchmal sogar Sicherheitstests durchführen, weil sie dem Team wirklich dabei helfen, die Qualität des Produkts sicherzustellen.

Ich möchte, dass die Leute in Russland auch anfangen zu denken, dass die Branche nicht mit Funktionstests endet.

— Zu diesem Zweck veranstalten wir eine neue Konferenz, die QualityConf, die sich der Qualität als integraler Disziplin widmet. Erzählen Sie uns mehr über die Idee. Was ist das Hauptziel der Konferenz?

Anastasia: Wir möchten eine Gemeinschaft von Menschen schaffen, die sich für die Herstellung von Qualitätsprodukten interessieren. Bieten Sie eine Plattform, auf der sie kommen, sich Berichte anhören und nach der Konferenz mit einem konkreten Verständnis dafür, was geändert werden muss, um die Qualität zu verbessern, wieder gehen können.

Heutzutage höre ich oft die Frage aus der Beratung, was zu tun ist, wenn es Probleme mit der Prüfung und Qualität gibt. Wenn man beginnt, mit Teams zu kommunizieren, stellt man fest, dass das Problem nicht bei den Testern selbst liegt, sondern bei der Strukturierung des Prozesses. Wenn Entwickler beispielsweise glauben, dass sie nur für das Schreiben von Code verantwortlich sind, endet ihre Verantwortung genau in dem Moment, in dem sie die Aufgabe dem Testen übergeben.

Nicht jeder denkt darüber nach, dass schlecht geschriebener Code von geringer Qualität und schlechter Architektur dem Projekt große Probleme bereiten. Sie denken nicht an die Kosten von Fehlern, daran, dass Fehler, die in der Produktion landen, hohe Kosten für das Unternehmen und das Team verursachen können. Es gibt keine Kultur, darüber nachzudenken. Ich möchte, dass wir damit beginnen, es auf der Konferenz zu verteilen.

Ich verstehe, dass dies keine Innovation ist. Edward Deming, der Autor der 14 Grundsätze der Qualität, schrieb bereits im letzten Jahrhundert über die Kosten eines Fehlers. Die Qualitätssicherung als Disziplin basiert auf diesem Buch, wird aber leider von der modernen Entwicklung vergessen.

— Planen Sie, Themen direkt zu Tests und Tools anzusprechen?

Anastasia: Ich gebe zu, dass es Berichte über Tools geben wird. Es gibt durchaus universelle Tools, mit denen Unternehmen und Teams Einfluss auf das Produkt nehmen können.

Alle Berichte werden weltweit durch eine gemeinsame Mission vereint: dem Publikum zu vermitteln, dass wir mit Hilfe dieses Ansatzes, Tools, dieser Methode, dieses Prozesses und dieser Testart die Qualität des Produkts beeinflusst und das Leben des Kunden verbessert haben.

Wir werden auf keinen Fall über ein Werkzeug um des Werkzeugs willen berichten. Alle im Programm enthaltenen Berichte werden durch ein gemeinsames Ziel vereint.

— Wen interessiert das, worüber Sie sprechen, wen sehen Sie als Gäste der Konferenz?

Anastasia: Wir werden Berichte für Entwickler haben, denen das Schicksal ihres Projekts, Produkts oder Systems am Herzen liegt. Ebenso wird es für Tester und, wie mir scheint, insbesondere für Manager von Interesse sein. Mit Managern meine ich Menschen, die Entscheidungen treffen und auch das Schicksal und die Entwicklung eines Produkts, Systems oder Teams beeinflussen können.

Das sind Menschen, die sich fragen, wie sie die Qualität eines Produkts oder Systems verbessern können. Auf unserer Konferenz lernen sie verschiedene Maßnahmenpakete kennen und können verstehen, was jetzt daran falsch ist und was geändert werden muss.

Ich denke, das Hauptkriterium besteht darin, zu verstehen, dass mit der Qualität etwas nicht stimmt, und darauf Einfluss nehmen zu wollen. Wir werden wahrscheinlich nicht in der Lage sein, Leute zu erreichen, die glauben, dass dies nur beim ersten Mal funktioniert.

— Glauben Sie, dass die Branche insgesamt reif ist, nicht nur über Tests, sondern auch über eine Qualitätskultur zu sprechen?

Anastasia: Ich glaube, ich bin gereift. Mittlerweile wenden sich viele Unternehmen vom traditionellen Wasserfallansatz hin zu Agile ab. Der Kunde steht im Mittelpunkt, die Leute in den Teams fangen wirklich an, darüber nachzudenken, wie man ein Qualitätsprodukt schafft. Selbst große Unternehmen konzentrieren sich wieder auf die Verbesserung der Qualität.

Gemessen an der Anzahl der Anfragen, die in der Community auftauchen, glaube ich, dass es an der Zeit ist. Ich bin mir natürlich nicht sicher, ob dies eine groß angelegte Revolution sein wird, aber ich möchte, dass diese Bewusstseinsrevolution stattfindet.

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

Konferenz zur hochwertigen Entwicklung von IT-Produkten QualitätsKonf gehalten in Moskau am 7. Juni. Sie wissen, welche Schritte ein hochwertiges Produkt ausmachen, wir haben Fälle erfolgreicher Fehlerbekämpfung in der Produktion, wir haben gängige Methoden in unserer Praxis getestet – wir brauchen Ihre Erfahrung. Schicken ihre Bewerbungen bis zum 1. Mai möglich, und das Programmkomitee wird dazu beitragen, das Thema für die Gesamtintegrität der Konferenz zu fokussieren.

Verbunden mit Plaudern, in dem wir Qualitätsthemen besprechen und die Konferenz abonnieren Telegrammkanalum über Programmneuigkeiten auf dem Laufenden zu bleiben.

Source: habr.com