Wer ist für die Qualität verantwortlich?

Hallo Habr!

Wir haben ein neues wichtiges Thema - die qualitativ hochwertige Entwicklung von IT-Produkten. In HighLoad ++ wird häufig darüber gesprochen, wie ausgelastete Dienste schnell ausgeführt werden können, und in Frontend Conf - einer coolen Benutzeroberfläche, die nicht langsamer wird. Wir haben regelmäßig Themen zum Testen und DevOpsConf zum Kombinieren verschiedener Prozesse, einschließlich Testen. Aber darüber, welche Qualität als Ganzes bezeichnet werden kann und wie man umfassend daran arbeitet, nein.

Lassen Sie es uns auf QualityConf beheben - wir werden eine Kultur des Denkens über die Qualität des Endprodukts für den Benutzer in jeder Entwicklungsphase entwickeln. Die Gewohnheit, sich nicht auf Ihren Verantwortungsbereich einzulassen und Qualität nicht nur mit Testern in Verbindung zu bringen.

Im Rahmen der Kürzung werden wir mit dem Leiter des Programmkomitees, dem Testleiter bei Tinkoff Business , dem Schöpfer der russischsprachigen QS-Community Anastasia Aseeva-Nguyen, über den Zustand der QS-Branche und die Mission der neuen Konferenz sprechen.



- Nastya, hallo. Bitte erzähle von dir.

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

Ich habe bei mehmat studiert und wollte zunächst Programmierer werden. Aber als ich ein interessantes Angebot hatte, 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 egal, welche Produkte entstehen, wie sie sich auf die Qualität im Unternehmen, im Team und im Prinzip im Entwicklungsprozess beziehen.

Mir ist klar, dass die Gemeinschaft in dieser Richtung zumindest in Russland nicht reif genug ist. Wir verstehen nicht immer, dass Qualitätssicherung nicht nur die Prüfung eines Antrags auf Einhaltung der Anforderungen ist. Ich möchte diese Situation ändern.

- Sie verwenden die Wörter Qualitätssicherung und Prüfung. In den Augen eines Durchschnittsmenschen überschneiden sich diese beiden Begriffe sehr oft. Wie unterscheiden sie sich, wenn Sie tief graben?

Anastasia: Sie unterscheiden sich vielmehr nicht. Testen ist Teil der Disziplin Qualitätssicherung, es ist eine direkte Aktivität - genau die Tatsache, dass ich etwas teste. Es gibt tatsächlich viele Arten von Tests, und verschiedene Personen sind für verschiedene Arten von Tests verantwortlich. In Russland, als es eine Welle von Outsourcern gab, die Tester an das Unternehmen liefern, wurden die Tests auf eine einzige Ansicht reduziert.

In den meisten Fällen beschränken sie sich nur auf Funktionstests: Sie überprüfen, ob das, was Entwickler kompiliert haben, der Spezifikation entspricht, und das ist alles.

- Sagen Sie mir bitte, welche anderen Disziplinen der Qualitätssicherung gibt es? Was beinhaltet es außer dem Testen noch?

Anastasia : Bei der Qualitätssicherung geht es in erster Linie darum, ein Qualitätsprodukt zu schaffen. Das heißt, wir fragen uns, welche Qualitätsmerkmale unser Produkt besitzen sollte. Wenn wir dies verstehen, können wir dementsprechend vergleichen, wer diese Qualitätsmerkmale beeinflusst. Es spielt keine Rolle, der Entwickler, Projektmanager oder Produktmanager ist eine Person, die die Entwicklung eines Produkts, seinen Rückstand und seine Strategie beeinflusst.

Der Tester ist sich seiner Rolle besser bewusst. Er versteht, dass seine Aufgabe nicht nur darin besteht, die Einhaltung der Anforderungen zu testen, sondern auch die Anforderungen zu testen, die Sprache des Produkttechnologen in Frage zu stellen und alle impliziten Anforderungen und Erwartungen des Kunden offenzulegen. Wenn wir unserem Kunden neue Funktionen anbieten, müssen wir seine Erwartungen wirklich erfüllen und seine Schmerzen lösen. Wenn wir über alle Qualitätsmerkmale 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 ein Feature freizugeben“ arbeitet.

