Lekcja 10 / finał

Finał: mini-audyt checkoutu

To nie jest kolejna mała składnia. Łączysz cały kurs w jedno praktyczne zadanie: sprawdzasz ryzykowne konta, osierocone zamówienia, podejrzane płatności i piszesz notatkę QA.

Sytuacja z pracy

W checkoutcie pojawiły się dziwne objawy: część użytkowników nie może kupić kursu, część zamówień nie pasuje do użytkowników, a przy niektórych płatnościach widać duplikaty. Twoim zadaniem nie jest „naprawić bazę”. Twoim zadaniem jest zebrać fakty i opisać ryzyko.

Tabele w audycie

users
Konta użytkowników: e-mail, status, data utworzenia.

orders
Zamówienia: właściciel, kwota, status.

payments
Płatności: zamówienie, status, operator, kwota.

bug_reports
Zgłoszenia błędów i statusy pracy nad nimi.

Plan audytu

Znajdź ryzykowne albo niekompletne konta.
Znajdź zamówienia bez pasującego użytkownika.
Znajdź zamówienia z więcej niż jedną płatnością.
Napisz notatkę: co wiemy, czego nie wiemy, co zgłaszamy dalej.

Krok 1: ryzykowne konta

SELECT id, email, status
FROM users
WHERE email IS NULL
   OR status IN ('blocked', 'pending');

To zapytanie łączy lekcje o WHERE, NULL i IN. Szukasz kont, które mogą mieć wpływ na logowanie, zakup albo komunikację mailową.

Krok 2: osierocone zamówienia

SELECT
  orders.id,
  orders.user_id,
  orders.amount,
  orders.status
FROM orders
LEFT JOIN users ON orders.user_id = users.id
WHERE users.id IS NULL;

To zapytanie wykorzystuje LEFT JOIN. Szukasz zamówień, które wskazują na użytkownika nieistniejącego w tabeli users.

Krok 3: podejrzane płatności

SELECT order_id, COUNT(*) AS payments_count
FROM payments
GROUP BY order_id
HAVING COUNT(*) > 1;

To zapytanie wykorzystuje raportowanie. Jeśli jedno zamówienie ma więcej niż jedną płatność, nie musi to od razu oznaczać błędu, ale jest to dobry kandydat do sprawdzenia.

Jak wygląda dobra notatka QA?

Co wiemy?
- Są konta bez e-maila albo ze statusem blocked/pending.
- Istnieją zamówienia wskazujące na brakującego użytkownika.
- Część zamówień ma więcej niż jedną płatność.

Czego nie wiemy?
- Nie znamy jeszcze przyczyny powstania tych danych.
- Nie wiemy, czy duplikaty płatności są realnymi obciążeniami, czy próbami płatności.

Co zgłaszamy dalej?
- Sprawdzenie integralności orders.user_id.
- Weryfikację przepływu płatności dla zamówień z payments_count > 1.
- Decyzję, jak obsłużyć konta bez e-maila w checkoutcie.

Jakie jest ryzyko?
- Użytkownik może nie kupić kursu, nie dostać maila albo widzieć niespójny status zamówienia.

Co tu jest najważniejsze?

Dobry QA nie kończy pracy na „zapytanie działa”. Dobry QA umie powiedzieć, jaki fakt wynika z danych, jakiego faktu nadal brakuje i jakie ryzyko produktowe może z tego wynikać.

Mini-zadanie

Wybierz jedno z trzech zapytań i dopisz obok niego: „co wiem po wyniku” oraz „czego nadal nie wiem”.

Ćwiczenie końcowe

Napisz własną notatkę QA dla checkoutu. Użyj czterech nagłówków: Co wiemy?, Czego nie wiemy?, Co zgłaszamy dalej?, Jakie jest ryzyko dla checkoutu?.

Quiz finałowy

Które zapytanie znajduje konta bez e-maila?

Zapytanie z email IS NULL.

Które zapytanie znajduje zamówienia bez użytkownika?

Zapytanie z LEFT JOIN users i WHERE users.id IS NULL.

Które zapytanie znajduje możliwe duplikaty płatności?

Zapytanie z GROUP BY order_id i HAVING COUNT(*) > 1.

Dlaczego wynik SQL nie jest pełną diagnozą?

Bo pokazuje fakty w danych, ale nie zawsze wyjaśnia przyczynę ich powstania.

Co dalej?

Po tym kursie warto ćwiczyć na własnych tabelach: wybierz jeden proces w aplikacji, rozpisz jego tabele i przygotuj trzy pytania SQL, które pomogłyby sprawdzić jakość danych.