{"id":31337,"date":"2021-06-10T14:36:56","date_gmt":"2021-06-10T12:36:56","guid":{"rendered":"https:\/\/nearshore-it.eu\/artykuly\/po-co-tyle-testow-czyli-rzecz-o-testowaniu-oprogramowania\/"},"modified":"2024-11-07T13:18:12","modified_gmt":"2024-11-07T12:18:12","slug":"po-co-tyle-testow-czyli-rzecz-o-testowaniu-oprogramowania","status":"publish","type":"post","link":"https:\/\/nearshore-it.eu\/pl\/artykuly\/po-co-tyle-testow-czyli-rzecz-o-testowaniu-oprogramowania\/","title":{"rendered":"Po co tyle test\u00f3w? Czyli rzecz o testowaniu oprogramowania"},"content":{"rendered":"\n
\n

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

    \n
  1. 1. Czym jest testowanie oprogramowania<\/a><\/li>\n
  2. 2. Testy \u2013 licz\u0105 si\u0119 liczby?<\/a><\/li>\n
  3. 3. Po co nam automatyzacja test\u00f3w?<\/a><\/li>\n
  4. 4. Utrzymanie test\u00f3w<\/a><\/li>\n
  5. 5. Wina tester\u00f3w i narz\u0119dzi?<\/a><\/li>\n
  6. 6. Testy fa\u0142szywie pozytywne<\/a><\/li>\n
  7. 7. Testy oprogramowania \u2013 ilo\u015b\u0107 czy jako\u015b\u0107?<\/a><\/li>\n
  8. 8. Za du\u017co test\u00f3w \u2013 mo\u017cliwe rozwi\u0105zania<\/a><\/li>\n
  9. 9. Zarz\u0105dzanie ryzykiem<\/a><\/li>\n
  10. 10. Podsumowanie<\/a><\/li>\n <\/ol>\n<\/div>\n\n\n

    Czym jest testowanie oprogramowania<\/h2>\n\n\n\n

    Musz\u0119 przyzna\u0107, \u017ce na pocz\u0105tku, szukaj\u0105c tytu\u0142u dla artyku\u0142u, do g\u0142owy przychodzi\u0142y mi ma\u0142o cenzuralne zwroty. G\u0142\u00f3wnie dlatego, \u017ce temat ograniczenia ilo\u015bci test\u00f3w wywo\u0142uje wiele negatywnych emocji. Po analizie r\u00f3\u017cnych komentarzy na bran\u017cowych stronach dochodz\u0119 do wniosku, \u017ce dzieje si\u0119 tak z wielu powod\u00f3w. Zaczn\u0119 od tego, czym jest testowanie oprogramowania, w tym celu odwo\u0142ajmy si\u0119 do definicji ISTQB:<\/p>\n\n\n\n

    \u201eProces sk\u0142adaj\u0105cy si\u0119 ze wszystkich czynno\u015bci cyklu \u017cycia, zar\u00f3wno statycznych, jak i dynamicznych, skoncentrowany na planowaniu, przygotowaniu i ewaluacji oprogramowania oraz powi\u0105zanych produkt\u00f3w w celu okre\u015blenia, czy spe\u0142niaj\u0105 one wyspecyfikowane wymagania, na wykazaniu, \u017ce s\u0105 one dopasowane do swoich cel\u00f3w oraz na wykrywaniu usterek.”<\/strong><\/p>\n\n\n\n

    Proces ten sam w sobie wskazuje, \u017ce naturaln\u0105 form\u0105 rozwoju test\u00f3w w danym projekcie jest zwi\u0119kszanie liczby przypadk\u00f3w testowych, a tak\u017ce innych aktywno\u015bci, kt\u00f3re s\u0105 wykonywane wok\u00f3\u0142 test\u00f3w.<\/p>\n\n\n\n

    Testy \u2013 licz\u0105 si\u0119 liczby?<\/h2>\n\n\n\n

    Zaczn\u0119 od liczb. Pracuj\u0105c ju\u017c \u0142adnych kilka lat w projektach zagranicznych, gdzie samych programist\u00f3w test\u00f3w jest 15 (nie m\u00f3wi\u0105c o ca\u0142ej armii tester\u00f3w manualnych, programist\u00f3w itd.), zauwa\u017cy\u0142em jedn\u0105 tendencj\u0119: licz\u0105 si\u0119 liczby.<\/strong><\/p>\n\n\n\n

    Nie jako\u015b\u0107 wykonywanych test\u00f3w, ale liczby. Test manager staje si\u0119 kim\u015b, kto \u201ebroni\u201d test\u00f3w przed osobami zarz\u0105dzaj\u0105cymi. Management najcz\u0119\u015bciej zwraca uwag\u0119 g\u0142\u00f3wnie na koszty, prezentuj\u0105c podej\u015bcie znane jako: \u201eA po co nam testy, przecie\u017c programi\u015bci powinni pisa\u0107 kod bez b\u0142\u0119d\u00f3w\u201d.<\/p>\n\n\n\n

    Takie sytuacje wci\u0105\u017c si\u0119 zdarzaj\u0105 i nie jest to tylko opowie\u015b\u0107 pochodz\u0105ca z odm\u0119t\u00f3w Internetu. To podej\u015bcie, z kt\u00f3rym spotyka\u0142em si\u0119 wielokrotnie przez 10 lat wykonywania test\u00f3w. Podej\u015bcie, kt\u00f3re\u2026 w og\u00f3le mnie nie dziwi \u2013 i m\u00f3wi\u0119 to bez sarkazmu. Kim jest dzi\u015b test manager? To osoba, kt\u00f3ra ma jak\u0105\u015b wiedz\u0119 techniczn\u0105, jednak wi\u0119kszo\u015b\u0107 swoich umiej\u0119tno\u015bci skupia zupe\u0142nie gdzie indziej. Podam przyk\u0142ad, kt\u00f3rego do\u015bwiadczy\u0142 pewnie niejeden z nas. Klasyczny konflikt interes\u00f3w studenta i wyk\u0142adowcy. Student rozk\u0142ada swoje si\u0142y i czas pomi\u0119dzy r\u00f3\u017cne przedmioty, tak by skutecznie osi\u0105gn\u0105\u0107 sw\u00f3j cel (dostanie si\u0119 na kolejny rok). Dla wyk\u0142adowcy z kolei to jego przedmiot jest najwa\u017cniejszy (wiem, co m\u00f3wi\u0119 \u2013 by\u0142em po obu stronach).<\/p>\n\n\n\n

    Manager zarz\u0105dza projektami tak, jak student zarz\u0105dza sesj\u0105, wi\u0119c testy s\u0105 tylko jednym z wielu element\u00f3w, i to nisko w hierarchii, bo najwa\u017cniejsze jest dostarczenie produktu. Aby udowodni\u0107 sens wynajmowania okre\u015blonej liczby tester\u00f3w, test manager musi pokaza\u0107 project managerowi dane: ilo\u015b\u0107 przypadk\u00f3w testowych, ilo\u015b\u0107 pokrycia przez automatyzacje, a tak\u017ce ilo\u015b\u0107 znajdowanych b\u0142\u0119d\u00f3w, czas zaoszcz\u0119dzony poprzez automatyzacj\u0119, ryzyka, potencjalne koszty b\u0142\u0119d\u00f3w itp.<\/p>\n\n\n\n

    Po co nam automatyzacja test\u00f3w?<\/h2>\n\n\n\n

    Dzi\u015b automatyzacja test\u00f3w<\/a> stanowi wa\u017cne uzupe\u0142nienie test\u00f3w manualnych. Testy automatyczne pozwalaj\u0105 zast\u0105pi\u0107 du\u017c\u0105 ilo\u015b\u0107 test\u00f3w manualnych i odci\u0105\u017cy\u0107 tester\u00f3w oprogramowania oraz zaoszcz\u0119dzi\u0107 czas. W przypadku test\u00f3w automatycznych z perspektywy test managera cz\u0119sto najwa\u017cniejsze jest, ile pokrywaj\u0105 test\u00f3w manualnych, a szczeg\u00f3lnie \u2013 ile godzin pracy tester\u00f3w manualnych zast\u0119puj\u0105 testy automatyczne.<\/strong> Wszystko wydaje si\u0119 w porz\u0105dku. Ilo\u015b\u0107 przypadk\u00f3w testowych ro\u015bnie, automatyzacja si\u0119 rozrasta. Przypadki testowe to jakie\u015b 4-5 tys., a automatyzacja pokrywa 1600. Kolejne osoby do\u0142\u0105czaj\u0105 do projektu. Statystyki si\u0119 zgadzaj\u0105, management jest wniebowzi\u0119ty. <\/p>\n\n\n\n

    Utrzymanie test\u00f3w<\/h2>\n\n\n\n

    I w tym momencie pojawia si\u0119 nowy problem \u2013 utrzymanie rosn\u0105cej liczby test\u00f3w. Presja czasu i narastaj\u0105ce skomplikowanie projektu powoduj\u0105, \u017ce z dnia na dzie\u0144 wszyscy maj\u0105 coraz wi\u0119cej zaj\u0119\u0107. Release z jednodniowych zamieniaj\u0105 si\u0119 w tygodniowe testy i pojawia si\u0119 konieczno\u015b\u0107 sprawdzania, czemu testy automatyczne nie dzia\u0142aj\u0105. Przy poprawianiu ich okazuje si\u0119, \u017ce s\u0105 nieaktualne, a manualny przypadek testowy nieaktualny od 3 miesi\u0119cy. Test przechodzi\u0142, a nagle pada. Nikt nie wie, jak dana funkcja powinna dzia\u0142a\u0107, bo zada\u0144 w Jirze s\u0105 tysi\u0105ce, a samo szukanie odpowiedzi trwa 2 dni. Oczywi\u015bcie mo\u017cna by si\u0119 zg\u0142osi\u0107 do osoby posiadaj\u0105cej wiedz\u0119, ale jej ju\u017c dawno nie ma w organizacji (w projektach IT rotacja pracownik\u00f3w to chleb powszedni).<\/p>\n\n\n\n

    Wina tester\u00f3w i narz\u0119dzi?<\/h2>\n\n\n\n

    W takiej sytuacji mo\u017cna pomy\u015ble\u0107, \u017ce to wina nieodpowiednich narz\u0119dzi, tester\u00f3w, kt\u00f3rzy \u017ale wykonuj\u0105 swoj\u0105 prac\u0119, a tak\u017ce test manager\u00f3w. W jakim\u015b stopniu na pewno, jednak przede wszystkim to kwestia skali. <\/strong><\/p>\n\n\n\n

    S\u0105 dwie rzeczy, kt\u00f3re nie maj\u0105 ogranicze\u0144 ze wzgl\u0119du na zasoby. Zak\u0142adanie wiecznego wzrostu gospodarki, jak i przyrostu liczby test\u00f3w. Zar\u00f3wno managerowie, test managerowie, jak i sami testerzy czy testerzy automatyzuj\u0105cy maj\u0105 ambicj\u0119 wykonywania jak najwi\u0119kszej liczby test\u00f3w, co jest ca\u0142kowicie naturalne. Niestety, ogranicza ich rzeczywisto\u015b\u0107. W pewnym momencie wykonywania test\u00f3w liczba istniej\u0105cych ju\u017c przypadk\u00f3w testowych powoduje do\u015b\u0107 znacz\u0105ce problemy.<\/p>\n\n\n\n

    Testy po prostu trzeba utrzymywa\u0107. Pokrycie przez testy automatyczne manualnych przypadk\u00f3w testowych w teorii ma zdejmowa\u0107 z bark\u00f3w tester\u00f3w manualnych konieczno\u015b\u0107 opieki nad dan\u0105 cz\u0119\u015bci\u0105. Jednak ten cel nie zostaje osi\u0105gni\u0119ty, je\u017celi przypadki manualne nie s\u0105 stale aktualizowane wzgl\u0119dem nowych funkcjonalno\u015bci, a wraz z nimi testy automatyczne.<\/p>\n\n\n\n

    Testy fa\u0142szywie pozytywne<\/h2>\n\n\n\n

    Jaka mo\u017ce by\u0107 skala problemu?<\/strong> To jest bardzo niebezpieczne pytanie. \u0141atwo wykaza\u0107 przypadki testowe, kt\u00f3re przestaj\u0105 dzia\u0142a\u0107. Takie testy po prostu \u201epadaj\u0105\u201d, a weryfikuje si\u0119 je, przechodz\u0105c manualnie, wi\u0119c podczas ich wykonywania mo\u017cna je poprawi\u0107. W wypadku test\u00f3w automatycznych r\u00f3wnie\u017c pokazuj\u0105 negatywny wynik, wi\u0119c te\u017c pojawia si\u0119 podobna \u015bcie\u017cka, cho\u0107 troch\u0119 d\u0142u\u017csza. Niestety, widzia\u0142em bardzo du\u017co projekt\u00f3w, kt\u00f3re na tym poprzestawa\u0142y. Jest jednak du\u017co bardziej szkodliwe zjawisko. A co, je\u017celi test przechodzi i jest nieaktualny? Liczba test\u00f3w fa\u0142szywie pozytywnych w projekcie nastawionym na ilo\u015b\u0107 test\u00f3w, a nie na ich jako\u015b\u0107, jest czym\u015b, czym zwyczajnie nie spos\u00f3b zarz\u0105dzi\u0107.<\/p>\n\n\n\n

    Testy oprogramowania \u2013 ilo\u015b\u0107 czy jako\u015b\u0107?<\/h2>\n\n\n\n

    Kolejn\u0105 konsekwencj\u0105 jest spadaj\u0105ca jako\u015b\u0107 test\u00f3w, zar\u00f3wno kodu, jak i samych przypadk\u00f3w testowych. Wida\u0107 to bardzo dobrze na przestrzeni czasu, w jakim dane przypadki s\u0105 pisane. Pierwsze przypadki testowe s\u0105 szczeg\u00f3\u0142owe, zawieraj\u0105 wszystko, co potrzeba. Kolejne s\u0105 ju\u017c tylko zgrubnymi opisami tworzonymi na szybko, a ich aktualizacja to problem. W kodzie pojawia si\u0119 coraz wi\u0119kszy ba\u0142agan, a code review test\u00f3w zamienia si\u0119 w pobie\u017cne spojrzenie na kod. Testerzy nie maj\u0105 czasu i wszystko zamienia si\u0119 w r\u00f3wni\u0119 pochy\u0142\u0105, gdy\u017c im wi\u0119cej test\u00f3w, tym wi\u0119cej problem\u00f3w, a management oczekuje sta\u0142ego przyrostu przypadk\u00f3w testowych.<\/p>\n\n\n\n

    Oczywi\u015bcie wszyscy s\u0105 tego \u015bwiadomi i pr\u00f3buje si\u0119 rozwi\u0105zywa\u0107 ten problem na wiele sposob\u00f3w. Czy ka\u017cdy jest jednak skuteczny?<\/p>\n\n\n\n

    Za du\u017co test\u00f3w \u2013 mo\u017cliwe rozwi\u0105zania<\/h2>\n\n\n\n

    B\u0142\u0119dna ucieczka w BDD<\/h3>\n\n\n\n

    Aby rozwi\u0105za\u0107 problem, wykorzystuje si\u0119 czasem Behaviour-Driven Development.<\/strong> O ile wydaje si\u0119 to jednym z ciekawszych kierunk\u00f3w, w wielu projektach przynosi skutek wr\u0119cz odwrotny. BDD m\u00f3wi\u0119 \u201etak\u201d, je\u015bli wdra\u017ca si\u0119 to rozwi\u0105zanie dla wszystkich. \u201eNie\u201d \u2013 je\u017celi tylko dla tester\u00f3w automatyzuj\u0105cych. W wielu projektach widzia\u0142em podej\u015bcie polegaj\u0105ce na tym, \u017ce testerzy manualni pisz\u0105 scenariusze metod\u0105 klasyczn\u0105, a automatyzuj\u0105cy w BDD. Strata czasu na kolejn\u0105 warstw\u0119 abstrakcji jest kropl\u0105 przelewaj\u0105c\u0105 czar\u0119 goryczy. W BDD cz\u0119sto test managerowie upatruj\u0105 innego ratunku. Ot\u00f3\u017c zdaje si\u0119, \u017ce je\u017celi zautomatyzowali\u015bmy du\u017c\u0105 cz\u0119\u015b\u0107 kodu i mamy grup\u0119 step\u00f3w, kt\u00f3re ju\u017c dzia\u0142aj\u0105, to mo\u017ce automatyzowa\u0107 ka\u017cdy, natomiast tak naprawd\u0119 stepy staj\u0105 si\u0119 nowym pseudoj\u0119zykiem, kt\u00f3ry staje si\u0119 niepotrzebny, je\u015bli mamy dobrze napisany kod.<\/p>\n\n\n\n

    Przeczytaj tak\u017ce:<\/strong> Organizacja data driven \u2013 strategia dla firm przysz\u0142o\u015bci<\/a><\/p>\n\n\n\n

    Aby rozwi\u0105za\u0107 problem skali, przyjmuje si\u0119 do pracy kolejnych tester\u00f3w<\/strong> \u2013 cz\u0119sto o bardzo ma\u0142ej wiedzy i do\u015bwiadczeniu, gdy\u017c kryterium jest cena. Managerowie \u0142udz\u0105 si\u0119, \u017ce dzi\u0119ki wykorzystaniu BDD mo\u017cna rozwija\u0107 automaty tylko poprzez ponowne u\u017cywanie gotowych krok\u00f3w napisanych w j\u0119zyku naturalnym. Cz\u0119sto w kopiowaniu kodu osoby takie mog\u0105 sobie bardzo dobrze poradzi\u0107, jednak nie ka\u017cdy ma talent i predyspozycje do nauki automatyzacji w ten spos\u00f3b. Wed\u0142ug mnie jest to b\u0142\u0119dne za\u0142o\u017cenie. Stwierdzam wr\u0119cz, \u017ce je\u017celi tester, patrz\u0105c na nazw\u0119 test\u00f3w i wykorzystywane metody napisane w Selenium, nie potrafi zrozumie\u0107, co robi dany test, to nie ma on szans na rozw\u00f3j. Takie rozwi\u0105zanie powoduje, \u017ce do projektu do\u0142\u0105cza osoba, kt\u00f3r\u0105 trzeba si\u0119 opiekowa\u0107, sp\u0119dza\u0107 z ni\u0105 czas \u2013 a warunki projektu nie stwarzaj\u0105 jej mo\u017cliwo\u015bci rozwoju.<\/p>\n\n\n\n

    Mo\u017cna do projektu do\u0142\u0105czy\u0107 do\u015bwiadczonych tester\u00f3w,<\/strong> kt\u00f3rzy maj\u0105 usprawni\u0107 kod automatyzacji lub wesprze\u0107 zesp\u00f3\u0142 w testach manualnych. Jest to rozwi\u0105zanie istotne, ale nadal nie rozwi\u0105zuje problemu ci\u0105g\u0142ego przyrostu test\u00f3w, kt\u00f3re te\u017c b\u0119dzie trzeba usprawnia\u0107.<\/p>\n\n\n\n

    Odpowiedzialno\u015b\u0107 za testy<\/h3>\n\n\n\n

    Rozwi\u0105zanie, kt\u00f3remu jestem przychylny, a kt\u00f3re coraz rzadziej mo\u017cna zaobserwowa\u0107, to zwi\u0119kszenie udzia\u0142u cz\u0119\u015bci \u201etest managerskiej\u201d.<\/strong> Osoba, kt\u00f3rej rola do\u015b\u0107 cz\u0119sto ogranicza si\u0119 do obrony test\u00f3w przed managementem i walki o kolejne zasoby, musi wr\u00f3ci\u0107 do korzeni. Niestety, takie elementy jak tworzenie strategii test\u00f3w, planowanie i koordynacja test\u00f3w oraz raportowanie ich wynik\u00f3w staj\u0105 si\u0119 reliktem. Nie chodzi o to, \u017ceby w projekcie by\u0142 to jeden jedyny cz\u0142owiek, kt\u00f3ry my\u015bli o wszystkim. Odpowiedzialnym test managerem powinien by\u0107 ka\u017cdy zwi\u0105zany z testami. Aby jednak takie podej\u015bcie mia\u0142o szanse powodzenia, trzeba przyj\u0105\u0107 pocz\u0105tkowe za\u0142o\u017cenie: \u201eNie, nie chodzi o ilo\u015b\u0107 test\u00f3w, ale o ich jako\u015b\u0107 i odpowiednie zarz\u0105dzanie\u201d.<\/strong><\/p>\n\n\n\n

    Dla wielu os\u00f3b ograniczanie test\u00f3w b\u0119dzie herezj\u0105, bo wydaje si\u0119, \u017ce ca\u0142y \u015bwiat m\u00f3wi: \u201eWi\u0119cej test\u00f3w!\u201d. Jednak nie, nie o to chodzi. Chodzi raczej o to, aby lepiej planowa\u0107 wykonywane prace, a tak\u017ce, aby tester oprogramowania bra\u0142 odpowiedzialno\u015b\u0107 za plan test\u00f3w.<\/strong> Ja jako osoba testuj\u0105ca dany obszar wiem, kt\u00f3re testy s\u0105 istotne i co przyniesie warto\u015b\u0107 klientowi. Bior\u0119 odpowiedzialno\u015b\u0107 za to, jakie wykonuj\u0119 przypadki testowe, jak r\u00f3wnie\u017c za to, co automatyzuj\u0119. Pewne obszary test\u00f3w na danym etapie projektu mog\u0105 by\u0107 nieistotne. Sensowne wydaje si\u0119 w\u0142o\u017cenie wysi\u0142ku nie tylko w wykonywanie test\u00f3w, ale przeanalizowanie zasadno\u015bci.<\/p>\n\n\n\n

    Przyk\u0142adowo, automatyzowanie ka\u017cdej \u015bcie\u017cki w wielu wypadkach nie ma sensu.<\/strong> Wiele \u015bcie\u017cek pokrywa podobne obszary, nie ma potrzeby wykonywa\u0107 odr\u0119bnych przypadk\u00f3w. Wr\u00f3\u0107my do podstaw metod i technik test\u00f3w, kt\u00f3re najcz\u0119\u015bciej tak naprawd\u0119 nie odpowiadaj\u0105 nam na pytanie \u201eJak najlepiej przetestowa\u0107\u201d, ale \u201eJak wykona\u0107 testy skutecznie, najmniejszym nak\u0142adem pracy, przyjmuj\u0105c ryzyko wynikaj\u0105ce z tej metody\u201d. Nie wymagajmy jednak od test managera, by powiedzia\u0142 nam, co mamy zrobi\u0107. To testerzy powinni dostarcza\u0107 informacj\u0119 test managerowi, ile i jakie testy w danym czasie wykonuj\u0105 w tym okre\u015blonym releasie. Test manager nie pracuje z dan\u0105 funkcjonalno\u015bci\u0105 i nie ma tej wiedzy.<\/p>\n\n\n\n

    Bardzo przydatna mo\u017ce si\u0119 okaza\u0107 analiza wp\u0142ywu \u2013 obszary, kt\u00f3re s\u0105 ju\u017c bardzo dobrze przetestowane, a tak\u017ce stabilne, cz\u0119sto nie potrzebuj\u0105 ponownych test\u00f3w. Okre\u015bli\u0107 mo\u017cna to na podstawie analizy wp\u0142ywu. Jako testerzy musicie wykonywa\u0107 j\u0105 przy ka\u017cdym nowym Sprincie. Taka analiza powinna odpowiada\u0107 na pytania:<\/p>\n\n\n\n