Gdzie zespół QA powinien przeprowadzić testy w modelu rozgałęzienia Gitflow

Jesteśmy dużym zespołem (10-12 programistów i 4 qa) pracującym nad wieloma projektami z tym samym repozytorium git. Jest to serwis internetowy oparty na bootowaniu wiosennym. Szukamy dobrej strategii rozgałęziania i wdrażania git. mamy również zespół qa, który zapewnia, że ​​nasze funkcje działają zgodnie z oczekiwaniami (w pewnym stopniu wolne od błędów).

Po przeczytaniu kilku artykułów mam wrażenie, że model Gitflow będzie dla nas dobrze działał. Oto moje pytanie.

Gdzie nasz zespół kontroli jakości powinien przetestować nasze funkcje?

1. powinni przetestować gałąź funkcji, w której będą zgłaszać błędy, a programista to naprawi, a gdy przejdzie test kontroli jakości, łączymy się, aby się rozwijać. a QA ponownie przeprowadzi testy na liczbach całkowitych w gałęzi developerskiej.
2. czy powinniśmy połączyć wszystkie funkcje (po testach jednostkowych i testach podstawowych od dewelopera), aby rozwinąć gałąź i pozwolić stamtąd test qa. poprawki i testy będą się również pojawiać w fazie rozwoju.

Jestem ciekawy, jakie podejście działało dobrze dla innych.

Kontrola jakości powinna prawdopodobnie testować dwa razy.

Pierwsze testy powinny dotyczyć określonych zmian i powinny zostać wykonane w gałęzi funkcji. Pozwala to przetestować kontrolę jakości pod kątem konkretnych zmian i zobaczyć, czy konkretna zmiana jest ukończona zgodnie ze specyfikacją i zachowuje się zgodnie z oczekiwaniami. Daje im także wczesny podgląd drugiej rundy testów, co tak naprawdę ma znaczenie dla kontroli jakości.

Pochodząc z mojego doświadczenia w różnych regulowanych środowiskach, drugie testowanie musi zostać przeprowadzone albo na znaczniku w gałęzi programistycznej, który odpowiada wydaniu, albo gałęzi wydania, a może gałęzi master. Przed wydaniem QA powinna testować pełny i kompletny kod, który będzie wdrożony przed jego wdrożeniem, i powinieneś być w stanie zapewnić, że wszystko, co zostało przetestowane przez QA, jest dokładnie identyczne z tym, co zostanie wdrożone do produkcji. Wolę, aby po zawieszeniu kodu znacznik został zastosowany do gałęzi wydania, a QA to przetestuje. Zmiany zostaną wprowadzone w gałęzi programistycznej, sprawdzone na miejscu, a następnie przetestowane ponownie w nowym tagu w gałęzi wydania. Te tagi w gałęzi wydania odpowiadają kandydatom do wydania.

Robię tutaj kilka założeń. Po pierwsze, masz dość przyzwoity zakres testów opartych na programistach. Idealnie byłoby to zautomatyzowane testy jednostkowe i integracyjne, które programiści uruchamiają i wykonują przed wysłaniem jakiegokolwiek kodu z dowolnego oddziału do kontroli jakości. Deweloperzy mogą również chcieć przeprowadzić testy eksploracyjne wokół interfejsu użytkownika, aby upewnić się, że wszystko wygląda dokładnie przed testowaniem jakości. Po drugie, istnieje dobra koordynacja między rozwojem a kontrolą jakości, aby zaplanować wprowadzanie zmian w celu zapewnienia wystarczającego czasu kontroli jakości w oparciu o funkcje.

Świetne pytanie. Nie wydaje mi się, żeby istniała „oficjalna” poprawna odpowiedź na to pytanie. To zależy od tego, jak szybko możesz przetestować.

Podstawowym problemem jest to, że każde scalenie, kompilacja, a nawet wdrożenie może potencjalnie spowodować błąd. Im dalej w górę łańcucha testujesz, tym wcześniej wiesz o błędach, ale także im więcej razy musisz ponownie testować.

Aby mieć pewność, że przetestowałeś oprogramowanie, z którego korzystają klienci, naprawdę musisz przetestować wdrożenie na żywo, zanim ruch klientów (przy założeniu aplikacji internetowej) zostanie skierowany na te serwery za pomocą niebieskiego / zielonego wzorca wdrażania.

Ale oczywiście jest to trochę za późno, aby po raz pierwszy sprawdzić kod w ogóle!

Jeśli przetestujesz gałąź wydania w środowisku qa env, możesz zaryzykować i zredukować testy na żywo tylko do testów dymu. i zastosuj poprawki błędów w gałęzi wydania. Ale nie możesz ocenić, czy funkcja jest kompletna przed utworzeniem wydania

Jeśli przetestujesz programowanie, otrzymasz mini gałęzie z funkcją naprawy błędów. Funkcje są nadal scalane przed ich oceną, a funkcje dla następnej wersji mogą kolidować z testowaniem bieżącej wersji.

Jeśli testujesz gałęzie Feature, potrzebujesz miliona środowisk i musisz uporządkować kolejność scalania i testować podpisy. plus dużo ponownych testów.

Z mojego doświadczenia polecam:

szybki test gałęzi funkcji na maszynie deweloperskiej. po prostu upewnij się, że jego funkcja jest kompletna, a testerzy / deweloperzy są zgodni co do wymagań.

Codzienne testy / testy automatyczne w oddziale deweloperskim wdrożonym na serwerach qa. Pozwala przetestować wszystkie funkcje razem i powiedzieć, kiedy będziesz gotowy do wydania.

Jeśli wszystkie funkcje są włączone, ale testy nie zostały zakończone. np. sprint jest zakończony. utworzyć gałąź wydania i wdrożyć w drugim środowisku qa. Pozwala to na poprawianie / testowanie błędów w wersji 1, aby kontynuować w tym samym czasie, co funkcje w wersji 2.

(wielbiciele Scrum powiedzą, że w sprincie 2 powinieneś umieszczać tylko poprawki błędów, ale bądźmy praktyczni)

Testy dymu podczas wdrażania zielonego / niebieskiego na żywo przed przełączeniem. Są to bardzo ważne, ponieważ wychwytujesz błędy konfiguracji / środowiska, których nikt tak naprawdę nie szuka podczas programowania.

Zgadzam się z Thomasem Owensem. Prawdopodobnie powinieneś testować dwa razy. Raz w gałęzi funkcji przed jej scaleniem i raz w głównej gałęzi przed wydaniem.

Tak naprawdę uwielbiam ten przepływ pracy, że stworzyłem narzędzie Topico , które automatycznie buduje i uruchamia wersje jednorazowe aplikacji dla każdego żądania ściągania, każde z własnym unikalnym testowym adresem URL. Pozwala to zespołowi kontroli jakości na oddzielne testowanie gałęzi funkcji bez potrzeby tworzenia jakiegoś dynamicznego środowiska testowego skonfigurowanego na ich własnym komputerze.

Takie podejście oznacza, że ​​tylko kod, który przeszedł testy na ludziach, kiedykolwiek dotrze do głównej gałęzi, zachowując w ten sposób jej integralność.

Wprowadziłem to w kilku firmach i bardzo pomogło to naszym cyklom wydawniczym. Jesteśmy teraz w stanie dokładnie zaplanować wydania i jesteśmy znacznie lepsi w zrozumieniu, co może sprawić, że pojawi się w następnym wydaniu i co będzie musiało czekać na przyszłe wydanie. To po prostu daje więcej pewności siebie.