Dlaczego przewodnik Scrum mówi, że nie ma testerów?

14

Czytam Scrum Guide ze scrum.org i mówi:

Zespoły programistów nie zawierają podgrup zajmujących się konkretnymi dziedzinami, takimi jak testy lub analizy biznesowe.

W dosłownym tłumaczeniu oznacza to, że nie ma testerów, co jest mylące. Jak mogą to sugerować?

Pete2k
źródło
4
W dosłownym tłumaczeniu oznacza to również, że nie ma programisty. Nie ma analityka biznesowego. Odpowiednią analogią jest to, że każdy jest ocalałym, którego zadaniem jest zrobienie (i nauczenie się) wszystkiego, co jest potrzebne, aby pomóc wszystkim przetrwać.
rwong
3
Nie, to wcale nie jest dosłowne tłumaczenie. Mówi, że nie ma dedykowanych podgrup, to wszystko. Możesz podzielić swoją drużynę na podgrupy, aby rozwiązać problemy, ale te drużyny powinny być w stanie mieszać się i dopasowywać za jednym zamachem. Nie mówi nic o braku testerów.
zzzzBov,

Odpowiedzi:

25

Oznacza to, że albo:

  1. Testerzy są zintegrowani z zespołem programistów - narzędzia do budowania, które pomagają programistom w testowaniu i testowaniu.

    lub:

  2. Zespół ćwiczy rozwój oparty na testach - tj. Piszą automatyczne testy, które ćwiczą system.

Każdy z tych środków oznacza, że ​​nie ma potrzeby tworzenia osobnego zespołu testującego.

ChrisF
źródło
TDD byłoby lepszym podejściem dla zespołów startupowych. Mam silne poczucie, że kiedy testerzy i programiści pracują razem w nowicjuszach, testowanie staje się problemem. Co mówisz?
Maxood,
4
@ Maxood: Powiedziałbym, że TDD zdecydowanie nie czyni zbędnym testowania ręcznego. Jeśli coś staje się problemem, rozwiązujesz go; nie zaczynasz tego unikać.
Michael Borgwardt,
@MichaelBorgwardt Very true! Ale co, jeśli uznasz, że Twój tester jest zajęty testowaniem jednostkowym, które jest przede wszystkim zadaniem programisty? Uważam, że ta pierwsza opcja powinna być dostępna tylko w przypadku optymalizacji kodu i skalowalności aplikacji itp. Co powiesz?
Maxood,
7
@ Maxood: Moim zdaniem testerzy nie powinni dotykać testów jednostkowych. Powinny pracować nad testami akceptacyjnymi we współpracy z programistami i ponosić odpowiedzialność za testowanie ręczne / GUI. Testy jednostkowe są na poziomie interesującym tylko dla programistów. Piramida testowa ( blogs.agilefaqs.com/2011/02/01/inverting-the-testing-pyramid ) ma również funkcje odpowiedzi, Testowanie jednostkowe = programiści, testowanie akceptacji = wspólne, testowanie GUI = testery.
martiert
12

W dosłownym tłumaczeniu oznacza to, że nie ma testerów, co jest mylące ... Jak mogą to sugerować?

Tak, dokładnie to sugerują. Innymi słowy - programiści to testerzy, a testerzy to programiści.

Chodzi o to, aby promować własność i jakość kodu .

Nie oznacza to, że kod nie jest testowany, ale że ludzie zaangażowani w jego pisanie są tymi, którzy są zaangażowani w testowanie go - nie ma podziału obowiązków.

Problemem, który to podejście próbuje rozwiązać, jest zbyt powszechna separacja między programistami i testerami, w której programiści piszą kod i „rzucają go na mur” drugiemu zespołowi, a następnie przesuwa się tam iz powrotem, opóźniając projekt i produkując oprogramowanie niestandardowe.

