Dlaczego w ogóle mówimy o ISTQB?
Testowanie oprogramowania w systemach ERP nie jest już „klikalnym sprawdzaniem, czy wszystko działa”. To pełnoprawna dziedzina wiedzy, w której funkcjonują międzynarodowe standardy i certyfikacje. Najważniejszą organizacją w tym obszarze jest ISTQB® (International Software Testing Qualifications Board), działająca od 2002 roku i zrzeszająca testerów z ponad 130 krajów.
Podstawowym certyfikatem jest CTFL (Certified Tester Foundation Level), który wprowadza w kluczowe pojęcia testowania, techniki projektowania przypadków testowych oraz – co dla nas istotne – 7 zasad testowania oprogramowania. To zbiór praktyk, które są neutralne technologicznie i mogą być stosowane zarówno w testach aplikacji mobilnych, systemów bankowych, jak i ERP.
W kontekście biznesowym przydają się również powiązane podejścia:
- ATDD (Acceptance Test-Driven Development) – tworzenie testów akceptacyjnych zanim powstanie konfiguracja czy kod. Dzięki temu wiemy, że rezultat spełnia oczekiwania biznesowe, a nie tylko techniczne.
- BDD (Behavior Driven Development) – opisywanie wymagań i testów w języku Given–When–Then, zrozumiałym dla biznesu i IT.
Dlaczego to ważne dla ERP? Bo w systemach finansowo-księgowych, kadrowo-płacowych czy logistycznych błędy mają bezpośrednie przełożenie na wynik finansowy, zgodność z prawem i satysfakcję klientów. Wdrożenie zasad ISTQB w codziennych testach ERP pozwala ograniczyć ryzyko, oszczędzić czas i pieniądze.
1. Testowanie ujawnia defekty, nie dowodzi ich braku
Zasada ISTQB : testy mogą pokazać, że coś nie działa, ale nigdy nie udowodnią, że system jest wolny od błędów.
W ERP : w Kadrach i Płacach test sprawdzający naliczenie wynagrodzenia może wykazać błąd w zasiłkach chorobowych, ale brak błędów w tym scenariuszu nie znaczy, że lista płac zawsze będzie poprawna.
Wniosek : definiuj testy krytycznych scenariuszy biznesowych, akceptując, że testowanie minimalizuje ryzyko, ale go nie eliminuje.
2. Testowanie wyczerpujące jest niemożliwe
Zasada ISTQB : nie da się przetestować wszystkich kombinacji danych. Trzeba priorytetyzować.
W ERP : nie sprawdzisz każdej kombinacji urlopów, nadgodzin i premii. Zastosuj tabele decyzyjne dla najczęstszych i najbardziej ryzykownych scenariuszy oraz wartości brzegowe (np. płaca minimalna, maksymalny limit nadgodzin).
Wniosek : skup się na tym, co najbardziej wpływa na finanse i zgodność z prawem.
3. Wczesne testowanie oszczędza czas i pieniądze
Zasada ISTQB : im wcześniej znajdziesz błąd, tym tańsza jego naprawa.
W ERP : zanim programista wdroży nową funkcję raportu finansowego, użytkownicy biznesowi mogą przygotować przykładowe zestawienia i sprawdzić ich zgodność z potrzebami. To prosty przykład ATDD – test akceptacyjny powstaje jeszcze przed implementacją.
Wniosek : angażuj użytkowników i analityków w testy już na etapie projektowania.
4. Defekty grupują się w klastrach
Zasada ISTQB : większość błędów występuje w niewielkiej liczbie modułów.
W ERP : typowe „gorące punkty” to integracje (banki, KSeF), migracje danych czy złożone workflow.
Wniosek : prowadź statystyki defektów – jeśli 70% błędów pojawia się w Kadrach i Płacach, w kolejnych aktualizacjach zwiększ tam zakres testów.
5. Testy tracą skuteczność, jeśli są powtarzane w niezmienionej formie
Zasada ISTQB (efekt pestycydów) : powtarzanie wciąż tych samych testów przestaje wykrywać nowe błędy.
W ERP : jeśli zawsze testujesz tylko standardową listę płac, nie odkryjesz błędów w nietypowych przypadkach (np. łączenie kilku etatów czy urlop wychowawczy).
Wniosek : rotuj dane testowe i dodawaj nowe scenariusze w miarę pojawiania się błędów i zmian prawa.
6. Testowanie zależy od kontekstu
Zasada ISTQB : nie ma uniwersalnego podejścia – inaczej testuje się system medyczny, inaczej aplikację mobilną.
W ERP :
- aktualizacja wersji enova365 → testy regresji i zgodności prawnej,
- nowa integracja bankowa → testy kontraktów i wydajności,
- zmiany w Kadrach i Płacach → testy obliczeniowe i wartości brzegowe.
Wniosek : dopasuj metodę do rodzaju zmiany.
7.Brak błędów ≠ sukces biznesowy
Zasada ISTQB : system może być technicznie poprawny, a mimo to nie spełniać potrzeb biznesu.
W ERP : raport sprzedaży może działać, ale jeśli nie wspiera podejmowania decyzji (np. brak kluczowych wskaźników), nie wnosi wartości.
Wniosek : testy muszą obejmować walidację – czyli sprawdzanie, czy system realizuje cele biznesowe, a nie tylko czy spełnia wymagania.
Jak wdrożyć zasady ISTQB w praktyce ERP
1. Plan oparty na ryzyku – priorytetyzuj moduły i funkcje kluczowe dla firmy (płace, podatki, cash-flow).
2. Techniki testowe – stosuj tabele decyzyjne, wartości brzegowe, diagramy stanów.
3. Regresja i automatyzacja – buduj zestaw przypadków uruchamiany po każdej aktualizacji; automatyzuj stabilne scenariusze (np. importy bankowe).
4. Dane testowe – używaj anonimizowanych kopii produkcyjnych oraz danych syntetycznych (zgodnie z RODO).
5. Kryteria akceptacji – opisuj testy w formie Given–When–Then, zrozumiałej dla biznesu i IT.
6. Metryki – mierz pokrycie testami, liczbę defektów na moduł, czas wykonania regresji.
7. Ciągłe doskonalenie – aktualizuj scenariusze po każdej zmianie i po każdej retrospektywie.
autor artykułu: Tomasz Mierzejewski
