Jak skutecznie przeprowadzić testy po wydaniu i zminimalizować wpływ wydania na klientów na żywo

how perform post release testing effectively

Kiedy zaczynałem swoją karierę jako QA, pracowałem w firmie, która oferowała swoje produkty jako SaaS. Wersje produkcyjne były krytyczne i istniała możliwość wpłynięcia na funkcjonalność dla klientów na żywo.

Wraz ze wzrostem bazy klientów, aby zarządzać ryzykiem i zminimalizować wpływ wydania dla klientów na żywo, przyjął zespół QA praktyka testowania po wydaniu.

To wszystko było dla mnie nowe i miałem wiele pytań i wątpliwości:

• Co to jest testowanie po wydaniu?
• Wszystko przetestowałem poprawnie, dlaczego musimy przeprowadzić testy po wydaniu?
• Czy wszystko od nowa testuję? Co dokładnie mam zrobić podczas weryfikacji po wydaniu?
• Co się stanie, jeśli znajdę problem? Itp.

Z przyjemnością przyznam, że wszystkie odpowiedzi znalazłem w kilku pierwszych wydaniach produkcyjnych.

Tutaj dzielę się tą wiedzą z wami wszystkimi. Postanowiłem napisać artykuł w formacie pytań i odpowiedzi, aby pokazać, w jaki sposób odkryłem odpowiedzi.

Czego się nauczysz:

• Co to jest weryfikacja wydania poprodukcyjnego?
• Jakie zadania i czynności obejmuje faza weryfikacji po wydaniu?
• Czy muszę wszystko ponownie przetestować?
• Jak sformułować strategię weryfikacji wydania postprodukcyjnego?
• Kto tworzy plan testów wydania postprodukcyjnego?
• Kto zatwierdza plan testów poprodukcyjnych?
• Kiedy mam utworzyć plan weryfikacji wydania poprodukcyjnego?
• Zakończyłem weryfikację wydania poprodukcyjnego. Co dalej?
• Co się stanie, jeśli znajdę problem?
• Co jeszcze muszę wiedzieć o procesie weryfikacji wydania po produkcji?
• Wniosek:
• rekomendowane lektury

Co to jest weryfikacja wydania poprodukcyjnego?

Zgodnie z definicją, Poczta znaczy Po , Dopuszczenie do produkcji odnosi się do wdrożenia do środowisk LIVE / produkcyjnych i Weryfikacja zawiera upewniając się, że udostępnione funkcje spełniają wymagania .

Zalecana lektura=> Jak skutecznie przygotować „środowisko testowe” przed rozpoczęciem testów

Celem jest weryfikacja wydania w środowiskach produkcyjnych / LIVE.

jak pisać przypadki testowe w testowaniu oprogramowania na przykładzie

Ale wtedy pojawiają się pytania:

• Dlaczego musimy przeprowadzać testy poprodukcyjne, gdy testowałem wszystko w środowisku kontroli jakości?
• Dlaczego spodziewamy się problemów w środowisku produkcyjnym, mimo że dokładnie przetestowaliśmy wydanie w środowisku testowym?

Istnieje wiele powodów, dla których moglibyśmy mieć problemy z produkcją, mimo że moglibyśmy śledzić ją kompletnie Proces zapewnienia jakości (to znaczy. planowanie testów , przegląd planu testów, cykl testów, testy regresji itp.)

Powody, dla których mielibyśmy problemy z produkcją:

1) Wydanie danych - Dane dostępne w środowiskach produkcyjnych i testowych mogą się różnić. Może to spowodować, że niektóre problemy z narożnikami mogą zostać pominięte w środowiskach testowych.

2) Problem z wdrożeniem - Jeśli Twoja firma ma ręczny proces wdrażania, wersja może być bardziej podatna na problemy z wdrożeniem. Niektóre typowe scenariusze mogą obejmować brak konfiguracji lub ustawień witryny, brakujące skrypty bazy danych, nieprzestrzeganie kolejności wdrażania (najpierw kod, następnie baza danych itp.), Zależności zainstalowane nieprawidłowo itp.

Przeczytaj także=> Co tester kontroli jakości powinien wiedzieć o procesie wdrażania

3) Nie zidentyfikowano obszarów oddziaływania - Mogą istnieć scenariusze, w których dotknięte obszary mogły nie zostać poprawnie i całkowicie zidentyfikowane przez zespół.

Na przykład, rozważ SaaS środowisko.

Jeśli zespół nie zidentyfikował wpływu ponownie podzielonej tabeli bazy danych na klienta korzystającego ze starszego schematu tabeli (np. Utrata danych, potrzeba migracja danych przed wydaniem itp.), itp. Ten problem jest mniej prawdopodobny w przypadku dobrze zaplanowanych projektów z precyzyjnymi wymaganiami. Ale taka możliwość nadal istnieje.