Oded
źródło
2
Jestem silnym zwolennikiem posiadania osoby A, którą opracowała osoba B. Co ma Scrum, aby uniknąć pułapek „własnej ślepoty na kod” (jeśli zarówno jesteś programistą, jak i testerem funkcji X, nie ćwiczysz kodu pod każdym względem, ponieważ wiesz, jak jest kodowany i zakładasz, że musi pracować, czy podświadomie unikać słabszych punktów)?
Marjan Venema
1
@MarjanVenema - Jaka osoba A napisała, może być przetestowana przez osobę B lub testy automatyczne mogą zostać napisane przed napisaniem kodu
Oded
5
Wszyscy programiści mają ślepotę zapewniania jakości, która nigdy nie ustępuje. To, co wydarzyło się w branży, to fakt, że ludzie posunęli się za daleko z „QA kontra Devs” i stworzyli ten system „przerzucenia muru”, a potem nastąpił luz. Devs i QA odnoszą sukcesy i porażki jako jeden zespół, ale QA to rola i umiejętność inna niż kodowanie. Kodery muszą testować, a testy jednostkowe są częścią kontroli jakości, ale nie jest to cała funkcja kontroli jakości. Role kontroli jakości często obejmują także tworzenie dokumentacji w miejscach, które nie stały się tak „zwinne”, że przestały pisać dokumentację techniczną.
Warren P
6
Z mojego doświadczenia wynika, że ​​właśnie rozdzielenie ról pozwala testerowi spojrzeć na oprogramowanie z punktu widzenia użytkownika końcowego i znaleźć o wiele więcej błędów niż programista. Powstały produkt zdecydowanie nie jest „niespełniający standardów”.
Giorgio,
2
Kontrola jakości i rozwój to dwie odrębne role z dwoma różnymi zestawami umiejętności (i skalami wynagrodzeń). Doskonała kontrola jakości wymaga poziomu koncentracji i specjalizacji, który po prostu nie nastąpi, jeśli ktoś wykonuje podwójną pracę jako programista i kontrola jakości.
17 z 26
2

Zasadniczą częścią tego jest to, że odpowiedzialnością kodera jest stworzenie kodu, który działa i spełnia wymagania. Wymaga to szczególnego sposobu myślenia - „Kod, który piszę, robi to, co powinien”.

Pomieszanie obowiązków programisty oznacza, że ​​programista musi teraz wprowadzić inne nastawienia do innych czynności, jednak jako programista trudno jest całkowicie oderwać się od tego nastawienia.

Obowiązkiem testera jest znalezienie błędów i miejsc, w których funkcjonalność odbiega od wymaganej funkcjonalności. Wymagało to sposobu myślenia „Kod jest zepsuty i dowiem się, jak”.

Podobnie, analityk biznesowy próbuje określić wymagania, o które tak naprawdę prosi klient. Wymaga to innego sposobu myślenia: „aplikacja nie działa w ten sposób, ale powinna”.

Aby koder działał w którejkolwiek z tych innych funkcji, istnieje uzasadnione prawdopodobieństwo, że nastawienia będą sprzeczne, a koder wykona podparat:

  • Coder / QA - „Kod działa doskonale, a ja już kodowałem, aby obsłużyć każdy możliwy sposób, który może go zepsuć”.
  • Coder / BA - „Kod powinien działać tak, jak tego chcę, i byłoby to fajne dodanie, o czym klient nie pomyślał.

Nie oznacza to, że każdy koder jest podatny na te problemy (spotkałem kilka bardzo utalentowanych typów koderów / QA ... chociaż nie dla kodu, który napisali).

Dotyczy to również zespołu programistów. Mieszanie obowiązków i związanych z nimi sposobów myślenia tych zespołów w zespole programistycznym naraża produkt końcowy (kod).

geocodezip
źródło
1

Mówi, że nie ma poddziałów przeznaczonych do testowania. To nie znaczy, że nie przeprowadzono żadnych testów. Oznacza to tylko, że członkowie zespołu przeprowadzą własne testy i często przetestują kod / funkcje innych osób. Nie jestem zbyt zaznajomiony z metodologią scrum, ale przejdę do tematu i powiem, że klient może być również zaangażowany w testowanie.

marco-fiset
źródło
„Klient może być również zaangażowany w testowanie” - tak, dokładnie tak, w przeciwnym razie masz projekt wodospadu, w którym definicja „zrobiliśmy to”, osiągnęliśmy koniec projektu ”. To nie jest zwinne.
Robin Green,
1

