blog.testowka.pl

Tester w Agile – sztuka zadawania pytań

opublikowany przez 31, Maj, 2012, w kategoriach Agile, Automatyzacja, Inne, Scrum, Testowanie, XP

Cały czas ludzie pytają mnie o to jaka jest rola testera w zespole pracującym wg Agile/Scrum? Jakie kompetencje powinien mieć taki tester? Czy wystarczy by tester w Agile tylko „klikał”? Jeśli klikanie to za mało to w jaki sposób poszerzać kompetencje testerów?

Rola testera w Agile jest niezwykle istotna! Szeroko rozumiane testowanie jest podstawą zwinnych metodyk wytwarzania oprogramowania. Przez „szeroko rozumiane” mam na myśli oczywiście nie tylko klikanie ale i automatyzację. Tak! Drodzy testerzy dobrze jeśli potraficie automatyzować testy – nie mówię tutaj o regularnym programowaniu, ale o ułatwianiu swojej i innych pracy. Oczywiście nie skreślam nigdy testerów klikających – ich wiedza i umiejętności są niewątpliwie istotne. Tester nie programujący/automatyzujący na co dzień może i powinien pełnić rolę „adwokata diabła” (klienta) – to tester potrafi najlepiej wczuć się w potencjalnego użytkownika testowanej aplikacji i spojrzeć na nią z zupełnie innej niż programiści perspektywy.

W trakcie sprintu/iteracji tester powinien poświęcać jak najwięcej czasu na… uwaga… testowanie. Testowanie to nie tylko wykonywanie scenariuszy czy też ich automatyzacja – to przede wszystkim zadawanie pytań. Pierwsze podstawowe pytanie zadawane, gdy ktoś oddaje coś do testów powinno brzmieć: „Czy to na pewno jest do testów gotowe?”, lub „Co programista rozumie poprzez zrobione?”. Ale czy moment „oddania do testów” jest pierwszą okazją do zadawania pytań? Oczywiście nie – pytać można dużo wcześniej – chociażby siadając z programistami i gdy nawet jeszcze nie przystąpią do swojej pracy zadawać pytania typu: „Jak zamierzasz to zaimplementować?”, „Czy wziąłeś pod uwagę taki scenariusz?”, „Jak to się ma do naszej Definition of Done?”. „Czy to na pewno wszystkie kryteria akceptacji jakie są wymagane by uznać tą funkcjonalność za skończoną?”. Oprócz programistów tester powinien gnębić swoimi pytaniami także klienta – doprecyzowując wymagania i eliminując wszelkie wątpliwości. Efektem ubocznym rozmów z klientem i programistami jest ciągłe poszerzanie wiedzy na temat testowanego produktu co w efekcie drastycznie podnosi jakość testów i przekłada się na produktywność całego zespołu.

Tester w Agile musi się wykazać pewną pro-aktywnością i samemu organizować swoją pracę. To tester powinien zawsze wychodzić na przeciw klientowi, użytkownikom czy programistom i aktywnie uczestniczyć w projekcie od samego początku.

Jeśli programiści korzystają z praktyk Programowania eXtremalnego (XP) takich jak programowanie w parach i Test Driven Development to nie ma lepszego miejsca dla testera niż siedzenie w parze z programistą. Oczywiście tester nie umiejący programować w kwestiach technicznych niewiele pomoże (przynajmniej na początku) ale już na przykład podczas dobierania odpowiednich przypadków testowych w TDD jego wiedza może być niezwykle przydatna. Tester w parze z programistą pełni rolę nawigatora (patrz google + pair programming). Tego typu podejście bardzo szybko sprawi, że tester poprzez najpierw zrozumienie kodu a następnie czynny udział w programowaniu będzie rozwijał swoje umiejętności potrzebne do automatyzacji testów i nie tylko.

