Koszyk pokazuje 109,00 zł. Produkt kosztuje 100,00 zł, a dostawa według wymagań jest bezpłatna od stu złotych. Czy to problem ceny, progu dostawy, czy podsumowania? W tej lekcji rozdzielisz te pytania. Nauczysz się sprawdzać stan pozycji, liczyć oczekiwane kwoty niezależnie od aplikacji i odtworzyć błąd dokładnie na granicy reguły.
Materiał jest dla początkujących testerów. Wystarczy obsługa przeglądarki oraz proste mnożenie i dodawanie. Pracujemy na fikcyjnym sklepie v1.0, w którym zmiany koszyka i złożenie zamówienia są lokalną symulacją JavaScript. Nie pobieramy pieniędzy, nie rezerwujemy towaru i nie kontaktujemy się z operatorem płatności. Umiejętnością docelową jest przygotowanie sprawdzalnego scenariusza koszyka, a nie certyfikowanie całego procesu zakupowego.
1. Zacznij od reguł, które da się policzyć
Przeczytaj instrukcję Sklepu DEMO. Produkty mają stałe ceny: Długopis testera 9,00 zł, Notes QA 20,00 zł, Kubek QA 25,00 zł, Karty przypadków 35,00 zł, Torba na testy 45,00 zł, Mata pod mysz 100,00 zł. Ilość każdego produktu musi być całkowita od 1 do 5. Ponowne dodanie tego samego produktu zwiększa ilość w istniejącej pozycji, aż do limitu.
Wartość pozycji to cena jednostkowa pomnożona przez ilość. Suma produktów jest sumą wartości wszystkich pozycji. Do niej dodajemy dostawę: 9,00 zł poniżej 100,00 zł, zero od 100,00 zł włącznie. Pusty koszyk ma dostawę zero. „Razem” oznacza sumę produktów i dostawy. W demo nie ma podatku doliczanego osobno, rabatów ani kodów promocyjnych.
Nie dopisuj takich reguł na podstawie innego sklepu. W rzeczywistym projekcie ustal na przykład, czy próg dostawy jest liczony przed rabatem, czy po rabacie, jakie są ograniczenia ilości i co dzieje się po zmianie ceny w katalogu. Brak odpowiedzi jest luką w wymaganiach. Nie ma uczciwego wyniku „błąd”, jeśli jedyną podstawą jest przyzwyczajenie testera.
Ustal też oczekiwany stan po zamówieniu. W naszym ćwiczeniu panel przechowuje kopię pozycji oraz trzech kwot w groszach, a koszyk staje się pusty. Panel jest dowodem działania kodu tej karty. Nie jest potwierdzeniem trwałego zamówienia na serwerze.
2. Przygotuj niezależny punkt odniesienia
Otwórz lokalny serwer poleceniem node tools/serwer-lekcji.cjs w katalogu projektu. Jeśli działa, skorzystaj z niego. Adres laboratorium:
http://127.0.0.1:8787/content/cwiczenia/sklep-demo/lab.html
Kliknij „Resetuj ćwiczenie”. Zanotuj wersję demo, datę i wersję przeglądarki. Na starcie ma być sześć produktów, puste pole wyszukiwania, wszystkie kategorie i sortowanie nazw. Koszyk jest pusty, wszystkie kwoty wynoszą zero, przycisk zamówienia jest zablokowany. Jeśli pozostał produkt z poprzedniej próby, nie przechodź dalej: najpierw przywróć znany stan.
Do obliczeń użyj groszy: notes to 2000, długopis 900, dostawa 900. Wartość oczekiwana 2000 + 900 + 900 = 3800 oznacza 38,00 zł. Ta forma zmniejsza ryzyko pomylenia separatora dziesiętnego i reguł zaokrąglania. W demo kwoty są małymi liczbami całkowitymi; mieszczą się w bezpiecznym zakresie typu Number. Granice tego zakresu opisuje specyfikacja ECMAScript: Number.MAX_SAFE_INTEGER.
Nie traktuj sposobu reprezentacji groszy jako pełnego projektu systemu finansowego. Przy walutach z inną liczbą miejsc, podatkach i rabatach dochodzą reguły zaokrąglania. Tutaj ich nie badamy. Najważniejsze jest to, że wynik testu liczysz przed obejrzeniem podsumowania aplikacji. Kopiowanie „Razem” do kolumny oczekiwanej daje pozorne potwierdzenie.
Dobrze przygotowana notatka testowa zawiera cenę jednostkową, ilość i wartość każdej pozycji, a następnie oddzielnie sumę produktów i koszt dostawy. Dopisz akcję, która zmieniła stan. Dzięki temu po tygodniu odtworzysz, czy kwota powstała po dodaniu produktu, zmianie ilości czy usunięciu pozycji. Jeśli korzystasz z kalkulatora, zachowaj zapis działania, nie tylko jego wynik. Przy zgłoszeniu dołącz zrzut pokazujący jednocześnie pozycje i podsumowanie; sam wycinek z kwotą nie pozwala ustalić danych wejściowych.
Sprawdzaj każdy poziom obliczenia. Prawidłowa końcowa suma może ukrywać dwie różnice, które się wzajemnie znoszą.
3. Wykonaj bazowy scenariusz zakupu
Dodaj Notes QA i Długopis testera. Sprawdź nazwy, ceny i ilości. Oczekujesz dwóch różnych pozycji z ilością 1. Wartość notesu to 20,00 zł, długopisu 9,00 zł, produkty razem 29,00 zł. Dostawa 9,00 zł daje końcowe 38,00 zł. W aktualnej wersji ten scenariusz przechodzi.
Teraz zmień ilość notesu na 2. Zatwierdź zmianę, opuszczając pole, na przykład klawiszem Tab. Kontrolka reaguje na zdarzenie zmiany; samo wpisanie bez zatwierdzenia nie jest zakończeniem tej akcji. Wartość notesu rośnie do 40,00 zł. Produkty kosztują 49,00 zł, dostawa nadal 9,00 zł, razem 58,00 zł.
Zapisz wynik każdej kwoty osobno. Jeżeli wartość notesu wzrosła, ale „Produkty” pozostało 29,00 zł, masz problem aktualizacji podsumowania. Jeśli oba poziomy zmieniły się prawidłowo, a „Razem” zostało 38,00 zł, zawężasz obserwację do ostatniej kwoty. Takie rozdzielenie daje programiście więcej informacji niż zdanie „koszyk źle liczy”.
Kliknij raz „Złóż zamówienie DEMO”. W panelu ostatniego zamówienia odczytaj subtotal: 4900, shipping: 900, total: 5800. Pozycje powinny obejmować notes w ilości 2 i jeden długopis. Koszyk ma zostać opróżniony, a przycisk zamówienia wyłączony. Suma zerowa w opróżnionym koszyku nie powinna zmieniać kwot zapamiętanych w panelu.
4. Testuj przejścia stanu, nie tylko gotowe koszyki
Koszyk jest funkcją, która zmienia się po akcjach użytkownika. Zbadaj dodanie, zwiększenie, zmniejszenie, usunięcie oraz zamówienie. Zacznij od jednej pozycji, dodaj ją drugi raz, usuń ją i dodaj ponownie. Według naszych reguł dwa dodania dają jedną pozycję z ilością 2. Usunięcie usuwa całą pozycję, a kolejne dodanie zaczyna od 1.
Oddziel limit ilości od dostępności towaru. Demo przyjmuje maksymalnie pięć sztuk każdego produktu, lecz nie ma magazynu. Gdy szósty klik „Dodaj” pozostawia ilość 5, jest to zgodne z zadeklarowaną regułą. Nie oznacza, że sprawdziliśmy ostatnią sztukę lub równoczesną rezerwację w prawdziwym sklepie.
W polu ilości przetestuj 1 i 5, a następnie 0, 6 oraz 1,5. Dwie pierwsze wartości mają być przyjęte. Pozostałe są niedozwolone i powinny zostawić poprzednią ilość oraz kwoty. Jeżeli przeglądarka przyjmuje kropkę jako separator, wpisz 1.5; zapis w raporcie podaj jednoznacznie jako wartość liczbową półtorej sztuki. Sprawdź także pustą kontrolkę i przywrócenie poprawnej liczby.
Usuwanie ostatniej pozycji ma szczególną regułę: dostawa znika wraz z produktami. Doliczanie 9,00 zł do pustego koszyka byłoby osobną niezgodnością. Po każdej próbie wróć do znanego stanu. Reset między niezależnymi scenariuszami pomaga, lecz w obrębie scenariusza nie powinien zasłaniać przejść, których właśnie chcesz się nauczyć.
5. Sprawdź próg darmowej dostawy
Wyrażenie „od 100,00 zł” obejmuje dokładnie 100,00 zł. To inna reguła niż „powyżej 100,00 zł”. Przygotuj trzy klasy wartości: poniżej progu, na progu i powyżej. W demo łatwo osiągniesz próg jedną Matą pod mysz. Wersja wadliwa nalicza dla niej 9,00 zł dostawy.
| Stan produktów | Suma produktów | Oczekiwana dostawa | Wynik demo |
|---|---|---|---|
| Jedna torba | 45,00 zł | 9,00 zł | 9,00 zł |
| Jedna mata | 100,00 zł | 0,00 zł | 9,00 zł — defekt |
| Mata i długopis | 109,00 zł | 0,00 zł | 0,00 zł |
| Usunięty długopis, zostaje mata | 100,00 zł | 0,00 zł | 9,00 zł — defekt |
Ten zestaw pokazuje zarówno granicę, jak i przeliczenie po usunięciu. Z samych wyników możemy stwierdzić: darmowa dostawa nie działa przy dokładnie stu złotych, a działa powyżej. Dopiero inspekcja kodu ćwiczenia potwierdza przyczynę: warunek subtotal > 10000 zamiast subtotal >= 10000.
To celowy defekt S01. W raporcie nie musisz podawać rozwiązania programistycznego. Wystarczą reset, dodanie maty, wymaganie, rzeczywiste trzy kwoty i dowód. Potencjalny skutek to doliczenie nieprzewidzianej opłaty. W produkcie ocenę priorytetu ustala się z zakresem użytkowników i procesu; nasz fikcyjny przykład nie dostarcza takich danych.
6. Oddziel interfejs od trwałego zamówienia
W prawdziwym systemie sprawdzenie ekranów trzeba połączyć z potwierdzeniem, co serwer przyjął. Kwota wyświetlana przed zamówieniem, kwota w żądaniu i kwota zatwierdzona przez backend mogą być różne. Przygotuj przypadki zmiany ceny, wygasłej promocji, niedostępności towaru i ponowienia akcji. Oczekiwane zachowanie uzgodnij z zespołem, zanim testujesz integrację.
W naszym demo Network nie pokaże żądania zamówienia: kod zmienia lokalny obiekt i tekst panelu. Brak żądania jest tutaj cechą ćwiczenia. Nie zgłaszaj go jako awarii prawdziwego checkoutu. Aby przećwiczyć odczytywanie API, skorzystaj z lekcji Network, która ma odrębne lokalne API.
Podobnie szybkie podwójne kliknięcie w tej karcie nie dowodzi odporności na podwójne obciążenie. Pierwsza synchroniczna akcja opróżnia koszyk i wyłącza przycisk. W prawdziwej płatności potrzebujesz dowodu po stronie systemu przetwarzającego zamówienie. Nie wpisuj do raportu „sprawdzono brak duplikatów płatności”, jeśli wykonano wyłącznie lokalny przycisk.
7. Zadanie: opisz błąd i przygotuj retest
Bez zaglądania do kodu odtwórz przypadek dokładnie stu złotych. Przygotuj zgłoszenie z tytułem, wymaganiem, warunkami startowymi, krokami, wynikiem rzeczywistym i oczekiwanym. Potem zaplanuj sprawdzenie po poprawce. Uwzględnij próg osiągnięty na dwa sposoby oraz powrót poniżej niego.
Drugą kombinacją na próg jest pięć notesów: 5 × 20,00 zł = 100,00 zł. Po zmniejszeniu ilości do 4 produkty kosztują 80,00 zł, dostawa 9,00 zł, razem 89,00 zł. To użyteczny test regresji, czyli sprawdzenie, czy naprawa nie zepsuła innego scenariusza. Pozwala także sprawdzić przeliczenie wywołane zmianą ilości, a nie dodawaniem innej pozycji.
Rozwiązanie zgłoszenia może mieć tytuł: „Sklep DEMO v1.0 nalicza dostawę przy sumie produktów dokładnie 100,00 zł”. Kroki: reset, dodanie maty, odczyt podsumowania. Rzeczywiście: produkty 100,00 zł, dostawa 9,00 zł, razem 109,00 zł. Oczekiwane: dostawa 0,00 zł, razem 100,00 zł. Podstawa: reguła darmowej dostawy od 100,00 zł włącznie.
Po poprawce sprawdź torbę, matę, matę z długopisem, pięć notesów, cztery notesy i pusty koszyk. Dodatkowo zamów koszyk na progu i porównaj zapisane kwoty. Nie wystarczy zobaczyć darmowej dostawy na ekranie, jeśli kopia zamówienia nadal przechowuje poprzedni koszt.
8. Dowody, ograniczenia i dalsza praca
Weryfikacja z 2 października 2026: Playwright, Node v24.16.0 i Chromium 151.0.7922.34. Potwierdzono bazowy koszyk 38,00 zł, zmianę na 58,00 zł, odrzucenie ilości 6, kopię lokalnego zamówienia i reset. Odtworzono S01 na 100,00 zł oraz prawidłowe zachowanie powyżej progu. Test uruchamia node tools/test-sklep-pliki.cjs; dowody są zapisane w tmp/qa-sklep-pliki/.
Automatyczna weryfikacja nie obejmuje rzeczywistej płatności, magazynu, podatków, utrwalenia zamówienia ani prób ingerencji w backend. Nie wykonano ręcznych testów czytnikiem ekranu ani na fizycznym telefonie.
Przejdź do checklisty koszyka lub pobierz PDF do zanotowania wyników. Kolejna lekcja wykorzystuje te same dane do wyszukiwania, filtrów i sortowania. Podstawę liczbową zweryfikowano w przywołanej specyfikacji ECMAScript; ceny, dostawa, wyniki i zalecany plan testów są własnym scenariuszem dydaktycznym, nie standardem sklepów internetowych.
Research i tekst z pomocą GPT-6.1 Sol, reasoning medium.
