DevOps - OK, aber was tun? So reduzieren Sie die Handarbeit und erzielen das gewünschte Ergebnis

Also Im Jahr 2018 hielt Baruch Sadogursky (Developer Advocate bei JFrog) auf der Heisenbug (Moskauer Testkonferenz) eine interessante Keynote, in der er über seine Grundgedanken sprach, wohin er gehen sollte. Im Jahr 2019, zur gleichen Zeit wie Heisenbug, fand eine Fortsetzung seines Berichts über das WIE statt, um dieses Ziel zu erreichen. Einerseits möchte ich die Version der Bewegung von B. Sadogursky unterstützen, die er ausgestrahlt hat, aber zum einen weiß ich es immer noch nicht, und zum anderen werde ich es wagen, meine Vision zu formulieren und meinen persönlichen Weg auf der Grundlage meiner eigenen Erfahrung zu beschreiben.

Gegeben

Für den Kontext (er ist fiktiv und jedes Zusammentreffen mit realen Fällen ist ein reiner Zufall) werden wir einem regionalen IT-Anbieter eine ziemlich große Entwicklungseinheit vorstellen. Innerhalb dieser Einheit gibt es eine Testfunktion, die aus 30 Personen mit unterschiedlichen Kenntnissen und Fähigkeiten besteht.

Gesellschaft

Das vorgestellte Unternehmen verfügt über mehrere Produkte, die seit langem im Handel sind, und die anfängliche Phase ihrer Entwicklung wurde vor mehr als 7-8 Jahren abgeschlossen. Da das Unternehmen ein Anbieter ist, überwacht es seine Produkte und entwickelt sie regelmäßig weiter, erstellt sie jedoch nicht von Grund auf neu. Dies bedeutet, dass die Produkte eine große Menge an Legacy-Code sowie "alte" technologische und architektonische Lösungen enthalten. Das Testen dieser Produkte in der Anfangsphase wurde nicht in Betracht gezogen, bevor ihre Entwicklung nach dem Prinzip "schneller, schneller und in der Produktion" durchgeführt wurde, aber heute gibt es eine große Menge manueller Tests - sowohl Regression als auch Testen neuer Funktionen. Ideologisch erfolgt die Produktentwicklung unter dem Druck der Geschäftsanforderungen, sodass keine Zeit bleibt, Ideologien zu überdenken und die Produkte selbst zu überarbeiten. Dies geschieht nur in dem Moment, in dem jeder versteht, dass dies nicht weiter als „vollständig“ funktioniert.

Neben alten Produkten entwickelt das Unternehmen unter Einsatz neuester Technologien und architektonischer Ansätze völlig neue Lösungen. Aber hier ist nicht alles glatt, da der allgemeine Druck von den Bedürfnissen des Geschäfts nicht nachlässt. Das Testen solcher Projekte ist bereits in der frühen Entwicklungsphase vorhanden, es gibt jedoch immer noch "manuelle Lösungen", die die schnellsten Ergebnisse liefern und es Entwicklern ermöglichen, ausschließlich Produktcode zu schreiben, ohne darüber nachzudenken, wie er getestet wird.

Testfunktion

Nun noch ein paar Worte zur Struktur: Wie gesagt, ca. 30 Personen sind Teil der Testfunktion. Von diesen ist 17-19 der Junior Link mit Erfahrung in diesem Bereich von nicht mehr als 1 Jahr. Oft sind dies Menschen ohne technische Ausbildung, aber mit „brennenden Augen“ und einem großen Wunsch, im IT-Bereich zu arbeiten (warum sie diesen Wunsch haben, ist ein gesondertes Diskussionsthema). Die restlichen 11-13 Personen sind die leitenden und mittleren Manager: 3-4 Personen repräsentieren die leitenden und 7-10 Personen - der Durchschnitt. Die gesamte Testfunktion ist auf 13-15 verschiedene Produkte / Projekte mit unterschiedlichem Grad an Beteiligung, Komplexität und Beteiligung verteilt.

Kultur

Dies ist die letzte Einführung.

