Czy poprawianie błędów jest poprawne bez dodawania nowych funkcji podczas wydawania oprogramowania do testowania systemu?

To pytanie skierowane jest do doświadczonych testerów lub przewodów pomiarowych. Oto scenariusz z projektu oprogramowania:

Powiedzmy, że zespół programistów ukończył pierwszą iterację 10 funkcji i udostępnił ją do testów systemowych. Zespół testowy stworzył przypadki testowe dla tych 10 funkcji i oszacował 5 dni na testowanie. Zespół twórców oczywiście nie może siedzieć bezczynnie przez 5 dni i zaczynają tworzyć 10 nowych funkcji do następnej iteracji. W tym czasie zespół testowy znalazł wady i podniósł kilka błędów. Błędy są traktowane priorytetowo i niektóre z nich muszą zostać naprawione przed następną iteracją. Problem polega na tym, że nie zaakceptują nowej wersji z nowymi funkcjami lub zmianami w istniejących funkcjach, dopóki wszystkie te błędy nie zostaną naprawione. Zespół testowy mówi, że w ten sposób możemy zagwarantować stabilne wydanie do testowania, jeśli wprowadzimy również nowe funkcje wraz z poprawką błędu. Nie mogą również wykonywać testów regresji wszystkich swoich przypadków testowych podczas każdej iteracji.

Oznacza to, że zespół programistów musi utworzyć gałąź kodu wyłącznie w celu naprawy błędów i inną gałąź, w której będą kontynuować rozwój. Jest więcej łączących się kosztów ogólnych, szczególnie ze zmianą faktorów i zmianami architektonicznymi.

Czy możesz się zgodzić, czy jest to powszechna zasada testowania. Czy problem zespołu testowego jest ważny? Czy spotkałeś się z tym w praktyce w swoim projekcie.

Powiedziałbym zamiast tego, że każde wydanie nowych funkcji powinno znajdować się w osobnej gałęzi. Pozwala to na oddzielenie programowania i wersji.

Jak Twoja wersja dla użytkowników końcowych działa w tym procesie? Zespół testujący system powinien być mniej zainteresowany harmonogramem programowania, a zamiast tego skupić się na harmonogramie wydania klienta.

Nie ma sensu próbować formalnie testować nowych funkcji w trakcie opracowywania, ponieważ są duże szanse, że kolejne 10 funkcji dotknie tej samej funkcjonalności i będzie wymagać ponownego przetestowania tych obszarów.

Mogą kontynuować nieformalne testowanie tymczasowych wewnętrznych wydań podczas opracowywania i dopracować swój projekt testowy (mam nadzieję, że złapie większość błędów związanych z tymi nowymi funkcjami), ale będą potrzebować dodatkowego okresu na koniec opracowywania w celu formalnego przetestowania nowych funkcji i regresji testowanie.

Kiedy szacują, że potrzeba 5 dni na przetestowanie 10 nowych funkcji, powinni wziąć pod uwagę, że potrzebują 5 dni na koniec cyklu programowania, przed wydaniem klientom, aby zweryfikować nowe funkcje (i prawdopodobnie więcej czasu na iterację jeśli zostaną znalezione błędy). W tym okresie wydanie klienta może zostać wydzielone do testowania, a nowe funkcje mogą być kontynuowane w następnej wersji.

Stosujemy podejście hybrydowe. W przypadku wersji dla klientów zdecydowanie mamy własny oddział, który jest przeznaczony wyłącznie do naprawiania krytycznych błędów.

Regularne opracowywanie jest kontynuowane w wielu wersjach oprogramowania. Załóżmy na przykład, że najnowsza stabilna wersja to 2.0. Wszystkie ryzykowne funkcje zostaną dodane do oddziału 3.0. Tylko poprawki błędów trafiają do gałęzi 2.0. Testy przeprowadzane przez dedykowany zespół ds. Kontroli jakości przeprowadzane są wyłącznie na stabilnych oddziałach. Wydania klientów są oczywiście wykonywane z innego oddziału opartego na wersji 2.0. Długotrwałe funkcje, takie jak rozwój platformy nowej generacji, będą realizowane w wersji 4.0, a nawet 3.0.