4) Nieznane obszary oddziaływania - Może się to zdarzyć, jeśli zakres i obszary uwolnienia, na które ma to wpływ, nie są znane. Na przykład w firmie, w której kilka programów ma wspólną bazę danych i architekturę, nawet niewielka zmiana może zepsuć funkcjonalność wielu produktów.

Jakie zadania i czynności obejmuje faza weryfikacji po wydaniu?

Zadania i czynności związane z wydaniem poprodukcyjnym obejmują zazwyczaj:

• Weryfikacja wydania poprodukcyjnego
• Zgłoś wyniki weryfikacji
• Zgłaszanie wszelkich problemów znalezionych w produkcji
• Czyszczenie danych weryfikacyjnych po wydaniu
• Monitorowanie po zwolnieniu (jeśli dotyczy)

Czy muszę wszystko ponownie przetestować?

Niekoniecznie. Zależy to od wersji, która ma zostać wydana, i analizy wpływu.

Szczegółowe testy należy przeprowadzać podczas regularnego cyklu kontroli jakości. Weryfikację po wydaniu należy przeprowadzić zgodnie z planem testów weryfikacji poprodukcyjnej, który powinien być pochodną pełnego planu testów dla tego wydania.

Jak sformułować strategię weryfikacji wydania postprodukcyjnego?

Planowanie weryfikacji wydania po produkcji należy wykonać w podobny sposób, jak zwykłe planowanie testów.

Strategia powinien znajdować się na tych samych liniach, co przepływ testowy, po którym następuje cykl kontroli jakości. Ważne jest, aby uwzględnić najważniejsze i krytyczne kroki, które zapewniają maksymalne pokrycie funkcjonalności.

różnica między testem poczytalności a testem dymu

Dobra strategia postprodukcji powinna:

• Uwzględnij kroki testowania nowych funkcji, a także głównych istniejących funkcji
• Zweryfikuj główne obszary wpływu
• Zezwalaj na maksymalne pokrycie funkcjonalności
• Opcjonalnie: Uwzględnij wszelkie krytyczne błędy znalezione w środowisku testowym
• Opcjonalnie: Uwzględnij priorytet przypadków testowych

Kto tworzy plan testów wydania postprodukcyjnego?

Będzie się to różnić w różnych firmach i będzie zależało od struktury organizacyjnej.

Weźmy przykład następującej organizacji zespołu ds. Kontroli jakości.

W tym scenariuszu dział kontroli jakości pracujący nad konkretnym projektem opracuje wstępny plan testów poprodukcyjnych.

Kto zatwierdza plan testów poprodukcyjnych?

Będzie się to różnić w różnych firmach i będzie zależało od struktury organizacyjnej.

Ponownie, biorąc pod uwagę tę samą strukturę organizacyjną, jak pokazano w poprzednim pytaniu, plan testów poprodukcyjnych powinien zostać zweryfikowany i zatwierdzony przez Kierownik testów lub kierownik ds. zapewnienia jakości .

Kiedy mam utworzyć plan weryfikacji wydania poprodukcyjnego?

Plan testów poprodukcyjnych można utworzyć w dowolnym momencie podczas cyklu tworzenia oprogramowania, po zidentyfikowaniu i zablokowaniu wymagań, zakresu rozwoju i obszarów wpływu. Zwykle łatwiej jest zespołowi kontroli jakości utworzyć plan testów postprodukcyjnych w połowie sprintu. Gwarantuje to wystarczająco dużo czasu na przegląd i zatwierdzenie.

Dobrą praktyką jest dołączenie tego planu testów do każdego formalne dokumenty podpisywania kontroli jakości zanim projekt wejdzie w fazę wdrożenia i wydania.

Zakończyłem weryfikację wydania poprodukcyjnego. Co dalej?

Po zakończeniu weryfikacji po wydaniu następne kroki będą wyglądać tak

1) Przekazywanie wyników weryfikacji - Wyniki weryfikacji należy przekazać zainteresowanym stronom, w tym wszelkie problemy, które mogły zostać wykryte podczas produkcji.

2) Zgłaszanie wszelkich problemów znalezionych na produkcji w narzędziu do zarządzania defektami - Do ułatwiają analizę przyczyn źródłowych i identyfikowalność .

3) Czyszczenie danych weryfikacyjnych po wydaniu - Czyszczenie danych należy wykonać po zakończeniu weryfikacji.

Na przykład, rozważ wydanie dla aplikacji eCommerce i powiedzmy, że utworzyłeś zamówienie testowe na produkcji. To zamówienie testowe należy anulować po zakończeniu weryfikacji.