Leider gibt es immer noch ein Missverständnis über den Wert, den die Testfunktion bringen kann. Dies liegt daran, dass das Ergebnis der Arbeit in Form (zum Beispiel) eines neuen Features für alle sichtbar, verständlich und praktisch „greifbar“ ist - wenn es implementiert wird, steigt die Gesamtqualität des Produkts, und es wird zumindest für die Produkte des Unternehmens nicht peinlich. Gleichzeitig gibt es einen gewissen Entwicklerkult, in dem die folgenden Aussagen zutreffen: "Der Entwickler ist der Hauptakteur, und wenn er nicht da ist, kann der Rest gefeuert werden" sowie "Entwickler sind eine teure Ressource und sollten nur Produktcode schreiben und nicht durch unwichtige Aktivitäten abgelenkt werden." ". Aufgrund dieser Aussagen hat sich in diesem Unternehmen eine bestimmte „Kultur“ gebildet.

Erklärung des Problems

Und wie sie sagen, wo liegt das Problem? Warum etwas ändern, wenn alles so funktioniert? Warum irgendwohin ziehen, wenn es ein funktionierendes Modell gibt, das sich auszahlt?

Diese Fragen können sich logischerweise bei einer Person stellen, die für die gesamte Entwicklung bezahlt. Aber es gibt diese 3-4 Personen in der Testfunktion, die sich als unterschätzt betrachten, die den ersten Bericht von B. Sadogursky gesehen haben und nicht nur die Gegenseite der Situation sehen und ändern möchten, was passiert, um ein paar zu lösen kranke “Probleme.

Next - pure Fantasie und Vorschläge basierend auf Materialien verschiedener Autoren und Spezialisten im IT-Bereich.

Lösung (möglich)

Beginnen wir mit der Definition von Zielen und Vorgaben im Rahmen des Wandels. Wir werden die kaufmännische Seite bewusst weglassen und nicht ansprechen, dies ist ein eigenständiges Thema für den holivar, zumal es in der aktuellen Situation dieses Unternehmens eine bedeutende Rolle spielte.

Wir zeichnen ein Bild von der Zukunft. Was streben wir an?

Zunächst möchten wir in kurzer Zeit einen Pool an hochwertigen (!) Produkten haben, die einen relativ hohen Gewinn bringen. Sie müssen verstehen, dass „rentabel“ nicht „Qualität“ bedeutet.

Was müssen wir tun, um das Ziel zu erreichen? Als erstes schlage ich vor, den Weg aus der Sicht der Technologie und nicht des Handels zu betrachten. Um das Ziel zu erreichen, ist es notwendig, sich auf die Tatsache zu konzentrieren, dass die Produkte die Bedürfnisse der Endbenutzer befriedigen müssen und gleichzeitig niedrige Kosten sowohl für die Entwicklung neuer Funktionen als auch für die Wartung der bereits in der Produktion befindlichen Funktionen verursachen. Das heißt, während der Entwicklung müssen wir: a) den Bewegungsvektor klar verstehen, b) die Produkte so zuverlässig machen, dass es keine Probleme mit ihrer Funktionsweise gibt, einfach ausgedrückt, sicherstellen, dass beim Arbeiten mit dem Produkt keine Fehler auftreten. Auf dieser Grundlage sollten wir für alle Produkte die sogenannte Zero Bug Policy haben, dh unsere Tests als Prozess sollten uns die Garantie geben, dass keine Produktionsfehler auftreten.

Der zweite Aspekt ist die Fokussierung auf das Endergebnis des gesamten Entwicklungsprozesses, wodurch wir nicht entwickeln können, was der Benutzer nicht verwenden kann oder nicht verstehen kann, wie er es verwendet. Wir erwähnen den zweiten Teil nur beiläufig, weil das Thema sehr umfangreich ist, aber es wird nicht funktionieren, ohne es zu berühren.

Daher lautet unser Ziel: " Schnell, effizient und zu einem vernünftigen Preis " (kostengünstig, höchstwahrscheinlich können Sie dies nicht sofort tun).

Versuchen wir nun zu korrelieren, was mit dem beabsichtigten Zweck angegeben wurde.

Schnell . Ja, das ist möglich, aber wir gefährden die Qualität: Bestehende manuelle Qualitätssicherungsprozesse können nur bei kleinen Produkten mit einfachen User Stories eine ausreichende Ausführungsgeschwindigkeit gewährleisten. Darüber hinaus ist das Unternehmensprofil die Entwicklung komplexer Lösungen zur Automatisierung von Geschäftsprozessen. Fazit - „schnell“ funktioniert nicht, da manuelle Arbeit in großen Mengen von vornherein an einer automatisierten Lösung scheitert.