- Es scheint, dass das, was Sie gerade beschrieben haben, die Aufgabe des Produkttechnologen ist. Im Prinzip geht es nicht um Tests und nicht um Qualität - es geht im Allgemeinen um Produktmanagement, nicht wahr?

Anastasia : Einschließlich. Qualitätssicherung ist nicht die Disziplin, für die eine bestimmte Person verantwortlich ist. Jetzt gibt es eine beliebte Richtung beim Testen, einen Ansatz namens Agiles Testen . In seiner Definition klingt es unkompliziert, dass dies ein Teamansatz zum Testen ist, der eine Reihe von Praktiken umfasst. Das gesamte Team ist für die Umsetzung dieses Ansatzes verantwortlich. Es ist nicht einmal erforderlich, dass ein Tester im Team ist. Das gesamte Team konzentriert sich darauf, dem Kunden einen Mehrwert zu bieten, damit dieser Wert seinen Erwartungen entspricht.

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

Anastasia : Richtig. Wenn wir darüber nachdenken, was wir für ein Qualitätsprodukt schaffen wollen, beginnen wir über die verschiedenen Qualitätsmerkmale nachzudenken. Zum Beispiel, wie Sie überprüfen können, ob wir wirklich eine Funktion erstellt haben, die unser Kunde benötigt.

Diese Art von Tests wird wie UAT (User Acceptance Testing) angezeigt. Leider wird es in Russland selten praktiziert, aber manchmal ist es in SCRUM-Teams als Demo für den Endkunden vorhanden. In ausländischen Unternehmen ist dies eine ziemlich häufige Art von Tests. Bevor wir die Funktionalität für alle Kunden öffnen, erstellen wir zunächst UAT, dh wir laden den Endbenutzer ein, der Tests durchführt und sofort Feedback gibt - erfüllt das Produkt wirklich die Erwartungen und löst Schmerzen. Erst danach erfolgt die Skalierung auf alle anderen Clients.

Das heißt, wir konzentrieren uns auf das Geschäft, auf den Endkunden, vergessen aber gleichzeitig nicht die Technologie . Die Produktqualität hängt auch stark von der Technologie ab. Wenn wir eine schlechte Architektur haben, können wir Funktionen nicht schnell veröffentlichen und die Kundenerwartungen erfüllen. Es kann viele Fehler geben, wenn wir versuchen zu skalieren oder wenn wir versuchen zu refaktorieren, können wir etwas kaputt machen. Dies alles wirkt sich auf die Kundenzufriedenheit aus.

Unter diesem Gesichtspunkt sollte die Architektur so sein, dass wir sauberen Code schreiben können, der es uns ermöglicht, Änderungen schnell vorzunehmen und keine Angst zu haben, dass wir alles kaputt machen. Damit sich die Verfeinerungsiterationen nicht über mehrere Monate erstrecken, nur weil wir so viele Vermächtnisse haben und lange Testschritte durchführen müssen.

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

Anastasia : Stellen Sie sich jetzt vor, wir haben einem Kunden bereits eine Funktion geliefert. Natürlich müssen Sie die Qualität des Produkts überwachen und wenn es bereits in Produktion ist. In diesem Stadium können Situationen mit nicht offensichtlichen Szenarien, den sogenannten Fehlern, auftreten.

Die erste Frage ist, wie wir mit diesen Fehlern arbeiten, nachdem wir das Produkt bereits veröffentlicht haben. Wie reagieren wir zum Beispiel auf die Last? Der Client ist nicht sehr zufrieden, wenn die Seite länger als 30 Sekunden geladen wird.

