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

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ć?

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.

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.

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).

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.

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ł.

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.

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.