Es ist selten, ein Projekt zu finden, in das Sie sich während des Interviews verlieben und auf das Sie stolz sind, wenn es neue Märkte erobert. Umso angenehmer ist es, wenn die Professionalität der Kollegen am besten ist und Sie sich in Ihrem Team wie im Busen Ihrer Familie fühlen. Ich hatte das Glück, nicht nur ein solches Projekt zu finden, sondern auch vor einiger Zeit den Testprozess darin zu beeinflussen. Ich werde Ihnen sagen, was in unserem Verständnis des optimalen Prozesses enthalten ist. wie wir zu monatlichen Veröffentlichungen kamen und wie sie für uns funktionieren; und wie wir uns an die Bedingungen der Quarantäne angepasst haben.
Unser Projekt ist ein Fernlehrsystem (LMS, Learning Management System), das von mehr als 7 Millionen Menschen in verschiedenen Ländern der Welt verwendet wird. Das System enthält mehr als 1000 Webseiten und etwa 10.000 Testfälle.
Derzeit beschäftigt das Projekt rund 15 Entwicklungsteams - vom Kunden in Norwegen und von Arcadia in Russland. Ich bin vor 8 Jahren als QS dem Projekt beigetreten. In den letzten 2 Jahren habe ich als QS-Leiter an der Optimierung des Testprozesses teilgenommen.
Was ist im Konzept eines optimalen Prozesses enthalten
Unsere Hauptaufgabe ist es, die Bedürfnisse der Endbenutzer zu erfüllen, einschließlich der Schaffung neuer Funktionen und der Systemunterstützung. Besonderes Augenmerk wird auf die Geschwindigkeit des Systems und die Stabilität der Arbeit unter Bedingungen hoher Last gelegt.
Der Entwicklungsprozess sollte in erster Linie die nachhaltige Erreichung von Geschäftszielen ermöglichen, z. B. die termingerechte und mit einem vereinbarten Qualitätsniveau abgeschlossene Arbeit. Der Prozess sollte aber auch für das Entwicklungsteam angenehm sein, damit alle am Prozess Beteiligten zufrieden sind. In unseren Teams haben wir einen optimalen Prozess für uns festgelegt, und hier sind die Mittel, mit denen dies erreicht wird.
Entwicklungsprozess im Allgemeinen:
a) Ein Entwicklungsansatz, der die Bedürfnisse des Teams erfüllt.
Wir arbeiten mit Scrum und Sprints, die 3 Wochen dauern. Vor dem Sprint findet eine Präsentation seiner Ziele statt und eine Reihe von Anforderungen für diesen Sprint werden gebildet. Als nächstes folgt die Planung, in der wir alle Aufgaben bewerten und die Aufgaben festlegen, die im Sprint enthalten sein werden. Am Ende des Sprints findet eine Sprint-Überprüfung statt, bei der wir alle erledigten Aufgaben demonstrieren und die erreichten Ziele bekannt geben. Dieser Ansatz ist für uns optimal: In einem Sprint schaffen wir es, eine ausreichende Menge neuer Funktionen zu erstellen und gleichzeitig eine bestimmte Anzahl von Fehlern von Endbenutzern zu beheben und zu testen - 10% der Sprintzeit werden für solche Fehler zugewiesen.
Ausrichten: Teamleiter, Entwickler, Tester. Das Verhältnis von Entwicklern zu Testern in unseren Teams beträgt 3: 1. Dieses Verhältnis ermöglicht es, das Sprintziel gleichmäßig zu erreichen - es gibt keine Zeiträume, in denen einer der Teilnehmer am Prozess untätig ist: Während Entwickler Änderungen vornehmen, erstellen oder aktualisieren Tester Testfälle im Zusammenhang mit dieser Änderung. Nach Abschluss der Entwicklung überprüfen die Tester die Änderungen, und die Entwickler fahren entweder mit den nächsten Aufgaben im Sprint fort oder helfen beim Testen (dies ist beim Testen umfangreicher Änderungen erforderlich).
Der Product Owner legt zu Beginn jedes Sprints Ziele und Anforderungen fest und akzeptiert diese am Ende. Außerdem verfügt jedes Team über einen Scrum Master, der bei der Lösung neu auftretender Probleme hilft.
Damit das Team verschiedene Aktivitäten ausführen kann, die nicht direkt mit den Aufgaben des Sprints zusammenhängen, und verschiedene Risiken berücksichtigt, beträgt die für die Erledigung der Aufgaben des Sprints berechnete Zeit 80% der Gesamtarbeitszeit des Teams. Das heißt, 2 Stunden pro Tag während eines regulären Sprints sind für die Kommunikation, verschiedene Besprechungen und Seminare sowie für die Behebung von Fehlern im Sprint reserviert.
b) Klare Anforderungen und gute Planung
Um sicherzustellen, dass sich die Planung nicht verzögert und der Sprint nicht aufgrund bisher unbekannter Details und mühsamer zusätzlicher Änderungen, die bereits während des Sprints hinzugefügt wurden, zum Fehlschlag wird, versuchen wir, nur Änderungen mit ausreichend klaren und präzisen Anforderungen in den Sprint einzubeziehen. Wenn der Projektbereich, der die Änderungen betrifft, dem Team nicht bekannt ist oder während der Planung viele Fragen vom Product Owner nicht beantwortet werden können, kann das Team eine Aufgabe zur Untersuchung dieses Bereichs oder eine Forschungsaufgabe sprinten, was zu klaren Anforderungen oder sogar führt eine Art Prototyp.
c) Rückblicke
Das Korrigieren von Fehlern ist ebenfalls wichtig. Dies gilt sowohl für Sprints als auch für Releases. Es kommt vor, dass wir keine Zeit für etwas haben oder Überstunden leisten müssen, um pünktlich zu sein - zum Beispiel, wenn eine Version vorab getestet werden muss (und dies sind zusätzliche Kosten, die das Unternehmen in Zukunft vermeiden möchte). Daher führen wir Retrospektiven durch, in denen wir diskutieren, was im Sprint oder Release gut und was schlecht war, und Maßnahmen entwickeln, um solche Fehler in Zukunft zu vermeiden.
d) Managementunterstützung
Manchmal treten Fragen oder Situationen auf, die auf Teamebene nicht gelöst werden können. Sie müssen den Prozess ändern oder das Management des Unternehmens in die Entscheidung einbeziehen. Es ist sehr wichtig zu sehen, dass sie Ihnen helfen wollen und bereit sind, Sie in einer solchen Situation zu unterstützen. In unserem Unternehmen ist damit alles in Ordnung - dies betrifft sowohl Arcadia als auch das Management des Kunden. Alle Probleme werden besprochen und es wird immer eine Lösung gefunden, die alle Parteien zufriedenstellt.
e) Und meiner Meinung nach ist eine gute Kommunikation von grundlegender Bedeutung. Und was wir im Unternehmen haben, ist für mich einer der Hauptvorteile komfortabler Arbeit - Wohlwollen, der Wunsch nach Kompromissen.
Dies gilt für alle: jedes Mitglied des Teams, den Product Owner, den Scrum Master, das Management des Unternehmens und viele andere Teilnehmer am Prozess. Jeder ist offen für Fragen und Diskussionen, Entwickler konsultieren Tester zu Anforderungen und entscheiden gemeinsam, wie diese oder jene Änderung am besten (sowohl aus entwicklungspolitischer als auch aus testtechnischer Sicht) vorgenommen werden kann. Der Product Owner wiederum ist ständig mit dem Team in Kontakt, löst alle Probleme umgehend und versucht immer, die Hälfte der Sprintziele zu erreichen. Der Scrum Master ist immer bereit zu helfen: zusätzliche Ressourcen zu finden (Tester / Entwickler, wenn sie für den Sprint oder die Veröffentlichung benötigt werden) oder Vorschläge zu machen, wie der Sprint am besten rechtzeitig organisiert werden kann.
Testprozess:
a) QS-Standards (Richtlinien) zum Schreiben von Testfällen.
In unserem Projekt sind Testfälle die wichtigste detaillierte Dokumentation zur Funktionalität des Systems, daher wird ihnen viel Aufmerksamkeit geschenkt. Für jede vom Team vorgenommene Änderung wird ein neuer Testfall geschrieben oder ein vorhandener aktualisiert.
Früher, als das System noch nicht so groß war, wurden Testfälle mit verschiedenen spezifischen Schritten sehr detailliert geschrieben, aber jetzt ist dieser Ansatz inakzeptabel geworden - es dauert viel Zeit, solche Testfälle zu aktualisieren. Aus diesem Grund haben wir (QS-Leiter) Standards entwickelt, deren Hauptanforderung darin besteht, Testskripte mit erwarteten Ergebnissen anstelle detaillierter Schritte in Testfällen zu schreiben.
b) QS-Standards für Sprinttests.
Sprint-Teststandards wurden entwickelt, um sicherzustellen, dass jedes Team gute Qualitätsänderungen vornimmt.
Diese Standards basieren auf der maximalen Testabdeckung, einschließlich:
- Testen der vom Team direkt vorgenommenen Änderungen (Funktionalität und ggf. Benutzeroberfläche);
- Testen des Systems nach dieser Änderung anhand einer Checkliste: Hierbei handelt es sich um obligatorische Überprüfungen. Dazu gehören das Testen der Zugänglichkeit für Menschen mit Behinderungen, das Überprüfen von Übersetzungen, das Überprüfen vorhandener Daten, das Testen mit Sonderzeichen, Sicherheitsüberprüfungen, das Testen von Änderungen in einer mobilen Anwendung und andere Überprüfungen ...
c) QS-Standards für Release-Tests.
Der Freigabeprozess und die darin verwendeten Standards werden nachstehend ausführlicher erörtert.
d) Verwendung automatisierter Regressionstests.
Die Erstellung automatisierter Tests für Regressionstests hat die Lebensdauer von Teams erheblich vereinfacht. Wenn Sie jetzt nach Befehlsänderungen einen Bereich überprüfen müssen, können Sie einfach automatische Regressionstests für den gewünschten Bereich des Systems ausführen (sofern dieser Bereich von Autotests abgedeckt wird). Wenn ein Teil des Systems durch Teamänderungen beschädigt wurde, wird dies durch automatische Regressionstests erkannt.
e) Gegenseitige Unterstützung von Testern, Unterstützung von Entwicklern.
Wir haben nicht sehr viele Tester (durchschnittlich 1 Tester für 3 Entwickler), außerdem werden sie von Zeit zu Zeit von den Sprint-Aufgaben zum Testen von Releases abgelenkt, und es ist möglicherweise nicht genug Zeit für alles.
In diesem Fall gibt es immer jemanden von den Testern anderer Teams mit geringerer Arbeitsbelastung, der helfen kann. Der QS-Leiter oder Scrum Master hilft bei der Suche nach einem solchen Tester. Darüber hinaus können Entwickler beim Testen von Änderungen im Sprint helfen, wenn bereits Testfälle für sie geschrieben wurden.
f) Kommunikation zwischen Testern.
Für die Kommunikation wird ein Chat in Microsoft Teams verwendet, in dem jeder Fragen stellen und umgehend Antworten erhalten kann, während der Rest der Tester die neuesten Informationen herausfindet. Wir halten auch monatliche QS-Meetings ab, bei denen Tester die aktuellen Aufgaben ihres Teams miteinander teilen und alle Probleme besprechen können - den Testansatz und / oder den Ort von Testfällen in Bezug auf einen Bereich, der dem Tester nicht vertraut ist; Fragen zur Veröffentlichung (Zusammensetzung des zukünftigen Veröffentlichungsteams, Änderung des Testzeitplans); zusätzliche obligatorische Überprüfungen hinzugefügt, nachdem ein kritischer Fehler in der Version usw. übersehen wurde.
Mit den oben aufgeführten Ansätzen können Sie gute Qualitätstests in einem leisen Betriebsmodus sicherstellen.
:
Früher hatten wir vierteljährliche Veröffentlichungen . In einem solchen Zeitrahmen wurden von den Teams für jede Veröffentlichung viele Änderungen vorgenommen. Dieses Änderungsvolumen erforderte sicherlich eine Regression vor der Veröffentlichung, sodass es einen separaten Zeitrahmen für die Regression gab und alle Teams damit verbunden waren. Dies dauerte normalerweise ungefähr 2 Wochen, und sowohl Tester als auch Teamentwickler nahmen an der Regression teil.
Nach einiger Zeit wurden Autotests für die Regression im Release-Testprozess verwendet. Nicht alle Regressionstests wurden mit Autotests abgedeckt, einige wurden manuell getestet. Insgesamt reduzierte dies die Regressionstestzeit, aber aufgrund der Größe des Systems war eine vollständige Regression immer noch zeitaufwändig.
Der gesamte Entwicklungszyklus sah ungefähr so aus:
Es wurde deutlich, dass dieser Ansatz für Releases nicht optimal ist, übermäßig arbeitsintensiv ist und keine schnelle und flexible Befriedigung von Endbenutzeranfragen ermöglicht. Die Herangehensweise an den Veröffentlichungsprozess erforderte Änderungen, und es wurde beschlossen, die Veröffentlichung häufiger durchzuführen - einmal im Monat.
Als wir zu monatlichen Releases übergingen , wurde klar, dass während der Release-Testphase keine Zeit für die Durchführung der Regression blieb - selbst bei teilweise automatisierten Regressionstests. Jetzt dauert die gesamte Vorbereitungszeit für die Veröffentlichung nur noch 2 Wochen. Daher erfolgt die Regression jetzt in Sprints und nur bei Bedarf (wenn die Entwickler melden, dass eine Regression eines bestimmten Teils des Systems erforderlich ist).
Da es jedoch in der Phase des Testens der Version erforderlich ist, nicht nur die neue Funktionalität, sondern auch den allgemeinen Zustand des Systems zu überprüfen, haben wir begonnen, Stabilisierung anstelle von Regression zu verwenden.
Die Stabilisierung umfasst:
a) Testen neuer Funktionen, die in dieser Version enthalten sind, durch jedes Team;
b) Das Testen kritischer Bereiche ist ein Test der Grundfunktionalität der Hauptbereiche des Systems (was offensichtlich viel weniger Zeit in Anspruch nimmt als ein vollständiger Regressionszyklus).
c) Testen von Fehlern, die in Teamänderungen für diese Version gefunden wurden.
Der gesamte Entwicklungszyklus sieht nun folgendermaßen aus:
Lassen Sie uns überlegen, was noch zur Vorbereitung auf die Veröffentlichung erforderlich ist.
Wenn die Stabilisierung abgeschlossen ist und das Release-Paket von guter Qualität ist, bevor es in die Produktion eingeführt wird, wird die Konfiguration in der Vorproduktionsumgebung getestet. Daher üben Operations die Aktualisierung der Umgebung, und Tester überprüfen die Konfiguration mit dem aktuellen Release-Paket vor dem eigentlichen Release.
Sie könnten denken, dass 2 Wochen Vorbereitung auf die Veröffentlichung zu viel sind und nur noch wenig Zeit für Tests im Sprint bleibt. Normalerweise dauert es 4-6 Tage, bis sich ein Tester auf eine Veröffentlichung vorbereitet hat. Es kommt darauf an:
- die Komplexität und den Umfang der Funktionen, die sein Team veröffentlichen wird,
- Teilnahme des Testers am Release-Team der aktuellen Version.
Alle Tester des Projekts (einschließlich des Release-Teams) nehmen an Stabilisierungstests teil. Das Testen der Konfiguration und des Releases selbst wird nur vom Release-Team durchgeführt.
Der allgemeine Zeitplan für Release-Tests sieht folgendermaßen aus:
Da kritische Bereiche und Konfigurationen konstante Tests enthalten, haben wir diese Testfälle teilweise automatisiert. Dies hat die Testzeit in Vorbereitung auf die Veröffentlichung erheblich verkürzt. Daher planen wir, die Verwendung von Autotests in Zukunft zu erweitern.
Unter dem Gesichtspunkt der Organisation von Tests wird für jede Version ein QS-Koordinator (jemand aus den QA-Leitern) ausgewählt. Die Vorlaufzeit für die Freigabe ist normalerweise für einen QS-Koordinator mehr als für reguläre Tester geplant, da der QS-Koordinator mehr Verantwortlichkeiten hat. Diese schließen ein:
- Definieren des Release-Teams und Überprüfen der Verfügbarkeit aller seiner Mitglieder zum Zeitpunkt der Veröffentlichung;
- Erstellung von Testplänen für die Veröffentlichung;
- Starten von Autotests in der Phase der Stabilisierung und Konfigurationstests;
- Koordination der Arbeit der Tester während der Release-Tests;
- Unterstützung der Tester bei der Lösung aller möglichen Probleme im Zusammenhang mit der Veröffentlichung;
- Kontrolle über die Durchführung von Tests und gegebenenfalls Umverteilung der Last, um das Testen überlasteter Teams zu unterstützen (dies können entweder Tester anderer Teams sein, die bereits Release-Tests abgeschlossen haben, oder Teamentwickler oder der QS-Koordinator selbst).
Und natürlich ist keine Veröffentlichung ohne Probleme vollständig. Wir lösen sie und entwickeln einen Plan, wie wir sie in Zukunft vermeiden können. Hier sind einige, auf die wir in letzter Zeit gestoßen sind:
- : , - , , - .
: . - : pre-production . — .
: . - : , .
:
a) - ( , ),
b) ,
c) ,
d) , . , , .
Lösung: In solchen Fällen versuchen wir, Zeit zu haben, um alles zu testen, was für die Veröffentlichung erforderlich ist, auch wenn die Teilnahme an der Veröffentlichung für alle zwei Wochen oder Überstunden erforderlich ist, da die Veröffentlichung eine Aufgabe mit höherer Priorität als die Sprintaufgaben ist.
Unabhängig davon, welche Probleme auftreten, können wir sie immer durch die Kräfte des Release-Teams oder durch die Einbeziehung von Personen lösen, die in einem bestimmten Bereich kompetent sind. Hauptsache, dies ist immer eine gut koordinierte Teamarbeit, die zu einem guten Ergebnis führt.
Arbeiten in Quarantäne: So stellen Sie die Arbeit der Tester sicher
In unserem Projekt ist die Arbeit vom Büro aus Voraussetzung. Dies geschieht, damit jeder Teilnehmer des Prozesses während der Arbeitszeit gefunden werden kann. Wenn er plötzlich nicht mehr in Chats antwortet, können ihn die mit ihm arbeitenden Personen darüber informieren, dass er von einigen seiner Kollegen benötigt wird. Dies ist relevant, da einige der Teams in Norwegen und einige in St. Petersburg sind.
Während der Pandemie, als sowohl Norwegen als auch Russland die Mehrheit der Bevölkerung in die Selbstisolation schickten, mussten wir auf Fernarbeit umsteigen.
Wir arbeiteten wie gewohnt weiter: Die Teams beendeten die Sprints immer noch mit guter Sprintproduktivität, und die Veröffentlichungen wurden pünktlich veröffentlicht.
Die Kommunikation blieb weiterhin auf einem guten Niveau - die Team-Anwendung deckte alle Anforderungen ab: Es gab aktive Gespräche im Chat, Besprechungen wurden ohne Probleme abgehalten; Wenn es Fragen gab, die dringend besprochen werden mussten, riefen sie einen Projektteilnehmer an.
Unter dem Gesichtspunkt der Organisation von Tests gab es keine Probleme: Während der Geschäftszeiten antworteten alle Tester in Chats und nahmen umgehend am Testen der Version teil. Für den Fall, dass wir jemanden finden müssen, der jedoch nicht im Chat antwortet, haben wir eine Liste mit Mobiltelefonnummern erstellt, die wir jedoch nie verwenden mussten.
Das einzige Problem, mit dem wir zu Hause bei einer Remote-Arbeit konfrontiert waren - aufgrund der Besonderheiten des VPN war es unmöglich, das System in einer Teamumgebung von Telefonen / Tablets aus zu testen. Dieses Problem wurde jedoch umgangen - dank des Projektmanagers und der IT-Abteilung, die eine Lösung gefunden haben. Wir haben angefangen, Proxys zu verwenden, wenn wir eine Verbindung über ein Heimnetzwerk herstellen, und jetzt können wir von zu Hause aus auf mobilen Geräten testen.
Jetzt kehren wir teilweise zur Arbeit im Büro zurück, aber ein Teil des Unternehmens arbeitet weiterhin von zu Hause aus. Und selbst wenn wir uns in verschiedenen Teilen der Stadt befinden, bleiben wir ein einziges engmaschiges Unternehmen, das in solch schwierigen Zeiten und unter solchen Bedingungen ohne Arbeit weiterarbeitet, wenn Kinder und Haustiere Aufmerksamkeit verlangen, das Internet langsamer wird und regelmäßig verschwindet, das Licht ausgeht und es so viele Ablenkungen gibt. Faktoren, die Sie überhaupt nicht verstehen, wie haben Sie es geschafft, wieder zu arbeiten ?!
Aber zusammen werden wir das alles überleben und endlich zu einem vollwertigen Büroleben zurückkehren. Wir werden uns noch breiter als gewöhnlich anlächeln.
Fazit
Zusammenfassend möchte ich einige Punkte erwähnen:
- , , . — .
- , , .
- , , , — . , .