Menu

Co tester kontroli jakości powinien wiedzieć o procesie zarządzania wydaniem i wdrożeniem

what qa tester should know about release

Wypróbuj Nasz Instrument Do Eliminowania Problemów

Na dzisiejszym spotkaniu naszego zespołu kierownik sprawdził ze wszystkimi na ich temat gotowość do wykonania testów . Wspomniał, że „kod będzie gotowy do kontroli jakości do jutra rano”. Co miał na myśli, mówiąc „kod będzie gotowy”, czy to oznacza, że ​​programiści będą pisać kod w środowisku QA dziś wieczorem?

Miał na myśli, że wdrożenie zaplanowano na noc, a nowy kod zostanie wdrożony w środowisku kontroli jakości do testów.

Wielu z was może teraz zapytać, czym jest wdrożenie i co tak naprawdę w nim robią?

proces zarządzania wydaniami i wdrożeniami dla QA

Czego się nauczysz:

Ogólny proces zarządzania wersjami i wdrożeniami oraz znaczenie dla zespołu kontroli jakości

  • Dlaczego naprawdę utrzymujemy różne środowiska?
  • W jaki sposób kod jest migrowany z jednego środowiska do drugiego?

W tym artykule omówię następujące tematy

  1. Dlaczego ważne jest, aby testerzy byli świadomi procesu wydawania i wdrażania?
  2. Różne środowiska
  3. Co masz na myśli mówiąc o tworzeniu i wdrażaniu?
  4. Wdrożenie planowane a awaryjne
  5. Lista kontrolna QA - przed i po wdrożeniu

# 1. Dlaczego tak ważne jest, aby testerzy byli świadomi procesu wdrażania?

Nasze główne zadanie wykonywania testów zależy od powodzenia wdrożenia. Jeśli zespół wdrożeniowy stanął przed wyzwaniami i napotkał kilka problemów i nie mógł poprawnie wdrożyć kodu, z pewnością będzie to oznaczać, że zespół ds. Kontroli jakości zidentyfikuje wiele błędów, które mogą być powiązane ze środowiskiem lub procesem wdrażania.

  • Jeśli Testerzy są świadomi procesu wdrażania, zrozumieją, jak ważne jest wykonanie swoich zadań w zaplanowanych ramach czasowych.
  • Testerzy zorientują się, czy problem jest naprawdę błędem w funkcjonalności lub czymś spowodowanym podczas wdrażania, powiedzmy, że tester jest przypisany do testowania funkcji raportu, ale kiedy próbuje zalogować się do witryny, widzi błąd, który oznacza, że ​​środowisko jest wyłączone , takie kwestie nie mogą być traktowane jako kwestie funkcjonalne, ale jako kwestie środowiskowe. Jeśli tester jest świadomy wdrożenia, może powiązać ten problem z wdrożeniem.
  • Można by uniknąć wielu problemów, jeśli testerzy naprawdę znają listę, która została wdrożona. Czasami zdarza się, że testujesz i zgłaszasz problem dotyczący obszarów, które nigdy nie zostały wdrożone.

# 2. Różne środowiska

Różne środowiska

W powyższej klasyfikacji omówiłem 4 najważniejsze środowiska, którymi kieruje się większość organizacji, jednak wielu klientów utrzymuje znacznie więcej środowisk, takich jak staging, pre-staging itp. Ponadto konwencja nazewnictwa może się różnić.

  • DEV - Środowisko deweloperskie to środowisko stworzone i utrzymywane przez zespół programistów do pisania kodu. Dostęp do tego środowiska ma tylko zespół programistów. Zwykle zespół ds. Kontroli jakości nie ma dostępu do tego środowiska. To środowisko jest najczęściej używane przez zespół deweloperów do testów jednostkowych.
  • QA - Środowisko QA to takie, w którym faktycznie przeprowadzane są testy. To środowisko jest własnością zespołu QA. Zespół DEV nie ma dostępu do tego środowiska. Po zakończeniu projektowania i kodowania kod jest przenoszony do środowiska QA, gdzie zespół QA przeprowadza testy.
  • UAT - Test akceptacji użytkownika to środowisko, w którym testy są przeprowadzane przez użytkowników biznesowych. Odbywa się to po zakończeniu testowania systemu. Głównym zamiarem jest przetestowanie systemu z biznesowego punktu widzenia. Dostęp do tego środowiska mają tylko użytkownicy biznesowi. Jednak w niektórych przypadkach zwracają się o pomoc do zapewnienia jakości, w takich okolicznościach zespół kontroli jakości otrzymuje tymczasowy dostęp do środowiska.
  • PROD - Środowisko PROD to rzeczywiste środowisko na żywo, które jest dostępne dla rzeczywistych użytkowników i żaden z zespołów DEV i QA nie ma dostępu do odczytu / zapisu do tego środowiska. Utrzymywane są zespoły wsparcia technicznego w celu rozwiązywania problemów związanych ze środowiskiem produkcyjnym.