Hier kommt die Ausbeutung oder, wie sie es jetzt nennen, DevOps ins Spiel. In der Tat sind dies Personen, die für den Betrieb des Produkts verantwortlich sind, wenn es bereits zum Verkauf steht. Dies umfasst verschiedene Arten der Überwachung. Es gibt sogar einen Subtyp des Testens - Testen auf dem Produkt, wenn wir uns erlauben, etwas vor dem Ausrollen nicht zu testen und es sofort auf dem Produkt zu testen. Dies ist eine Reihe von Maßnahmen aus Sicht der Organisation der Infrastruktur, mit denen Sie schnell auf einen Vorfall reagieren, ihn beeinflussen und korrigieren können.

Infrastruktur ist auch wichtig. Oft gibt es Situationen, in denen es während des Tests unmöglich ist, sicherzustellen, dass wir wirklich alles haben, was wir dem Kunden geben möchten. Wir rollen zum Produkt - und fangen an, nicht offensichtliche Situationen zu erfassen. Und das alles, weil die Infrastruktur im Test nicht mit der Infrastruktur auf dem Produkt übereinstimmt. Dies führt zu einer neuen Art von Tests - Infrastrukturtests . Dies sind verschiedene Konfigurationen, Einstellungen, Datenbankmigration usw.

Dies wirft die Frage auf - vielleicht muss das Team die Infrastruktur als Code verwenden.

Ich glaube, dass die Infrastruktur die Produktqualität direkt beeinflusst.

Ich hoffe, die Konferenz wird einen Bericht mit einem realen Fall haben. Schreiben Sie uns, wenn Sie aus eigener Erfahrung wissen möchten, wie sich die Infrastruktur als Code auf die Qualität auswirkt. Infrastruktur als Code erleichtert es, alle Einstellungen zu überprüfen und etwas zu testen, was sonst einfach unmöglich ist. Daher ist die Nutzung auch an der Entwicklung eines Qualitätsprodukts beteiligt.

- Was ist mit Analyse und Dokumentation?

Anastasia : Dies gilt eher für Unternehmenssysteme. Wenn wir über Unternehmen sprechen, fallen uns sofort Leute wie Analysten und Systemanalysten ein. Sie werden manchmal als technische Redakteure bezeichnet. Sie erhalten die Aufgabe, eine Spezifikation zu schreiben und sie beispielsweise einen Monat lang abzuschließen.

Es wurde wiederholt bewiesen, dass das Schreiben einer solchen Dokumentation zu sehr langen Iterationen der Entwicklung und langen Iterationen der Verfeinerung führt, da während des Testprozesses Fehler entdeckt werden und die Rückgabe beginnt. Infolgedessen gibt es viele Schleifen, die die Entwicklungskosten erhöhen. Darüber hinaus kann dies zu Sicherheitslücken führen. Wir scheinen den Referenzcode geschrieben zu haben, haben dann aber Änderungen vorgenommen, die die perfekt durchdachte Architektur zerstören.

Das Ergebnis ist ein nicht so hochwertiges Produkt, da bereits Patches in der Architektur erschienen sind und der Code an einigen Stellen nicht ausreichend durch Tests abgedeckt ist, da die Fristen ablaufen und Sie alle Fehler schneller schließen müssen. Und das alles, weil in der ursprünglichen Spezifikation nicht alle Punkte berücksichtigt wurden, die implementiert werden müssen.

Entwickler sind keine Schädlinge und schreiben keinen fehlerhaften Code.

Wenn wir uns zunächst eine Spezifikation ausdenken würden, in der alle notwendigen Punkte behandelt würden, würde alles genau so implementiert, wie es sollte. Aber das ist Utopie.

Es ist wahrscheinlich unmöglich, eine perfekte Spezifikation von 100 Seiten zu schreiben. Daher müssen wir über alternative Methoden zum Schreiben von Dokumentation , Spezifizieren und Festlegen von Aufgaben nachdenken , die uns der Tatsache näher bringen, dass der Entwickler genau das tut, was wir benötigen.

Hier kommen die agilen Ansätze - User Stories mit Akzeptanzkriterien. Dies gilt eher für Teams, die sich in kleinen Iterationen entwickeln.

