Radek Smilgin
Pierwsza myśl: „DevOps? Naprawdę? W 2026 roku, kiedy to już powszechne stało się budowanie procesów wytwórczych dopasowanych do organizacji, a nie narzucanie jednomyślicielstwa wdrożeniowego”.
DevOps jest OK i miał swój wkład w budowanie kultur wytwarzania oprogramowania, ale nie niósł niczego odkrywczego. Był jedynie zbiorem praktyk zgrabnie ułożonych, by pokazać, jak można zautomatyzować proces wydawniczy. W międzyczasie i praktyki się pozmieniały, i narzędzia wyewoluowały, a w dodatku namieszało AI. Część młodszych czytelników może nie połączyć kropek. Z drugiej strony ISTQB® do poziomu podstawowego nie wydaje sylabusów bez przypisania do roli lub zadania do wykonania. Musiało więc wpaść coś, do czego można przykleić kontrolę jakości i padło na DevOps. Można to było jednak umieścić bliżej inżynierii automatyzacji, albo wydzielić jako inżynierię jakości (o tym więcej za chwilę).
CT-QDO, bo taki skrót opisuje nowy sylabus, niesie niespotykane do tej pory w innych sylabusach treści i podejścia do tematów:
- pierwszy raz tak dużo uwagi poświęca się QA, co daje nadzieję na poważny dialog odnośnie do tego, co tester oprogramowania może zrobić w ramach swoich kompetencji, a co już wpada do koszyka specjalisty ds. zapewnienia jakości,
- ISTQB® otworzyło się na pojęcie „quality engineering”, które, co może szokować, do tej pory w jej sylabusach praktycznie nie istniało; inżynieria jakości jako procesowe i techniczne podejście do jakości powinno już dawno funkcjonować na poziomie zapewnienia jakości i kontroli jakości,
- tak mało powtórzeń; ISTQB® przyzwyczaiło nas do tego, że sylabusy mają część wspólną, czyli hasła i opisy, które wydają nam się znajome z innych publikacji; tutaj wszystko wydaje się być relatywnie nowe, a w związku z tym wnoszące nową wartość.
A to tylko część niespodzianek, które każą ciepło myśleć o tym sylabusie.
W mojej opinii największą zaletą CT-QDO jest przejście od klasycznego „testowania jako aktywności” do quality engineeringu jako całego strumienia wartości. Sylabus definiuje QA jako działania budujące zaufanie, że wymagania jakościowe zostaną spełnione, a QE jako wszystkie działania jakościowe prowadzące do stworzenia oprogramowania spełniającego potrzeby klienta. W nowoczesnych organizacjach tester coraz rzadziej jest osobą „na końcu procesu”, a coraz częściej uczestniczy w:
- analizie wymagań,
- CI/CD,
- jakości pipeline’u,
- automatyzacji,
- monitoringu,
- observability,
- decyzjach release/no-release,
- analizie produkcyjnej.
Idąc dalej, sylabus sensownie (i zgodnie z prawdą) pokazuje, że DevOps nie jest narzędziem, frameworkiem ani osobnym zespołem, ale kulturą współpracy, komunikacji, automatyzacji i ciągłego doskonalenia. Wprost podkreśla też, że DevOps ma obejmować nie tylko kodowanie i utrzymanie, ale również CI, bezpieczeństwo, release, infrastrukturę i monitoring produkcyjny. To jest mocna strona, bo wiele organizacji nadal rozumie DevOps jako „kogoś od Jenkinsa i Kubernetesa”.
Kolejnym słusznym posunięciem jest wprowadzenie metryk DORA: change lead time, deployment frequency, change fail percentage i failed deployment recovery time. Dobrze wypada też część SRE: SLA, SLO i SLI są opisane jako elementy mierzenia jakości usługi. Sylabus wskazuje, że SLI mogą być mierzone zarówno w fazach developmentu przez testy, jak i operacyjnie przez monitoring, observability oraz telemetrię. To przydatne dla testerów, którzy chcą wyjść poza „passed/failed” i rozumieć jakość jako cechę działającej usługi.
CT-QDO trafnie pokazuje również continuous testing (ciągłe testowanie) jako aktywność rozciągniętą od pomysłu do produkcji, a nie jako „automatyczne testy w pipeline”. To kolejna słuszna obserwacja w świecie CI. W praktyce wiele zespołów myli continuous testing z nocnym uruchamianiem regresji. CT-QDO przypomina nam, że chodzi o ciągły przepływ informacji o jakości.
Sylabus nie powiela również mitu „w DevOps wszystko musi być automatyczne”. Wprost mówi, że testowanie manualne pozostaje istotną częścią kontroli jakości, bo dostarcza innego rodzaju informacji niż automatyzacja, wspiera ocenę usability, daje interesariuszom dodatkową pewność i bywa bardziej elastyczne oraz opłacalne (zależnie od kontekstu). Wartościowe jest również osadzenie w sylabusie testów eksploracyjnych, crowd testingu i quality hunting w sosie DevOps, CI/CD oraz kultury feedbacku.
Najmocniejszą częścią praktyczną jest rozdział 3. CT-QDO porusza tematy, które realnie bolą organizacje DevOps:
- „single source of truth” dla testaliów,
- śledzenie między wymaganiami a testami,
- raportowanie jakości w CI/CD,
- automatyzacja zarządzania danymi testowymi,
- analiza statystyczna wyników,
- automatyzacja środowisk testowych.
Szczególnie ważne jest podkreślenie, że raport jakości powinien łączyć dane z automatycznych i manualnych testów oraz produkcyjnego monitoringu. To bardzo dobra odpowiedź na problem współczesnych zespołów: mamy dane w wielu narzędziach, ale nie mamy jednej użytecznej informacji o jakości.
Jeśli Wam mało, to CT-QDO dobrze dobiera nowoczesne tematy, które tester w DevOps powinien przynajmniej rozumieć:
- testowanie API,
- testowanie kontraktowe,
- infrastruktura jako kod,
- feature toggles,
- strategie gałęzi,
- inżynierię chaosu,
- telemetrię,
- obserwowalność,
- konteneryzację.
Jednocześnie pamiętajmy, że choć sylabus dotyka tematów technicznych, to jedynie na poziomie koncepcyjnym. Przykład: w części o automation hands-on wskazuje się, że ćwiczenie ma dotyczyć decyzji strategicznych: co automatyzować, gdzie automatyzacja jest konieczna, gdzie opcjonalna i czego nie automatyzować – a nie narzędzi ani implementacji. Dlatego CT-QDO nie zastąpi szkoleń DevOps ani praktycznych kursów narzędziowych.
Część bardzo aktualnych tematów ma jedynie poziom K1 (prostego zrozumienia), np. feature toggles. To może być odbierane jako słabość. Właśnie te obszary są dziś kluczowe w DevOps, a wymaganie egzaminacyjne jest zbyt płytkie. Tester pracujący w środowisku DevOps powinien nie tylko rozpoznawać pojęcia, ale rozumieć ich wpływ na jakość, ryzyko, testowalność i decyzje releasowe.
DevSecOps-i również mogą poczuć rozczarowanie zakresem. Security co prawda pojawia się w sylabusie, ale temat bezpieczeństwa jest zbyt lekko potraktowany. Można to potraktować jako pewien kompromis między objętością sylabusa a chęcią pokazania wszystkich niuansów.
Rynkowo CT-QDO jest bardziej przydatny niż wiele wąskich certyfikatów ISTQB, bo odpowiada na realną zmianę pracy QA: przejście od testera jako wykonawcy testów do roli osoby odpowiedzialnej za informacje o jakości w pipeline, produkcie i produkcji. Jest to jeden z niewielu sylabusów, który buduje wiedzę mid+ i seniorów.
Ten sylabus oraz egzamin, zarówno jak wiele innych z zakresu ISTQB®, znajdziecie na platformie EDU!
