Przy projektowaniu testów najłatwiej stracić czas na przypadki, które niczego nowego nie wnoszą, albo odwrotnie - pominąć ważny zakres danych. Jedną z najpraktyczniejszych technik, która pomaga uniknąć obu błędów, jest equivalence partitioning, czyli podział danych na klasy, w których system powinien zachowywać się tak samo. W tym tekście pokazuję, jak znaleźć takie klasy, jak dobrać reprezentantów i kiedy trzeba dołożyć testy graniczne, żeby nie przepuścić błędów na krawędziach zakresu.
To podejście szczególnie dobrze działa przy formularzach, regułach biznesowych i API, gdzie wejścia da się sensownie pogrupować. W praktyce daje mi to szybszy projekt testów, mniejszą liczbę przypadków do utrzymania i lepszą kontrolę nad tym, co naprawdę zostało sprawdzone.
Najważniejsze fakty o testowaniu przez klasy równoważności
- Jedna reprezentatywna wartość z klasy zwykle wystarcza, jeśli reguła jest dobrze opisana.
- Technika najlepiej sprawdza się przy zakresach, limitach, listach dozwolonych wartości i prostych regułach biznesowych.
- Warto zawsze łączyć ją z analizą wartości granicznych, bo same klasy nie pokazują błędów na styku zakresów.
- Każda sensowna klasyfikacja powinna obejmować zarówno dane poprawne, jak i niepoprawne.
- Metoda porządkuje testy, ale nie zastępuje testów kombinatorycznych ani eksploracyjnych tam, gdzie logika jest bardziej złożona.
Na czym polega podział na klasy równoważności
To klasyczna technika testów czarnoskrzynkowych. Zakładam w niej, że jeśli dwa wejścia prowadzą do tego samego zachowania systemu, można traktować je jako część jednej klasy. Zamiast sprawdzać wszystkie możliwe wartości, wybieram po jednym reprezentancie z każdej klasy i oceniam, czy system reaguje zgodnie z wymaganiami.
Najprościej: jeśli dwa przypadki mają dawać ten sam efekt, nie muszę testować ich obu tylko dlatego, że różnią się liczbą, literą albo pozycją na liście. Jeśli pole przyjmuje wiek od 18 do 65 lat, to 24, 31 i 58 należą do tego samego obszaru poprawnych danych. Oczywiście to wciąż założenie, a nie dowód. Jeżeli wymagania są niepełne albo logika ukrywa dodatkowe warunki, jedna próbka nie wykryje wszystkiego.
- Zakresy liczbowe, na przykład limity, progi i przedziały cenowe.
- Listy dozwolonych wartości, na przykład kraj, plan abonamentowy albo typ konta.
- Warunki biznesowe, w których część danych ma przejść, a część ma zostać odrzucona.
- Pola tekstowe z ograniczeniem długości, formatem albo wzorcem.
Najczęściej zaczynam od wejść, ale tę samą logikę da się przenieść także na wyjścia, jeśli system zwraca wyniki, które można sensownie pogrupować. Kiedy mam już taki model w głowie, następny krok to wyznaczenie klas bez zgadywania.
Jak wyznaczyć klasy równoważności krok po kroku
W praktyce nie zaczynam od samej tabelki, tylko od pytania: co dokładnie ma robić system z daną wartością? Dopiero potem rozbijam dane na klasy. Taki porządek oszczędza mi później poprawiania całego zestawu przypadków, gdy wymagania okazują się bardziej szczegółowe niż na pierwszy rzut oka.
- Spisz regułę biznesową i typ danych. Zanim cokolwiek podzielę, muszę wiedzieć, czy testuję liczbę, tekst, datę czy zestaw wartości z listy.
- Rozdziel dane na poprawne i niepoprawne. W praktyce zawsze szukam obu stron, bo klasa błędna jest tak samo ważna jak poprawna.
- Wydziel granice. Jeśli zakres kończy się na 100, to 100 i 101 zwykle nie powinny trafić do tej samej klasy.
- Wybierz reprezentanta z każdej klasy. Najczęściej biorę wartość środkową dla klasy poprawnej i charakterystyczną wartość dla klasy błędnej.
- Sprawdź zależności między polami. Jeżeli jedno pole zmienia sens drugiego, klasy trzeba budować ostrożniej niż w prostym formularzu.
- Dodaj testy graniczne tam, gdzie ryzyko jest największe. Sama klasyfikacja to dobry filtr, ale nie zawsze wystarczy.
W zespole produktowym najwięcej czasu oszczędza mi punkt drugi i trzeci, bo to one wyciągają z wymagań realne granice działania systemu. Żeby to nie zostało na poziomie teorii, pokazuję teraz prosty przykład z aplikacji SaaS.
Przykład na formularzu rejestracji i walidacji pól
Załóżmy, że platforma B2B sprzedaje licencje w trzech planach, a pole liczba licencji przy rejestracji ma przyjmować wartości od 1 do 500. Logika biznesowa wygląda tak:
| Zakres | Rodzaj klasy | Przykładowy test | Oczekiwane zachowanie |
|---|---|---|---|
| 0 i mniej | Niepoprawna | 0 | Komunikat o błędzie |
| 1-25 | Poprawna | 12 | Plan Basic |
| 26-100 | Poprawna | 60 | Plan Team |
| 101-500 | Poprawna | 250 | Plan Enterprise |
| Powyżej 500 | Niepoprawna | 501 | Komunikat o limicie |
W takim układzie nie muszę sprawdzać 2, 3, 4, 5, 6, 7, 8 i 9 tylko dlatego, że mieszczą się w tej samej klasie co 12. Jeżeli 12 przechodzi zgodnie z oczekiwaniem, mam mocne podstawy, by uznać pozostałe wartości z tego przedziału za podobne zachowaniem. To nie zastępuje testów granicznych, ale bardzo dobrze ogranicza liczbę zbędnych przypadków.
Ten sam sposób myślenia działa też dla pól tekstowych i wyborów z listy. Dla pola kraj mogę mieć klasę poprawną, na przykład Polska, oraz klasę błędną, na przykład wartość spoza listy. Dla hasła klasę poprawną wyznaczam po spełnieniu minimalnej długości, a błędną po wszystkim, co tę regułę łamie. Po takim przykładzie naturalnie pojawia się pytanie, gdzie kończy się sens tego podejścia, a zaczyna analiza wartości granicznych.
Kiedy trzeba dołożyć analizę wartości granicznych
Największy błąd, jaki widzę, to traktowanie klas równoważności jak pełnego pokrycia. To nie jest pełne pokrycie. Metoda mówi tylko tyle, że wartości wewnątrz klasy powinny zachowywać się podobnie. Nie mówi nic o tym, czy system poprawnie obsługuje przejście z jednej klasy do drugiej.
| Metoda | Co sprawdza | Najlepsze zastosowanie | Czego może nie zauważyć |
|---|---|---|---|
| Klasy równoważności | Reprezentantów całych grup danych | Walidacja wejść, reguły biznesowe, formularze | Błędy ukryte tuż przy granicy |
| Analiza wartości granicznych | Punkty na styku zakresów | Limity, progi, zakresy liczbowe, daty | Różnice wewnątrz klasy |
Jeśli reguła brzmi „od 1 do 100”, to największe ryzyko zwykle siedzi przy 0, 1, 100 i 101. Właśnie tam najczęściej wychodzą błędy typu >= zamiast >, zła interpretacja zakresu albo niekonsekwentna walidacja po stronie frontu i backendu. Z mojego doświadczenia najlepszy zestaw testów powstaje wtedy, gdy klasy i granice są projektowane razem, a nie jedna po drugiej w oderwaniu.
Gdy to już mam, przechodzę do najczęstszych pułapek, bo to one najczęściej obniżają skuteczność całej techniki.
Najczęstsze błędy, które psują sens tej techniki
- Zbyt szerokie klasy - jeśli w jednym worku lądują wartości, które faktycznie wywołują różne zachowania, reprezentant niewiele wnosi.
- Testowanie tylko poprawnych danych - klasa niepoprawna jest potrzebna równie mocno, bo to ona sprawdza walidację i komunikaty błędów.
- Ignorowanie zależności między polami - dwa niezależne wejścia to co innego niż dwa pola, które wspólnie decydują o wyniku.
- Wybór „wygodnej” wartości zamiast reprezentatywnej - liczba 1 bywa łatwa do wpisania, ale nie zawsze dobrze reprezentuje klasę poprawną.
- Brak aktualizacji po zmianie wymagań - jeśli biznes zmieni limit z 100 na 120, stare klasy przestają być poprawne.
- Mylenie metody z gwarancją jakości - to narzędzie do ograniczania liczby testów, a nie dowód, że problemów już nie ma.
Najbardziej kosztowny błąd widzę zwykle tam, gdzie zespół zatrzymuje się na jednej klasie poprawnej i jednej błędnej, choć reguła ma kilka wyraźnie różnych progów. Jeśli w systemie istnieją osobne ścieżki dla 25, 100 i 500, to każda z nich zasługuje na własne sprawdzenie. Z tego miejsca łatwo przejść do pytania praktycznego: kiedy ta technika naprawdę daje największy zwrot.
Kiedy ta metoda daje największy zwrot w zespole produktowym
Najwięcej korzyści widzę w miejscach, gdzie dane wejściowe da się jasno pogrupować, a błędy walidacji mają realny koszt. Chodzi przede wszystkim o formularze rejestracyjne, panele administracyjne, importy plików, endpointy API, kalkulatory cen i reguły uprawnień. W takich obszarach klasy równoważności szybko porządkują chaos wymagań i skracają czas przygotowania testów.
W automatyzacji ta technika też ma sens, ale pod jednym warunkiem: klasy muszą być opisane czytelnie i łatwe do utrzymania. Jeśli testy są rozrzucone po wielu plikach, a granice ukryte w stałych, potem trudno je aktualizować po zmianie wymagań. Dlatego ja zwykle zapisuję klasy wprost w nazwach przypadków albo w tabeli testowej, żeby każdy w zespole wiedział, dlaczego dany reprezentant został wybrany.
Nie używałbym jej jednak jako jedynej metody dla logiki z wieloma zależnościami kombinatorycznymi. Gdy wynik zależy od kilku pól naraz, do gry wchodzą też inne techniki, na przykład testowanie tabel decyzji albo parowanie kombinacji. Klasy równoważności są świetnym filtrem startowym, ale nie zamieniają się w pełną strategię dla całego systemu.
Jeśli mam wybrać jedno podejście na początek, najpierw rozbijam dane na klasy, potem dokładam granice, a dopiero później sprawdzam zależności między polami. To daje mi szybki zysk przy rozsądnym nakładzie pracy i zwykle wystarcza, żeby odsiać większość zbędnych przypadków bez utraty ważnych scenariuszy.
