Standard ISO/IEC 9126 porządkuje to, co w QA najłatwiej się rozmywa: jak odróżnić produkt, który tylko działa, od produktu naprawdę dobrego jakościowo, jak mierzyć ryzyko przed wydaniem i jak zamienić ogólne oczekiwania w testowalne kryteria. W praktyce ten model pomaga spiąć testy funkcjonalne, wydajnościowe, użytecznościowe i utrzymaniowe w jeden spójny proces. Dla zespołu oznacza to mniej uznaniowych ocen, a więcej decyzji opartych na danych.
Model jakości pomaga zamienić ogólne wymagania na mierzalne kryteria QA
- Opisuje jakość produktu przez 6 głównych cech, a nie przez pojedynczą listę błędów.
- Rozróżnia jakość wewnętrzną, zewnętrzną i jakość w użyciu, więc porządkuje pracę testów na kilku poziomach.
- Największą wartość daje wtedy, gdy cechy jakości przekładam na konkretne metryki, progi i scenariusze testowe.
- To podejście nadal jest przydatne w legacy i dokumentacji, choć w nowych projektach częściej odwołuję się dziś do nowszego modelu 25010.
Jak rozumieć ten standard w procesach QA
W praktyce nie traktuję tego standardu jako „kolejnej normy do przeczytania”, tylko jako wspólny język dla QA, developerów i biznesu. Jego sens polega na tym, że zamiast mówić ogólnie „chcemy wysokiej jakości”, można wskazać, jakiej jakości oczekujemy i jak ją sprawdzimy. To duża różnica, zwłaszcza w zespołach, które pracują szybko i łatwo gubią granicę między poprawnością funkcjonalną a jakością produktu jako całości.
Najważniejsze jest tu rozróżnienie trzech poziomów. Jakość wewnętrzna dotyczy cech widocznych w kodzie i architekturze, zanim produkt trafi do użytkownika. Jakość zewnętrzna opisuje zachowanie systemu w czasie uruchomienia, czyli to, co widać w testach i środowisku. Jakość w użyciu odpowiada na pytanie, czy użytkownik naprawdę osiąga swój cel bez tarcia, błędów i zbędnego wysiłku. W QA te trzy poziomy warto oglądać razem, bo dopiero wtedy widać pełny obraz ryzyka.
Ja używam tej perspektywy szczególnie wtedy, gdy zespół ma już sporo testów automatycznych, ale nadal nie umie odpowiedzieć na pytanie, czy produkt jest gotowy do wydania. Sam fakt, że testy przechodzą, nie mówi jeszcze nic o wygodzie użycia, wydajności pod obciążeniem czy łatwości utrzymania. Właśnie dlatego ten model nadal się przydaje, mimo że sam standard został zastąpiony nowszym podejściem. Żeby zobaczyć, jak to działa w praktyce, trzeba przejść od definicji do konkretnych cech jakości.
Jakie cechy jakości opisuje model
Model porządkuje jakość wokół sześciu obszarów. To nie jest lista do odhaczania, tylko mapa, która pomaga zdecydować, co testować, czym mierzyć i jaki wynik uznać za akceptowalny. W dobrze prowadzonym QA nie próbuję pokryć wszystkiego jednakowo. Zamiast tego wybieram cechy najważniejsze dla konkretnego produktu i kontekstu biznesowego.
| Cecha | Co oznacza w praktyce | Co sprawdza QA | Przykład miary |
|---|---|---|---|
| Funkcjonalność | Czy system robi to, do czego został zbudowany, w tym czy poprawnie obsługuje zgodność, bezpieczeństwo i wymianę danych. | Testy scenariuszy biznesowych, testy API, walidację uprawnień, zgodność reguł. | 100% krytycznych scenariuszy zaliczonych, 0 otwartych defektów blokujących. |
| Niezawodność | Czy system działa stabilnie, odzyskuje się po awarii i nie psuje się przy typowym obciążeniu. | Testy długotrwałe, testy odporności na błędy, recovery, failover, soak test. | Odzyskanie usługi w mniej niż 60 sekund po restarcie, niski odsetek błędów pod obciążeniem. |
| Użyteczność | Czy użytkownik rozumie interfejs, szybko się uczy i bez problemu wykonuje zadania. | Testy UX, heurystyczną ocenę interfejsu, analizę ścieżek onboardingowych. | Wysoki odsetek ukończonych zadań, krótki czas pierwszej obsługi, pozytywny feedback użytkowników. |
| Wydajność | Czy system reaguje szybko i nie zużywa nadmiernie zasobów. | Testy obciążeniowe, profilowanie, monitorowanie czasu odpowiedzi i zużycia pamięci. | Czas odpowiedzi p95 poniżej 2 sekund dla kluczowego flow. |
| Utrzymywalność | Czy system da się łatwo analizować, zmieniać i testować bez kosztownych skutków ubocznych. | Przeglądy kodu, analiza statyczna, testy jednostkowe, ocena podatności na regresję. | Czas wdrożenia zmiany, stabilność testów, czas potrzebny na diagnozę błędu. |
| Przenośność | Czy system da się uruchomić, przenieść lub odtworzyć w innym środowisku bez dużego wysiłku. | Testy instalacji, wdrożenia, zgodności środowisk, pracy w różnych konfiguracjach. | Skuteczne uruchomienie w środowiskach docelowych bez ręcznych poprawek. |
Najbardziej praktyczna lekcja jest taka: nie każda cecha ma taki sam ciężar. W aplikacji bankowej najważniejsze będą niezawodność i bezpieczeństwo, w e-commerce zwykle szybciej zaboli wydajność i użyteczność, a w narzędziu dla developerów większą rolę odegra utrzymywalność. Dobra praca QA polega właśnie na tym, żeby te różnice nazwać, a nie przykryć jedną uniwersalną checklistą. Teraz przechodzę do tego, jak przełożyć te cechy na realny plan testów.
Jak przełożyć model na plan testów i kryteria akceptacji
Jeżeli mam sprowadzić ten model do konkretnego procesu QA, zaczynam od pytania: co musi się udać, żeby ten produkt był naprawdę gotowy? Dopiero potem dobieram metryki. W przeciwnym razie łatwo skończyć z listą ładnych pojęć, które nie pomagają ani testerowi, ani product ownerowi, ani zespołowi utrzymaniowemu.
- Zdefiniuj kontekst użycia. Inaczej testuje się aplikację mobilną dla klientów detalicznych, a inaczej system operacyjny dla firm logistycznych. Liczy się urządzenie, sieć, obciążenie, czas użycia i poziom doświadczenia użytkownika.
- Wybierz 3-5 cech jakości, które naprawdę wpływają na sukces produktu. Nie ma sensu rozciągać zespołu na wszystkie sześć, jeśli dwie z nich są marginalne dla danego przypadku.
- Przypisz do każdej cechy jedną metrykę wiodącą i jedną pomocniczą. Ja zwykle zaczynam od prostszego zestawu, bo zbyt rozbudowany dashboard szybciej przeszkadza, niż pomaga.
- Ustal próg akceptacji. Zamiast pisać „szybko działa”, lepiej zapisać, że 95. percentyl czasu odpowiedzi dla kluczowego flow ma być poniżej 2 sekund.
- Dobierz typ testu do cechy. Funkcjonalność sprawdzisz inaczej niż wydajność, a użyteczność inaczej niż odzyskiwanie po awarii.
Przykład: dla aplikacji do zakupów online mogę ustawić wymaganie, że dodanie produktu do koszyka działa w mniej niż 1 sekundę w typowym obciążeniu, a ścieżka zakupu kończy się bez błędu w co najmniej 99% prób w środowisku testowym. To już nie jest ogólne „działa dobrze”, tylko konkret, który da się obronić w review i w raporcie QA.
Ten sam model pomaga też w lepszym planowaniu regresji. Jeśli wydanie dotyka logiki płatności, nie wystarczy przepuścić testy funkcjonalne. Trzeba sprawdzić wpływ na niezawodność, wydajność i obsługę błędów, bo właśnie tam najczęściej wychodzą problemy „niewidoczne” na poziomie pojedynczego scenariusza. Z takiego podejścia płynnie wynika pytanie, dlaczego dziś częściej wskazuje się nowszy model jakości.
Dlaczego nowszy model 25010 przejął rolę poprzednika
W 2026 roku nie budowałbym nowego systemu jakości wyłącznie na starszym modelu, bo jego rola jest dziś przede wszystkim historyczna i koncepcyjna. Nowszy model 25010 zastąpił wcześniejsze podejście, ponieważ lepiej opisuje współczesne systemy, w których granica między softwarem, danymi, infrastrukturą i usługą jest dużo mniej wyraźna niż kiedyś. To ważne zwłaszcza w projektach chmurowych, mobilnych i platformowych.
| Obszar | Starsze podejście | Nowsze podejście | Co to znaczy dla QA |
|---|---|---|---|
| Zakres modelu | Klasyczny model jakości produktu i osobna perspektywa jakości w użyciu. | Szerszy i bardziej precyzyjny model dla współczesnych produktów i systemów ICT. | Łatwiej opisać produkty złożone, rozproszone i usługowe. |
| Bezpieczeństwo | Ujęte mniej wyraźnie, częściowo w obszarze funkcjonalności. | Wyodrębnione bardziej jednoznacznie. | Łatwiej nadać bezpieczeństwu własne kryteria, testy i odpowiedzialność. |
| Zastosowanie | Dobre dla dokumentacji, legacy i projektów, które nadal mówią tym językiem. | Lepsze jako punkt startu dla nowych produktów i polityk jakości. | W nowych projektach rzadziej trzeba „tłumaczyć” model na współczesne realia. |
| Praca zespołu | Łatwo zamienić go w zestaw pojęć bez dobrej operacjonalizacji. | Lepsze wsparcie dla mierzalnych wymagań i audytu jakości. | QA ma prostszy most między wymaganiami, testami i metrykami. |
Moje praktyczne podejście jest proste: starszego modelu nie wyrzucam, ale nie udaję, że wystarcza do wszystkiego. W dokumentacji legacy, w szkoleniach i w rozmowach o jakości nadal ma sens. Gdy jednak buduję nowy proces QA albo porządkuję kryteria dla nowego produktu, wybieram nowszy model jako punkt odniesienia, a starszy traktuję raczej jako fundament, z którego wyrósł. To prowadzi do najważniejszej kwestii: jak korzystać z tej logiki bez dokładania zespołowi zbędnej biurokracji.
Jak używać tego podejścia w zespole, żeby poprawiać jakość zamiast mnożyć dokumenty
Największy błąd, jaki widzę, to próba wdrożenia modelu jakości jako kolejnej ceremonii. Wtedy zamiast lepszego QA pojawia się arkusz, który nikt nie aktualizuje, i raport, który nie zmienia żadnej decyzji. Ja wolę podejście lżejsze, ale ostrzejsze: mniej punktów, za to każdy powiązany z ryzykiem, testem i właścicielem.
- Nie testuj wszystkiego tak samo - jeśli produkt nie jest wrażliwy na przenośność, nie poświęcaj temu tyle samo uwagi co niezawodności.
- Nie myl jakości kodu z jakością produktu - dobry code review nie zastępuje testów wydajnościowych ani obserwacji zachowania użytkownika.
- Nie zostawiaj metryk na koniec sprintu - kryteria jakości powinny żyć już w refinamencie, a nie dopiero w raporcie po wydaniu.
- Nie buduj zbyt dużej liczby wskaźników - jedna metryka wiodąca i jedna pomocnicza na cechę zwykle wystarczą, jeśli są dobrze dobrane.
- Nie ignoruj kontekstu biznesowego - ta sama aplikacja może wymagać innych priorytetów jakościowych w Polsce, na innym rynku albo w innym modelu wdrożenia.
Jeżeli mam zostawić jedną praktyczną zasadę, to tę: model jakości ma pomagać podejmować decyzje, a nie tworzyć ładną dokumentację. Gdy zespół potrafi przełożyć cechy produktu na mierzalne kryteria, testy i progi akceptacji, QA zaczyna realnie wspierać biznes. I właśnie w tym miejscu stary model nadal broni się najlepiej - nie jako relikt, tylko jako uporządkowana mapa, która nadal ułatwia rozmowę o jakości tam, gdzie produkt, użytkownik i ryzyko spotykają się w jednym miejscu.
