Kodowanie i testowanie w tym samym sprincie

Jak odbywa się testowanie w ramach tego samego sprintu co kodowanie, jeśli całość lub większość kodowania nie jest wykonywana do końca sprintu? (Mam na myśli opracowanie „zupy do orzechów” i testowanie pojedynczego PBI w sprincie).

Większość odpowiedzi, które widziałem online, dotyczy automatyzacji kontroli jakości, ale nawet to nie jest tak naprawdę możliwe, ponieważ na ogół potrzebujesz funkcjonalnego interfejsu użytkownika do rejestrowania lub tworzenia automatycznych testów. Mam tylko scenorysy, które wciąż ewoluują, gdy rozwijam funkcje i odkrywam nowe wymagania.

W moim przypadku opracowuję nową aplikację komputerową. Aplikacje komputerowe zazwyczaj nie są zbyt dobrze testowane automatycznie. Mam kilka zautomatyzowanych testów jednostkowych, ale nie są to ręczne testy funkcjonalne / integracyjne, które wykonałby specjalista ds. Kontroli jakości.

Tak więc, gdzie jestem teraz, że mój sprint kończy się jutro, wciąż mam kodowanie do ukończenia, a moi pracownicy QA nie mają jeszcze nic do przetestowania i nie mam pojęcia, jak przetestować wszystko, co im dam, bez trzymania ich za ręce.

Jestem pewien, że nie jestem pierwszą osobą, która ma ten dylemat.

W przeszłości robiłem potok: w bieżącym sprincie zespół testujący testuje funkcje, które zostały zaimplementowane podczas poprzedniego sprintu. W mojej obecnej pracy premier nazywa to podejście „wodospadem” i jako takie jest niedopuszczalne.

Jeśli nie przetestujesz historii użytkownika (USA) i nie sprawdzisz, czy kryteria akceptacji są spełnione, ta historia nie zostanie wykonana. Jeśli nie zostanie to zrobione, USA oczywiście przejdą do następnego sprintu. A jeśli wszystkie twoje Stany Zjednoczone są w tym stanie, sprint zakończył się bez żadnej wartości dodanej do projektu. Z punktu widzenia klienta nie mogę odróżnić tego od całego zespołu programistów wyjeżdżających na wakacje.

Jedna z zasad lean (zwinna nie kończy się na scrumie) mówi „jakość jest wbudowana”. Coś się dzieje tylko wtedy, gdy spełnia określone przez ciebie kryteria jakości. Jest to bardzo ważne, aby mieć naprawdę sprawny proces, zakończenie sprężyny zerową wartością lub oddzielne testowanie od rozwoju to objawy dużego problemu.

Istnieje wiele rzeczy, które możesz zrobić:

• automatyzacja jest kluczem do sukcesu. Przynajmniej na poziomie testu jednostkowego i niektóre inne praktyki, takie jak CI są również ważne. To nie wystarczy, ale jeśli zostanie wykonane dobrze, tego typu testy powodują kilka błędów lub nie wykryto żadnych błędów podczas testowania ręcznego (zwykle drobne rzeczy w interfejsie użytkownika). Jeśli masz dedykowane osoby odpowiedzialne za kontrolę jakości, to one mogą automatyzować testy akceptacyjne, a niektóre z tych automatyzacji można uruchomić przed zakończeniem sprintu.

• Spójrz na rozmiar swoich historii użytkowników. Jeśli masz USA, które zakończyło się przez dwa pierwsze dni sprintu, na trzeci dzień osoba QA może je przetestować. Moim zdaniem posiadanie niewielkich (SMART) historii użytkowników jest jedną z najważniejszych rzeczy dla sukcesu w sprawnym rozwoju, a wiele osób wydaje się nie zdawać sobie z tego sprawy.

