{"id":31264,"date":"2019-10-31T21:40:21","date_gmt":"2019-10-31T18:40:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kto-otvetit-za-kachestvo\/"},"modified":"2019-10-31T21:40:21","modified_gmt":"2019-10-31T18:40:21","slug":"kto-otvetit-za-kachestvo","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/kto-otvetit-za-kachestvo","title":{"rendered":"Wer ist verantwortlich f\u00fcr die Qualit\u00e4t?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hallo, Habra!<\/p>\n

Wir haben ein neues wichtiges Thema \u2013 die qualitativ hochwertige Entwicklung von IT-Produkten. Wir sprechen oft auf HighLoad++, dar\u00fcber, wie man belastbare Dienste schnell macht, und auf der Frontend Conf \u2013 \u00fcber gro\u00dfartige Benutzeroberfl\u00e4chen, die nicht ruckeln. Regelm\u00e4\u00dfig haben wir Themen \u00fcber Testing und bei DevOpsConf \u00fcber die Integration verschiedener Prozesse, einschlie\u00dflich Testing. Was die Qualit\u00e4t als Ganzes betrifft und wie man wirklich umfassend daran arbeitet \u2013 dar\u00fcber gibt es nichts.<\/p>\n

Wir werden das \u00e4ndern in QualityConf<\/a><\/noindex>\u00a0\u2013 wir werden die Kultur f\u00f6rdern, \u00fcber die Qualit\u00e4t des Endprodukts f\u00fcr die Benutzer in jeder Phase der Entwicklung nachzudenken. Die Gewohnheit, sich nicht nur auf das eigene Verantwortungsbereich zu beschr\u00e4nken, und Qualit\u00e4t nicht nur mit Testern zu assoziieren.<\/p>\n

Im Folgenden sprechen wir mit der Vorsitzenden des Programmkomitees, der Leiterin der Testing-Abteilung bei Tinkoff.Biz, der Sch\u00f6pferin der russischsprachigen QA-Community Anastasia Aseeva-Nguyen<\/b> \u00fcber den Zustand der QA-Branche und die Mission der neuen Konferenz.<\/p>\n

\"Wer
\n<\/a><\/noindex>
\n\u2013 Nastya, hallo. Erz\u00e4hl bitte etwas \u00fcber dich.<\/em><\/strong><\/p>\n

\"WerAnastasia<\/strong>: Ich leite das Testing bei der Bank und bin verantwortlich f\u00fcr eine sehr gro\u00dfe Mannschaft \u2013 wir sind \u00fcber 90 Personen. Wir haben eine wichtige Gesch\u00e4ftslinie, wir sind verantwortlich f\u00fcr das \u00d6kosystem f\u00fcr juristische Personen.<\/p>\n

Ich habe Mathematik und Mechanik studiert und wollte urspr\u00fcnglich Programmiererin werden. Aber als ich ein interessantes Angebot bekam, habe ich mich entschieden, es als Testerin auszuprobieren. Merkw\u00fcrdigerweise stellte sich heraus, dass das meine Berufung war. Jetzt sehe ich meine gesamte Arbeit genau in dieser Branche.<\/p>\n

Ich bin ein \u00fcberzeugter Verfechter der Quality Assurance-Disziplin. Mir liegt es am Herzen, welche Produkte erstellt werden, wie zur Qualit\u00e4t im Unternehmen, im Team und im Allgemeinen im Entwicklungsprozess steht.<\/p><\/blockquote>\n

\nEs ist mir offensichtlich, dass die Community in diesem Bereich nicht ausreichend reif ist<\/strong>, zumindest in Russland. Nicht immer verstehen wir, dass Qualit\u00e4tssicherung nicht nur das Testen der Anwendung auf die Einhaltung der Anforderungen ist. Ich m\u00f6chte diese Situation \u00e4ndern.<\/p>\n

\u2013 Du verwendest die Begriffe Quality Assurance und Testing. In den Augen der \u00d6ffentlichkeit \u00fcberschneiden sich diese beiden Begriffe sehr oft. Wo liegt der Unterschied, wenn man tiefer gr\u00e4bt?<\/em><\/strong><\/p>\n

Anastasia:<\/strong> Im Wesentlichen unterscheiden sie sich nicht. Testing ist ein Teil der Disziplin Qualit\u00e4tssicherung, es ist eine unmittelbare Aktivit\u00e4t \u2013 die Tatsache, dass ich etwas teste. Es gibt tats\u00e4chlich sehr viele Arten des Testens, und f\u00fcr 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.<\/p>\n

In den meisten F\u00e4llen beschr\u00e4nkt man sich nur auf funktionales Testen: Man \u00fcberpr\u00fcft, ob das, was die Entwickler programmiert haben, der Spezifikation entspricht und das war's.<\/p>\n

\u2014 Erz\u00e4hle bitte, welche anderen Disziplinen der Qualit\u00e4tssicherung es noch gibt? Was geh\u00f6rt au\u00dfer dem Testen noch dazu?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Qualit\u00e4tssicherung dreht sich in erster Linie um die Schaffung eines qualitativ hochwertigen Produkts. Das hei\u00dft, wir stellen uns die Frage, welche Qualit\u00e4tsmerkmale unser Produkt haben sollte. Wenn wir das verstehen, k\u00f6nnen wir feststellen, wer diese Qualit\u00e4tsmerkmale beeinflusst. Es spielt keine Rolle, ob Entwickler, Projektmanager oder Produktverantwortlicher<\/strong>\u00a0\u2014 das ist die Person, die das Produkt, sein Backlog und seine Strategie beeinflusst.<\/p>\n

Der Tester beginnt, seine Rolle besser zu erkennen. Er versteht, dass seine Aufgabe nicht nur darin besteht, auf \u00dcbereinstimmung 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\u00e4ten bieten, m\u00fcssen wir wirklich seine Erwartungen erf\u00fcllen und sein Problem l\u00f6sen. Wenn wir an alle Qualit\u00e4tsmerkmale denken, wird der Kunde zufrieden sein und verstehen, dass das Unternehmen, dessen Produkt er nutzt, tats\u00e4chlich an seinen Interessen interessiert ist und nicht nach dem Prinzip \u201ehauptsache eine Funktion herausbringen\u201c arbeitet.<\/p>\n

\u2014 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\u00e4t \u2013 das ist ganz allgemein das Produktmanagement, oder?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Unter anderem. Qualit\u00e4tssicherung ist keine Disziplin, f\u00fcr die eine bestimmte Person verantwortlich ist. Aktuell gibt es einen popul\u00e4ren Ansatz im Testen, der als Agile Testing<\/strong>. In seiner Definition steht ausdr\u00fccklich, dass es sich um einen teamorientierten Ansatz f\u00fcr das Testen handelt, der einen bestimmten Satz von Praktiken umfasst. Die Verantwortung f\u00fcr 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.<\/p>\n

\u2014 Das bedeutet, dass die Qualit\u00e4t nahezu alle umliegenden Disziplinen ber\u00fchrt und Rahmenbedingungen f\u00fcr alles um uns herum setzt?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Richtig. Wenn wir dar\u00fcber nachdenken, ein qualitativ hochwertiges Produkt zu schaffen, beginnen wir, \u00fcber verschiedene Qualit\u00e4tsattribute nachzudenken. Zum Beispiel, wie wir \u00fcberpr\u00fcfen k\u00f6nnen, dass wir wirklich eine Funktion umgesetzt haben, die unserem Kunden ben\u00f6tigt.<\/p>\n

Hier kommt eine Art von Testen ins Spiel, die UAT<\/strong> (User Acceptance Testing) genannt wird. Leider wird dies in Russland selten praktiziert, ist aber manchmal in SCRUM-Teams als Demo f\u00fcr den Endkunden vorhanden. In ausl\u00e4ndischen Unternehmen ist dies eine weit verbreitete Testform. Bevor wir die Funktionalit\u00e4t f\u00fcr alle Kunden freigeben, f\u00fchren wir zuerst UAT durch, das hei\u00dft, wir laden den Endverbraucher ein, der das Testen durchf\u00fchrt und sofort Feedback gibt \u2013 ob das Produkt wirklich den Erwartungen entspricht und ein Problem l\u00f6st. Erst danach erfolgt das Scaling f\u00fcr alle anderen Kunden.<\/p>\n

Das hei\u00dft, wir orientieren uns am Gesch\u00e4ft, am Endkunden, aber dabei vergessen wir nicht die Technologie<\/strong>. Auch die Technologie hat einen gro\u00dfen Einfluss auf die Qualit\u00e4t des Produkts. Wenn wir eine schlechte Architektur haben, k\u00f6nnen wir keine Funktionen schnell ver\u00f6ffentlichen und den Erwartungen des Kunden entsprechen. Es kann viele Fehler geben, wenn wir versuchen zu skalieren, oder beim Versuch, Refactoring durchzuf\u00fchren, k\u00f6nnen wir etwas kaputtmachen. Das alles wird sich auf die Zufriedenheit des Kunden auswirken.<\/p>\n

Aus dieser Sicht sollte die Architektur so beschaffen sein, dass wir sauberen Code schreiben k\u00f6nnen, der es uns erm\u00f6glicht, schnell \u00c4nderungen vorzunehmen und keine Angst zu haben, dass wir alles zerbrechen. Damit die Iterationen der \u00dcberarbeitung sich nicht \u00fcber mehrere Monate hinziehen, nur weil wir so viel Legacy haben und lange Testphasen erforderlich sind.<\/p>\n

\u2014 Also sind bereits Entwickler, Architekten, Produktmanager, Product Owner, die Tester selbst, eingebunden. Wer ist noch am Prozess der Qualit\u00e4tssicherung beteiligt?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Stellen wir uns vor, dass wir das Feature bereits an den Kunden geliefert haben. Es ist offensichtlich, dass die Qualit\u00e4t des Produkts \u00fcberwacht werden muss, auch wenn es bereits in der Produktion eingesetzt wird. In dieser Phase k\u00f6nnen Situationen mit nicht offensichtlichen Szenarien, die sogenannten Bugs, auftreten.<\/p>\n

Die erste Frage ist: Wie gehen wir mit diesen Bugs um, nachdem wir das Produkt bereits ver\u00f6ffentlicht haben? Wie reagieren wir zum Beispiel auf Lasten? Der Kunde wird nicht sehr zufrieden sein, wenn die Seite l\u00e4nger als 30 Sekunden l\u00e4dt.<\/p>\n

Hier kommt der Betrieb ins Spiel oder, wie man heute sagt, DevOps<\/strong>. Tats\u00e4chlich sind das die Personen, die f\u00fcr den Betrieb des Produkts verantwortlich sind, wenn es schon in der Produktion ist. Dazu geh\u00f6rt eine Vielzahl von Monitoring-Methoden. Es gibt sogar eine Unterkategorie des Testens \u2013 das sogenannte Testing in der Produktion, bei dem wir uns erlauben, etwas nicht bis zur Ver\u00f6ffentlichung zu testen und es sofort in der Produktion testen. Dies umfasst eine Reihe von Ma\u00dfnahmen aus Sicht der Infrastrukturorganisation, die es erm\u00f6glichen, schnell auf einen Vorfall zu reagieren, darauf Einfluss zu nehmen und ihn zu beheben.<\/p>\n

Die Infrastruktur ist ebenfalls wichtig. Oft gibt es Situationen, in denen es w\u00e4hrend der Tests nicht m\u00f6glich ist zu \u00fcberpr\u00fcfen, dass wir tats\u00e4chlich alles haben, was wir dem Kunden zur Verf\u00fcgung stellen wollten. Wir rollen es in der Produktion aus \u2013 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 \u2013 Infrastruktur-Testing<\/strong>. Dazu geh\u00f6ren verschiedene Konfigurationen, Einstellungen, Migration von Datenbanken usw.<\/p>\n

Daraus ergibt sich die Frage \u2013 vielleicht muss das Team Infrastruktur als Code verwenden.<\/p>\n

Ich glaube, dass die Infrastruktur einen direkten Einfluss auf die Qualit\u00e4t des Produkts hat.<\/p><\/blockquote>\n

\nIch 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\u00e4hlen, wie Infrastruktur als Code die Qualit\u00e4t beeinflusst. Infrastruktur als Code erm\u00f6glicht es, alle Einstellungen einfacher zu \u00fcberpr\u00fcfen und das zu testen, was andernfalls einfach unm\u00f6glich w\u00e4re. Daher wird auch der Betrieb in den Prozess der Entwicklung eines hochwertigen Produkts einbezogen.<\/p>\n

\u2013 Und was ist mit der Analyse und Dokumentation?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Das bezieht sich mehr auf Enterprise-Systeme. Wenn wir \u00fcber 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.<\/p>\n

Es wurde immer wieder nachgewiesen, dass das Schreiben solcher Dokumentationen zu sehr langen Entwicklungszyklen und ausgedehnten \u00dcberarbeitungen f\u00fchrt, weil im Testprozess Bugs entdeckt werden und R\u00fcckgaben anfangen. Infolgedessen gibt es sehr viele Schleifen, die die Entwicklungskosten erh\u00f6hen. Au\u00dferdem kann dies Sicherheitsanf\u00e4lligkeiten einf\u00fchren. Wir haben scheinbar den Referenzcode geschrieben, aber dann \u00c4nderungen vorgenommen, die die perfekt durchdachte Architektur brechen.<\/p>\n

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\u00e4ngen und alle Bugs schneller behoben werden m\u00fcssen. Das liegt daran, dass in der urspr\u00fcnglichen Spezifikation nicht alle Aspekte ber\u00fccksichtigt wurden, die implementiert werden m\u00fcssen.<\/p>\n

Entwickler sind keine \u00dcbelt\u00e4ter und schreiben nicht absichtlich fehlerhaften Code.<\/p><\/blockquote>\n

\nH\u00e4tten wir die Spezifikation von Anfang an durchdacht, in der alle notwendigen Aspekte beleuchtet worden w\u00e4ren, dann w\u00e4re alles genau so umgesetzt worden, wie es n\u00f6tig ist. Aber das ist eine Utopie.<\/p>\n

Wahrscheinlich ist es unm\u00f6glich, eine ideale Spezifikation auf 100 Seiten zu schreiben. Deshalb m\u00fcssen wir \u00fcber alternative M\u00f6glichkeiten nachdenken, Dokumentation<\/strong>, Spezifizierung und Aufgabenstellung zu schreiben, die uns n\u00e4her bringen, dass der Entwickler genau das macht, was n\u00f6tig ist.<\/p>\n

Hier fallen einem Ans\u00e4tze aus Agile ein \u2013 User Stories mit Akzeptanzkriterien. Das ist eher f\u00fcr Teams geeignet, die in kleinen Iterationen arbeiten.<\/p>\n

\u2013 Was ist mit Usability-Tests, der Benutzerfreundlichkeit des Produkts, dem Design?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Das ist ein sehr wichtiger Punkt, denn im Team gibt es Designer. Oftmals werden Designer als Service genutzt \u2013 entweder eine Designerabteilung oder ein Designer im Outsourcing. Es kommt h\u00e4ufig vor, dass der Designer scheinbar den Produktmanager geh\u00f6rt hat und das gemacht hat, was er verstanden hat. Aber wenn wir mit der Iteration beginnen, stellt sich heraus, dass tats\u00e4chlich 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\u00f6glicherweise sind mehrere Iterationen notwendig, nur weil es ein Problem mit dem Verst\u00e4ndnis des Designs durch den Frontend-Entwickler gibt.<\/p>\n

Au\u00dferdem gibt es ein weiteres Problem. Derzeit gewinnen Designsysteme an Popularit\u00e4t. Sie sind im Trend, aber ihr Nutzen ist nicht ganz offensichtlich.<\/p>\n

Ich sto\u00dfe auf die Meinung, dass Designs, einerseits, die Entwicklung vereinfachen, andererseits aber auch sehr viele Einschr\u00e4nkungen f\u00fcr die Schnittstelle auferlegen.<\/p><\/blockquote>\n

\nLetztendlich entwickeln wir nicht die Funktion, die der Kunde m\u00f6chte, sondern die, die uns bequem ist, weil wir bestimmte Bausteine bereits haben, aus denen wir sie erstellen k\u00f6nnen.<\/p>\n

Ich denke, dass es sich lohnt, auf dieses Thema zu achten und dar\u00fcber nachzudenken, ob wir wirklich die Kundenprobleme l\u00f6sen, wenn wir versuchen, die Arbeit am Design zu vereinfachen.<\/p>\n

\u2014 Es gibt erstaunlich viele Themen, die mit Qualit\u00e4tssicherung verbunden sind. Gibt es in Russland eine Konferenz, bei der man all dies besprechen kann?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Es gibt die \u00e4lteste Konferenz zur Testung, die in diesem Jahr zum 25. Mal stattfindet und einfach \"SQA Days\" hei\u00dft. In erster Linie werden dort Werkzeuge und spezifische Ans\u00e4tze zum Testen f\u00fcr funktionale Tester diskutiert. In der Regel werden auf den SQA Days spezifische Bereiche im Verantwortungsbereich der Tester detailliert behandelt, aber keine umfassenden Veranstaltungen.<\/p>\n

Es hilft sehr, sich in verschiedenen Werkzeugen und Ans\u00e4tzen 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, \u00fcber die globale Produktziele und dessen Gesch\u00e4ftsaspekte nachzudenken.<\/p>\n

Ich leite eine gro\u00dfe Abteilung, f\u00fchre viele Interviews, die es tats\u00e4chlich erm\u00f6glichen, 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\u00f6nnen Lasttests, Leistungstests und sogar manchmal Sicherheitstests durchf\u00fchren, weil sie wirklich dem Team helfen, die Produktqualit\u00e4t zu gew\u00e4hrleisten.<\/p>\n

Ich w\u00fcnschte mir, dass unsere Leute in Russland auch anfangen w\u00fcrden, dar\u00fcber nachzudenken, dass die Branche nicht mit funktionalen Tests endet.<\/p>\n

\u2014\u00a0Zu diesem Zweck organisieren wir die neue Konferenz QualityConf, die sich der Qualit\u00e4t als ganzheitlicher Disziplin widmet. Erz\u00e4hl mir mehr \u00fcber die Idee, was ist das Hauptziel der Konferenz?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Wir m\u00f6chten eine Gemeinschaft von Menschen schaffen, die daran interessiert sind, qualitativ hochwertige Produkte zu entwickeln. Eine Plattform anbieten, wo sie kommen, Vortr\u00e4ge h\u00f6ren und nach der Konferenz mit einem konkreten Verst\u00e4ndnis gehen k\u00f6nnen, was sie \u00e4ndern m\u00fcssen, um die Qualit\u00e4t zu verbessern.<\/p>\n

Ich h\u00f6re oft Anfragen aus dem Consulting, was zu tun ist, wenn es Probleme mit dem Testen und der Qualit\u00e4t 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\u00fcr das Schreiben des Codes verantwortlich sind, endet ihre Verantwortung genau in dem Moment, in dem sie die Aufgabe zum Testen \u00fcbergeben.<\/p>\n

Nicht jeder denkt dar\u00fcber nach, dass schlecht geschriebener, minderwertiger Code mit schlechter Architektur gro\u00dfe Probleme f\u00fcr das Projekt mit sich bringen kann. Sie denken nicht \u00fcber die Kosten von Fehlern nach, dar\u00fcber, dass Bugs, die in die Produktion gelangen, zu hohen Kosten f\u00fcr das Unternehmen und das Team f\u00fchren k\u00f6nnen. Es gibt keine Kultur, dar\u00fcber nachzudenken. Ich m\u00f6chte, dass wir auf der Konferenz anfangen, diese Kultur zu verbreiten.<\/p>\n

Ich verstehe, dass dies keine Innovation ist. Edward Deming, der Autor der 14 Qualit\u00e4tsprinzipien, schrieb bereits im letzten Jahrhundert \u00fcber die Kosten von Fehlern. Auf diesem Buch basiert die Qualit\u00e4tssicherung als Disziplin, aber leider vergisst die moderne Entwicklung oft dar\u00fcber.<\/p>\n

\u2014\u00a0Werden Sie auch Themen direkt zum Testen und zu Tools behandeln?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Ich gehe davon aus, dass es Vortr\u00e4ge \u00fcber Tools geben wird. Es gibt ausreichend universelle Werkzeuge, mit denen Unternehmen und Teams Einfluss auf das Produkt nehmen k\u00f6nnen.<\/p>\n

Alle Vortr\u00e4ge 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\u00e4t des Produkts beeinflusst und das Leben des Kunden verbessert haben.<\/p><\/blockquote>\n

\nWir werden definitiv keine Vortr\u00e4ge \u00fcber Werkzeuge halten, nur um der Werkzeuge willen. Alle Vortr\u00e4ge, die ins Programm kommen, werden ein gemeinsames Ziel verfolgen.<\/p>\n

\u2014\u00a0Wer wird an dem, was du sagst, interessiert sein, wen siehst du als G\u00e4ste der Konferenz?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Wir werden Pr\u00e4sentationen f\u00fcr Entwickler haben, denen das Schicksal ihres Projekts, Produkts oder Systems nicht gleichg\u00fcltig 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\u00f6nnen.<\/p>\n

Das sind Menschen, die sich fragen, wie sie die Qualit\u00e4t des Produkts oder Systems steigern k\u00f6nnen. Auf unserer Konferenz erfahren sie mehr \u00fcber verschiedene Ma\u00dfnahmenpakete und k\u00f6nnen verstehen, was jetzt nicht stimmt und was ge\u00e4ndert werden muss.<\/p>\n

Ich denke, das Hauptkriterium ist, zu erkennen, dass mit der Qualit\u00e4t etwas nicht stimmt, und den Wunsch zu haben, etwas zu \u00e4ndern. Wahrscheinlich wird es uns nicht gelingen, beim ersten Mal durchdringen zu den Menschen, die denken, dass alles schon in Ordnung ist.<\/p>\n

\u2014 Was denkst du, hat die Branche insgesamt den reifen Zustand erreicht, um nicht nur \u00fcber Tests, sondern \u00fcber eine Kultur der Qualit\u00e4t zu sprechen?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: 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\u00fcber nachzudenken, wie man ein qualitativ hochwertiges Produkt schafft. Selbst in Unternehmen der Enterprise-Klasse gibt es eine Umorientierung hin zur Verbesserung der Qualit\u00e4t.<\/p>\n

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\u00fcrde mir w\u00fcnschen, dass dieser Bewusstseinswandel stattfindet.<\/p>\n

\u2014 Vereinbart! Wir werden die Kultur vermitteln und das Bewusstsein ver\u00e4ndern.<\/em><\/strong><\/p>\n

Konferenz \u00fcber qualitativ hochwertige Entwicklung von IT-Produkten QualityConf<\/a><\/noindex> stattfinden in Moskau am 7. Juni<\/strong>. Sie wissen, aus welchen Phasen ein qualitativ hochwertiges Produkt besteht, es gibt erfolgreiche Fallstudien zur Bek\u00e4mpfung von Bugs in der Produktion, und in unserer eigenen Praxis haben wir beliebte Methoden \u00fcberpr\u00fcft \u2013 wir ben\u00f6tigen Ihre Erfahrungen. Schicken Sie<\/a><\/noindex> Ihre Anmeldungen bis zum 1. Mai<\/strong>, und das Programmkomitee wird helfen, das Thema f\u00fcr die Gesamtheit der Konferenz zu fokussieren.<\/p>\n

Treten Sie dem Chat<\/a><\/noindex>bei, in dem wir Fragen zur Qualit\u00e4t und zur Konferenz besprechen, und abonnieren Sie Telegram-Kanal<\/a><\/noindex>, um \u00fcber Neuigkeiten zum Programm informiert zu bleiben.<\/p><\/blockquote>\n

Quelle: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0423\u00a0\u043d\u0430\u0441 \u043d\u043e\u0432\u0430\u044f \u0432\u0430\u0436\u043d\u0430\u044f \u0442\u0435\u043c\u0430\u00a0\u2014 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u0430\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430 IT-\u043f\u0440\u043e\u0434\u0443\u043a\u0442\u043e\u0432. \u041c\u044b\u00a0\u0447\u0430\u0441\u0442\u043e \u0433\u043e\u0432\u043e\u0440\u0438\u043c \u043d\u0430\u00a0HighLoad++, \u043a\u0430\u043a \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u043d\u0430\u0433\u0440\u0443\u0436\u0435\u043d\u043d\u044b\u0435 \u0441\u0435\u0440\u0432\u0438\u0441\u044b \u0431\u044b\u0441\u0442\u0440\u044b\u043c\u0438, \u0430\u00a0\u043d\u0430\u00a0Frontend Conf\u00a0\u2014 \u043a\u043b\u0430\u0441\u0441\u043d\u044b\u0439 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u044c\u0441\u043a\u0438\u0439 \u0438\u043d\u0442\u0435\u0440\u0444\u0435\u0439\u0441, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u043d\u0435\u00a0\u0442\u043e\u0440\u043c\u043e\u0437\u0438\u0442. \u0423\u00a0\u043d\u0430\u0441 \u0440\u0435\u0433\u0443\u043b\u044f\u0440\u043d\u043e \u0435\u0441\u0442\u044c \u0442\u0435\u043c\u044b \u043f\u0440\u043e \u0442\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435, \u0438\u00a0DevOpsConf \u043f\u0440\u043e \u043e\u0431\u044a\u0435\u0434\u0438\u043d\u0435\u043d\u0438\u0435 \u0440\u0430\u0437\u043d\u044b\u0445 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u043e\u0432, \u0432\u043a\u043b\u044e\u0447\u0430\u044f \u0442\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435. \u0410\u00a0\u043f\u0440\u043e\u00a0\u0442\u043e, \u0447\u0442\u043e \u043c\u043e\u0436\u043d\u043e \u043d\u0430\u0437\u0432\u0430\u0442\u044c \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u043e \u0432\u00a0\u0446\u0435\u043b\u043e\u043c, \u0438\u00a0\u043a\u0430\u043a \u043d\u0430\u0434 \u043d\u0438\u043c \u043a\u043e\u043c\u043f\u043b\u0435\u043a\u0441\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c\u00a0\u2014 \u043d\u0435\u0442. \u0418\u0441\u043f\u0440\u0430\u0432\u0438\u043c \u044d\u0442\u043e \u043d\u0430 QualityConf\u00a0\u2014 \u0431\u0443\u0434\u0435\u043c \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u0442\u044c […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":23230,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-31264","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Wer ist verantwortlich f\u00fcr die Qualit\u00e4t? | ProHoster","description":"Hallo, Habr! Wir haben ein neues wichtiges Thema \u2014 qualitativ hochwertige Entwicklung von IT-Produkten.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/kto-otvetit-za-kachestvo","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u0442\u043e \u043e\u0442\u0432\u0435\u0442\u0438\u0442 \u0437\u0430 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u043e? | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0423 \u043d\u0430\u0441 \u043d\u043e\u0432\u0430\u044f \u0432\u0430\u0436\u043d\u0430\u044f \u0442\u0435\u043c\u0430 \u2014 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u0430\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430 IT-\u043f\u0440\u043e\u0434\u0443\u043a\u0442\u043e\u0432.","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/kto-otvetit-za-kachestvo","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:40:21+00:00","article:modified_time":"2019-10-31T18:40:21+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"31264","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 05:19:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 03:19:50","updated":"2026-01-21 05:19:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/31264","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=31264"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/31264\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/23230"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=31264"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=31264"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=31264"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}