Konzentrieren Sie sich auf das Ergebnis . Es ist möglich, aber es erfordert, dass die Teilnehmer den Wert eines ausreichend tiefen Eintauchens in den Themenbereich und einen großen Zeitaufwand für die Übermittlung dieses Werts an den endgültigen Ausführenden erzeugen. Gleichzeitig sind Darsteller Entwickler, die im Rahmen einer der Anweisungen die maximale Zeit für das Schreiben von Code aufwenden sollten, ohne von der Umgebung abgelenkt zu werden.

Daraus folgt, dass zur Lösung des Hauptproblems nicht nur QS-Experten, sondern auch Entwickler in den Testprozess einbezogen werden müssen. Um die Geschwindigkeit der Lieferung von Wert zu erhöhen, ist es gleichzeitig erforderlich, die Prozesse der Lieferautomatisierung und der Automatisierung der Überprüfung des Liefergegenstandes genauer zu betrachten.

Was muss getan werden, um das Hauptproblem zu lösen?

Erfahrungsgemäß erfordert es meiner Meinung nach:

1. Tauchen Sie Entwickler mehr in die Produktziele ihres Produkts ein.
   
2. Unternehmen davon zu überzeugen, dass Automatisierungskosten wichtig sind und mehr wirtschaftliche Vorteile für alle wirtschaftlichen Kosten bieten.
   
3. Es ist ratsam, alles zu automatisieren, was automatisiert werden kann, um manuelle Arbeit vom Wertschöpfungsprozess bis zum Maximum auszuschließen.
   
4. Implementieren Sie die Zero Bug Policy, ohne die Benutzer auf Probleme stoßen, die unsere Produkte abstoßen. Ein erfolgreiches Beispiel für "DoDo" legt übrigens nahe, dass dies durchaus erreichbar ist.
   

Was müssen wir tun, um die Teilnehmer von der Notwendigkeit zu überzeugen, Einstellungen und Weltanschauungen zu ändern?

Entwickler

Wie man argumentiert - warum müssen sie etwas anderes als ihre Lieblingsprogrammierung für Funktionscode tun? Ich schlage vor, mich direkt auf die Probleme zu konzentrieren, die bei einer solchen Organisation auftreten. Es gibt mehrere von ihnen:

1. Entwickeln, was niemand braucht. IMHO, das ist eines der ersten Probleme. Die Entwickler tun etwas und vertrauen darauf, dass sie es richtig machen, aber am Ende erhalten sie das falsche Ergebnis, das der Endbenutzer wollte. Warum? Denn Aufgaben und Probleme werden ihnen nicht von denen übertragen, die das Produkt letztendlich nutzen, sondern von Managern oder Kunden, die diese Produkte später nicht nutzen. Warum passiert das? Alle Menschen haben unterschiedliche Ansichten. Wenn der Entwickler keine rein technische, sondern eine funktionale Aufgabe mit einer Beschreibung des Ergebnisses am Ausgang (und noch besser - mit einer Beschreibung des Problems, das diese Aufgabe lösen sollte) gestellt würde, gäbe es ein besseres Verständnis für das Ergebnis und infolgedessen die Anzahl der Fälle, in denen etwas entwickelt wurde unnötig wäre reduziert. Ja, das ist eine bekannte Wahrheit, aber das Problem ist immer noch nicht gelöst, es muss mit dem Unternehmen gelöst werden, was die Formulierung der Aufgaben für die Entwicklung auf eine etwas andere Weise rechtfertigt. Darüber, wie dies dem Unternehmen vermittelt werden kann - weiter.
   
2. Die Notwendigkeit, zwischen Kontexten zu wechseln. Während des Entwicklungsprozesses mit manuellen Tests sind die Testergebnisse häufig zu spät, sodass der Entwickler durch die Lösung von Problemen abgelenkt werden muss, die sich aus Tests ergeben. Was hindert Entwickler daran, nach der Implementierung ihr eigenes Ergebnis zu überprüfen? Es gibt zwei Punkte. Zum einen mangelt es an Kenntnissen und Fähigkeiten im Bereich der Qualitätssicherung. Die zweite - Entwickler denken oft, dass dies nicht ihre Aufgabe ist, und aus diesem Grund wollen sie es nicht tun. In einem der frühen Podcasts von RadioQA gibt es eine ganze Ausgabe über die Entwicklung ohne Tester, die diesen Effekt und die Gründe für diese "Zurückhaltung" ausführlich genug beschreibt.
   

