{"id":30493,"date":"2019-04-17T07:47:07","date_gmt":"2019-04-17T05:47:07","guid":{"rendered":"https:\/\/nearshore-it.eu\/artykuly\/rola-testera-w-zespole-scrumowym\/"},"modified":"2024-10-02T15:33:55","modified_gmt":"2024-10-02T13:33:55","slug":"rola-testera-w-zespole-scrumowym","status":"publish","type":"post","link":"https:\/\/nearshore-it.eu\/pl\/artykuly\/rola-testera-w-zespole-scrumowym\/","title":{"rendered":"Rola testera w zespole scrumowym"},"content":{"rendered":"\n
\n

Przejd\u017a do:<\/p>\n

    \n
  1. 1. Hierarchia w zespole scrumowym<\/a><\/li>\n
  2. 2. Tester: model tradycyjny vs. Scrum<\/a><\/li>\n
  3. 3. Rola testera w Scrumie \u2013 mity<\/a><\/li>\n
  4. 4. Zadania testera w zespole scrumowym<\/a><\/li>\n
  5. 5. Podsumowanie<\/a><\/li>\n <\/ol>\n<\/div>\n\n\n

    Hierarchia w zespole scrumowym<\/h2>\n\n\n\n

    Pytanie o to, czy tester oprogramowania jest tak samo warto\u015bciowym cz\u0142onkiem jak inne osoby w zespole, jest tak naprawd\u0119 pytaniem o hierarchi\u0119, czyli o to, kto decyduje o organizacji pracy w zespole. Czy jest to Product Owner, czyli W\u0142a\u015bciciel Produktu? Ten przecie\u017c odpowiedzialny jest za produkt, kt\u00f3ry ma dostarczy\u0107 klientowi, nie za zesp\u00f3\u0142 \u2013 nie jest wi\u0119c jego mened\u017cerem i nie nadzoruje jego pracy. A mo\u017ce t\u0105 osob\u0105 jest Scrum Master? Przewodnik po Scrumie<\/em> podpowiada, \u017ce jest on \u201eservant-leaderem”, co oznacza, \u017ce skupia si\u0119 na identyfikowaniu potrzeb zespo\u0142u \u2013 nie zarz\u0105dza, lecz obserwuje i czuwa nad tym, aby zasady Scruma by\u0142y respektowane. Czy wi\u0119c o porz\u0105dku pracy decydowa\u0107 powinni zatem sami programi\u015bci? Wydaje si\u0119, \u017ce te\u017c nie do ko\u0144ca. A wi\u0119c kto? Tak naprawd\u0119 to ca\u0142y zesp\u00f3\u0142 deweloperski \u2013 wsp\u00f3lnie i dzi\u0119ki sta\u0142ej komunikacji \u2013 podejmuje decyzje i zarz\u0105dza swoim czasem pracy.<\/strong><\/p>\n\n\n\n

    Przeczytaj tak\u017ce:<\/strong> Samozarz\u0105dzanie to zarz\u0105dzanie przysz\u0142o\u015bci<\/a><\/p>\n\n\n\n

    Tester: model tradycyjny vs. Scrum<\/h2>\n\n\n\n

    Wa\u017cne jest, aby zrozumie\u0107 rol\u0119 testera w takim samozarz\u0105dzaj\u0105cym si\u0119 zespole. W modelu kaskadowym poza okre\u015blon\u0105 hierarchi\u0105 i podzia\u0142em r\u00f3l w zespole panuje konkretny porz\u0105dek pracy w procesie dostarczania produktu. W takim modelu projekt wchodzi w faz\u0119 test\u00f3w, w momencie kiedy deweloperzy ko\u0144cz\u0105 prace implementacyjne.<\/p>\n\n\n\n

    We frameworku Scrum tester oprogramowania nie czeka z testami do ko\u0144ca prac programistycznych, lecz wsp\u00f3\u0142pracuje z innymi cz\u0142onkami zespo\u0142u deweloperskiego w trakcie okre\u015blonych iteracji, czyli Sprint\u00f3w. Umo\u017cliwia to weryfikowanie pracy zespo\u0142u deweloperskiego na ka\u017cdym etapie powstawania produktu. Dodatkowo w Sprincie ograniczenie roli testera do przetestowania danej funkcjonalno\u015bci po jej wytworzeniu wi\u0105za\u0142oby si\u0119 z niewykorzystaniem ca\u0142ego jego potencja\u0142u i marnowaniem jego czasu mi\u0119dzy kolejnymi implementacjami.<\/p>\n\n\n\n

    Rola testera w Scrumie \u2013 mity<\/h2>\n\n\n\n

    Wok\u00f3\u0142 roli testera w zespole scrumowym naros\u0142o wiele mit\u00f3w. Do najbardziej rozpowszechnionych nale\u017cy ten, \u017ce rola testera jest niepotrzebna, poniewa\u017c ka\u017cdy cz\u0142onek zespo\u0142u deweloperskiego posiada ju\u017c wszystkie potrzebne kompetencje do stworzenia pe\u0142nowarto\u015bciowej funkcjonalno\u015bci. Takie przekonanie mo\u017ce wynika\u0107 z b\u0142\u0119dnej interpretacji definicji zawartej w Przewodniku po Scrumie<\/em>, kt\u00f3ry definiuje co prawda zesp\u00f3\u0142 deweloperski jako wielozadaniowy i posiadaj\u0105cy wszystkie kompetencje niezb\u0119dne do wytworzenia Przyrostu, nie okre\u015bla jednak kompetencji poszczeg\u00f3lnych cz\u0142onk\u00f3w zespo\u0142u. W Scrumie ka\u017cdy jest Deweloperem, czyli osob\u0105 wsp\u00f3\u0142tworz\u0105c\u0105 produkt. Tester oprogramowania powinien zatem bra\u0107 czynny udzia\u0142 w pracy zespo\u0142u podczas trwania Sprintu i anga\u017cowa\u0107 si\u0119 w trakcie spotka\u0144.<\/strong> Rol\u0105 testera w Scrumie jest wi\u0119c nie tylko testowanie, lecz tak\u017ce dbanie o utrzymanie jako\u015bci powstaj\u0105cego produktu i samego procesu jego powstawania \u2013 na przyk\u0142ad poprzez doskonalenie Backlogu produktu, o czym szerzej pisz\u0119 w dalszej cz\u0119\u015bci artyku\u0142u.<\/p>\n\n\n\n

    Kolejnym, moim zdaniem krzywdz\u0105cym, mitem jest to, \u017ce w procesach zwinnych, jak Scrum, nie ma miejsca na testy inne ni\u017c automatyczne. W Scrumie ka\u017cdy Sprint jest inny, niezb\u0119dna jest wi\u0119c elastyczno\u015b\u0107 w kontek\u015bcie planowania, wykonania i analizy test\u00f3w oraz ich wynik\u00f3w. Jest to praca, kt\u00f3r\u0105 tester musi wykona\u0107 samodzielnie i to on dobiera rodzaj test\u00f3w oraz ich szczeg\u00f3\u0142owo\u015b\u0107 na podstawie analizy ryzyka. W tych dzia\u0142aniach pomaga\u0107 powinni pozostali cz\u0142onkowie zespo\u0142u \u2013 tak aby wsp\u00f3lnie dostarczy\u0107 najlepszy mo\u017cliwy produkt w okre\u015blonym czasie.<\/p>\n\n\n\n

    Jak wi\u0119c tego dokona\u0107? Odpowiem wymijaj\u0105cym stwierdzeniem: to zale\u017cy. Niestety nie ma tu z\u0142otego \u015brodka. Pocz\u0105tkuj\u0105cym testerom polecam, by starali si\u0119 by\u0107 cz\u0142onkami zespo\u0142u nie tylko z nazwy. Uczestniczcie w ca\u0142ym procesie powstawania oprogramowania, a takie podej\u015bcie zaowocuje szybkim zdobywaniem wiedzy i do\u015bwiadczenia.<\/strong> Dzi\u0119ki temu \u0142atwiej b\u0119dzie wam planowa\u0107 i organizowa\u0107 prac\u0119 w ka\u017cdym kolejnym Sprincie, co z kolei prze\u0142o\u017cy si\u0119 na lepsz\u0105 i bardziej wydajn\u0105 prac\u0119 ca\u0142ego zespo\u0142u deweloperskiego.<\/p>\n\n\n\n

    Zadania testera w zespole scrumowym<\/h2>\n\n\n\n

    Doskonalenie Backlogu produktu<\/h3>\n\n\n\n

    Wiele os\u00f3b zastanawia si\u0119, w jaki spos\u00f3b tester anga\u017cuje si\u0119 w dzia\u0142ania zespo\u0142u. Przyjrzyjmy si\u0119 bli\u017cej mo\u017cliwym zadaniom testera w zespole deweloperskim, by lepiej zrozumie\u0107 jego rol\u0119 w Scrumie.<\/p>\n\n\n\n

    O Product Ownerze mo\u017cna powiedzie\u0107, \u017ce jest \u201ebohaterem ostatniej akcji”.<\/a> Tester oprogramowania z kolei wkracza do akcji ju\u017c na samym pocz\u0105tku, podczas doskonalenia Backlogu produktu. Dzi\u0119ki znajomo\u015bci ca\u0142ej aplikacji, rozumieniu roli u\u017cytkownika i warto\u015bci, jak\u0105 dana funkcja wnosi, tester ju\u017c na etapie sprawdzania wymaga\u0144 postawionych przez Product Ownera mo\u017ce zwr\u00f3ci\u0107 uwag\u0119 na jako\u015b\u0107, testowalno\u015b\u0107 oraz u\u017cyteczno\u015b\u0107 danej funkcjonalno\u015bci.<\/strong><\/p>\n\n\n\n

    Wiedza testera ju\u017c na pocz\u0105tkowym etapie pomo\u017ce unikn\u0105\u0107 zb\u0119dnej pracy, kt\u00f3rej rezultatem mog\u0142oby by\u0107 niedostarczenie oczekiwanej przez Product Ownera warto\u015bci. Efekt? Ca\u0142y zesp\u00f3\u0142 oszcz\u0119dza czas na wytwarzaniu funkcjonalno\u015bci, kt\u00f3ra np. powiela\u0142aby rozwi\u0105zania ju\u017c istniej\u0105ce, by\u0142aby niepraktyczna lub nieprzydatna w gotowym systemie. Zaoszcz\u0119dzony w ten spos\u00f3b czas mo\u017cna po\u015bwi\u0119ci\u0107 na dodawanie niezb\u0119dnych i poprawnie zaplanowanych element\u00f3w Backlogu. Pozwala to tak\u017ce oszcz\u0119dzi\u0107 czas poprawiania b\u0142\u0119dnie zaplanowanych rozwi\u0105za\u0144 dzi\u0119ki temu, \u017ce dostarczamy oczekiwane efekty i produkt wysokiej jako\u015bci.<\/p>\n\n\n\n

    Estymacja<\/h3>\n\n\n\n

    Czy estymacja jest zadaniem tylko dla programist\u00f3w? Wiele razy spotka\u0142em si\u0119 z tak\u0105 opini\u0105, pracuj\u0105c jako tester w zespo\u0142ach zwinnych. Z w\u0142asnego do\u015bwiadczenia mog\u0119 jednak powiedzie\u0107, \u017ce doskonalenie Backlogu produktu i eliminowanie zb\u0119dnej pracy ma kluczowy wp\u0142yw na estymacj\u0119 czasu trwania zada\u0144 przez zesp\u00f3\u0142 scrumowy.<\/p>\n\n\n\n

    Wiele zespo\u0142\u00f3w deweloperskich boryka si\u0119 z problemem braku czasu na testowanie po implementacji danego rozwi\u0105zania. Ale proces wytwarzania oprogramowania nie ko\u0144czy si\u0119 wraz z zako\u0144czeniem implementacji, zatem estymacja powinna uwzgl\u0119dnia\u0107 tak\u017ce czynno\u015bci nast\u0119puj\u0105ce po niej. Rol\u0105 testera w trakcie estymacji jest wi\u0119c odpowiednio wcze\u015bnie przewidzie\u0107 zadania zwi\u0105zane z testowaniem. Dzi\u0119ki prawid\u0142owej estymacji tester nie b\u0119dzie przeci\u0105\u017cony liczb\u0105 zada\u0144, a dodatkowo nigdy nie powinno doj\u015b\u0107 w Sprincie do sytuacji, kiedy brakuje czasu na testy.<\/strong><\/p>\n\n\n\n

    Pami\u0119tajmy, \u017ce w Scrumie ca\u0142y zesp\u00f3\u0142 odpowiada za ewentualne niepowodzenia, wi\u0119c wszyscy powinni pracowa\u0107 nad unikaniem wy\u017cej wymienionych sytuacji. Poprawne wykonanie estymacji pozwala lepiej ustali\u0107 wydajno\u015b\u0107 zespo\u0142u i deklarowanie realnych Przyrost\u00f3w.<\/p>\n\n\n\n

    Tworzenie Definition of Ready i Definition of Done<\/h3>\n\n\n\n

    Gotowo\u015b\u0107 produktu okre\u015blaj\u0105 dwa dokumenty, kt\u00f3re powinien sporz\u0105dzi\u0107 ka\u017cdy zesp\u00f3\u0142 scrumowy: Definition of Ready (DoR)<\/strong>, czyli kryterium gotowo\u015bci, i Definition of Done (DoD)<\/strong> \u2013 kryterium uko\u0144czenia.<\/p>\n\n\n\n

    DoR definiuje, kiedy dany element Backlogu mo\u017ce zosta\u0107 zawarty w Sprincie, a wi\u0119c jest przygotowany w spos\u00f3b umo\u017cliwiaj\u0105cy jego zrozumienie, zaimplementowanie oraz dostarczenie, a wiedza testera jest w tym zakresie wa\u017cna i potrzebna. Tester na tym etapie powinien dopilnowa\u0107 w szczeg\u00f3lno\u015bci tego, \u017ceby<\/strong> ka\u017cdy element Backlogu by\u0142 dla ca\u0142ego zespo\u0142u zrozumia\u0142y i testowalny.<\/strong> Jego wiedza i do\u015bwiadczenie pomagaj\u0105 p\u00f3\u017aniej dopilnowa\u0107, aby punkt ten by\u0142 spe\u0142niony dla ka\u017cdego elementu Backlogu podczas jego doskonalenia.<\/p>\n\n\n\n

    Definition of Done (DoD)<\/strong> definiuje z kolei uko\u0144czenie wytwarzania danego elementu i okre\u015bla, czy dana funkcjonalno\u015b\u0107 jest uko\u0144czona. W tym dokumencie nale\u017cy zadba\u0107 o to, aby pojawi\u0142 si\u0119 punkt m\u00f3wi\u0105cy o potwierdzaniu dzia\u0142ania ka\u017cdej funkcjonalno\u015bci testami.<\/strong> W mojej osobistej opinii nie powinien natomiast definiowa\u0107 ich rodzaju, gdy\u017c mog\u0142oby to doprowadzi\u0107 do sytuacji, kiedy pewne elementy Backlogu nie mog\u0142yby zosta\u0107 uko\u0144czone ze wzgl\u0119du na brak mo\u017cliwo\u015bci wykonania konkretnych rodzaj\u00f3w test\u00f3w. Wynika to z tego, i\u017c Definition of Done odnosi si\u0119 do ka\u017cdego wytworzonego elementu, a zastosowany rodzaj test\u00f3w i ich szczeg\u00f3\u0142owo\u015b\u0107 mog\u0105 si\u0119 r\u00f3\u017cni\u0107 w zale\u017cno\u015bci od wielu czynnik\u00f3w.<\/p>\n\n\n\n

    Podsumowanie<\/h2>\n\n\n\n

    Dzi\u0119ki zrozumieniu zasad funkcjonowania zespo\u0142\u00f3w scrumowych oraz tego, \u017ce na ka\u017cdym etapie, bez wzgl\u0119du na rol\u0119 w zespole, ich cz\u0142onkowie dzi\u0119ki swoim kompetencjom maj\u0105 realny wp\u0142yw na warto\u015b\u0107 i jako\u015b\u0107 produktu, zyskujemy nowe spojrzenie na rol\u0119 testera w procesie dostarczania produktu. W tek\u015bcie, kt\u00f3ry mam nadziej\u0119 b\u0119dzie pierwszym z wielu o roli testera w Scrumie, pr\u00f3bowa\u0142em przedstawi\u0107, jak istotny jest jego wk\u0142ad na ka\u017cdym etapie \u2013 nie tylko w trakcie test\u00f3w po implementacji. Patrz\u0105c na zadania testera z szerszej perspektywy, dostrzegamy, \u017ce jego rol\u0105 jest nie tylko znajdywanie b\u0142\u0119d\u00f3w w funkcjonalno\u015bciach, lecz tak\u017ce przyczynianie si\u0119 do w\u0142a\u015bciwego zaplanowania dzia\u0142a\u0144 ca\u0142ego zespo\u0142u, tak by wsp\u00f3lnie dostarczy\u0107 najwy\u017csz\u0105 mo\u017cliw\u0105 jako\u015b\u0107. Mam nadziej\u0119, \u017ce m\u00f3j artyku\u0142 pomo\u017ce wielu pocz\u0105tkuj\u0105cym testerom poszukuj\u0105cym odpowiedzi na pytanie: \u201eW jak wielu miejscach mog\u0119 poprawi\u0107 nie tylko swoj\u0105 prac\u0119, lecz tak\u017ce dzia\u0142anie ca\u0142ego zespo\u0142u deweloperskiego?”.<\/p>\n","protected":false},"excerpt":{"rendered":"

    Samoorganizacja i brak hierarchii znanej nam z innych modeli zarz\u0105dzania \u2013 oto, co proponuje Scrum jako framework. Zamiast tradycyjnego modelu szef \u2013 podw\u0142adni mamy zesp\u00f3\u0142 deweloperski, w kt\u00f3rym ka\u017cdy jest osob\u0105 przyczyniaj\u0105c\u0105 si\u0119 do sukcesu projektu, Deweloperem. Wiele os\u00f3b, s\u0142ysz\u0105c o rolach w Scrumie, zadaje sobie pytania: jaka jest w takim razie rola testera? Czy jest on pe\u0142noprawnym cz\u0142onkiem zespo\u0142u deweloperskiego?<\/p>\n","protected":false},"author":70,"featured_media":30494,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"iawp_total_views":53,"footnotes":""},"categories":[1,583],"tags":[562],"offering":[522],"class_list":["post-30493","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-artykuly","category-zarzadzanie-projektami","tag-qa","offering-tech-blog"],"acf":[],"_links":{"self":[{"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/posts\/30493","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/users\/70"}],"replies":[{"embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/comments?post=30493"}],"version-history":[{"count":2,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/posts\/30493\/revisions"}],"predecessor-version":[{"id":33076,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/posts\/30493\/revisions\/33076"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/media\/30494"}],"wp:attachment":[{"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/media?parent=30493"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/categories?post=30493"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/tags?post=30493"},{"taxonomy":"offering","embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/offering?post=30493"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}