4) Monitorowanie zwolnienia po produkcji (jeśli dotyczy) - Niektóre wydania wymagają monitorowania na produkcji.

Na przykład, jeśli zespół wprowadził ulepszenia w celu poprawy czasu ładowania strony w Aplikacji, należałoby to monitorować przez pewien czas, aby upewnić się, że poprawa była rzeczywiście widoczna po wydaniu. Osoby odpowiedzialne za monitorowanie powinny być jasno określone i przekazane.

Co się stanie, jeśli znajdę problem?

Wszelkie problemy należy zgłaszać w Narzędzie do zarządzania defektami i przekazane zainteresowanym stronom. W przypadku wykrycia jakichkolwiek krytycznych problemów w produkcji, informacja o wynikach powinna nastąpić natychmiast, ponieważ konieczne byłoby podjęcie decyzji, czy kompilacja musi zostać wycofana w celu dalszego zbadania problemu.

Ważne jest, aby wszystkie znalezione problemy były zgłaszane w narzędziu do śledzenia defektów. Zaleca się, aby były one zgłaszane jako osobny typ problemu (np. Błąd poprodukcyjny), aby pokazać oddzielenie od błędów regularnego cyklu kontroli jakości. Te problemy można łatwo odfiltrować, jeśli jest to wymagane do celów analizy pierwotnej przyczyny.

Co jeszcze muszę wiedzieć o procesie weryfikacji wydania po produkcji?

Oprócz faktycznego procesu weryfikacji wydania poprodukcyjnego, planu i strategii, poniżej znajduje się kilka wskazówek:

• Ważne jest, aby określić jasne oczekiwania dotyczące zakresu i celu weryfikacji po wydaniu. Zainteresowane strony (wewnętrzne i zewnętrzne) powinny być świadome następujących kwestii
  • Zespół nie może wszystkiego przetestować na produkcji
  • Zespół nie może zmarnować dni testowania na kilka godzin zarezerwowanych na weryfikację po wydaniu

Dlatego testowanie na produkcji opierałoby się zasadniczo na zatwierdzonym planie testów poprodukcyjnych.

Ograniczenia:

Należy zachować należytą ostrożność podczas podejmowania decyzji o zakresie poprodukcyjnych testów wersji. Istnieją ograniczenia co do tego, co i ile możemy faktycznie przetestować na produkcji. Środowisko produkcyjne zawiera bieżące dane klientów i wymaga bardzo ostrożnej obsługi. Dodatkowe planowanie należy przeprowadzić w przypadku zmian, które obejmują migrację danych, aktualizację, usuwanie itp.

Przykład 1): W przypadku firmy eSurvey, jeśli testowanie obejmuje udzielenie odpowiedzi i przesłanie ankiety, dział kontroli jakości musiałby wysłać prośbę o usunięcie ankiety testowej po weryfikacji, aby nie wpływać na dane zebrane w ankietach klienta i ich statystyki.

JEST przykład # 2): W przypadku firmy zajmującej się handlem internetowym załóżmy, że zadanie SQL aktualizacji cen jest uruchamiane codziennie o północy i przesyła ostateczną cenę do witryny internetowej. Nie możemy wielokrotnie uruchamiać tego kodu SQL na żądanie w celu weryfikacji po wydaniu, ponieważ może to spowodować wypchnięcie niezakończonych danych do produkcji.

Co więcej, może zwiększyć szanse Zakleszczenia DB oraz wysokie zużycie zasobów procesora i pamięci w godzinach szczytu, co może wpływać na wydajność aplikacji klienckiej.

• Nakład pracy wymagany do testowania po wydaniu i wszystkich powiązanych działań powinien być wbudowany i uwzględniony w Planie projektu. W zależności od reguł biznesowych i specyfiki projektu można to uznać za narzut projektu lub uwzględnić w cyklu kontroli jakości lub włączyć jako część planu zarządzania wersjami.
• W przypadku problemów zgłaszanych podczas weryfikacji po wydaniu należy przeprowadzić analizę pierwotnej przyczyny, aby dowiedzieć się, dlaczego problem nie został wcześnie wykryty i co można zrobić lepiej następnym razem, aby uniknąć jego napotkania. Analiza przyczyn źródłowych może pomóc zespołowi wyciągnąć wnioski z wcześniejszych problemów i wypełnić wszelkie luki we wdrożeniu. W zależności od struktury organizacyjnej, Kierownik Testów lub Kierownik ds. Zapewnienia jakości może przeprowadzić analizę przyczyn źródłowych na podstawie informacji uzyskanych od zespołu projektowego. Niektóre typowe przyczyny mogą obejmować problem z kodowaniem, problem z wymaganiami, problem z projektem, problem z danymi, ograniczenia stron trzecich, brakujący scenariusz testowy itp. Odpowiednie działania korygujące i zapobiegawcze mogą być tworzone i śledzone.
• Dzienniki serwera może być również używany do monitorowania kompilacji po wydaniu. Dziennik serwera może zawierać zdarzenia lub problemy, które mogą być niewidoczne dla klienta, ale spowodują problemy w zapleczu. To monitorowanie można przypisać jako element akcji do kierownika deweloperskiego i zespołu DevOps.