Wszystko to wygląda dobrze na papierze. Ale jeśli klient chce konkretnej funkcji, należy ją dodać do samego oddziału 2.0, ponieważ 3.0 nie jest wystarczająco stabilny, aby mógł zostać udostępniony klientom. Oznacza to, że zespół kontroli jakości będzie musiał ponownie uruchomić cały pakiet regresji.

Jedną z rzeczy, które robimy, jest pokrycie kodu każdego przypadku testowego regresji. Uruchamiane są tylko przypadki testowe regresji, na które będą miały wpływ zmiany kodu dla tej funkcji. Oczywiście w przypadku wersji dla klientów uruchamiany jest pełny pakiet regresji.

To naprawdę zależy od tego, jak ściśle nowe funkcje są powiązane z częściami, które wymagają naprawy błędów. Np. Jeśli dodasz nową funkcję przeciągnij i upuść do jednej małej części interfejsu, nie powinna ona wpłynąć na błąd związany z analizowaniem pliku załadowanego przez użytkownika.

Powiedziawszy to, zrozumiałe (niekoniecznie uzasadnione) jest, aby testerzy chcieli przetestować poprawki „Ceteris paribus” (wszystkie „inne” rzeczy są takie same).

Mogą pojawić się inne obawy dotyczące sposobu wydania i oczekiwań użytkowników końcowych. Np. Może być konieczne wydanie tylko po jednej iteracji poprawek błędów + testowanie i jeszcze jedna nowa funkcja + testowanie, ponieważ użytkownicy TYLKO chcą ponownej instalacji lub aktualizacji, gdy pojawią się nowe funkcje. Niektóre mogą wymagać poprawek jak najszybciej jak najszybciej.

Możesz rozwiązać ten (powszechny) problem, łącząc scal oba zespoły.

Testerzy w zespole programistycznym, testując powstające funkcje, mogą pomóc większości zespołów zwiększyć jakość wyników.

Sugeruję przeczytanie tego doskonałego postu na blogu Henrika Kniberga, który wyjaśnia Kabana . W procesie Scrum znajdziesz wiele pomysłów (darmowa książka również autorstwa Henrika Kniberga ).

Napisał również na swoim blogu doskonały artykuł Kanban VS Scrum .

Cieszyć się.

Zespół testowy zdecydowanie ma uzasadnione obawy, ale kwestionowałbym potrzebę wielokrotnych iteracji testów dla każdego wydania. Po co przeprowadzać całą serię testów wersji kodu, której użytkownicy nigdy nie zobaczą?

Jeśli testerzy próbują uzyskać określoną wersję dla klienta, która nie oczekuje nowych funkcji, ich żądanie jest uzasadnione, uzasadnione i należy pochylić się, aby je dostarczyć.

Jeśli ma to jedynie pomóc w ich „procesach” podczas normalnych faz programowania i upewnić się, że lista błędów nie wymyka się spod kontroli, to bez problemu, zapytaj szefa działu testowania, czy to ograniczenie może być nieco rozluźnione, dopóki zbliżamy się do punktu wydania.

Rozważ zmianę systemu kontroli źródła na produkt rozproszony. Ułatwi to dostarczenie takiego wydania.

„Czy możesz się zgodzić, czy jest to powszechna zasada testowania.

Yes

Czy problem zespołu testowego jest ważny?

Yes

Czy spotkałeś się z tym w praktyce w swoim projekcie. ”

Yes

:

and Yes Merging is the downside of it 

Nie zapytałeś, kto to jest odpowiedzialność, ale to odpowiedzialność Menedżera konfiguracji. Ta strategia transmisji powinna znajdować się w jego CMP. W przeciwnym razie zwolnij go / ją. Myślę, że odpowiedź Pierre'a 303 jest również bardzo dobra, ale oczywiście tam, gdzie to możliwe technicznie (np. Myśl o wydaniu Siebel ...) i organizacyjnie.

Problem polega na tym, że jeśli testują błędy na gałęzi, muszą ponownie przetestować, a regresja przetestować je na pniu po ponownym połączeniu (chyba że bardzo ufają, którzy dobrzy testerzy rzadko są). To nie tylko praca dla programistów, ale także praca dla testerów.

Nie ma tu właściwej odpowiedzi, ale należy wziąć pod uwagę kilka rzeczy:

• Czy te wydania błędów (bez nowej funkcjonalności) trafią kiedykolwiek do użytkowników? Jeśli tak, to tak, musi być rozgałęziony i przetestowany, a każdy musi zaakceptować to jako koszty ogólne.