Przeczytaj także=> Jak skutecznie przygotować „stanowisko testowe” i zminimalizować defekty środowiska testowego

# 3. Co masz na myśli mówiąc o budowaniu i wdrażaniu

Kompilacja zawiera głównie skompilowany pakiet, który może zawierać wykonywalny bat, exe, biblioteki, takie jak dll, lib i archiwa, takie jak pliki zip. Zespół programistów tworzy kompilację i dostarcza ją zespołowi wdrożeniowemu w celu zainstalowania.

Kompilacją kodu źródłowego zajmuje się głównie zespół programistów i po wygenerowaniu kompilacji umieszczają go w określonej lokalizacji, która jest dostępna dla zespołu wdrożeniowego w celu wdrożenia w innym środowisku.

Po wdrożeniu kompilacji zespół ds. Kontroli jakości jest powiadamiany o wykonaniu testowanie weryfikacji kompilacji (BVT) i jeśli się powiedzie, zespół wykonuje resztę testy funkcjonalności .

W niektórych organizacjach, w których nie mają oddzielnego zespołu wdrożeniowego, zespół programistów dostarcza kompilację do kontroli jakości, a zespół kontroli jakości samodzielnie kończy wdrażanie. Z tym wiąże się duże ryzyko, w takich przypadkach zasoby QA powinny być sprawne technicznie, aby zrozumieć ogólny proces wdrażania kompilacji, a także powinny wiedzieć, jak naprawić, jeśli wystąpi problem.

Kompilacje są obsługiwane za pomocą numerów, np. 1.0.01 lub 1.0.03. Jest więc możliwe, że wersja 1.0.01 może korzystać z biblioteki DLL v0.2, a wersja 1.0.03 może działać z biblioteką DLL v0.5. Dla zespołu kontroli jakości ważne jest, aby upewnić się, że poprawna kompilacja została wdrożona w środowisku przed rozpoczęciem testów. Zawsze dobrze jest śledzić zmiany wprowadzone w ramach każdej kompilacji.

jak otworzyć plik .dat na komputerze Mac

Utrzymanie oddzielnego zespołu wdrożeniowego jest zawsze dobrą praktyką, ponieważ pomaga w płynnym przenoszeniu kodu z jednego środowiska do drugiego.

Wdrażanie to proces, w którym kod / kompilacja jest przenoszona z jednego środowiska do drugiego. Większość organizacji obecnie stosuje właściwy kanał wdrażania i utrzymuje oddzielny zespół, który zajmuje się tym wszystkim.

Buduj i wdrażaj

Przed wdrożeniem spotyka się zespół składający się z programisty, kierownika ds. Rozwoju, inżyniera wdrożeniowego, lidera testów i innych interesariuszy biznesowych. Na spotkaniu deweloper jest zwykle proszony o opisanie swojej zmiany. Zwykle muszą wypełnić określony formularz ze szczegółami dotyczącymi zmian i planu wycofywania.

W przypadku pominięcia niektórych szczegółów zmiany nie zostaną zatwierdzone do wdrożenia. Następnie zespół decyduje, czy zmiana może być częścią wdrożenia następnego dnia. Kierownik ds. Kontroli jakości jest proszony o zatwierdzenie, aby mieć pewność, że zmiana nie wpłynie na żaden z istniejących testów. Na spotkaniu planowane są końcowe pozycje rozmieszczenia.

Zatwierdzona lista jest opracowywana przez zespół wdrożeniowy w dniu wdrożenia. Zespół uruchamia zestaw programów zdefiniowany w każdym formularzu zmian (dostarczonym przez programistów), a następnie wysyła komunikat po zakończeniu wdrażania.

