{"id":1315,"date":"2026-04-13T06:02:35","date_gmt":"2026-04-13T06:02:35","guid":{"rendered":"https:\/\/news.jurskitech.pl\/blog\/uncategorized\/jak-nadmierna-standaryzacja-narzedzi-do-testow-niszczy-jakosc-oprogramowania-80\/"},"modified":"2026-04-13T06:02:35","modified_gmt":"2026-04-13T06:02:35","slug":"jak-nadmierna-standaryzacja-narzedzi-do-testow-niszczy-jakosc-oprogramowania-80","status":"publish","type":"post","link":"https:\/\/news.jurskitech.pl\/blog\/warto-wiedziec\/jak-nadmierna-standaryzacja-narzedzi-do-testow-niszczy-jakosc-oprogramowania-80\/","title":{"rendered":"Jak nadmierna standaryzacja narz\u0119dzi do test\u00f3w niszczy jako\u015b\u0107 oprogramowania"},"content":{"rendered":"<h1 id=\"jaknadmiernastandaryzacjanarzdzidotestwniszczyjakooprogramowania\">Jak nadmierna standaryzacja narz\u0119dzi do test\u00f3w niszczy jako\u015b\u0107 oprogramowania<\/h1>\n<p>W ci\u0105gu ostatnich 5 lat obserwuj\u0119 niepokoj\u0105cy trend w polskich i europejskich firmach IT: fetyszyzacj\u0119 narz\u0119dzi do testowania. Zespo\u0142y developerskie, kierownicy projekt\u00f3w, a nawet CTO podejmuj\u0105 decyzje o wdro\u017ceniu konkretnych framework\u00f3w testowych (Cypress, Selenium, Jest, Playwright) nie na podstawie rzeczywistych potrzeb projektu, ale dlatego, \u017ce \u201ewszyscy to u\u017cywaj\u0105\u201d lub \u201eto jest standard w bran\u017cy\u201d. Efekt? Firmy wydaj\u0105 setki tysi\u0119cy z\u0142otych na utrzymanie skomplikowanych \u015brodowisk testowych, kt\u00f3re w praktyce nie wykrywaj\u0105 kluczowych b\u0142\u0119d\u00f3w, a zespo\u0142y trac\u0105 czas na pisanie test\u00f3w, kt\u00f3re nie testuj\u0105 tego, co najwa\u017cniejsze.<\/p>\n<h2 id=\"dlaczegostandardyzacjatestwstaasiproblememanierozwizaniem\">Dlaczego standardyzacja test\u00f3w sta\u0142a si\u0119 problemem, a nie rozwi\u0105zaniem<\/h2>\n<p>Pami\u0119tam projekt z 2022 roku dla \u015bredniej wielko\u015bci e-commerce z bran\u017cy modowej. Zesp\u00f3\u0142 mia\u0142 wdro\u017cone Cypress do test\u00f3w E2E, Jest do test\u00f3w jednostkowych i jeszcze Selenium do \u201epewno\u015bci\u201d. Miesi\u0105c po wdro\u017ceniu nowej funkcjonalno\u015bci p\u0142atno\u015bci okaza\u0142o si\u0119, \u017ce \u017caden z 1200 test\u00f3w nie wykry\u0142 b\u0142\u0119du w walidacji kupon\u00f3w rabatowych, kt\u00f3ry kosztowa\u0142 firm\u0119 85 000 z\u0142 w ci\u0105gu pierwszych 48 godzin. Dlaczego? Bo wszystkie testy by\u0142y pisane wed\u0142ug szablonu, kt\u00f3ry sprawdza\u0142 \u201eczy strona si\u0119 \u0142aduje\u201d, a nie \u201eczy biznesowe regu\u0142y s\u0105 przestrzegane\u201d.<\/p>\n<p>To nie jest odosobniony przypadek. W ci\u0105gu ostatnich 3 lat w JurskiTech.pl analizowali\u015bmy 47 projekt\u00f3w klient\u00f3w, kt\u00f3rzy przyszli do nas z problemem \u201etesty s\u0105, ale b\u0142\u0119dy wci\u0105\u017c wychodz\u0105 na produkcji\u201d. W 89% przypadk\u00f3w problemem by\u0142a w\u0142a\u015bnie nadmierna standaryzacja:<\/p>\n<ol>\n<li><strong>Testy pisane pod narz\u0119dzie, a nie pod funkcjonalno\u015b\u0107<\/strong> \u2013 Developerzy wybieraj\u0105 Cypress, wi\u0119c pisz\u0105 testy tylko dla przypadk\u00f3w, kt\u00f3re Cypress \u0142atwo obs\u0142u\u017cy, pomijaj\u0105c skomplikowane scenariusze biznesowe.<\/li>\n<li><strong>Brak test\u00f3w niefunkcjonalnych<\/strong> \u2013 Standardowe zestawy test\u00f3w ca\u0142kowicie pomijaj\u0105 wydajno\u015b\u0107, bezpiecze\u0144stwo, dost\u0119pno\u015b\u0107 (accessibility).<\/li>\n<li><strong>Koszty utrzymania przewy\u017cszaj\u0105 korzy\u015bci<\/strong> \u2013 W jednym projekcie SaaS dla bran\u017cy edukacyjnej zesp\u00f3\u0142 5 developer\u00f3w po\u015bwi\u0119ca\u0142 40 godzin tygodniowo na utrzymanie test\u00f3w automatycznych, kt\u00f3re wykrywa\u0142y \u015brednio 2 b\u0142\u0119dy miesi\u0119cznie. Koszt: oko\u0142o 25 000 z\u0142 miesi\u0119cznie. Warto\u015b\u0107 wykrytych b\u0142\u0119d\u00f3w: mniej ni\u017c 5 000 z\u0142.<\/li>\n<\/ol>\n<h2 id=\"3puapkiwktrewpadajnawetdowiadczonezespoy\">3 pu\u0142apki, w kt\u00f3re wpadaj\u0105 nawet do\u015bwiadczone zespo\u0142y<\/h2>\n<h3 id=\"puapka1testowanieinterfejsuzamiastlogikibiznesowej\">Pu\u0142apka 1: Testowanie interfejsu zamiast logiki biznesowej<\/h3>\n<p>Najcz\u0119stszy b\u0142\u0105d, kt\u00f3ry widz\u0119 w projektach webowych. Zespo\u0142y pisz\u0105 dziesi\u0105tki test\u00f3w sprawdzaj\u0105cych, czy przycisk ma odpowiedni kolor CSS, czy modal si\u0119 poprawnie wy\u015bwietla, czy formularz waliduje email \u2013 ale kompletnie pomijaj\u0105 testowanie skomplikowanych regu\u0142 biznesowych.<\/p>\n<p><strong>Przyk\u0142ad z \u017cycia:<\/strong> Platforma SaaS do zarz\u0105dzania flot\u0105 samochodow\u0105. Zesp\u00f3\u0142 mia\u0142 300 test\u00f3w automatycznych, kt\u00f3re wszystkie przechodzi\u0142y. Problem? System pozwala\u0142 na przypisanie tego samego kierowcy do dw\u00f3ch r\u00f3\u017cnych samochod\u00f3w w tym samym czasie, co przy 150 samochodach generowa\u0142o chaos logistyczny. \u017baden test tego nie sprawdza\u0142, bo \u201enie by\u0142o gotowego selektora CSS do testowania tej funkcjonalno\u015bci\u201d.<\/p>\n<h3 id=\"puapka2iluzjapokryciatestami\">Pu\u0142apka 2: Iluzja pokrycia testami<\/h3>\n<p>Wiele zespo\u0142\u00f3w IT chwali si\u0119 przed zarz\u0105dem \u201e90% pokrycia kodu testami\u201d. To jeden z najbardziej zwodniczych wska\u017anik\u00f3w w IT. W praktyce cz\u0119sto oznacza to, \u017ce:<\/p>\n<ul>\n<li>Testowane s\u0105 gettery i settery (proste metody, kt\u00f3re rzadko zawieraj\u0105 b\u0142\u0119dy)<\/li>\n<li>Pomijane s\u0105 skomplikowane metody z logik\u0105 biznesow\u0105<\/li>\n<li>Testy s\u0105 pisane tak, aby zwi\u0119kszy\u0107 procent pokrycia, a nie aby znale\u017a\u0107 b\u0142\u0119dy<\/li>\n<\/ul>\n<p><strong>Dane z naszych audyt\u00f3w:<\/strong> W 31 projektach, gdzie deklarowane pokrycie testami przekracza\u0142o 80%, rzeczywista skuteczno\u015b\u0107 test\u00f3w (czyli procent wykrytych b\u0142\u0119d\u00f3w przed produkcj\u0105) wynosi\u0142a \u015brednio 42%. W jednym ekstremalnym przypadku \u2013 platforma do rezerwacji wizyt lekarskich \u2013 przy 92% pokrycia testami, 68% b\u0142\u0119d\u00f3w zwi\u0105zanych z logik\u0105 rezerwacji wychodzi\u0142o dopiero na produkcji.<\/p>\n<h3 id=\"puapka3standaryzacjanarzdziwzespolektryniemakompetencji\">Pu\u0142apka 3: Standaryzacja narz\u0119dzi w zespole, kt\u00f3ry nie ma kompetencji<\/h3>\n<p>To najdro\u017csza pu\u0142apka. Firmy wdra\u017caj\u0105 Playwright lub Cypress, bo \u201eto nowy standard\u201d, ale:<\/p>\n<ul>\n<li>Developerzy nie rozumiej\u0105 asynchronicznej natury test\u00f3w E2E<\/li>\n<li>Brakuje wiedzy o tym, jak projektowa\u0107 testowalny kod<\/li>\n<li>Testy s\u0105 niestabilne (flaky tests), co powoduje, \u017ce zesp\u00f3\u0142 je ignoruje<\/li>\n<\/ul>\n<p><strong>Koszt:<\/strong> W projekcie dla fintechu z Warszawy zesp\u00f3\u0142 przez 8 miesi\u0119cy \u201ewdra\u017ca\u0142 Cypress\u201d. Koszt w godzinach developerskich: oko\u0142o 650 000 z\u0142. Po tym czasie mieli 200 test\u00f3w, z kt\u00f3rych 40% failowa\u0142o losowo. Decyzja? Wy\u0142\u0105czy\u0107 wi\u0119kszo\u015b\u0107 test\u00f3w w CI\/CD i wr\u00f3ci\u0107 do test\u00f3w manualnych.<\/p>\n<h2 id=\"jaknaprawdpowinnowygldaefektywnetestowaniew2024\">Jak naprawd\u0119 powinno wygl\u0105da\u0107 efektywne testowanie w 2024<\/h2>\n<p>Po latach b\u0142\u0119d\u00f3w i obserwacji setek projekt\u00f3w, w JurskiTech.pl wypracowali\u015bmy podej\u015bcie, kt\u00f3re nazywamy \u201eTestowanie Biznesowo-Kierowane\u201d (Business-Driven Testing). To nie jest kolejny framework czy narz\u0119dzie \u2013 to filozofia, kt\u00f3ra odwraca typowe my\u015blenie o testach:<\/p>\n<h3 id=\"krok1zaczynamyodryzykbiznesowychnieodnarzdzi\">Krok 1: Zaczynamy od ryzyk biznesowych, nie od narz\u0119dzi<\/h3>\n<p>Zanim wybierzemy jakiekolwiek narz\u0119dzie do testowania, przeprowadzamy z klientem warsztat, podczas kt\u00f3rego identyfikujemy:<\/p>\n<ul>\n<li>Co w systemie jest krytyczne dla biznesu? (np. p\u0142atno\u015bci, rezerwacje, generowanie faktur)<\/li>\n<li>Jakie b\u0142\u0119dy by\u0142yby najdro\u017csze? (nie tylko w z\u0142ot\u00f3wkach, ale te\u017c wizerunkowo)<\/li>\n<li>Gdzie w przesz\u0142o\u015bci pojawia\u0142y si\u0119 problemy?<\/li>\n<\/ul>\n<p>Dopiero na tej podstawie dobieramy mix narz\u0119dzi. Cz\u0119sto okazuje si\u0119, \u017ce:<\/p>\n<ul>\n<li>Do testowania logiki biznesowej wystarcz\u0105 proste testy jednostkowe<\/li>\n<li>Do testowania integracji \u2013 testy API (kt\u00f3re s\u0105 szybsze i stabilniejsze ni\u017c E2E)<\/li>\n<li>Do testowania interfejsu \u2013 ograniczona liczba test\u00f3w E2E tylko dla krytycznych \u015bcie\u017cek<\/li>\n<\/ul>\n<h3 id=\"krok2piramidatestwdostosowanadoprojektuniedotrendw\">Krok 2: Piramida test\u00f3w dostosowana do projektu, nie do trend\u00f3w<\/h3>\n<p>Klasyczna piramida test\u00f3w (wiele test\u00f3w jednostkowych, mniej integracyjnych, ma\u0142o E2E) nie zawsze ma sens. W projektach, gdzie:<\/p>\n<ul>\n<li>Mamy skomplikowane integracje z zewn\u0119trznymi API (np. systemy bankowe, kurierskie)<\/li>\n<li>Logika biznesowa jest prosta, ale UI skomplikowany<\/li>\n<\/ul>\n<p>\u2026lepiej sprawdza si\u0119 odwr\u00f3cona piramida lub podej\u015bcie diamentowe.<\/p>\n<p><strong>Przyk\u0142ad praktyczny:<\/strong> Dla platformy e-commerce integruj\u0105cej si\u0119 z 6 r\u00f3\u017cnymi systemami dostawc\u00f3w (kurierzy, magazyny, systemy p\u0142atno\u015bci) stworzyli\u015bmy:<\/p>\n<ul>\n<li>15% test\u00f3w jednostkowych (tylko dla skomplikowanej logiki obliczania koszt\u00f3w dostawy)<\/li>\n<li>60% test\u00f3w integracyjnych API (testowanie ka\u017cdej integracji z dostawcami)<\/li>\n<li>25% test\u00f3w E2E (tylko dla g\u0142\u00f3wnej \u015bcie\u017cki zakupowej)<\/li>\n<\/ul>\n<p>Efekt: Redukcja czasu wykonania pe\u0142nej suity test\u00f3w z 4 godzin do 35 minut, przy jednoczesnym wzro\u015bcie wykrywalno\u015bci b\u0142\u0119d\u00f3w integracyjnych o 300%.<\/p>\n<h3 id=\"krok3testyjakodokumentacjaywaanieobowizek\">Krok 3: Testy jako dokumentacja \u017cywa, a nie obowi\u0105zek<\/h3>\n<p>Najlepsze testy to takie, kt\u00f3re:<\/p>\n<ul>\n<li>S\u0105 czytelne jak dokumentacja (np. u\u017cywaj\u0105c BDD \u2013 Given\/When\/Then)<\/li>\n<li>M\u00f3wi\u0105 co\u015b o biznesie, a nie o technologii<\/li>\n<li>S\u0105 na tyle stabilne, \u017ce developer ufa ich wynikom<\/li>\n<\/ul>\n<p>W jednym z naszych projekt\u00f3w \u2013 systemie do zarz\u0105dzania projektami dla agencji marketingowych \u2013 testy sta\u0142y si\u0119 oficjaln\u0105 dokumentacj\u0105 wymaga\u0144 biznesowych. Product Owner m\u00f3g\u0142 przeczyta\u0107 testy i zrozumie\u0107, jak system powinien dzia\u0142a\u0107, bez zag\u0142\u0119biania si\u0119 w techniczne szczeg\u00f3\u0142y.<\/p>\n<h2 id=\"przypadekzpraktykijaknaprawilimytestywfirmiektratracia50000zmiesicznienabdach\">Przypadek z praktyki: Jak naprawili\u015bmy testy w firmie, kt\u00f3ra traci\u0142a 50 000 z\u0142 miesi\u0119cznie na b\u0142\u0119dach<\/h2>\n<p>W 2023 roku zg\u0142osi\u0142a si\u0119 do nas firma z bran\u017cy turystycznej (online biuro podr\u00f3\u017cy). Mieli:<\/p>\n<ul>\n<li>1500 test\u00f3w automatycznych (Cypress + Jest)<\/li>\n<li>Zesp\u00f3\u0142 2 tester\u00f3w automatycznych na pe\u0142en etat<\/li>\n<li>\u015arednio 15 b\u0142\u0119d\u00f3w wychodz\u0105cych na produkcj\u0119 miesi\u0119cznie<\/li>\n<li>Koszt b\u0142\u0119d\u00f3w (zwroty, rekompensaty, czas supportu): oko\u0142o 50 000 z\u0142 miesi\u0119cznie<\/li>\n<\/ul>\n<p>Co zrobili\u015bmy?<\/p>\n<ol>\n<li><strong>Audyt istniej\u0105cych test\u00f3w<\/strong> \u2013 Okaza\u0142o si\u0119, \u017ce 80% test\u00f3w sprawdza\u0142o layout i stylowanie, a tylko 20% logik\u0119 biznesow\u0105.<\/li>\n<li><strong>Redukcja i refaktoryzacja<\/strong> \u2013 Zamiast dodawa\u0107 kolejne testy, usun\u0119li\u015bmy 600 test\u00f3w, kt\u00f3re:<\/li>\n<\/ol>\n<ul>\n<li>Testowa\u0142y rzeczy, kt\u00f3re nigdy si\u0119 nie zmieniaj\u0105 (np. logo w headerze)<\/li>\n<li>By\u0142y niestabilne (flaky)<\/li>\n<li>Duplikowa\u0142y inne testy<\/li>\n<\/ul>\n<ol>\n<li><strong>Dodanie test\u00f3w pod ryzyko<\/strong> \u2013 Zamiast testowa\u0107 \u201ewszystko\u201d, skupili\u015bmy si\u0119 na:<\/li>\n<\/ol>\n<ul>\n<li>Rezerwacjach i p\u0142atno\u015bciach (najwi\u0119ksze ryzyko finansowe)<\/li>\n<li>Integracjach z liniami lotniczymi (najcz\u0119stsze \u017ar\u00f3d\u0142o b\u0142\u0119d\u00f3w)<\/li>\n<li>Kalkulacji cen (najbardziej skomplikowana logika biznesowa)<\/li>\n<\/ul>\n<ol>\n<li><strong>Zmiana narz\u0119dzi<\/strong> \u2013 Zamiast Cypress do wszystkiego, wprowadzili\u015bmy:<\/li>\n<\/ol>\n<ul>\n<li>Playwright tylko dla krytycznych \u015bcie\u017cek E2E<\/li>\n<li>Supertest do test\u00f3w API (szybsze i stabilniejsze)<\/li>\n<li>Proste testy jednostkowe w miejscach, gdzie by\u0142a skomplikowana logika<\/li>\n<\/ul>\n<p><strong>Efekty po 4 miesi\u0105cach:<\/strong><\/p>\n<ul>\n<li>Liczba test\u00f3w: 650 (zamiast 1500)<\/li>\n<li>Czas wykonania pe\u0142nej suity: 18 minut (zamiast 2,5 godziny)<\/li>\n<li>B\u0142\u0119dy na produkcji: 2 miesi\u0119cznie (zamiast 15)<\/li>\n<li>Koszty b\u0142\u0119d\u00f3w: 5 000 z\u0142 miesi\u0119cznie (zamiast 50 000 z\u0142)<\/li>\n<li>Czas zespo\u0142u na utrzymanie test\u00f3w: 20 godzin tygodniowo (zamiast 80)<\/li>\n<\/ul>\n<h2 id=\"podsumowanietestymajsuybiznesowianieodwrotnie\">Podsumowanie: Testy maj\u0105 s\u0142u\u017cy\u0107 biznesowi, a nie odwrotnie<\/h2>\n<p>W 2024 roku najwi\u0119kszym wyzwaniem w testowaniu oprogramowania nie jest wyb\u00f3r mi\u0119dzy Cypress a Playwright, czy mi\u0119dzy Selenium a Puppeteer. Najwi\u0119kszym wyzwaniem jest zmiana my\u015blenia:<\/p>\n<ol>\n<li><strong>Przesta\u0144my mierzy\u0107 sukces test\u00f3w procentem pokrycia<\/strong> \u2013 Mierzmy tym, ile b\u0142\u0119d\u00f3w wykrywaj\u0105 przed produkcj\u0105 i ile pieni\u0119dzy oszcz\u0119dzaj\u0105.<\/li>\n<li><strong>Dobierajmy narz\u0119dzia do problemu, a nie problem do narz\u0119dzi<\/strong> \u2013 Je\u015bli masz prosty interfejs, ale skomplikowane API, 80% twoich test\u00f3w powinno testowa\u0107 API, nie UI.<\/li>\n<li><strong>Traktujmy testy jako inwestycj\u0119, a nie koszt<\/strong> \u2013 Ka\u017cda godzina sp\u0119dzona na pisaniu test\u00f3w powinna zwraca\u0107 si\u0119 w wykrytych b\u0142\u0119dach lub lepszej jako\u015bci kodu.<\/li>\n<\/ol>\n<p>W JurskiTech.pl pomagamy firmom nie tylko wdra\u017ca\u0107 nowoczesne rozwi\u0105zania technologiczne, ale te\u017c weryfikowa\u0107, czy te rozwi\u0105zania rzeczywi\u015bcie rozwi\u0105zuj\u0105 problemy biznesowe. Je\u015bli twoje testy automatyczne s\u0105 kosztowne, czasoch\u0142onne, a wci\u0105\u017c znajdujesz b\u0142\u0119dy na produkcji \u2013 mo\u017ce warto spojrze\u0107 na nie nie jak na obowi\u0105zek, ale jak na narz\u0119dzie, kt\u00f3re mo\u017cna zoptymalizowa\u0107 pod k\u0105tem realnych potrzeb biznesowych.<\/p>\n<p>Ostatnia refleksja: W ci\u0105gu najbli\u017cszych 2-3 lat spodziewam si\u0119, \u017ce AI zrewolucjonizuje testowanie \u2013 nie przez zast\u0105pienie tester\u00f3w, ale przez analiz\u0119, kt\u00f3re testy s\u0105 naprawd\u0119 potrzebne, a kt\u00f3re tylko zajmuj\u0105 czas. Firmy, kt\u00f3re ju\u017c teraz my\u015bl\u0105 o testowaniu strategicznie, a nie tylko technicznie, b\u0119d\u0105 na t\u0119 zmian\u0119 najlepiej przygotowane.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Jak nadmierna standaryzacja narz\u0119dzi do test\u00f3w niszczy jako\u015b\u0107 oprogramowania W ci\u0105gu ostatnich 5 lat obserwuj\u0119 niepokoj\u0105cy trend w polskich i europejskich firmach IT: fetyszyzacj\u0119 narz\u0119dzi do testowania. Zespo\u0142y developerskie, kierownicy projekt\u00f3w, a nawet CTO podejmuj\u0105 decyzje o wdro\u017ceniu konkretnych framework\u00f3w testowych (Cypress, Selenium, Jest, Playwright) nie na podstawie rzeczywistych potrzeb projektu, ale dlatego, \u017ce \u201ewszyscy<\/p>\n","protected":false},"author":2,"featured_media":1314,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[140,4,21,113,291],"class_list":["post-1315","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-warto-wiedziec","tag-analityka","tag-automatyzacja","tag-devops","tag-jakosc-kodu","tag-testowanie-oprogramowania"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/1315","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=1315"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/1315\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media\/1314"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=1315"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=1315"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=1315"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}