Myślę, że częściowo oznacza to, że masz pisać testy dla własnego kodu, abyś wiedział, że działa (jeśli nie, to tak naprawdę go nie ukończyłeś), a częściowo, że czasami można oczekiwać, że będziesz testerem kodu innych osób .

Zamiast pozwalać ludziom na przeniesienie zadania jakości oprogramowania na kogoś innego i ignorowanie go, zmusza to wszystkich do myślenia o pisanym przez siebie kodzie przez cały czas z punktu widzenia jakości, więc jest to dobry pomysł.

Matt Gibson
źródło
1

To stwierdzenie zasadniczo stara się uniknąć pracy w trybie wyciszenia. Jedną z części tego rozwiązania są praktyki takie jak - Rozwój oparty na testach - Programowanie w parach - Żądania ściągania - Automatyzacja testów i podobne, które sprawiają, że testowanie jest nieodłączną częścią procesu rozwoju, a nie czymś, co odbywa się w oderwaniu od strony 'po'.

Ponadto w Przewodniku po Scrumie bardzo niewiele mówi się o rolach. W rzeczywistości mówią o zespole programistycznym. Oznacza to, że chcesz silnego, wielofunkcyjnego zespołu. Oznacza to, że w zależności od tego, czego potrzebują twoje projekty, potrzebujesz szeregu umiejętności, takich jak UX, BA, QA / Tester, Ops, Coder itp. Itd., Ale to, czy jest to jedna, czy wiele osób zajmujących się nimi, nie ma znaczenia.

Zespoły, z którymi pracuję, z pewnością mają rolę QA, ponieważ mamy ludzi DevOps. Ale wszyscy są także Devami, tylko ze specjalizacją w tych obszarach. Sztuka polega na tym, aby nie wpaść w silosy i pracować w izolacji.

użytkownik334514
źródło
1

Nie musi to oznaczać, że nie ma testerów. Może się zdarzyć, że zespół Scrumowy ma dedykowanych testerów lub nie.

Dla mnie to stwierdzenie o Scrumie oznacza, że ​​powinieneś myśleć o całym procesie dostaw jako o jednym zespole. Przynależność do tego samego zespołu sugeruje kilka rzeczy:

  1. Istnieje jedna ocena dla historii / błędu / zadania. Nie ma oszacowania dewelopera i oszacowania testowego.
  2. Zespół nie ocenia historii i nie angażuje się w nią bez obecności testera.
  3. Jeśli coś pójdzie nie tak, to nie jest to wina testera, ale wina programisty. To wina zespołu .
  4. Zespół nigdy nie musi pożyczać, prosić ani prosić o testerów.
  5. Testowanie jest częścią definicji wykonanej. Praca niesprawdzona to praca niepełna.
  6. Programiści powinni wziąć pod uwagę testowalność, projektując swój kod.

Jeśli pracują razem w jednym zespole, to zespół odnosi sukces razem i razem zawodzi. Byłem w bardzo udanym zespole Scrum, który miał kilku testerów. Testerzy byli obecni podczas wszystkich pojedynków, sesji pielęgnacyjnych, planowania itp. Gdyby nie było jasne, jak przetestować historię, zespół nie zaangażowałby się w nią. Podczas szacowania zawsze rozmawialiśmy z naszymi testerami.

Potencjalne oznaki, że tak naprawdę nie możesz traktować testerów jako części zespołu dostarczającego, nawet jeśli uważasz, że tak:

  1. Testerzy mają „stand-up QA” (tak, widziałem to).
  2. Testerzy mają osobną strukturę zarządzania.
  3. Masz potencjalną kontrolę jakości.
  4. Polegasz w dużej mierze na kompleksowych testach.
  5. Testy zapisują następujący sprint.
  6. Większość testów odbywa się ostatniego dnia sprintu.

Są to subiektywne i niekoniecznie złe. Są to jednak, moim zdaniem, czerwone flagi.

Wszystko to mówi, że jest całkowicie możliwe posiadanie zespołu Scrum bez nikogo, kto ma wyznaczoną rolę testera. To też może dobrze działać. Zwłaszcza jeśli zautomatyzujesz testowanie. TDD też pomaga.

Brandon
źródło