Komunikat Deployment Complete stanowi wskazówkę dla zespołu QA, że zmiany / nowy kod jest gotowy do przetestowania.

Obowiązkiem zespołu wdrożeniowego jest przeniesienie zmian z DEV do QA. Po zakończeniu testów QA kod jest przenoszony do UAT. Przeniesienie danych PROD jest najważniejszą częścią i musi być wykonywane poza godzinami pracy, ponieważ podczas wdrażania środowisko musi zostać obniżone i należy to zrobić z najwyższą ostrożnością, ponieważ może to mieć poważny wpływ na biznes.

Większość wdrożeń Prod jest wykonywana późną nocą, kiedy prawdopodobieństwo, że środowisko zostanie dotknięte przez użytkowników końcowych, jest mniejsze.

# 4. Wdrożenie planowane a awaryjne

Każda organizacja prowadzi kalendarz wdrożeń. Wielu klientów realizuje wdrażanie raz w tygodniu, a wielu robi to co dwa tygodnie, mówiąc, że planowane wdrożenie powinno odbywać się tylko we wtorki lub we wtorek i piątek. Dni oddelegowania mogą ulec zmianie, jeśli planowany dzień oddelegowania przypada w święto.

W powyższej sekcji omówiłem proces, który jest wykonywany dla każdego planowane wdrożenie .

Planowane wdrożenia mogą mieć własne wyzwanie. Pomyśl o przypadku, w którym nowy kod jest wdrażany w środowisku QA i podczas testu poprawności zespół identyfikuje defekt blokera i testowanie musi zostać zatrzymane. Czy zespół testowy czeka tydzień do następnego wdrożenia?

Aby poradzić sobie z takimi sytuacjami, poprawki awaryjne i wdrożenia są wykonywane, gdy zespół wdrożeniowy nie musi czekać do planowanego dnia wdrożenia. Muszą przestrzegać i starać się o zatwierdzenie nawet w przypadku wdrożeń awaryjnych, ale te zatwierdzenia zwykle następują szybko, a nowe zmiany mogą zostać wdrożone w środowisku kontroli jakości tego samego dnia lub tak szybko, jak to możliwe.

# 5. Lista kontrolna QA - przed i po wdrożeniu

Przed wdrożeniem -

Cały faza projektowania testów ma miejsce zanim kod zostanie faktycznie przeniesiony do środowiska. To wykonanie testu zależy od dostępności kodu w środowisku kontroli jakości, podczas gdy zespół wdrożeniowy pracuje nad wdrożeniem kodu w kontroli jakości, zespół kontroli jakości powinien upewnić się, że wykonał poniższe czynności -

Po wdrożeniu -

Po wdrożeniu pierwszą rzeczą, jaką robimy jako zespół kontroli jakości, jest rozpoczęcie testu poczytalności. Ale zanim zaczniemy test poczytalności, powinniśmy upewnić się, że zadbano o następujące kwestie -

  • Zespół ds. Kontroli jakości powinien otrzymać powiadomienie od zespołu wdrożeniowego o pomyślnym wdrożeniu i być gotowy do kontroli jakości.
  • Zespół ds. Kontroli jakości powinien śledzić wdrożoną kompilację.
  • Upewnij się, że zespół ds. Kontroli jakości ma listę pomyślnie wdrożonych zmian, a także elementów, które nie zostały wdrożone, nawet jeśli zostały zaplanowane. Może się zdarzyć, że zespół wdrożeniowy nie będzie mógł przeprowadzić wdrożenia z powodu brakujących szczegółów itp.

Wniosek

Mam nadzieję, że powyższy artykuł dał ci wyobrażenie o ogólnym procesie zarządzania wydaniem i wdrażaniem, który był częścią ogólnego cyklu tworzenia oprogramowania. To była tylko ogólna procedura stosowana w większości organizacji, jednak wielu klientów ma różne protokoły.

Autor : Ten niesamowity artykuł został napisany przez członka zespołu STH, Priyę R.

Czy uważasz, że ten proces był pomocny? Poinformuj nas o procesie wdrażania, który realizujesz w swojej organizacji.

rekomendowane lektury

^