Kolejny temat, który ostatnio ktoś poruszył to problem z testerami, którzy uważają, że naturalną ścieżką kariery testera jest w pewnym momencie zostanie (młodszym) programistą. Ogólnie uważam, że nie ma w tym nic złego – jeśli weźmiemy pod uwagę fakt że programowanie to gra zespołowa to posiadanie w zespole programisty z backgroundem testerskim niezwykle ułatwia życie. Taki programista/tester jest w stanie fachowo wspierać kolegów testerów w momencie, gdy akurat zadań dla testerów jest więcej. Ponadto bagaż doświadczeń zdobytych na stanowisku testera sprawia, że taka osoba dużo lepiej rozumie istotę i problemy związane z testowaniem więc wykorzystując swoje umiejętności programistyczne może skutecznie ułatwiać pracę testerów. Z drugiej strony kto by tam chciał być programistą gdy testowanie jest takie ciekawe! 😛

Powyższe to tylko kilka moich pomysłów, a w zasadzie zbiór prywatnych doświadczeń związanych z testowanie w zespole pracującym wg Agile/Scrum. Z chęcią posłucham o Waszych pomysłach a przede wszystkim doświadczeniach co do tego jak pracować w takim zespole – w komentarzach jest dużo miejsca…


6 Comments for this entry

  • Łukasz Herok

    Jeśli tester faktycznie się przyłoży i będzie zdobywał wiedzę biznesową bezpośrednio od klienta, potem uczył się szczegółów technicznych przy implementacji z programistą to chyba bardziej naturalnym kierunkiem rozwoju będzie analityk ;).

  • streser

    Anality, Programista, Senior Tester, Test Engineer… Co za różnica? Najważniejsze, że niezwykle wartościowy członek zespołu wnoszący bardzo dużą wartość!

  • Maciek T

    Wydaje mi się, że w agile tester oprócz umiejętnego zadawania pytań, sam powinien potrafić też odpowiedzieć na pytania ze strony programistów (m.in te dotyczące właśnie ‚logiki biznesowej’).
    Zgadzam się, że tworzenie par dev tester może
    przynieść sporo korzyści testerowi, ale nie tylko jemu. Przecież dev też może skorzystać ucząc się od testera odpowiedniego podejścia do testów. I tu zahaczamy o kolejną rzecz. Tester powinien zadbać o rozwój umiejętności testerskich u programistów (choćby po to, żeby z czasem mieć co raz mniej powodów do narzekań na to co dostaje na końcu do przetestowania 🙂 )

    @stereser
    do zobaczenia na byop w Krk

  • Adam

    Kilka ortów w tekście – „Tester w parze z programistom” -programistą. Kilka razy się to pojawia 🙂

  • streser

    Dzięki!
    Poprawione. Mam nadzieję, że wszystko… 🙂
    Potencjalna przyczyna: deklinacja w liczbie pojedynczej i mnogiej… 🙂

  • S!MON

    Odniosę się do sztuki z tematu w nawiązaniu nie tylko do testerów 😉 Osobiście czasem mam wrażenie, że programista nawet w sytuacji, gdy należałoby się pokusić o zadanie pytania inwestuje czas w pisanie kodu… i nie pyta. W konsekwencji z uwagi na niewłaściwą interpretację zagadnienia musi ten kod skorygować. A wystarczyło zadać pytanie kontrolne… Oczywiście ma to bezpośredni związek z jakością informacji na temat wykonywanego zadania, a z tą bywa różnie.

    Sztuka zadawania pytań nie jest taka prosta i nie jest do opanowania przez wszystkich w jednakowym czasie. Niektórzy ją mają w małym palcu, niektórzy muszą się jej nauczyć, niektórzy będą się z nią męczyć… z różnymi efektami. Ważne żeby pytać, drążyć. Dzięki temu w parze „jakoś vs jakość” bliżej będzie nam do tego drugiego. W bardzo dużym uproszczeniu 🙂

    @Maciek T – gdyby jedynym powodem do narzekań testera była jakość produktu, który oddaje programista.. 😉

1 Trackback or Pingback for this entry

Skomentuj