- Was ist mit Usability-Tests, Produkt-Usability, Design?

Anastasia : Dies ist ein sehr wichtiger Punkt, da es Designer im Team gibt. Meistens nutzen Designer es als Dienstleistung - entweder die Designabteilung oder den ausgelagerten Designer. Oft gibt es Situationen, in denen der Designer dem Produkttechnologen zugehört und das getan hat, was er verstanden hat. Aber wenn wir mit der Iteration beginnen, stellt sich heraus, dass nicht das, was erwartet wurde, tatsächlich getan wurde: Der Designer hat etwas vergessen, das Verhalten nicht durchdacht, weil er nicht im Team oder im Kontext war, oder der Front-End-Entwickler hat es nicht vollständig verstanden Layout. Es kann mehrere Iterationen dauern, nur weil es ein Problem mit dem Verständnis des Designs durch den Front-End-Entwickler gibt.

Außerdem gibt es noch ein anderes Problem. Designsysteme werden immer beliebter. Sie sind auf Hype, aber die Vorteile von ihnen sind nicht ganz offensichtlich.

Ich bin auf die Meinung gestoßen, dass Design-Systeme einerseits die Entwicklung vereinfachen und andererseits der Benutzeroberfläche viele Einschränkungen auferlegen.

Infolgedessen erstellen wir keine solche Funktion, die der Kunde erhalten möchte, sondern eine für uns bequeme, da wir bereits bestimmte Cubes haben, aus denen wir sie erstellen können.

Es scheint mir, dass Sie diesem Thema Aufmerksamkeit schenken und darüber nachdenken sollten, ob wir die Schmerzen des Kunden wirklich lösen, um die Arbeit am Design zu vereinfachen.

- Es stellt sich überraschend viele Themen im Zusammenhang mit der Qualitätssicherung heraus. Gibt es in Russland eine Konferenz, auf der alle diskutiert werden können?

Anastasia : Es gibt die älteste Testkonferenz, die dieses Jahr zum 25. Mal stattfindet und als SQA Days Quality Assurance Conference bezeichnet wird. Es werden hauptsächlich Tools und spezifische Testansätze für Funktionstester erörtert. In Berichten zu SQA-Tagen werden in der Regel bestimmte Bereiche im Verantwortungsbereich der Tester selbst eingehend untersucht, nicht jedoch komplexe Ereignisse.

Es hilft sehr, verschiedene Tools und Ansätze zu verstehen, wie man Datenbanken, APIs usw. testet. Gleichzeitig motiviert es einerseits nicht, nicht nur Tests in die Entwicklung eines besseren Produkts einzubeziehen. Auf der anderen Seite werden Tester nicht mehr in den Prozess einbezogen, um über das globale Ziel des Produkts und seiner Geschäftskomponente nachzudenken.

Ich leite eine große Abteilung, führe viele Interviews, die es uns tatsächlich ermöglichen, den Stand der Branche als Ganzes darzustellen. In der Regel arbeiten unsere Mitarbeiter im Unternehmen und haben einen klaren Verantwortungsbereich. Kollegen, die in ausländischen Projekten arbeiten, verwenden verschiedene Arten von Tests: Sie können selbst Lasttests, Leistungstests und manchmal sogar Sicherheitstests durchführen, da sie dem Team wirklich helfen, das Produkt mit Qualität zu versehen.

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

- Dafür organisieren wir eine neue Konferenz QualityConf, die sich der Qualität als ganzheitlicher Disziplin widmet. Erzählen Sie uns mehr über die Idee, was ist das Hauptziel der Konferenz?

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

Oft höre ich jetzt eine Anfrage von der Beratung, was zu tun ist, wenn es Probleme mit dem Testen und der Qualität gibt. Wenn Sie mit Teams sprechen, sehen Sie, dass das Problem nicht bei den Testern selbst liegt, sondern bei der Art und Weise, wie der Prozess aufgebaut ist. 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 zum Testen übertragen haben.