Przykład:

Przegląd projektu:

Następujące zmiany muszą zostać wprowadzone w aplikacji mediów społecznościowych, w szczególności w procesie rejestracji

1. Należy usunąć weryfikację pola nazwiska. Wcześniej zostało zaimplementowane jako „Nazwisko powinno mieć minimum 4 znaki” (ulepszenie istniejącego pola)
2. Zaimplementuj przycisk przełączania obok adresu e-mail, aby użytkownik mógł ustawić ustawienia prywatności dla adresu e-mail wyświetlanego w jego profilu (prośba o nową funkcję)
3. Użytkownik powinien mieć możliwość wyboru swojego awatara (żądanie nowej funkcji)
4. Zmniejsz liczbę wywołań interfejsu API podczas procesu rejestracji, aby poprawić wydajność aplikacji (ulepszenie)

Plan weryfikacji wydania poprodukcyjnego:

jak wyświetlić plik JSON

Wniosek:

Z większością firm programistycznych teraz przyjęcie metodologii Agile wzrosła liczba wydań produkcyjnych.

Na przykład, podczas używania Model wodospadu , zespół może mieć wydanie produkcyjne co 1,5 miesiąca, jednak w procesie Agile ten sam zespół może teraz mieć wydanie produkcyjne co 2-3 tygodnie.

Przy każdym wydaniu produkcyjnym mamy możliwość świadomego lub nieświadomego wpływania na funkcjonalność żywych klientów. Przyjęcie weryfikacji wydania poprodukcyjnego natychmiast po wydaniu może zapewnić dodatkowe zaufanie do wydania, jednocześnie zapewniając sieć bezpieczeństwa cofania wydania, zanim nasi klienci na żywo napotkają pewne problemy.

Dla projektów o dużym wpływie / ryzyku plan weryfikacji wydania poprodukcyjnego można ustrukturyzować w oparciu o priorytet scenariusza testowego. Krytyczny test priorytetowy może być wykonany jako pierwszy, a informacja o wynikach i wszelkich problemach może zostać wysłana do interesariuszy. Jeśli nie zostaną znalezione żadne krytyczne problemy, poprodukcyjna weryfikacja wydania może być kontynuowana, w przeciwnym razie należy podjąć decyzję o wycofaniu, aby zminimalizować przestoje aplikacji i wpływ na aktywnych klientów.

Dodatkowo, testy wydania poprodukcyjnego można zautomatyzować a skrypty testowe mogą być uruchamiane na żądanie po każdym wydaniu jako test regresji. Ponownie, należy zachować ostrożność podczas uruchamiania automatycznych skryptów testowych w środowisku produkcyjnym, ponieważ może to mieć wpływ na dane i funkcjonalność klienta na żywo.

Weryfikacja wydania poprodukcyjnego to ostatnia linia obrony dla dowolnej firmy programistycznej. Jeśli nie wykryjemy problemów, nasi klienci to zrobią, a to może mieć druzgocące skutki dla reputacji każdej firmy programistycznej.

Aby zachować niezawodność produktu, niezbędna jest weryfikacja zmian wprowadzonych do produkcji natychmiast po wdrożeniu.

O autorze: Ten pomocny artykuł został napisany przez Nehę B. Obecnie pracuje jako kierownik ds. Zapewnienia jakości i specjalizuje się w kierowaniu i zarządzaniu zespołami kontroli jakości w firmie i poza nią.

Podziel się z naszymi czytelnikami swoją strategią / wskazówkami / doświadczeniami w zakresie testowania wydania postprodukcyjnego.

rekomendowane lektury

• Najlepsze narzędzia do testowania oprogramowania 2021 (Narzędzia do automatyzacji testów QA)
• Testing Primer Pobierz eBook
• 7-etapowa praktyczna implementacja testowania ręcznego przed wydaniem do produkcji
• Testowanie obciążenia za pomocą samouczków HP LoadRunner
• Praktyczny przebieg procesu testowania oprogramowania QA (wymagania do wydania)
• Różnica między testami na komputerach stacjonarnych, serwerach klienckich i testach internetowych
• Co to jest test gamma? Końcowy etap testów
• Co to jest wczesne testowanie: testuj wcześnie, testuj często, ALE jak? (Praktyczny przewodnik)