Gdy zespół mówi, że aplikacja ma być „wysokiej jakości”, szybko okazuje się, że każdy rozumie to inaczej. Model ISO 25010 porządkuje tę rozmowę i pokazuje, jak oceniać nie tylko funkcje, lecz także wydajność, bezpieczeństwo, niezawodność, łatwość utrzymania czy możliwość rozwoju produktu. Poniżej wyjaśniam, jak wykorzystać go w procesach QA, projektować mierzalne wymagania i unikać typowych błędów.
Model jakości, który zamienia ogólne oczekiwania w konkretne kryteria
- 9 charakterystyk jakości obejmuje aktualna edycja ISO/IEC 25010:2023.
- Standard pomaga tworzyć wymagania niefunkcjonalne, scenariusze testowe i kryteria akceptacji.
- Nie jest to norma certyfikacyjna ani gotowy plan testów, lecz rama do podejmowania decyzji.
- Największą wartość daje przełożenie cech na mierzalne wskaźniki, takie jak czas odpowiedzi, dostępność lub odsetek błędów.
- Wersja z 2023 roku dodała między innymi bezpieczeństwo operacyjne, skalowalność i odporność.
Co właściwie definiuje ISO/IEC 25010
ISO/IEC 25010 należy do rodziny SQuaRE, czyli standardów dotyczących wymagań jakościowych i oceny systemów oraz oprogramowania. Najnowsza edycja została opublikowana w listopadzie 2023 roku i opisuje model jakości produktu informatycznego. Może być stosowana nie tylko do aplikacji, lecz także do szerszych produktów ICT, obejmujących między innymi sprzęt, dane i infrastrukturę komunikacyjną.
Najważniejsza idea jest prosta. Jakość nie oznacza wyłącznie braku błędów. Produkt może działać zgodnie z wymaganiami, a jednocześnie być powolny, trudny w obsłudze albo niemożliwy do bezpiecznego rozwijania. Model daje zespołom wspólny język do opisu tych różnic.
W praktyce QA traktuję ten standard jako mapę pytań. Czy system realizuje właściwe funkcje? Czy działa wystarczająco szybko przy obciążeniu? Czy można go łatwo zmienić, wdrożyć w innym środowisku i odzyskać po awarii? Takie pytania są znacznie bardziej użyteczne niż ogólne stwierdzenie, że „aplikacja powinna być stabilna”.
Model produktu a jakość użytkowania
Warto rozróżnić dwie rzeczy. Edycja z 2023 roku koncentruje się na jakości produktu, czyli właściwościach samego systemu lub oprogramowania. Osobny standard ISO/IEC 25019:2023 opisuje jakość w użyciu, a więc między innymi skuteczność, efektywność, satysfakcję i wpływ warunków użytkowania.
To rozdzielenie ma znaczenie dla testów. Wynik testu obciążeniowego mówi, jak system zachowuje się technicznie, ale nie odpowiada jeszcze na pytanie, czy użytkownik rzeczywiście osiąga cel bez zbędnego wysiłku. Dobre QA łączy oba spojrzenia, zamiast traktować metryki techniczne jako pełny obraz jakości.
Dziewięć obszarów jakości w aktualnym modelu
Wersja 2023 obejmuje dziewięć głównych charakterystyk. Każda z nich dzieli się na podcharakterystyki, które ułatwiają przełożenie ogólnej idei na wymagania, testy i pomiary.
| Charakterystyka | Podcharakterystyki | Przykład w QA |
|---|---|---|
| Przydatność funkcjonalna | Kompletność, poprawność i adekwatność funkcjonalna | Weryfikacja, czy funkcje realizują wymagane procesy biznesowe i zwracają poprawne wyniki. |
| Efektywność działania | Zachowanie czasowe, wykorzystanie zasobów i pojemność | Testy wydajnościowe, limity czasu odpowiedzi, zużycie CPU oraz obsługiwana liczba użytkowników. |
| Kompatybilność | Współistnienie i interoperacyjność | Sprawdzenie współpracy z przeglądarkami, systemami, API i innymi aplikacjami. |
| Zdolność do interakcji | Rozpoznawalność adekwatności, łatwość uczenia, operacyjność, ochrona przed błędami, zaangażowanie, inkluzywność, pomoc użytkownika i samoopisowość | Testy użyteczności, dostępności, nawigacji oraz reakcji interfejsu na błędne działania. |
| Niezawodność | Bezbłędność, dostępność, tolerancja błędów i odtwarzalność | Monitorowanie awarii, testy failover, odtwarzanie kopii i sprawdzanie działania po błędach. |
| Bezpieczeństwo | Poufność, integralność, niezaprzeczalność, rozliczalność, autentyczność i odporność | Testy kontroli dostępu, szyfrowania, logowania zdarzeń i odporności na ataki. |
| Utrzymywalność | Modułowość, ponowne użycie, analizowalność, modyfikowalność i testowalność | Przeglądy architektury, analiza kodu, czas wprowadzania zmian i łatwość automatyzacji testów. |
| Elastyczność | Adaptowalność, skalowalność, instalowalność i zastępowalność | Testowanie wdrożeń w różnych środowiskach, wzrostu obciążenia oraz wymiany komponentów. |
| Bezpieczeństwo operacyjne | Ograniczenia operacyjne, identyfikacja ryzyka, bezpieczny stan awaryjny, ostrzeganie o zagrożeniach i bezpieczna integracja | Analiza ryzyka oraz testy systemów, których awaria może zagrozić ludziom, mieniu lub środowisku. |
Największa zmiana względem edycji z 2011 roku polega na dodaniu bezpieczeństwa operacyjnego jako osobnej charakterystyki. Zmieniono także nazwy i zakresy kilku obszarów. „Użyteczność” zastąpiła zdolność do interakcji, „przenośność” została zastąpiona elastycznością, a między nowymi lub rozszerzonymi podcharakterystykami znalazły się skalowalność, inkluzywność, samoopisowość i odporność.
Nie radzę jednak odhaczać wszystkich punktów z równą intensywnością. System płatności, aplikacja medyczna i wewnętrzny panel raportowy mają inne profile ryzyka. Wybór priorytetów powinien wynikać z domeny, użytkowników, danych, wymagań prawnych i konsekwencji awarii.
Jak przełożyć model na proces QA
Sam dokument nie stworzy dobrej jakości. Jego rolą jest pomóc zespołowi podjąć trafne decyzje jeszcze przed rozpoczęciem testów. Najlepiej włączyć go do procesu już podczas analizy wymagań, a nie dopiero przed wydaniem produktu.
1. Zdefiniuj profil jakości produktu
Najpierw wybierz charakterystyki istotne dla konkretnego systemu. Dla aplikacji bankowej wysoko ustawisz bezpieczeństwo, niezawodność i przydatność funkcjonalną. Dla platformy e-commerce równie ważne będą efektywność działania, zdolność do interakcji i skalowalność podczas kampanii sprzedażowych.
Dobrym rozwiązaniem jest krótki warsztat z udziałem produktu, biznesu, architektów, programistów i QA. Każdy obszar można ocenić na przykład w skali od 1 do 5, a potem uzasadnić, dlaczego otrzymał daną wagę. Sama liczba nie jest dowodem jakości, ale pomaga ujawnić rozbieżności w oczekiwaniach.
2. Zamień ogólne hasła na wymagania mierzalne
Zdanie „system ma być szybki” nie nadaje się do obiektywnej oceny. Lepsze wymaganie brzmi: „95% żądań wyszukiwania ma kończyć się w czasie do 800 ms przy 500 jednoczesnych użytkownikach”. Wtedy QA wie, co zmierzyć, w jakich warunkach i z jakim wynikiem.
Podobnie można opisać dostępność, bezpieczeństwo czy odzyskiwanie po awarii. Przykładowo system może wymagać dostępności na poziomie 99,9% w miesiącu, zdefiniowanego czasu RTO wynoszącego 60 minut oraz odtworzenia danych do punktu nie starszego niż 15 minut, czyli RPO na poziomie 15 minut.
3. Dopasuj techniki testowe
Każda charakterystyka wymaga nieco innego podejścia. Testy funkcjonalne nie wystarczą do oceny wydajności, a skan bezpieczeństwa nie pokaże, czy użytkownik rozumie komunikaty w interfejsie. W praktyce tworzę macierz, która łączy obszar jakości z wymaganiem, ryzykiem, techniką testową i właścicielem wyniku.
- Efektywność działania sprawdzają testy obciążeniowe, wydajnościowe i analiza zużycia zasobów.
- Niezawodność obejmuje testy odporności na awarie, restartów, odtwarzania i długotrwałego działania.
- Bezpieczeństwo wymaga między innymi testów penetracyjnych, kontroli uprawnień i weryfikacji logów.
- Zdolność do interakcji ocenia się przez testy użyteczności, dostępności i obserwację zachowań użytkowników.
- Utrzymywalność można analizować przez przeglądy kodu, metryki złożoności, czas naprawy i pokrycie testami.
4. Ustal kryteria wejścia i wyjścia
Model dobrze sprawdza się jako podstawa kryteriów akceptacji wydania. Produkt nie musi osiągnąć idealnego wyniku w każdej kategorii, ale wyjątki powinny być świadome i udokumentowane. Jeżeli aplikacja spełnia funkcje, lecz nie przechodzi testu bezpieczeństwa o wysokim ryzyku, decyzja o wdrożeniu powinna wymagać wyraźnej akceptacji właściciela ryzyka.
W zespołach pracujących zwinnie charakterystyki można wpisać do Definition of Done, kryteriów akceptacji i backlogu jakościowego. Dzięki temu QA nie staje się końcową bramką, lecz częścią codziennego projektowania produktu.
Jak mierzyć jakość bez tworzenia pozorów kontroli
Najczęstszy problem nie polega na braku metryk, lecz na wyborze takich, które łatwo raportować, ale trudno interpretować. Sam procent pokrycia kodu testami nie mówi, czy najważniejsze ryzyka zostały sprawdzone. Podobnie liczba znalezionych błędów może rosnąć dlatego, że testy są lepsze, a nie dlatego, że produkt stał się gorszy.
| Obszar | Przykładowy wskaźnik | Na co uważać |
|---|---|---|
| Wydajność | Mediana i percentyl p95 czasu odpowiedzi, przepustowość, zużycie CPU | Średnia może ukrywać problemy odczuwalne przez najwolniejszych użytkowników. |
| Niezawodność | Dostępność, MTTR, liczba awarii, odsetek nieudanych operacji | Dostępność bez analizy skutków awarii nie pokazuje pełnego ryzyka. |
| Bezpieczeństwo | Liczba podatności według krytyczności, czas ich usunięcia, skuteczność kontroli dostępu | Brak wykrytej podatności nie oznacza braku podatności. |
| Interakcja | Czas wykonania zadania, odsetek błędów użytkownika, skuteczność i satysfakcja | Opinie zespołu nie zastępują testów z reprezentatywnymi użytkownikami. |
| Utrzymywalność | Czas wdrożenia zmiany, czas diagnozy, liczba regresji i koszt naprawy | Metryki kodu są sygnałem, a nie bezpośrednim pomiarem kosztu utrzymania. |
Warto mierzyć także trend w czasie. Jednorazowy wynik testu jest migawką, natomiast porównanie kolejnych wydań pokazuje, czy produkt rzeczywiście dojrzewa. Dla systemu produkcyjnego dołożyłbym dane z monitoringu, obsługi incydentów i opinii użytkowników, bo jakość ujawnia się również po wdrożeniu.
W przypadku systemów wykorzystujących sztuczną inteligencję model pozostaje użytecznym punktem wyjścia, ale nie wyczerpuje tematu. Trzeba dodatkowo ustalić sposób oceny jakości danych, stabilności wyników, wyjaśnialności i odporności na manipulację. Nie traktowałbym więc zgodności z modelem jako dowodu, że system AI jest bezpieczny lub godny zaufania.
Co zespoły QA najczęściej robią źle
Traktowanie standardu jak listy kontrolnej
Odznaczenie dziewięciu charakterystyk nie oznacza, że produkt jest dobrej jakości. Lista pomaga odkryć obszary do analizy, ale dopiero wymagania, testy i dowody pomiarowe nadają jej sens. W małym projekcie pełna dokumentacja każdego podpunktu może kosztować więcej, niż realnie zyskujemy.
Mylenie jakości produktu z certyfikacją
ISO/IEC 25010 opisuje model jakości, a nie procedurę uzyskania certyfikatu dla aplikacji. Firma może używać go wewnętrznie do planowania QA, zakupów i odbioru systemu, bez deklarowania formalnej certyfikacji. To ważne rozróżnienie, szczególnie podczas rozmów z klientem lub dostawcą.
Używanie starej terminologii bez wyjaśnienia
W materiałach branżowych nadal często pojawiają się osiem charakterystyk i nazwy znane z edycji 2011. Nie jest to automatycznie błąd, jeśli projekt świadomie korzysta ze starszego modelu, ale dokumentacja powinna wskazywać, z której edycji korzysta zespół. Mieszanie definicji utrudnia porównywanie wyników i prowadzi do nieporozumień.
Próba maksymalizacji wszystkiego naraz
Nie da się jednocześnie zwiększać bezpieczeństwa, szybkości, elastyczności i wygody bez żadnych kompromisów. Szybsze szyfrowanie, bardziej szczegółowe logowanie albo dodatkowe walidacje mogą wpływać na wydajność i wygodę. Dlatego profil jakości powinien pokazywać priorytety oraz świadome kompromisy, a nie obiecywać perfekcję w każdym obszarze.
Przeczytaj również: Ocena jakościowa w QA - Czy liczby to wszystko?
Odkładanie jakości na koniec projektu
Jeżeli wymaganie dotyczące skalowalności pojawia się dopiero przed premierą, zespół może nie mieć już możliwości zmiany architektury. Tak samo testowalność i bezpieczeństwo są w dużej mierze decyzjami projektowymi. Najlepszy moment na użycie modelu to analiza i projektowanie, zanim koszt korekty gwałtownie wzrośnie.
Jak zacząć bez rozbudowanej biurokracji
Na początek wystarczy jednostronicowy profil jakości. Wybierz trzy do pięciu najważniejszych charakterystyk, opisz dla każdej po jednym ryzyku, jednym wymaganiu mierzalnym i jednej metodzie weryfikacji. Taki dokument daje zespołowi więcej niż kilkudziesięciostronicowa procedura, której nikt nie aktualizuje.
Przykładowy profil dla platformy sprzedażowej może obejmować: czas odpowiedzi p95 poniżej 1 sekundy, dostępność na poziomie 99,9%, brak podatności krytycznych przed wydaniem, obsługę określonej liczby transakcji na minutę oraz możliwość odtworzenia usługi w ciągu godziny. Każdy punkt ma wtedy właściciela, test i warunek akceptacji.
W mojej ocenie największą wartość daje połączenie modelu z zarządzaniem ryzykiem. ISO/IEC 25010 nie powinno zastępować zdrowego rozsądku ani wiedzy domenowej. Powinno pomóc zespołowi zobaczyć, gdzie jakość naprawdę ma znaczenie, jak ją sprawdzić i kiedy wynik jest wystarczający dla konkretnego produktu.
Od modelu jakości do decyzji o wydaniu
ISO/IEC 25010 najlepiej działa jako wspólna rama rozmowy między biznesem, projektantami, programistami i QA. Porządkuje wymagania, ułatwia dobór testów i pokazuje, że jakość obejmuje znacznie więcej niż poprawne działanie funkcji.
Najrozsądniejszy pierwszy krok to wybranie kilku charakterystyk o największym wpływie na użytkowników i ryzyko biznesowe, a potem zapisanie ich w postaci konkretnych, mierzalnych kryteriów. Dzięki temu standard przestaje być teorią, a zaczyna wspierać codzienne decyzje dotyczące architektury, testów i publikowania kolejnych wersji.
