Hallo. Mein Name ist Dasha. Ich teste eine mobile 2GIS-Anwendung unter iOS. Ich möchte unseren Prozess der Durchführung von Funktionen teilen, der nicht nur Zeit spart, sondern auch meine persönlichen Fähigkeiten verbessert. Lesen Sie den Artikel, um herauszufinden, wie wir es schaffen, Produkte, Designer und Entwicklung im selben Kontext zu halten. Wir glauben, dass die Überprüfung der ersten Testanordnung durch alle interessierten Personen das Leben wirklich erleichtert. Und Kommunikation ist der Schlüssel zur Verwaltung einer Funktion.
Unser Schmerz
Bei der Kommunikation mit Testern anderer Unternehmen stelle ich häufig fest, dass das Testen ihrer Funktionen irgendwie chaotisch und unstrukturiert ist. Aus diesem Grund wird Zeit verschwendet, die Stärke der an der Entwicklung beteiligten Personen. Die Leute werden wütend, beginnen ihre Kollegen zu hassen und warten auf der Veranda auf sie.
Zuvor hatten wir auch etwas Ähnliches: Bei der Planung eines Sprints flog eine Aufgabe ein, zu Beginn des Sprints, der in die Entwicklung aufgenommen wurde, haben wir die Aufgabe dabei ausgearbeitet. Wenn es Fragen zur Interaktion mit anderen Teams gab, gingen wir zum Produkt. Es kam oft vor, dass in einigen Teams die Arbeit bereits in vollem Gange war: Alle freuten sich auf die Veröffentlichung, jemand hatte bereits von der Funktion im Kampf geträumt; und im anderen Team wussten sie nicht einmal von seiner Existenz. Ein solcher Prozess war ineffektiv, verbrachte viel Zeit / Mühe und brachte Chaos.
Infolgedessen erkannten sie, dass es unmöglich war, so zu leben, und begannen, einen neuen Prozess aufzubauen. Er hat bereits geholfen, die Nerven und möglicherweise das Leben eines Menschen zu retten.
Über das Team
Unser Team besteht aus: 9 Entwicklern, 6 Testern, einem Produkt und einem Designer. Bei der Planung einer Iteration (was wir in den nächsten 4 Monaten tun werden) werden Funktionen kompiliert, die Sie im aktuellen Zeitraum veröffentlichen möchten. Wenn die Liste zusammengestellt wird, wird jedem Feature des Teams aus Entwicklung und Test ein Feature zugewiesen, das von Anfang bis Ende mit Features ausgestattet ist.
Für uns ist eine Person vorgestellt, die mit Funktionen von TK bis zur Veröffentlichung lebt. Er verfügt über aktuelle Informationen darüber, was mit dem gesamten Feature passiert, und dient als Einstiegspunkt für Fragen zur Bearbeitung von Features für Personen aus anderen Teams. Weitere
Informationen zu Funktionen finden Sie am Ende des
Berichts von Sasha Kartavtsev . Denken Sie an diesen Begriff, dann wird er mehr als einmal gefunden.
In 9 Schritten freigeben
Der gesamte Prozess der Veröffentlichung von Funktionen kann in 9 Hauptphasen unterteilt werden. Aus Gründen der Klarheit nehmen wir das kürzlich veröffentlichte Feature der „Belohnungen“ und erzählen, wie wir es in allen neun Phasen durchgeführt haben.
Auszeichnungen sind eine Belohnung für Benutzer für ihren Beitrag zum Produkt. Benutzer erhalten sie, um Bewertungen zu schreiben, Fotos hochzuladen und neue Unternehmen zum Verzeichnis hinzuzufügen. Sie sind auf der Registerkarte „Mein 2GIS“ zu sehen.
Stufe 1 - TK-Entwicklungsprozess
Bevor wir mit der Ausarbeitung der Funktionen begannen, haben wir einen Chatroom in Ruhe eingerichtet und alle dort beteiligten Personen angerufen. Wir waren uns einig, dass wir darin alle Themen zu Funktionen und Ereignissen im Leben von Chat-Teilnehmern diskutieren werden, die sich auf den Verlauf der Veröffentlichung auswirken können. Es ist nicht notwendig zu sagen, dass Sie Milch genommen haben, aber Sie müssen über Urlaub / Krankheitsurlaub sprechen, sonst laufen Sie Gefahr, wegen Nichtbeantwortung in Hass zu geraten.
Zunächst befassten sich die Funktionen aus Entwicklung und Test mit TK / Designs, stellten Fragen und schlugen Verbesserungen vor, basierend auf den Erfahrungen mit anderen Funktionen. Die Funktion wurde überwacht, sodass die Fragen innerhalb eines Tages beantwortet wurden. Wenn sich die Fristen verzögerten, deuteten dieselben Leute den Produkt- / Verantwortlichen an, dass die Uhr tickt und es wäre schön, bereits zu antworten.
Der Prozess der Entwicklung von TK gilt als abgeschlossen, wenn alle Hauptprobleme abgeschlossen sind, es endgültige Entwürfe gibt und die Entwicklung keine Fragen zur Implementierung von Funktionen hat.
In der ersten Phase ist es sehr cool, einen Prototyp eines Features zu erstellen und ihn bei der Entwicklung eines TOR zu verwenden: Es hilft, das Feature auf dem Gerät zu fühlen und Unvollkommenheiten frühzeitig zu erkennen und Fälle zum Testen zu finden. Produkte können bereits vor Beginn der Entwicklung auf der Plattform Änderungen an der Logik vornehmen.
Stufe 2 - Erstellung der Checkliste
Während der Ausarbeitung des ToR als Testfunktion habe ich Testfälle für die Funktion in TestRail erstellt, nach denen die Funktion anschließend überprüft wurde. Priorisierte Fälle für ihre weitere Automatisierung. Da die Funktion ein Backend enthält, habe ich dem Testplan eine Überprüfung hinzugefügt: Welche Felder senden wir, welche erhalten wir und was passiert, wenn hier ein unverständlicher Unsinn vorliegt. Geben wir der Entwicklung und den Produkten die fertige Checkliste zum Synchronisieren der Erwartungen an die Funktion, damit beim Testen nicht eine Sache gedacht wird, das Produkt eine andere erwartet und der Entwickler etwas anderes getan hat.
Stufe 3 - Entwicklung
Nach der Entwicklung des ToR begann die Entwicklung des Features. Das Testen von zu diesem Zeitpunkt geschlossenen / diskutierten offenen Themen im ToR und im Chatroom informierte die Entwicklung über alle Änderungen, falls vorhanden: neue Anforderungen, neue Designs, neue Texte, alles andere - die Entwicklung sollte sich über alles im Klaren sein, sonst gibt es keine Möglichkeit, einen Kampf zu vermeiden.
Stufe 4 - Überprüfung der ersten Feature-Assembly
Nachdem wir die erste Baugruppe erhalten hatten, warfen wir sie in einen Feature-Chat, in dem wir die Produkte und Designer zu einer Überprüfung aufforderten. Durch Tests wurde überprüft, ob die Baugruppe angezeigt und Feedback gegeben wurde - je schneller, desto besser. Dies geschieht in einem frühen Stadium, damit später keine unangenehmen Situationen auftreten.
Ein Beispiel für eine unangenehme SituationSie sitzen abends ruhig zu Hause, berühren niemanden. Sie denken, dass alles im Rückstand ist, morgen wird das Feature in den Kampf ziehen. Aber um ein Uhr morgens platzt ein böses Produkt in Ihr Haus (das ist echt, weil sie drei Stockwerke über mir wohnt) oder der Designer (das ist schon weniger real, er wohnt weit weg von mir, aber er hat ein Auto) mit den Anforderungen, die Schrift dringend zu reparieren / Farbe / Polsterung, sonst “nicht freigegeben werden! so kann man nicht ausgehen “, und am Morgen wurde die PR-Firma bereits umrissen, und das war's, es ist alles den Bach runter. Und jetzt sitzen Sie um zwei Uhr morgens, rufen den Entwickler an und starten Tickets. Im Allgemeinen ist es wertvoll, rechtzeitig Feedback von den richtigen Personen zu erhalten. Wenn Sie es ganz am Anfang bekommen, können Sie die Freigabe von dieser Flanke nicht festziehen.
Stufe 5 - Plattformtest
Parallel zur Überprüfung der ersten Baugruppe begannen die Tests auf der Plattform mit zuvor kompilierten Testfällen. Wenn Sie während des Testprozesses Probleme fanden, die die Veröffentlichung zu stören drohten, oder feststellten, dass etwas besser gemacht werden könnte, fügten sie dem Chat Funktionen hinzu oder hinterließen einen Kommentar in der Arbeitserklärung. Wir haben dafür gesorgt, dass die Frage nicht offen blieb.
Gleichzeitig gab es Änderungen in der Logik der Funktionen (z. B. Benutzeroberfläche). Sie gaben dem Produkt und dem Designer die Baugruppe zur Überprüfung, um sicherzustellen, dass die Erwartungen mit der Realität übereinstimmten.
Stufe 6 - Integrationstests
Dieser Punkt ist erforderlich, wenn andere Teams als Mobiltelefone an der Entwicklung der Funktion teilnehmen. Zum Beispiel Handys + Backend. Wenn wir die Schriftart oder Farbe des Symbols ersetzt haben, findet natürlich keine Integration statt. In unserem Beispiel mit Rewards handelt es sich jedoch um ein Backend - Integration war unabdingbar.
Das erste, was zu tun war, war ein Dock in Confluence zu bauen. In der Regel tut dies zunächst eine Person.
Das Dokument schreibt vor:
- Durchführungstermine;
- Teilnehmer - damit das Team die Helden vom Sehen her kennt und die Helden diese Tatsache nicht widerlegen können;
- Liste der Schecks;
- Liste der Fälle - Überprüfung von Szenarien mit bestimmten Bedingungen.
Nachdem ich ein Dock zusammengestellt hatte, warf ich es in den Feature-Chat und forderte alle Integrationsteilnehmer auf, die Fälle zu überprüfen / zu ergänzen.
An Tag X versammelten sich die Integrationsteilnehmer in einem Büro und überprüften alle Szenarien von den Integrationsdocks aus. Es ist großartig, gemeinsame Integrationen mit dem Backend-Team durchzuführen - Sie lösen alle Probleme sofort vor Ort und klären alle Kuriositäten.
Stufe 7 - Support Briefing
Vor der Veröffentlichung informierten sie den Support darüber, dass eine Funktion bald veröffentlicht wird. Es ist Zeit, sich fertig zu machen. Dali las TK, Poke Assembly. Sie berichteten, welche Chats geschrieben und an wen sie sich wenden sollten, wenn sie Feedback von Benutzern erhalten.
Stufe 8 - Freigabe
Wir haben mit dem Rolling der Funktion begonnen, den Chat darüber informiert und parallel Crashlytics, Feedback im Store und Support angesehen. Wir hofften auf den besten, getrunkenen Baldrian. Mit den Prämien verlief alles reibungslos, aber wir waren bereit, sofort einen Hotfix zu erstellen und alle im Feature-Chat zu informieren, wenn während des Rollouts ein kritischer Fehler auf der Plattformseite gefunden wurde.
Stufe 9 - Unterstützung für Funktionen nach der Veröffentlichung
Nachdem das Feature in den Kampf eingetreten war, wurde unsere Rolle informativ: Sie beantworteten eingehende Fragen, forderten sie auf, lösten einige Plattformprobleme oder gaben sie weiter, wenn sie verstanden, dass das Problem im Backend lag. Nach der Veröffentlichung habe ich auch die Fälle auf dem Rewards-Scheck in den Hauptkoffer des Testpfads gegossen, damit sie in Zukunft wiederverwendet werden können.
Und wenn kurz
- Halten Sie immer alle im gleichen Kontext. Wichtige Änderungen melden.
- Sobald eine Versammlung mit Funktionen erscheint, organisieren Sie eine Überprüfung der ersten Versammlung durch alle interessierten Parteien.
- Wenn zu irgendeinem Zeitpunkt Änderungen in der Logik eines Features auftreten, organisieren Sie auch eine Überprüfung.
- Erhalten Sie die Antwort: Schreiben, anrufen, treten, bis Sie antworten.
- Bereiten Sie die Unterstützung für eine neue Funktion vor und helfen Sie ihr nach dem Start.
Das Wissen und die Erfahrung, die ich dabei gesammelt habe, helfen mir sowohl bei der Arbeit als auch im Leben. Ich habe Kommunikation, Unabhängigkeit und Verantwortung gefördert und mich über die Arbeit unseres Teams hinaus in das Produkt vertieft. Das Team ist übrigens auch glücklich - im Falle eines Fakap trinkt er jetzt Wein, nicht Baldrian.