W ci\u0105gu ostatnich dw\u00f3ch lat obserwuj\u0119 niepokoj\u0105cy trend w polskich firmach IT: zespo\u0142y po\u015bwi\u0119caj\u0105 wi\u0119cej czasu na standaryzacj\u0119 narz\u0119dzi do testowania ni\u017c na faktyczne testowanie. W efekcie otrzymujemy pi\u0119kne raporty z pokryciem kodu na poziomie 90%, podczas aplikacje w produkcji padaj\u0105 na prostych scenariuszach u\u017cytkowych. To klasyczny przyk\u0142ad tego, jak \u015blepe pod\u0105\u017canie za \u201ebest practices\u201d mo\u017ce przynie\u015b\u0107 efekt odwrotny do zamierzonego.<\/p>\n
W 2023 roku przeprowadzi\u0142em audyt w 7 \u015brednich firmach software house’owych w Polsce. Wszystkie mia\u0142y wdro\u017cone kompleksowe frameworki testowe: Cypress dla e2e, Jest dla jednostkowych, Playwright dla integracyjnych. Ka\u017cdy zesp\u00f3\u0142 chwali\u0142 si\u0119 standardyzacj\u0105 proces\u00f3w, ale gdy poprosi\u0142em o pokazanie, jak te testy wykry\u0142y ostatni krytyczny b\u0142\u0105d w produkcji \u2013 zapad\u0142a cisza.<\/p>\n
Problem zaczyna si\u0119 tam, gdzie liderzy techniczni traktuj\u0105 standaryzacj\u0119 jako KPI. \u201eMusimy mie\u0107 80% pokrycia testami\u201d brzmi dobrze w raporcie dla zarz\u0105du, ale w praktyce oznacza cz\u0119sto pisanie test\u00f3w, kt\u00f3re sprawdzaj\u0105 oczywisto\u015bci. Widzia\u0142em test jednostkowy, kt\u00f3ry przez 50 linii kodu weryfikowa\u0142, czy funkcja zwraca string \u2013 podczas gdy prawdziwy problem biznesowy (walidacja danych u\u017cytkownika) by\u0142 ca\u0142kowicie pomini\u0119ty.<\/p>\n
Najbardziej niebezpieczny efekt. Zesp\u00f3\u0142 widzi zielone testy w CI\/CD i my\u015bli: \u201enasza jako\u015b\u0107 jest pod kontrol\u0105\u201d. Tymczasem w jednej z platform e-commerce, z kt\u00f3r\u0105 wsp\u00f3\u0142pracowali\u015bmy, wszystkie testy przechodzi\u0142y, ale klienci nie mogli finalizowa\u0107 zam\u00f3wie\u0144 przez 3 dni. Dlaczego? Testy sprawdza\u0142y API endpointy, ale nie symulowa\u0142y rzeczywistego flow u\u017cytkownika z wieloma otwartymi kartami i przerwanymi sesjami.<\/p>\n
W startupie, kt\u00f3ry audytowa\u0142em, dodanie nowego pola do formularza zajmowa\u0142o 2 dni \u2013 nie przez kodowanie, ale przez aktualizacj\u0119 47 powi\u0105zanych test\u00f3w. Zesp\u00f3\u0142 tak bardzo skupi\u0142 si\u0119 na utrzymaniu \u201eczystej\u201d architektury test\u00f3w, \u017ce zapomnia\u0142, po co w\u0142a\u015bciwie je pisze. To jak budowanie perfekcyjnie zaprojektowanej fabryki, kt\u00f3ra produkuje tylko dokumentacj\u0119.<\/p>\n
Programi\u015bci nienawidz\u0105 pisa\u0107 bezsensownych test\u00f3w. W anonimowej ankiecie w\u015br\u00f3d 50 polskich developer\u00f3w, 68% przyzna\u0142o, \u017ce pisanie test\u00f3w do trywialnych funkcji demotywuje ich bardziej ni\u017c praca z legacy code. Jeden senior developer powiedzia\u0142 mi: \u201eCzuj\u0119 si\u0119 jak urz\u0119dnik wype\u0142niaj\u0105cy formularze, zamiast in\u017cynier rozwi\u0105zuj\u0105cy problemy\u201d.<\/p>\n
Zamiast pyta\u0107 \u201ejakie narz\u0119dzie do test\u00f3w wybra\u0107?\u201d, zacznij od: \u201eco mo\u017ce najszybciej zepsu\u0107 do\u015bwiadczenie naszego u\u017cytkownika?\u201d. W JurskiTech dla klienta z platform\u0105 SaaS do zarz\u0105dzania projektami zacz\u0119li\u015bmy od zmapowania 5 krytycznych \u015bcie\u017cek u\u017cytkownika, kt\u00f3re generowa\u0142y 80% przychod\u00f3w. Testy pisali\u015bmy tylko dla nich, pomijaj\u0105c mniej istotne funkcje.<\/p>\n
Klasyczny b\u0142\u0105d: testy \u0142ami\u0105 si\u0119 przy refaktoringu, cho\u0107 funkcjonalno\u015b\u0107 dzia\u0142a tak samo. W jednym z projekt\u00f3w migracji z REST na GraphQL, zamiast przepisywa\u0107 200 test\u00f3w sprawdzaj\u0105cych struktur\u0119 odpowiedzi, przepisali\u015bmy je na testy akceptacyjne: \u201eu\u017cytkownik mo\u017ce doda\u0107 produkt do koszyka\u201d. Po migracji 95% test\u00f3w przesz\u0142o bez zmian.<\/p>\n
Zapomnij o \u201epokryciu kodu\u201d. Zacznij mierzy\u0107:<\/p>\n
W jednej firmie po zmianie metryk na te biznesowe, zesp\u00f3\u0142 zmniejszy\u0142 liczb\u0119 test\u00f3w o 40%, a jako\u015b\u0107 wzros\u0142a \u2013 bo skupili si\u0119 na testowaniu tego, co naprawd\u0119 wa\u017cne.<\/p>\n
Du\u017cy bank w Polsce wdro\u017cy\u0142 standaryzacj\u0119 test\u00f3w API po tym, jak r\u00f3\u017cne zespo\u0142y u\u017cywa\u0142y 5 r\u00f3\u017cnych narz\u0119dzi. Kluczem sukcesu by\u0142o:<\/p>\n
Efekt: czas wdro\u017cenia nowych funkcji skr\u00f3ci\u0142 si\u0119 o 30%, bo developerzy nie musieli uczy\u0107 si\u0119 nowych narz\u0119dzi dla ka\u017cdego mikroserwisu.<\/p>\n
M\u0142oda firma e-commerce wyda\u0142a 6 miesi\u0119cy na wdro\u017cenie \u201eidealnego\u201d pipeline’u testowego z 4 warstwami test\u00f3w. Gdy w ko\u0144cu uruchomili platform\u0119, okaza\u0142o si\u0119, \u017ce testy nie wykry\u0142y problemu z koszykiem w Safari \u2013 bo wszystkie testy uruchamiali na Chromie. Straty: 15% porzuconych koszyk\u00f3w w pierwszym miesi\u0105cu.<\/p>\n
W naszych projektach stosujemy prost\u0105 zasad\u0119: testy maj\u0105 s\u0142u\u017cy\u0107 biznesowi, nie odwrotnie. Oto nasze praktyki:<\/p>\n
Testy eksploracyjne przed automatyzacj\u0105<\/strong> \u2013 zanim napiszemy pierwszy test automatyczny, przez 2 dni manualnie testujemy aplikacj\u0119 jak u\u017cytkownik. To daje nam zrozumienie, co naprawd\u0119 wymaga automatyzacji.<\/p>\n<\/li>\n Piramida test\u00f3w dostosowana do projektu<\/strong> \u2013 dla ma\u0142ego MVP wystarcz\u0105 testy e2e krytycznych \u015bcie\u017cek. Dla systemu bankowego potrzebujemy pe\u0142nej piramidy. Nie ma jednego szablonu.<\/p>\n<\/li>\n Developerzy pisz\u0105 testy, ale QA decyduje co testowa\u0107<\/strong> \u2013 rozdzielamy odpowiedzialno\u015bci. Developer wie JAK testowa\u0107, QA wie CO testowa\u0107.<\/p>\n<\/li>\n Regularne usuwanie test\u00f3w<\/strong> \u2013 co kwarta\u0142 przegl\u0105damy testy i usuwamy te, kt\u00f3re:<\/p>\n<\/li>\n<\/ol>\n Standaryzacja narz\u0119dzi do test\u00f3w nie jest z\u0142a sama w sobie \u2013 staje si\u0119 problemem, gdy staje si\u0119 celem. Prawdziwa jako\u015b\u0107 oprogramowania pochodzi z testowania tego, co wa\u017cne dla u\u017cytkownika i biznesu, nie z procent\u00f3w pokrycia kodu.<\/p>\n W ci\u0105gu najbli\u017cszych 2 lat spodziewam si\u0119 powrotu do bardziej pragmatycznego podej\u015bcia do testowania. Firmy, kt\u00f3re zrozumiej\u0105, \u017ce testy to \u015brodek do celu (stabilnej aplikacji), a nie cel sam w sobie, zyskaj\u0105 przewag\u0119 konkurencyjn\u0105.<\/p>\n Ostatnia my\u015bl: nast\u0119pnym razem, gdy b\u0119dziesz implementowa\u0107 nowe narz\u0119dzie testowe, zadaj sobie pytanie: \u201eCzy to pomo\u017ce nam szybciej wykrywa\u0107 prawdziwe b\u0142\u0119dy, czy tylko \u0142adniej wygl\u0105da\u0107 w raporcie?\u201d. R\u00f3\u017cnica mi\u0119dzy tymi odpowiedziami to cz\u0119sto r\u00f3\u017cnica mi\u0119dzy projektem, kt\u00f3ry si\u0119 skaluje, a takim, kt\u00f3ry tonie w technicznej z\u0142o\u017cono\u015bci.<\/p>\n","protected":false},"excerpt":{"rendered":" Jak nadmierna standaryzacja narz\u0119dzi do test\u00f3w niszczy jako\u015b\u0107 oprogramowania W ci\u0105gu ostatnich dw\u00f3ch lat obserwuj\u0119 niepokoj\u0105cy trend w polskich firmach IT: zespo\u0142y po\u015bwi\u0119caj\u0105 wi\u0119cej czasu na standaryzacj\u0119 narz\u0119dzi do testowania ni\u017c na faktyczne testowanie. W efekcie otrzymujemy pi\u0119kne raporty z pokryciem kodu na poziomie 90%, podczas aplikacje w produkcji padaj\u0105 na prostych scenariuszach u\u017cytkowych. To<\/p>\n","protected":false},"author":2,"featured_media":1451,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[4,21,301,113,291],"class_list":["post-1452","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-warto-wiedziec","tag-automatyzacja","tag-devops","tag-inzynieria-oprogramowania","tag-jakosc-kodu","tag-testowanie-oprogramowania"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/1452","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=1452"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/1452\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media\/1451"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=1452"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=1452"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=1452"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
Podsumowanie: wracaj\u0105c do sensu testowania<\/h2>\n