Nicht jeder glaubt, dass schlecht geschriebener Code von schlechter Qualität mit schlechter Architektur große Probleme für das Projekt darstellt. Denken Sie nicht an die Kosten von Fehlern, da Fehler, die in die Produktion kamen, zu hohen Kosten für das Unternehmen und das Team führen können. Keine Kultur, um darüber nachzudenken. Ich möchte, dass wir es auf der Konferenz verteilen.

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

- Planen Sie, Themen direkt über Tests und Tools anzusprechen?

Anastasia : Ich gebe zu, dass es Berichte über die Tools geben wird. Es gibt ziemlich universelle Werkzeuge, mit denen Unternehmen und Teams ein Produkt beeinflussen können.

Alle Berichte werden weltweit durch eine gemeinsame Mission vereint: Dem Publikum zu vermitteln, dass wir mit diesem Ansatz, Werkzeug, Methode, Prozess und Art der Prüfung die Qualität des Produkts beeinflusst und das Leben des Kunden verbessert haben.

Wir werden definitiv keine Berichte über das Tool für das Tool haben. Alle Berichte, die in das Programm fallen, werden durch ein gemeinsames Ziel vereint.

- Wer interessiert sich für das, worüber Sie sprechen, wen Sie als Gäste der Konferenz sehen?

Anastasia : Wir werden Berichte für Entwickler haben, denen das Schicksal ihres Projekts, Produkts und Systems nicht gleichgültig ist. Ähnlich interessant wird es für Tester sein, und es scheint mir besonders für Manager. Mit Managern meine ich Menschen, die Entscheidungen treffen und das Schicksal und die Entwicklung eines Produkts, Systems oder Teams beeinflussen können.

Dies sind Leute, die sich fragen, wie sie die Qualität eines Produkts oder Systems verbessern können. Auf unserer Konferenz lernen sie verschiedene Komplexe von Ereignissen kennen und können verstehen, was nicht richtig ist und was geändert werden muss.

Ich denke, das Hauptkriterium ist zu verstehen, dass etwas mit der Qualität nicht stimmt, und sie beeinflussen zu wollen. Wahrscheinlich wird es uns nicht gelingen, Menschen zu erreichen, die glauben, dass es funktionieren wird.

- Glauben Sie, dass die Branche insgesamt gereift ist, um nicht nur über Tests, sondern auch über eine Kultur der Qualität zu sprechen?

Anastasia : Ich glaube ich bin gereift. Jetzt entfernen sich viele Unternehmen vom traditionellen Waterfall-Ansatz in Richtung Agile. Es gibt eine Kundenorientierung, die Leute in Teams beginnen wirklich darüber nachzudenken, wie man ein Qualitätsprodukt schafft. Auch in Unternehmen gibt es eine Neuorientierung zur Qualitätsverbesserung.

Nach der Anzahl der Anfragen in der Community zu urteilen, glaube ich, dass es Zeit ist. Ich bin mir natürlich nicht sicher, ob dies eine groß angelegte Revolution sein wird, aber ich möchte, dass diese Bewusstseinsveränderung stattfindet.

- Einverstanden! Wir werden eine Kultur vermitteln und den Geist wenden.

Am 7. Juni findet in Moskau eine Konferenz zur Qualitätsentwicklung von QualityConf IT-Produkten statt. Sie wissen, ab welchem ​​Stadium ein qualitativ hochwertiges Produkt hergestellt wird, es gibt Fälle auf Lager, in denen Fehler auf dem Produkt erfolgreich behoben werden können. Wir haben in unserer Praxis beliebte Techniken getestet - wir benötigen Ihre Erfahrung. Senden Sie Ihre Bewerbungen bis zum 1. Mai , und das Programmkomitee wird Ihnen dabei helfen, das Thema auf die allgemeine Integrität der Konferenz zu konzentrieren.

Stellen Sie eine Verbindung zu einem Chat her, in dem wir Qualitätsprobleme und eine Konferenz besprechen, abonnieren Sie den Telegrammkanal , um über Programmnachrichten auf dem Laufenden zu bleiben.