• Współpraca między testerem a programistami to kolejna kluczowa część sukcesu. W moim poprzednim projekcie, kiedy USA zakończyły prace dewelopera, osoba przeprowadzająca kontrolę jakości „paruje testy” z deweloperem (może być ręczna, może polegać na uruchomieniu zautomatyzowanych lub lepiej obu), działa to całkiem dobrze.

Podstawowym problemem jest to, że masz programistów, którzy kodują, ale nie testują, oraz testerów, którzy testują, ale nie kodują.

Rozwiąż ten problem, a nie będziesz miał tego problemu, i prawdopodobnie bardziej wydajnego zespołu.

Jednym ze sposobów, który w przeszłości działał dla mnie, było zasugerowanie programistom i testerom powiązania opowieści z wyraźnym zadaniem dostarczenia w pełni przetestowanej historii. Razem z tym wymazałem wszystkie formy myślenia „dev devlet”: brak kolumn „dev devlet” na płycie scrum / kanban / trello, brak postawy „dev dev” przez programistów.

Stało się:

• Pary były odpowiedzialne za dostarczanie opowieści i oboje poniosłyby porażkę, gdyby historia nie została ukończona. Byli traktowani jako odpowiedzialni specjaliści odpowiedzialni za dostarczanie oprogramowania i w większości przypadków tak robili.

• Wykonano znacznie mniej prac testowych, ponieważ testerzy byli narażeni na testy jednostkowe i integracyjne, więc nie powtórzyli ręcznie tego samego testu.

• Niektóre testy zostały zautomatyzowane, gdy deweloperzy lepiej zrozumieli, czego potrzebują testerzy.

• Niektórzy się zdenerwowali.

• Historie dostarczano średnio szybciej, ponieważ cykl testu-zatwierdzenia-ściągnięcia-testu stał się prawie natychmiastowy

Oczywiście jest to tylko moje anegdotyczne doświadczenie, ale możesz spróbować samemu, jeśli możesz.

W twoim przypadku, biorąc pod uwagę twój komentarz, że testerzy i programiści są autorytatywnie rozdzieleni w twojej firmie, przesłanie wydaje mi się jasne. Istnieje oczywista bariera w komunikacji i współpracy wynikająca z reguł firmy.

Jest to problem z komunikacją , a nie zwinny . Przyjęcie zwinnej metodologii jest po prostu widoczne. Zespoły Silo'd są znanym anty-wzorcem zarządzania , więc w tym przypadku zaakceptuj brak możliwości dostosowania zwinnego!

Rzeczywista rola twojego QA jest bliska testom akceptacyjnym. Wyobrażam sobie, że może to zrobić odrębny zespół, który działa raczej jako właściciel produktu niż część zespołu programistów.

Przykład: podczas sprintu musisz dodać funkcję, która umożliwia filtrowanie wyników wyszukiwania według różnych kryteriów. Masz już zaimplementowany mechanizm wyszukiwania, ale wyniki są uporządkowane alfabetycznie.

• Podczas sprintu:

  1. Zespół opracowuje projekt nowej funkcji i wpływ na rzeczywistą bazę kodu.

  2. Deweloperzy piszą testy jednostkowe, które zapewniają, że zamawianie działa zgodnie z oczekiwaniami, a jednocześnie zapisują rzeczywisty kod.

  3. Nowa funkcja została dokładnie przetestowana, aby upewnić się, że niczego nie psuje (testy regresji) i że działa zgodnie z oczekiwaniami (testy jednostkowe).

  4. Jeśli jest to możliwe i właściwe , co nie ma miejsca w większości projektów , właściciel produktu (a więc zespół kontroli jakości) może stale oceniać nową funkcję, aby uniemożliwić zespołowi pójście w złym kierunku. Wymaga to ciągłej integracji z dziesiątkami kompilacji każdego dnia.

• Po sprincie właściciel produktu ocenia nową funkcję, aby sprawdzić, czy odpowiada ona potrzebom klienta. Twój zespół kontroli jakości jest już tutaj, po zakończeniu sprintu.

Uważam, że Twoje rzeczywiste problemy są następujące:

• Zakres . Sprint dotyczy twojego zespołu i tylko twojego zespołu, a nie twojej faktycznej kontroli jakości, która działa bardziej jak właściciel produktu.

• Testowanie . Fakt, że masz zespół kontroli jakości, nie oznacza, że ​​wszystko, co musisz zrobić, to napisać kod. Zadaniem twojego zespołu jest dostarczenie funkcji, która działa zgodnie z oczekiwaniami, a nie wyrzucanie kodu do przetestowania przez innych. Jeśli polegasz na zespole ds. Kontroli jakości, który przeprowadzi dla ciebie testy, zwiększy to całkowity koszt, ponieważ błędy zostaną naprawione jeden do dwóch tygodni później, a nie zostaną naprawione niemal natychmiast.

jeśli całość lub większość kodowania nie zostanie wykonana do końca sprintu?

Dlaczego nie kończy się wcześniej? To kluczowe ograniczenie jest źródłem twoich problemów i widziałem, że dwa podejścia były skuteczne. Jedna pasuje dobrze do zwinnego podejścia (ale nie do innych powszechnych praktyk), a druga do nieco zwinnych (ale jest bardziej powszechna).

Po pierwsze, nie kodujesz do końca sprintu. W rzeczywistości pisanie kodu jest stosunkowo małą częścią rozwoju. Jeśli skończysz mniej więcej w połowie sprintu, zapewni to mnóstwo czasu QA na wykonanie swojej pracy. Pozostawia ci również dużo czasu na napisanie dokumentacji, uporządkowanie długu technicznego, zaprojektowanie pozycji zaległości ... Wszystkie inne rzeczy, które musisz zrobić dla produktu wysokiej jakości. Jedynym minusem tego, co widziałem, jest to, że uzyskanie funkcjonalności i testów jednostkowych jest prawie niemożliwe . Osobiście uważam, że przeprowadzanie testów jednostkowych po pozwoleniu QA na sprawdzenie funkcjonalności jest w porządku , ale zwolennicy TDD (i inni) się nie zgodzą.

Drugą opcją jest sprawienie, by dział kontroli jakości przeprowadził sprint za personelem programistycznym, tak jak twoi nienawidzą PM. Ja też nie lubię tego. Eliminuje to koncepcję „produktu do zwolnienia” na końcu sprintu, nawet jeśli masz proces eskalacji swoich wydań. Co gorsza, programiści będą koncentrować się na „nowych” rzeczach, gdy pojawi się w nich QA z pytaniami lub błędami z testów. Twórcy oprogramowania raczej nie naprawiają błędów w tym układzie. Ale widziałem, że na czas produkuje wysokiej jakości oprogramowanie.

Przewodnik Scrumowy wymaga, aby zespoły były funkcjonalne. Wszyscy członkowie zespołu są uważani za programistów, niezależnie od ich indywidualnej specjalizacji. Osoby z silosem (programista, tester, qa, ux itp.) Nie są pomocne w Scrumie. Członkowie zespołu pomagają sobie wzajemnie, gdzie tylko mogą. Nie ma koncepcji „przekazania przedmiotu qa”.

W twojej sytuacji brzmi to tak, jakbyś miał problem z oszacowaniem. Szacując pozycje zaległości produktu, należy wziąć pod uwagę wszystkie działania, tj .: kodowanie, testowanie, przegląd partnerski, wdrażanie, integracja - bez względu na zdefiniowaną definicję wykonanych wymagań.

Jako ogólną zasadę spodziewaj się, że w sprincie znajdzie się od 5 do 15 pozycji zaległych produktów. To daje wyobrażenie o tym, jak duży powinien być każdy element zaległości w produkcie. Daje to również doskonałą szansę na „wykonanie” pracy w trakcie sprintu.