• Czy możliwe jest podzielenie nowej funkcjonalności w taki sposób, aby istniała w całkowicie oddzielnych obszarach aplikacji do poprzednich fragmentów, nad którymi pracowano? Jeśli tak, daje to możliwość - testerzy mogą przeprowadzić ponowne testy błędów i testy regresji części aplikacji. Nie jest idealny, ale jest to kompromis, który może zadziałać i dać im to, czego chcą.

• Ile naprawdę pracy kosztuje rozgałęzienie ich wydania? Zasadniczo jest to ból, ale faktyczna ilość pracy zwykle nie jest tak świetna. Oczywiście potrzebujesz ich, aby potwierdzić, że to nie tylko więcej pracy dla nich (zobacz pierwszą rzecz, jaką mówię), ale widziałem, jak miejsca to robią.

• Czy jest lepszy sposób na użycie kontroli wersji? Coś w rodzaju Mercurial (patrz http://hginit.com/ - przeczytaj, to dobrze) lub inny rozproszony system kontroli wersji rozgałęzia się i łączy w inny sposób, co może pomóc w obejściu problemu. Naprawdę, spójrz na to, ponieważ myślę, że może to być odpowiedź na twój problem.

Ale powodzenia, to ból. Przede wszystkim pamiętaj, że najlepsza droga będzie bardzo zależała od Twojej firmy, produktu i sytuacji, więc upewnij się, że o tym pomyślisz, a nie tylko wyciągnij coś z półki i uwierz, że musisz przestrzegać tego w 100%.

Jeśli błędy, które opisujesz, są rzeczywistymi defektami, a nie optymalizacjami projektowymi , tak, naprawdę powinieneś spróbować je naprawić przed rozpoczęciem pracy nad nowymi funkcjami.

Jeśli budujesz nowe funkcje na podstawie znanych błędów, tworzysz domek z kart. Prawdopodobnie stworzysz kruche, nieprzewidywalne oprogramowanie. W zależności od poziomu izolacji między błędnym kodem a nowymi funkcjami błędy mogą również wpływać na nowe funkcje. Jeśli tak, to skąd wiesz, czy nowe funkcje działają poprawnie?

Jeśli najpierw naprawisz swoje błędy, będziesz mieć silniejsze podstawy do dodawania nowych funkcji.

Z pewnością zdarzają się sytuacje, w których siły zewnętrzne wywierają presję, aby postępować wbrew rozsądkowi. Postaraj się pomóc decydentom w podjęciu świadomej decyzji, gdy będą świadomi konsekwencji któregokolwiek z działań (tj. Nierozwiązanych wad w porównaniu z brakującymi terminami dostarczenia funkcji) i pozwól im podjąć decyzję. Czasami istnieją prawne i finansowe powody, dla których konieczne są działania, choć nie są one preferowane.

Zawsze staraj się naprawiać błędy przed dodaniem nowych funkcji!

Tam, gdzie pracuję, radzimy sobie z tym scenariuszem, w którym każde zamierzone wydanie do produkcji ma swój własny oddział. Załóżmy na przykład, że przez sekundę pojawi się wydanie pod koniec czerwca, a kolejne pod koniec lipca. Wydanie czerwcowe otrzyma własny oddział, a wszystkie funkcje zostaną tam dodane i przesłane do kontroli jakości. W tym momencie zaczniemy pracować nad wydaniem lipcowym i oddziałem z oddziału czerwcowego. Kiedy QA znajdzie błędy, naprawiamy je w czerwcowym oddziale, a kiedy poprawki zostaną przekazane do QA, są one łączone w lipcowej gałęzi wydania. Dodaje to trochę narzutu do obsługi tych połączeń, ale zazwyczaj połączenia są dość bezbolesne. Od czasu do czasu jest to uciążliwe, ponieważ wiesz, co się dzieje, ale dzieje się tak tylko wtedy, gdy wprowadzane są zmiany hurtowe, a nie powinny się zdarzyć podczas cyklu kontroli jakości (ale zdarzają się, więcej niż lubię przyznać). Ale z dobrym zestawem testów (jednostkowych i integracyjnych), pokryciem kodu i wszystkimi innymi modnymi hasłami TDD, ryzyko jest nieco zmniejszone. Aby pomóc, zwykle mamy jedną osobę obsługującą scalenia dla każdego projektu.