Czym jest jakość oprogramowania w praktyce

Jakość. Wszyscy jej chcą. Mało kto potrafi ją zdefiniować. A niemal nikt nie zgadza się, kto za nią odpowiada.

Kiedy zapytasz programistę, co oznacza “jakościowe oprogramowanie”, odpowie: “działa i nie ma bugów.” Zapytaj interesariusza biznesowego — powie: “spełnia potrzeby użytkowników.” Zapytaj inżyniera QA i — jeśli jest uczciwy — chwilę pomilczy, zanim odpowie.

Ta chwila milczenia jest ważna. Oznacza, że naprawdę się nad tym zastanowił.

W tym artykule chcę dać Ci roboczą definicję jakości oprogramowania, którą możesz stosować w codziennych rozmowach, na planowaniu sprintu i podczas przeglądu architektury — nie tylko w teorii, ale w praktyce.

Dwa spojrzenia na jakość

Istnieją dwa klasyczne podejścia do definiowania jakości — oba wywodzą się z inżynierii przemysłowej i zaskakująco dobrze przekładają się na świat oprogramowania.

Zgodność z wymaganiami (Philip Crosby): Jakość oznacza robienie dokładnie tego, co zostało określone w specyfikacji. Jeśli spec mówi, że przycisk ma być niebieski, niebieski przycisk to jakość. Czerwony to defekt.

Przydatność do celu (Joseph Juran): Jakość oznacza, że produkt robi to, czego użytkownik naprawdę potrzebuje. Spec może mówić “niebieski przycisk”, ale jeśli użytkownicy go nie mogą znaleźć, bo zlewa się z tłem, jakość jest niska — mimo że spec jest spełniona.

Oba podejścia są ważne. Widziałem systemy produkcyjne, które były technicznie poprawne — każdy test przechodził, każde wymaganie było spełnione — ale prawdziwi użytkownicy uznawali je za bolesne, mylące lub zawodne. I widziałem systemy budowane na intuicji, które były pełne nieudokumentowanych, ale krytycznych zachowań.

Profesjonalne podejście łączy oba: jakość to przydatność do celu w ramach uzgodnionych ograniczeń.

Model jakości ISO/IEC 25010

Jeśli potrzebujesz bardziej ustrukturyzowanego modelu, norma ISO/IEC 25010 definiuje osiem głównych charakterystyk jakości:

1. Odpowiedniość funkcjonalna — czy robi to, co ma robić?
2. Wydajność — czy odpowiada wystarczająco szybko, przy rozsądnym zużyciu zasobów?
3. Kompatybilność — czy współpracuje z innymi systemami?
4. Użyteczność — czy użytkownicy mogą faktycznie z niego korzystać?
5. Niezawodność — czy działa konsekwentnie przez długi czas?
6. Bezpieczeństwo — czy chroni dane i odpiera ataki?
7. Pielęgnowalność — czy programiści mogą wprowadzać zmiany bez psucia innych części?
8. Przenośność — czy może działać w różnych środowiskach?

Większość zespołów skupia się na punkcie 1 i czasem na punkcie 2. Reszta to “wymagania niefunkcjonalne” — co w praktyce znaczy: “wiemy, że powinniśmy się tym zajmować, ale nie mamy na to ticketów.”

Atrybuty funkcjonalne vs niefunkcjonalne

Rozróżnienie między funkcjonalnymi i niefunkcjonalnymi aspektami jakości jest jednym z najbardziej niezrozumianych zagadnień w inżynierii oprogramowania.

Atrybuty funkcjonalne odpowiadają na pytanie: czy robi właściwą rzecz?

• Poprawność — wyniki są dokładne dla prawidłowych danych wejściowych
• Kompletność — wszystkie wymagane funkcje są obecne
• Stosowność — funkcje faktycznie odpowiadają zamierzonemu zastosowaniu

Atrybuty niefunkcjonalne odpowiadają na pytanie: czy robi tę rzecz właściwie?

• Wydajność — przy jakim obciążeniu, w jakim czasie odpowiedzi?
• Bezpieczeństwo — jakie wektory ataku są zablokowane?
• Użyteczność — czy przeciętny użytkownik potrafi osiągnąć cel bez pomocy?
• Pielęgnowalność — ile czasu zajmuje dodanie nowej funkcji bez regresji?
• Niezawodność — jaki jest dopuszczalny czas przestoju?

Wzorzec, który obserwuję bez przerwy: wymagania niefunkcjonalne rzadko są zapisywane na początku projektu. Pojawiają się jako skargi w środowisku produkcyjnym. “Strona jest za wolna.” “Logowanie jest mylące.” “Nowy programista potrzebuje trzech tygodni, żeby zrozumieć kod.”

Rozwiązanie wymaga dyscypliny: pisz scenariusze jakości przed napisaniem kodu.