Wreszcie zadaniem zespołu jest przeniesienie jednego elementu zaległości w produkcie na „gotowe”, a następnie przejście do następnego. Czasami robienie tego oznacza, że ​​ludzie stąpają sobie po palcach, dlatego sensowne jest narastanie więcej niż jednego zaległości produktu na raz. Zaleca się jednak ograniczenie pracy w toku (WIP) i przeniesienie pozycji zaległych produktów do końca.

Testowanie i kodowanie idą w parze. Możesz zaplanować to moduł po module. Po zakończeniu modułu możesz dostarczyć go testerom. Cały scenariusz zależy również od fazy testowania, nad którą pracujesz. Spiralny model SDLC wygląda dobrze. Dzięki temu wygodne jest jednoczesne testowanie i kodowanie. Innym rozwiązaniem mogłoby być model V .

Moja odpowiedź, która na początku jest prawdopodobnie dość dziwna, brzmiałaby następująco: nie masz czasu na testowanie, ponieważ uważasz, że należy przeprowadzić testy pod kątem skutków ubocznych kodu. I ze skutkiem ubocznym mam na myśli termin informatyka :

mówi się, że funkcja (...) ma efekt uboczny, jeśli oprócz zwracania wartości ma także (...) obserwowalną interakcję ze (...) światem zewnętrznym.

Podniosłem cytat, aby podkreślić część „interakcja ze światem zewnętrznym”: chcesz, aby testy odbywały się w interfejsie użytkownika, ponieważ jest on drukowany na ekranie („[rozpocząć testowanie] tak naprawdę nie jest możliwe, ponieważ ogólnie potrzebujesz funkcjonalnej Interfejs użytkownika do rejestrowania lub tworzenia automatycznych testów z „).

Inne odpowiedzi mówiły o zautomatyzowaniu tego „testu akceptacyjnego”, aby mógł się on odbyć szybko. To prawda, ale nie rozwiązuje w pełni oryginalnego problemu: co zrobić, jeśli nie ma wystarczająco dużo czasu na napisanie testów akceptacyjnych?

Musisz zrezygnować z testowania, gdy kod wejdzie w interakcję ze światem zewnętrznym, tj. Wydrukuje coś i oczekuje pewnej ilości danych wejściowych. Problem z efektami ubocznymi polega na tym, że są one w rzeczywistości niestabilne. To przyszło mi do głowy podczas czytania wywiadu z Guido van Rossumem, gdzie powiedział, że stwierdzenie, że wyłącza komputer, można udowodnić, że działa tylko poprzez jego wykonanie.

Rozwiązaniem tej „niestabilności” jest zrozumienie, że jeśli raz udowodniłeś, że instrukcja działa, możesz używać jej wszędzie i polegać na niej. Wyizoluj go w funkcji i przetestuj wszystko inne .

Przybliżając ten przykład do pytania, funkcja jest teraz prawdopodobnie całą biblioteką lub strukturą i zamiast wyłączać komputer, wypisuje coś: interfejs użytkownika. Zachowaj połączenia z nim tak głupie i stabilne, jak to możliwe , ponieważ po wejściu do tej części aplikacji możesz testować tylko za pomocą drogich testów akceptacyjnych, tj. Jakiejś zewnętrznej obserwacji.

Uznanie interfejsu użytkownika za „obce terytorium” jest właściwie właściwym punktem widzenia, ponieważ nie trzeba testować logiki biblioteki, która nie jest przez ciebie udostępniana, i być może, co zaskakujące, jest to realistyczny punkt widzenia: czy naprawdę oczekujesz, że kiedykolwiek przetestujesz to wywołanie, np. MyWidget.draw()czy tego, czego oczekujesz, do poziomu pojedynczego piksela?

Nie oznacza to, że testy akceptacyjne nie są ważne ani że można je pominąć. Ma pozostać, a automatyzacja, jak sugerują inne odpowiedzi, ma ogromne zalety. Ale jeśli chcesz znaleźć czas na przetestowanie i zakodowanie w tym samym sprincie, postaraj się, aby Twój kod był jak najbardziej wolny od skutków ubocznych.