W ostatnich latach obserwuj\u0119 niepokoj\u0105cy trend w polskich firmach IT: automatyzacja test\u00f3w sta\u0142a si\u0119 celem samym w sobie, a nie \u015brodkiem do osi\u0105gni\u0119cia lepszej jako\u015bci oprogramowania. Zespo\u0142y developerskie chwal\u0105 si\u0119 wska\u017anikami pokrycia testami, podczas gdy w tle ro\u015bnie d\u0142ug techniczny, a produkty maj\u0105 coraz wi\u0119cej ukrytych b\u0142\u0119d\u00f3w.<\/p>\n
Pracuj\u0105c z kilkoma \u015brednimi firmami technologicznymi w ostatnim kwartale, zauwa\u017cy\u0142em powtarzaj\u0105cy si\u0119 schemat: 85% pokrycia testami automatycznymi, ale jednocze\u015bnie 40% wzrost zg\u0142osze\u0144 od klient\u00f3w dotycz\u0105cych b\u0142\u0119d\u00f3w w produkcji. Paradoks? To nie przypadek, a konsekwencja trzech fundamentalnych b\u0142\u0119d\u00f3w w podej\u015bciu do automatyzacji.<\/p>\n
Najcz\u0119stszy b\u0142\u0105d, kt\u00f3ry obserwuj\u0119: zespo\u0142y automatyzuj\u0105 testy bez zrozumienia, co naprawd\u0119 ma znaczenie dla u\u017cytkownika ko\u0144cowego. Przyk\u0142ad z ostatniego projektu e-commerce: zesp\u00f3\u0142 mia\u0142 1200 test\u00f3w automatycznych dla koszyka zakupowego, ale wszystkie sprawdza\u0142y tylko techniczne aspekty API. \u017baden test nie weryfikowa\u0142, czy u\u017cytkownik mo\u017ce faktycznie przej\u015b\u0107 przez ca\u0142y proces zakupowy w realistycznych warunkach.<\/p>\n
Klient zg\u0142osi\u0142 problem: na urz\u0105dzeniach mobilnych z wolniejszym internetem proces p\u0142atno\u015bci zawiesza\u0142 si\u0119 po 30 sekundach. Testy automatyczne tego nie wykry\u0142y, bo wszystkie dzia\u0142a\u0142y w idealnych warunkach laboratoryjnych. Zesp\u00f3\u0142 sp\u0119dzi\u0142 3 miesi\u0105ce na pisaniu test\u00f3w, kt\u00f3re nie testowa\u0142y tego, co naprawd\u0119 wa\u017cne.<\/p>\n
Dlaczego to si\u0119 dzieje?<\/strong> Deweloperzy cz\u0119sto automatyzuj\u0105 to, co \u0142atwe do zautomatyzowania, a nie to, co krytyczne dla biznesu. W efekcie mamy pi\u0119kne raporty z zielonymi znacznikami, kt\u00f3re nie maj\u0105 prze\u0142o\u017cenia na rzeczywiste do\u015bwiadczenie u\u017cytkownika.<\/p>\n Drugi problem, kt\u00f3ry niszczy produktywno\u015b\u0107: testy automatyczne staj\u0105 si\u0119 tak skomplikowane, \u017ce ich utrzymanie zajmuje wi\u0119cej czasu ni\u017c rozw\u00f3j nowych funkcji. Widzia\u0142em projekt, gdzie zesp\u00f3\u0142 5 developer\u00f3w sp\u0119dza\u0142 60% czasu na naprawianiu padaj\u0105cych test\u00f3w, a tylko 40% na faktycznym kodowaniu.<\/p>\n Przyk\u0142ad z platformy SaaS dla ma\u0142ych firm: testy end-to-end by\u0142y tak kruche, \u017ce ka\u017cda zmiana w UI powodowa\u0142a lawin\u0119 b\u0142\u0119d\u00f3w. Zamiast skupi\u0107 si\u0119 na dodawaniu warto\u015bciowych funkcji, zesp\u00f3\u0142 ca\u0142y czas gasi\u0142 po\u017cary w testach. W ci\u0105gu 6 miesi\u0119cy koszt utrzymania test\u00f3w przekroczy\u0142 koszt ich pierwotnego stworzenia.<\/p>\n Kluczowa obserwacja:<\/strong> Automatyzacja ma sens tylko wtedy, gdy koszt jej utrzymania jest ni\u017cszy ni\u017c koszt r\u0119cznego testowania. W wielu projektach ten pr\u00f3g zosta\u0142 dawno przekroczony, ale nikt nie ma odwagi przyzna\u0107, \u017ce cesarz jest nagi.<\/p>\n Trzecia pu\u0142apka, najniebezpieczniejsza dla jako\u015bci: ca\u0142kowite porzucenie test\u00f3w manualnych na rzecz automatyzacji. Testy automatyczne sprawdzaj\u0105 tylko to, co zosta\u0142o zaprogramowane. Nie wykryj\u0105 nieoczekiwanych zachowa\u0144, problem\u00f3w z u\u017cyteczno\u015bci\u0105 ani b\u0142\u0119d\u00f3w wynikaj\u0105cych z kombinacji czynnik\u00f3w.<\/p>\n Case study z aplikacji webowej dla sektora finansowego: zesp\u00f3\u0142 by\u0142 dumny z 95% pokrycia testami automatycznymi. Problem odkry\u0142 dopiero tester manualny podczas eksploracji: przy okre\u015blonej sekwencji dzia\u0142a\u0144 (dodanie produktu \u2192 zmiana waluty \u2192 zastosowanie kuponu rabatowego) system oblicza\u0142 b\u0142\u0119dn\u0105 kwot\u0119 ko\u0144cow\u0105. \u017baden test automatyczny tego nie przewidywa\u0142, bo scenariusz by\u0142 zbyt specyficzny.<\/p>\n Wniosek praktyczny:<\/strong> Najlepsze zespo\u0142y, z kt\u00f3rymi pracuj\u0119, stosuj\u0105 zasad\u0119 70\/30: 70% test\u00f3w automatycznych dla regresji i 30% czasu na testy eksploracyjne. To w\u0142a\u015bnie te 30% znajduje najwi\u0119cej krytycznych b\u0142\u0119d\u00f3w.<\/p>\n Zacznij od ryzyka biznesowego<\/strong> Mierz warto\u015b\u0107, nie ilo\u015b\u0107<\/strong> Inwestuj w testy, kt\u00f3re si\u0119 zwracaj\u0105<\/strong> Nie rezygnuj z my\u015blenia ludzkiego<\/strong> W JurskiTech.pl pomagamy firmom budowa\u0107 sensowne strategie testowania, kt\u00f3re faktycznie poprawiaj\u0105 jako\u015b\u0107 produkt\u00f3w. Ostatnio pracowali\u015bmy z platform\u0105 e-commerce, kt\u00f3ra mia\u0142a problem podobny do opisywanych: pi\u0119kne raporty z test\u00f3w, ale ci\u0105g\u0142e awarie w sezonie sprzeda\u017cowym.<\/p>\n Zamiast dodawa\u0107 kolejne testy automatyczne, przeprowadzili\u015bmy audyt i okaza\u0142o si\u0119, \u017ce:<\/p>\n Po przebudowie strategii testowej:<\/p>\n Automatyzacja test\u00f3w to pot\u0119\u017cne narz\u0119dzie, ale jak ka\u017cde narz\u0119dzie \u2013 mo\u017ce zaszkodzi\u0107, je\u015bli u\u017cywa si\u0119 go bezmy\u015blnie. Pami\u0119taj: chodzi o to, \u017ceby produkty dzia\u0142a\u0142y lepiej, a nie o to, \u017ceby mie\u0107 wi\u0119cej zielonych znacznik\u00f3w w raporcie.<\/p>\n Najlepsze zespo\u0142y developerskie traktuj\u0105 automatyzacj\u0119 jak dobregos szefa kuchni traktuje swoje no\u017ce: wybiera odpowiednie narz\u0119dzie do zadania, dba o jego ostro\u015b\u0107, ale wie, \u017ce to jego umiej\u0119tno\u015bci i do\u015bwiadczenie tworz\u0105 prawdziw\u0105 warto\u015b\u0107.<\/p>\n","protected":false},"excerpt":{"rendered":" Jak nadmierna automatyzacja test\u00f3w niszczy jako\u015b\u0107 kodu: 3 pu\u0142apki W ostatnich latach obserwuj\u0119 niepokoj\u0105cy trend w polskich firmach IT: automatyzacja test\u00f3w sta\u0142a si\u0119 celem samym w sobie, a nie \u015brodkiem do osi\u0105gni\u0119cia lepszej jako\u015bci oprogramowania. Zespo\u0142y developerskie chwal\u0105 si\u0119 wska\u017anikami pokrycia testami, podczas gdy w tle ro\u015bnie d\u0142ug techniczny, a produkty maj\u0105 coraz wi\u0119cej ukrytych<\/p>\n","protected":false},"author":2,"featured_media":507,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[166,21,113,253,19],"class_list":["post-508","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-warto-wiedziec","tag-automatyzacja-testow","tag-devops","tag-jakosc-kodu","tag-praktyki-it","tag-web-development"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/508","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/comments?post=508"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/508\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media\/507"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=508"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=508"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=508"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}2. Konserwacja test\u00f3w poch\u0142ania wi\u0119cej czasu ni\u017c rozw\u00f3j produktu<\/h2>\n
3. Brak test\u00f3w eksploracyjnych = \u015blepa automatyzacja<\/h2>\n
Jak budowa\u0107 sensown\u0105 strategi\u0119 testowania?<\/h2>\n
\n
\nPrzed napisaniem pierwszego testu automatycznego zadaj pytanie: \u201eCo si\u0119 stanie, je\u015bli ta funkcja zawiedzie?\u201d Automatyzuj najpierw obszary o najwy\u017cszym ryzyku dla biznesu, a nie te naj\u0142atwiejsze technicznie.<\/p>\n<\/li>\n
\nZamiast \u015bciga\u0107 si\u0119 w procentach pokrycia, mierz:<\/p>\n<\/li>\n<\/ol>\n\n
\nTe metryki powiedz\u0105 wi\u0119cej o jako\u015bci ni\u017c 1000 zielonych test\u00f3w.<\/li>\n<\/ul>\n\n
\nJe\u015bli utrzymanie testu kosztuje wi\u0119cej ni\u017c jego warto\u015b\u0107 \u2013 usu\u0144 go lub przepisz. Testy to nie trofea do kolekcjonowania, a narz\u0119dzia do osi\u0105gania cel\u00f3w biznesowych.<\/p>\n<\/li>\n
\nNajlepsze automatyzacje nie zast\u0105pi\u0105 do\u015bwiadczonego testera, kt\u00f3ry potrafi my\u015ble\u0107 jak u\u017cytkownik i szuka\u0107 nietypowych scenariuszy.<\/p>\n<\/li>\n<\/ol>\nPodsumowanie: Automatyzacja jako \u015brodek, nie cel<\/h2>\n
\n
\n