Hallo, Habr!
Wir haben ein neues wichtiges Thema – die qualitativ hochwertige Entwicklung von IT-Produkten. Oft sprechen wir auf HighLoad++ darüber, wie man stark belastete Dienste schnell macht, und auf der Frontend Conf über großartige Benutzeroberflächen, die nicht ruckeln. Regelmäßig haben wir Themen zum Testen, und bei DevOpsConf geht es um die Integration verschiedener Prozesse, einschließlich Testing. Aber darüber, was man insgesamt Qualität nennen kann und wie man umfassend daran arbeitet – das fehlt.
Wir werden das ändern in – wir werden eine Kultur entwickeln, die es wichtig findet, über die Qualität des Endprodukts für den Benutzer in jeder Entwicklungsphase nachzudenken. Die Gewohnheit, sich nicht nur auf seinen Verantwortungsbereich zu konzentrieren, und Qualität nicht nur mit Testern zu assoziieren.
Im Folgenden sprechen wir mit der Leiterin des Programmausschusses, der Leiterin des Testteams bei Tinkoff.Business und der Gründerin der russischsprachigen QA-Community Anastasia Aseeva-Nguyen über den Zustand der QA-Branche und die Mission der neuen Konferenz.
– Nastya, hallo. Erzähl uns bitte etwas über dich.
Anastasia: Ich leite die Testabteilung in einer Bank und bin für ein großes Team von über 90 Personen verantwortlich. Wir haben eine wichtige Geschäftszeile und sind für das Ökosystem für juristische Personen zuständig.
Ich habe Mathematik und Informatik studiert und wollte ursprünglich Programmiererin werden. Als sich jedoch eine interessante Gelegenheit ergab, entschied ich mich, in die Rolle der Testerin hineinzuschnuppern. Überraschenderweise stellte ich fest, dass dies mein Ruf war. Jetzt sehe ich meine gesamte Arbeit genau in dieser Branche.
Ich bin eine leidenschaftliche Verfechterin der Disziplin Quality Assurance. Es liegt mir am Herzen, welche Produkte entwickelt werden und wie das Thema Qualität im Unternehmen, im Team und allgemein im Entwicklungsprozess behandelt wird.
Für mich ist es offensichtlich, dass die Gemeinschaft in diesem Bereich nicht ausreichend ausgereift ist, zumindest in Russland. Oft verstehen wir nicht, dass Qualitätssicherung nicht nur das Testen einer Anwendung auf Übereinstimmung mit den Anforderungen bedeutet. Ich würde gerne diese Situation ändern.
— Du verwendest die Begriffe Quality Assurance und Testing. Für den Normalverbraucher überschneiden sich diese beiden Begriffe häufig. Worin unterscheiden sie sich, wenn man tiefer gräbt?
Anastasia: Eigentlich unterscheiden sie sich nicht. Testing ist ein Teil der Disziplin Quality Assurance und stellt eine konkrete Tätigkeit dar – der Fakt, dass ich etwas teste. Es gibt in der Tat sehr viele Testarten, und für verschiedene Testarten sind die unterschiedlichsten Personen verantwortlich. Doch in Russland, als die Welle der Outsourcing-Unternehmen entstand, die Tester in Firmen vermitteln, wurde das Testing auf eine einzige Art reduziert.
In den meisten Fällen beschränkt man sich nur auf funktionales Testing: Es wird überprüft, ob das, was die Entwickler programmiert haben, der Spezifikation entspricht und das war's.
— Erzähl mir bitte, welche weiteren Disziplinen zur Qualitätssicherung gehören? Was gehört noch neben Testing dazu?
Anastasia: Quality Assurance bedeutet in erster Linie, ein qualitativ hochwertiges Produkt zu schaffen. Das heißt, wir fragen uns, welche Qualitätsmerkmale unser Produkt haben sollte. Wenn wir das verstehen, können wir herausfinden, wer diese Qualitätsmerkmale beeinflusst. Es spielt keine Rolle, ob es sich um einen Entwickler, einen Projektleiter oder einen Produktmanager handelt. — Das ist die Person, die Einfluss auf die Produktentwicklung, auf das Backlog und auf die Strategie hat.
Der Tester beginnt besser zu verstehen, welche Rolle er spielt. Er erkennt, dass seine Aufgabe nicht nur darin besteht, die Anforderungen zu testen, sondern auch die Anforderungen selbst zu hinterfragen, Formulierungen, die vom Produktmanager kommen, kritisch zu prüfen und alle impliziten Anforderungen sowie Erwartungen des Kunden offenzulegen. Wenn wir unserem Kunden neue Funktionalitäten bereitstellen, müssen wir seine Erwartungen tatsächlich erfüllen und seine Probleme lösen. Wenn wir über alle Qualitätsattribute nachdenken, wird der Kunde zufrieden sein und verstehen, dass das Unternehmen, dessen Produkt er nutzt, sich wirklich um seine Interessen kümmert und nicht nach dem Prinzip "nur eine Funktion bereitstellen" arbeitet.
— Es scheint, dass das, was du gerade beschrieben hast, die Aufgabe des Produktmanagers ist. Das geht doch im Grunde nicht um Tests und nicht um Qualität – es geht doch insgesamt um Produktmanagement, oder?
Anastasia: Zum Teil. Qualitätssicherung ist keine Disziplin, für die eine bestimmte Person verantwortlich ist. Derzeit gibt es einen beliebten Ansatz in der Tests, der als Agile Testing. In seiner Definition wird klar, dass es sich um einen teamorientierten Ansatz für Tests handelt, der einen bestimmten Satz von Praktiken umfasst. Die Umsetzung dieses Ansatzes obliegt dem gesamten Team, was nicht zwingend einen Tester in der Mannschaft erfordert. Das gesamte Team ist darauf ausgerichtet, dem Kunden Wert zu bieten, der seinen Erwartungen entspricht.
— Das bedeutet, dass Qualität fast alle umgebenden Disziplinen umfasst und die Rahmenbedingungen für alles andere setzt?
Anastasia: Richtig. Wenn wir darüber nachdenken, was wir schaffen möchten, um ein qualitativ hochwertiges Produkt zu entwickeln, fangen wir an, über verschiedene Qualitätsattribute nachzudenken. Zum Beispiel, wie wir sicherstellen können, dass die Funktion, die wir entwickelt haben, tatsächlich für unseren Kunden benötigt wird.
Hier kommt eine Testart ins Spiel, die UAT (User Acceptance Testing). Leider wird diese Methode in Russland selten angewendet, kommt aber manchmal in SCRUM-Teams vor, zum Beispiel als Demo für den Endkunden. In Unternehmen im Ausland ist dies eine verbreitete Testmethode. Bevor wir die Funktionalität für alle Kunden freigeben, führen wir zunächst UAT durch, das heißt, wir laden den Endverbraucher ein, der die Tests durchführt und direkt Feedback gibt – erfüllt das Produkt tatsächlich die Erwartungen und löst es ein Problem? Erst danach erfolgt das Rollout für alle anderen Kunden.
Das heißt, wir orientieren uns am Geschäft und am Endkunden, dabei vergessen wir die Technologie nicht. Auch die Technologie hat einen starken Einfluss auf die Qualität des Produkts. Wenn wir eine schlechte Architektur haben, können wir keine Funktionen schnell implementieren und die Erwartungen der Kunden nicht erfüllen. Es kann viele Bugs geben, wenn wir versuchen, zu skalieren, oder beim Refactoring könnten wir etwas kaputt machen. Das alles wirkt sich auf die Kundenzufriedenheit aus.
Aus dieser Perspektive muss die Architektur so gestaltet sein, dass wir sauberen Code schreiben können, der schnelle Änderungen ermöglicht, ohne Angst haben zu müssen, dass wir alles zerbrechen. Damit die Iterationen zur Verbesserung sich nicht über mehrere Monate ziehen, nur weil wir so viel Legacy haben und lange Testphasen durchführen müssen.
— Insgesamt sind bereits Entwickler, Architekten, Produktverantwortliche, Produktmanager und die Tester selbst beteiligt. Wer ist noch im Prozess der Qualitätssicherung involviert?
Anastasia: Stellen wir uns nun vor, dass wir die Funktion bereits an den Kunden ausgeliefert haben. Es ist offensichtlich, dass wir die Qualität des Produkts auch im laufenden Betrieb im Auge behalten müssen. In dieser Phase können sich Situationen mit nicht offensichtlichen Szenarien zeigen, die sogenannten Bugs.
Die erste Frage ist, wie wir mit diesen Bugs umgehen, nachdem wir das Produkt bereits veröffentlicht haben. Wie reagieren wir, wenn beispielsweise die Last steigt? Der Kunde wird nicht sehr zufrieden sein, wenn die Seite länger als 30 Sekunden zum Laden braucht.
Hier kommt der Betrieb ins Spiel oder, wie man heutzutage sagt, DevOps. Tatsächlich sind das Menschen, die für den Betrieb des Produkts verantwortlich sind, sobald es live ist. Dazu gehören verschiedene Arten von Monitoring. Es gibt sogar eine Unterkategorie des Testens – das Testing im Live-Betrieb, bei dem wir uns erlauben, etwas bis zur Ausrollung nicht zu testen und es sofort live erproben. Dies umfasst eine Reihe von Maßnahmen zur Organisation der Infrastruktur, die es ermöglichen, schnell auf Vorfälle zu reagieren, sie zu beeinflussen und zu beheben.
Die Infrastruktur ist ebenfalls wichtig. Oft gibt es Situationen, in denen wir während eines Tests nicht sicherstellen können, dass wir tatsächlich alles haben, was wir dem Kunden anbieten möchten. Wenn wir dann live gehen, stoßen wir auf unvorhergesehene Situationen. Das liegt daran, dass die Infrastruktur im Test nicht mit der Live-Infrastruktur übereinstimmt. Daraus ergibt sich eine neue Art des Testens – Infrastruktur Testing. Dazu gehören verschiedene Konfigurationen, Einstellungen, Datenbankmigration usw.
Deshalb stellt sich die Frage – möglicherweise sollte das Team Infrastruktur als Code nutzen.
Ich glaube, dass die Infrastruktur direkten Einfluss auf die Qualität des Produkts hat.
Ich hoffe, dass es auf der Konferenz einen Vortrag mit einem echten Anwendungsfall geben wird. Schreiben Sie uns, wenn Sie bereit sind, Ihre Erfahrungen darüber zu teilen, wie Infrastructure as Code die Qualität beeinflusst. Infrastructure as Code ermöglicht es, alle Einstellungen einfacher zu überprüfen und das zu testen, was sonst einfach nicht möglich wäre. Daher wird auch der Betrieb in den Prozess der Entwicklung qualitativ hochwertiger Produkte einbezogen.
— Was ist mit Analytik und Dokumentation?
Anastasia: Das bezieht sich eher auf Enterprise-Systeme. Wenn wir über Enterprise sprechen, denken wir sofort an Personen wie Analysten und Systemanalytiker. Manchmal werden sie technische Autoren genannt. Sie erhalten den Auftrag, eine Spezifikation zu schreiben, und setzen dies beispielsweise innerhalb eines Monats um.
Es ist vielfach bewiesen, dass das Schreiben solcher Dokumentationen zu sehr langen Entwicklungszyklen und langen Iterationen bei der Überarbeitung führt, da während des Testprozesses Bugs entdeckt werden und Rückgaben beginnen. Infolgedessen entstehen viele Schleifen, die die Entwicklungskosten erhöhen. Darüber hinaus können dabei Schwachstellen entstehen. Wir glauben, wir haben den Referenzcode geschrieben, doch dann haben wir Änderungen vorgenommen, die die perfekt durchdachte Architektur destabilisieren.
Das Ergebnis ist ein nicht ganz qualitativ hochwertiges Produkt, da die Architektur bereits mit Flickstellen versehen ist und der Code an einigen Stellen nicht ausreichend getestet ist, weil die Fristen drängen und alle Bugs schneller behoben werden müssen. Und das alles, weil in der ursprünglichen Spezifikation nicht alle Aspekte berücksichtigt wurden, die umgesetzt werden mussten.
Entwickler sind keine Schädlinge und schreiben nicht absichtlich fehlerhaften Code.
Wenn wir zu Beginn eine Spezifikation durchdacht hätten, die alle notwendigen Aspekte beleuchtet, wäre alles genau so umgesetzt worden, wie es nötig ist. Aber das ist Utopie.
Wahrscheinlich ist es unmöglich, eine ideale Spezifikation auf 100 Seiten zu erstellen. Daher Man sollte über alternative Möglichkeiten zur Erstellung von Dokumentation nachdenken., Spezifizierung, Aufgabenstellung, die uns näherbringt, damit der Entwickler genau das macht, was nötig ist.
Hier kommen agile Ansätze in den Sinn – Benutzerstories mit Akzeptanzkriterien. Das ist eher für Teams anwendbar, die sich in kleinen Iterationen weiterentwickeln.
– Wie steht es um Usability-Tests, die Benutzerfreundlichkeit des Produkts, das Design?
Anastasia: Das ist ein sehr wichtiger Punkt, denn im Team gibt es Designer. Häufig werden Designer als Dienstleistung in Anspruch genommen – entweder durch eine Designabteilung oder durch einen externen Designer. Es kommt oft vor, dass der Designer scheinbar den Produktmanager gehört hat und das gemacht hat, was er verstanden hat. Aber wenn wir zur Iteration übergehen, stellt sich heraus, dass tatsächlich nicht das umgesetzt wurde, was erwartet wurde: Der Designer hat etwas vergessen oder das Verhalten nicht vollständig durchdacht, weil er nicht im Team und nicht im Kontext ist, oder der Frontend-Entwickler hat sein Layout nicht vollständig verstanden. Es kann mehrere Iterationen erfordern, nur weil es ein Verständnisproblem zwischen dem Design und dem Frontend-Entwickler gibt.
Es gibt noch ein weiteres Problem. Momentan gewinnen Design-Systeme an Popularität. Sie sind im Trend, aber der Nutzen ist nicht ganz offensichtlich.
Ich stoße auf die Meinung, dass Design-Systeme einerseits die Entwicklung vereinfachen, andererseits jedoch viele Einschränkungen für die Benutzeroberfläche mit sich bringen.
Letztendlich erstellen wir nicht die Funktion, die der Kunde möchte, sondern die, die für uns bequem ist, weil wir bereits bestimmte Bausteine haben, aus denen wir sie zusammensetzen können.
Ich denke, man sollte dieses Thema in Betracht ziehen und überlegen, ob wir in dem Versuch, die Designarbeit zu vereinfachen, wirklich das Problem des Kunden lösen.
— Es gibt erstaunlich viele Themen im Zusammenhang mit Quality Assurance. Gibt es in Russland eine Konferenz, auf der all dies diskutiert werden kann?
Anastasia: Es gibt eine der ältesten Konferenzen zum Testen, die in diesem Jahr zum 25. Mal stattfindet und die Qualitätssicherungs-Konferenz SQA Days genannt wird. Primär werden dort Werkzeuge und konkrete Testansätze für Funktionstester diskutiert. In den Vorträgen auf den SQA Days werden typischerweise spezifische Bereiche innerhalb der Verantwortung der Tester tiefgehend behandelt, jedoch keine umfassenden Themen.
Das hilft enorm dabei, sich in verschiedenen Werkzeugen und Ansätzen zurechtzufinden, wie man Datenbanken, APIs usw. testet. Auf der anderen Seite motiviert es jedoch nicht, auch andere Aspekte in die Schaffung eines qualitativ besseren Produkts einzubeziehen, und die Tester werden nicht aktiver in den Prozess einbezogen, um über die globale Zielsetzung des Produkts und dessen Geschäftsaspekte nachzudenken.
Ich leite eine große Abteilung und führe viele Vorstellungsgespräche, die tatsächlich einen Überblick über den Zustand der Branche insgesamt geben. Unsere Mitarbeiter arbeiten in der Regel im Enterprise-Bereich und haben klare Verantwortlichkeiten. Kollegen, die an internationalen Projekten arbeiten, nutzen verschiedene Testmethoden: Sie können Lasttests, Leistungstests und manchmal sogar Sicherheitstests (Security Testing) durchführen, da sie dem Team helfen, die Qualität des Produkts zu gewährleisten.
Ich würde mir wünschen, dass auch in Russland die Leute anfangen, darüber nachzudenken, dass die Branche nicht nur mit Funktionstests endet.
— Dafür organisieren wir die neue Konferenz QualityConf, die der Qualität als ganzheitlicher Disziplin gewidmet ist. 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. Wir wollen eine Plattform bieten, auf die sie kommen können, um Vorträge zu hören und nach der Konferenz mit einem klaren Verständnis darüber zu gehen, was sie ändern müssen, um die Qualität zu verbessern.
Ich höre oft Anfragen aus der Beratung, was zu tun ist, wenn es Probleme beim Testen und mit der Qualität gibt. Wenn man mit den Teams spricht, wird deutlich, dass das Problem nicht bei den Testern liegt, sondern darin, wie der Prozess gestaltet ist. Zum Beispiel, wenn Entwickler glauben, dass sie nur für das Schreiben von Code verantwortlich sind, endet ihre Verantwortung genau in dem Moment, in dem sie die Aufgabe in die Tests übergeben.
Nicht alle denken daran, dass schlecht geschriebener, qualitativ minderwertiger Code mit einer schlechten Architektur große Probleme für das Projekt mit sich bringen kann. Sie denken nicht an die Kosten von Fehlern und daran, dass Bugs, die in die Produktion gelangen, erhebliche Kosten für das Unternehmen und das Team verursachen können. Es fehlt an einer Kultur, über all das nachzudenken. Ich möchte, dass wir auf der Konferenz damit beginnen, diese Kultur zu verbreiten.
Ich verstehe, dass das keine Neuerung ist. Edward Deming, der Autor der 14 Qualitätsgrundsätze, schrieb bereits im letzten Jahrhundert über die Kosten von Fehlern. Auf diesem Buch basiert die Disziplin der Qualitätssicherung. Leider vergisst die moderne Entwicklung das jedoch.
— Werdet ihr auch konkret Themen über das Testen und die Tools ansprechen?
Anastasia: Ich gehe davon aus, dass es Vorträge über Werkzeuge geben wird. Es gibt recht universelle Werkzeuge, mit denen Unternehmen und Teams das Produkt beeinflussen können.
Alle Vorträge werden global unter einer gemeinsamen Mission vereint: dem Publikum zu vermitteln, dass wir durch diesen Ansatz, dieses Werkzeug, diese Methode, diesen Prozess oder diese Art des Testens die Produktqualität beeinflusst und das Leben der Kunden verbessert haben.
Wir werden definitiv keine Vorträge über Werkzeuge nur um der Werkzeuge willen haben. Alle Vorträge, die im Programm enthalten sind, werden ein gemeinsames Ziel verfolgen.
— Wer wird an dem interessiert sein, worüber du sprichst? Wen siehst du als Gäste der Konferenz?
Anastasia: Wir werden Vorträge für Entwickler haben, die um das Schicksal ihres Projekts, Produkts oder Systems besorgt sind. Ebenso wird es für Tester interessant sein und, wie ich denke, insbesondere für Manager. Mit Managern meine ich Personen, die Entscheidungen treffen und das Schicksal sowie die Entwicklung des Produkts, Systems und Teams beeinflussen können.
Das sind die Menschen, die sich fragen, wie sie die Produktqualität und die Systeme verbessern können. Auf unserer Konferenz werden sie verschiedene Maßnahmen kennenlernen und verstehen, was jetzt nicht stimmt und was geändert werden muss.
Ich denke, das Hauptkriterium ist das Bewusstsein, dass mit der Qualität etwas nicht stimmt, und der Wunsch, darauf Einfluss zu nehmen. Wahrscheinlich werden wir es nicht schaffen, beim ersten Mal die Menschen zu erreichen, die glauben, dass alles gut so ist.
— Was denkst du, hat die Branche im Allgemeinen den Reifegrad erreicht, um nicht nur über Tests, sondern auch über eine Kultur der Qualität zu sprechen?
Anastasia: Ich glaube, sie hat es erreicht. Viele Unternehmen wenden sich derzeit vom traditionellen Waterfall-Ansatz hin zu Agile. Es gibt eine Ausrichtung auf den Kunden, und die Menschen in den Teams beginnen wirklich darüber nachzudenken, wie sie ein qualitativ hochwertiges Produkt erstellen können. Selbst in Enterprise-Unternehmen findet eine Umorientierung zur Qualitätssteigerung statt.
Anhand der Anzahl der Anfragen, die in der Gemeinschaft auftauchen, denke ich, dass es bereits an der Zeit ist. Ich bin mir zwar nicht sicher, ob es eine großangelegte Revolution sein wird, aber ich würde mir wünschen, dass dieser Umbruch im Bewusstsein stattfindet.
— Wir haben einen Deal! Wir werden die Kultur fördern und das Bewusstsein verändern.
Konferenz über die qualitativ hochwertige Entwicklung von IT-Produkten stattfinden in Moskau am 7. Juni. Wissen Sie, aus welchen Phasen ein qualitativ hochwertiges Produkt besteht, wir haben erfolgreiche Beispiele für den Umgang mit Bugs in der Produktion und haben in unserer Praxis bewährte Methoden getestet — wir benötigen Ihre Erfahrung. Ihre Bewerbungen bis zum 1. Mai, und das Programmkomitee hilft dabei, das Thema für die allgemeine Kohärenz der Konferenz zu fokussieren.
Treten Sie dem , in dem wir Fragen zur Qualität und zur Konferenz diskutieren, abonnieren Sie , um über Neuigkeiten im Programm informiert zu bleiben.
Quelle: habr.com