Wie helfen Tests Entwicklern, die angegebenen Probleme zu lösen?

1. Informieren Sie sich über den Themenbereich oder den Zweck der zu lösenden Aufgaben. Was sind die typischen Fragen, die ein Entwickler bei der Einführung einer Aufgabe stellt? „Wie geht das?“ „Und was ist hier zu tun?“ „Und wie geht das, obwohl nur dies bekannt ist?“ „Und wie wirkt sich das auf diese Funktion aus?“ Alle diese Fragen haben zum Ziel , die Umsetzung der Aufgabe zu klären , und die Variabilität dieser Aufgabe nicht zu verstehen. Was macht ein Tester, wenn er eine neue Beschreibung einer neuen Funktion kennt? Er stellt auch Fragen, aber auf eine etwas andere Weise: „Was wird passieren, wenn?“ „Warum sollte das so sein?“ „Was soll ich am Ende bekommen?“ „Was habe ich am Anfang?“ „Wie soll das zusammenhängen? damit? " Das heißt, fast alle Fragen zielen darauf ab , das Benutzerszenario genau zu identifizieren und das Ergebnis dieser Funktion zu verstehen.
   
   Was ist wichtig? Indem Sie nicht nur klarstellende Fragen stellen (wie implementiert werden soll), sondern auch Fragen, die auf das Verständnis des Endergebnisses abzielen, können Sie mehr Informationen über die Aufgabe erhalten und die erwarteten nicht nur vertrauten, sondern auch einfacheren und effektiveren Methoden anwenden. In einem positiven Szenario hilft dies, keinen zusätzlichen Code zu schreiben oder genau das zu erstellen, was der Endbenutzer benötigt, was wir auch brauchen.
   
   Jemand wird fragen: "Warum sollte ich als Entwickler interessiert sein oder darüber nachdenken?" Wir werden antworten - um uns nicht „zum Tisch“ zu entwickeln. Die Ergebnisse einer Umfrage unter Entwicklern in meiner Umgebung zeigen, wie demotivierend es ist, wenn Sie etwas tun, es aber nicht freigeben (in ein Regal stellen).
   