Zamiast “API powinno być szybkie” napisz: “Endpoint /orders zwraca wyniki w czasie poniżej 200ms przy P99 przy 1000 jednoczesnych użytkownikach.” To jest testowalne. To może stać się quality gate. To jest inżynieria.

Koszt błędu — dlaczego shift-left ma znaczenie

Znane badania wskazują, że błąd znaleziony w środowisku produkcyjnym może kosztować wielokrotnie więcej niż ten sam błąd wykryty podczas analizy wymagań. Dokładny mnożnik zależy od projektu, ale kierunek jest niezmiennie taki sam:

Faza:          Wymagania → Projekt → Implementacja → Testowanie → Produkcja
Względny koszt:    1×        5×          10×             25×         100×

Dlaczego taka różnica? Bo naprawienie błędu w produkcji oznacza:

• Klient go zgłosił (utrata wiarygodności)
• Programista musi zmienić kontekst i zrozumieć stary kod
• Hotfix musi przejść przez cały pipeline wdrożeniowy
• Odbywa się spotkanie post-mortem
• Trzeba dodać test regresyjny, żeby nie powtórzyło się to samo

Ten sam błąd logiczny wykryty podczas przeglądu projektu zajmuje 15 minut do naprawienia przy tablicy.

Shift-left nie oznacza “pisz więcej testów wcześniej.” Oznacza: angażuj myślenie o jakości wcześniej. Przeglądaj wymagania pod kątem niejednoznaczności. Weryfikuj kontrakty API podczas projektowania. Pisz kryteria akceptacji przed rozpoczęciem prac w sprincie.

To jest różnica między sprawdzaniem jakości a budowaniem jej.

Rola QA a jakość całego zespołu

Oto niewygodna prawda: inżynierowie QA nie mogą zagwarantować jakości.

Mogą znajdować defekty. Mogą zmniejszać ryzyko. Mogą wskazywać luki. Ale jeśli defekty są wprowadzane szybciej, niż można je znaleźć, pipeline przecieka — niezależnie od umiejętności zespołu QA.

Nowoczesny model rozkłada odpowiedzialność za jakość na cały zespół:

Rola	Odpowiedzialność za jakość
Programista	Testy jednostkowe, code review, TDD, czysty kod
Product Owner	Jasne kryteria akceptacji, example mapping
DevOps / Platform	Quality gates w CI/CD, parytety środowisk
Inżynier QA	Strategia testowania, analiza ryzyka, exploratory testing, coaching
Architekt	Testowalność, obserwowalność, izolacja błędów

Nowoczesna rola QA jest bliższa coachowi jakości niż strażnikowi. Pytają “Co może pójść nie tak z tym podejściem?” zanim sprint się zacznie. Nie czekają, żeby się przekonać.

Przykład z życia wzięty

Pewien zespół zbudował funkcję checkout w sklepie e-commerce. Każdy test jednostkowy przechodził. Każdy test integracyjny przechodził. Checklistę testów manualnych uzupełniono. Funkcja wyszła na produkcję.

Trzy dni później dział obsługi klienta otrzymał dziesiątki zgłoszeń: na iOS 15 z pewnymi dostawcami płatności przycisk “Potwierdź zamówienie” przestawał reagować po pierwszym tapnięciu.

Co się stało?

Atrybut jakości	Status
Poprawność funkcjonalna	✅ Przycisk wysyłał zamówienie
Wydajność	✅ Czas odpowiedzi poniżej 200ms
Kompatybilność	❌ Nie testowano na dotkniętej kombinacji iOS + płatność
Użyteczność	❌ Brak wizualnego feedbacku → użytkownicy tapowali ponownie → podwójne zamówienia

Oba błędy były niefunkcjonalne. Żaden nie pojawił się w żadnym tickecie. Żaden nie był częścią żadnej definicji ukończenia.

Podsumowanie — jakość to kultura, nie checklist

Nie możesz przetestować jakości do systemu. Musisz ją do niego wbudować.

Każdy zespół ma kulturę jakości — albo świadomą, albo przypadkową. Ta przypadkowa produkuje “przeszło przez QA” jako wymówkę i “nie mieliśmy czasu testować” jako wyjaśnienie incydentów.

Ta świadoma zaczyna się od wspólnych definicji: Co jakość oznacza dla waszego produktu? Które atrybuty jakości są najważniejsze? Kto odpowiada za każdy z nich?

Jedna rzecz, którą możesz zrobić w tym tygodniu: Na następnym planowaniu sprintu zapytaj: “Jakie niefunkcjonalne atrybuty jakości powinniśmy wziąć pod uwagę przy tej funkcji?” Jakość rozmowy, która nastąpi, powie Ci więcej o kulturze jakości Twojego zespołu niż jakikolwiek raport z testów.

---

To jest pierwszy artykuł z serii Seria 1 — QA Ogólne — praktyczne wprowadzenie do inżynierii jakości dla programistów i specjalistów QA.