2. Eine andere Frage: "Warum muss ich als Entwickler testen, wenn wir Tester haben?" Oder "Warum muss ich zusätzlichen Code entwickeln, der die festgelegten Produktaufgaben nicht erfüllt?" Hier können Sie noch etwas anbieten. Automatisierte Tests sind im Wesentlichen derselbe Code, der mit einer leichten Nuance den gleichen Programmiergesetzen folgt. Wenn ein Entwickler im Rahmen eines großen Produkts arbeitet, muss er die im Produkt ausgewählten Entwicklungsregeln und -technologien einhalten und in der Sprache schreiben, in der dieses Produkt für die Verwendung der in diesem Produkt verwendeten Frameworks geschrieben wurde. Dies ist beim Schreiben eines Tests nicht erforderlich: Niemand zwingt Sie, dieselbe Sprache oder dieselben Ansätze zu verwenden. Wenn Sie automatisierte Tests implementieren, können Sie auf einfache Weise eine völlig neue Sprache ausprobieren und Erfahrungen damit sammeln.
   
   Es gibt eine einfache Regel, die Entwickler beim Schreiben von Produktcode einhalten: die maximale Optimierung Ihrer Arbeit, den optimalen Ressourcenverbrauch, die optimale Leistung, (vorzugsweise) die maximale Wiederverwendung und so weiter. Bei der Entwicklung automatisierter Tests gibt es auch Regeln, es gibt Vorlagen, es gibt Frameworks, aber sie sind unterschiedlich. Ihre Aufgabe ist es, ihnen zu ermöglichen, den Testcode so schnell wie möglich zu erstellen, was funktionieren wird ... Es wird einfach funktionieren.
   
   Optimierung und Geschwindigkeit der Ausführung in Autotests sind sekundäre Punkte und werden nicht sofort erinnert. Wenn Sie es also plötzlich mit Kotlin, Java oder einer anderen Sprache versuchen möchten, das Projekt jedoch in einer völlig anderen Sprache als gewünscht geschrieben ist (z. B. in C #), können Sie es durch Entwickeln von Autotests in die gewünschte Sprache ändern.
   
3. „Wie teste ich? Ich verstehe nichts davon. Ich bin nur ein Entwickler. " Hier kommen Tester zur Hilfe, oder besser gesagt QS-Ingenieure, die alle Technologien kennen, auf denen das Hauptprodukt basiert. Dank ihres Wissens können sie Entwicklern beibringen, wie und was zu testen ist, wie die richtigen Daten ausgewählt werden, was der Datengenerator tun sollte, um Risiken nach Typ zu minimieren, und worauf Sie überhaupt nicht achten sollten. In einem solchen Tandem machen Tester das Beste aus ihrem Wissen, und Entwickler leisten keine unnötigen und unnötigen Arbeiten.
   
4. „Aber was ist mit der Geschwindigkeit? Sie leidet! " Ja, sie wird in den frühen Phasen der Projektentwicklung leiden, und natürlich ist es von Anfang an teuer, sich in die Vollautomatisierung zu stürzen. Was tun, damit die Kosten optimal sind? Zumindest müssen wir klar verstehen, wie und was zu automatisieren ist. Und es macht auch Sinn, nicht alles mit Tests sorglos zu schließen und eine 100% ige Abdeckung des Codes anzustreben, sondern dies anhand des Risikomodells zu tun. QS-Ingenieure werden dasselbe tun.
   
5. „Geschwindigkeit! Wir wollen schnell genug liefern. Wir möchten auch vertrauenswürdig sein und unsere Produkte waren fehlerfrei! “ Hier schlage ich vor, die Herangehensweise an die Entwicklung zu ändern. Wenn es früher in Mode war, alles lokal im Debug-Modus auszuführen, ist heute für ernsthafte Anwendungen häufig eine gewisse Infrastruktur erforderlich, um zu funktionieren. Hier bieten sich alle neuen Trends rund um die Dockerisierung und die Umsetzung verschiedener Stände an. Eine andere Sache ist wichtig: Schon in der ersten Entwicklungsphase müssen Sie darüber nachdenken, wie es an die Arbeitsstände geliefert wird, dh nicht nur alles von Hand bereitstellen, sondern einen automatisierten Bereitstellungsprozess einrichten. Was wird es uns geben? Wenn der Zeitpunkt für die Lieferung an die Produktion gekommen ist, reicht es aus, nur den Berechnungspunkt zu ändern und nicht den gesamten Prozess von Grund auf neu zu konfigurieren. Was wird dies dem Entwickler geben? Mehr Vertrauen, dass er alles richtig macht, weil die Übermittlungsskripte mehr als eine Runde geprüft wurden und es keine Probleme mit der Veröffentlichung geben sollte.
   

Geschäft

Aber was ist mit dem Geschäft? Warum sollte er sich für diese Transformation interessieren? Warum ist es für ihn sinnvoll, in diesen Ansatz zu investieren? Wenn ich die Erklärung aufbaue, gehe ich den gleichen Weg. Welche Probleme hat dieses Unternehmen derzeit, welche Probleme müssen Sie bei der Arbeit im IT-Bereich und bei der Entwicklung von Hightech-Produkten lösen? Auch hier werde ich mich genau auf meine Meinung verlassen:

1. "Was passt vielleicht nicht zum Geschäft?" Oft wird bei der Entwicklung vergessen, dass das Produkt nicht nur entwickelt, sondern auch verkauft werden muss, wofür ein ausreichend umfangreiches Maßnahmenpaket erforderlich ist, einschließlich der Vorbereitung auf den Markteintritt. — , , .
   
   « , ? ?» . , . , , . , . , ( ) .
   
2. « ?» , . , , , , .. , . , .
   
   « ( ) ?» — . — . , . , , , , . , . Warum ist das wichtig? . , , « , , , » , , .
   
3. — . , . , , . , .
   
   ? , - . . , , , . , , , , , . , .
   

, « ». ?

1. , , , , . : X Y , , , X Z , Z < Y. : , , ( ) .
   
2. — QA-. , «» . , QA- , , , . : , , , , , .
   — , . . , , , , , , , , , . .
   
3. — . , , . , , , , . , QA-. , . , , «» — , , , . , , .
   
4. , , — (, , - ). . , . , , , , , (), .
   

— , . , , , , . , , , « » — . , .

Mach weiter. .

? , 90% , 60% , .

, . , , - . , . , , , , — , .

«» , . «» , QA-. , — . , , ShiftLeft- QA- , - , QA- .

- . , . .