Lekcja 1 / fundament
Po co QA-owi SQL i czym jest baza danych
Zanim napiszesz pierwsze zapytanie, poukładamy sobie obraz: gdzie aplikacja trzyma dane, czym jest baza, czym jest tabela i po co QA w ogóle zagląda pod maskę produktu.
Najpierw: skąd biorą się dane w aplikacji?
Kiedy użytkownik zakłada konto, kupuje kurs, opłaca zamówienie albo wysyła zgłoszenie do supportu, aplikacja musi gdzieś zapisać te fakty. Nie wystarczy, że ekran przez chwilę coś pokaże. System musi pamiętać, kto ma konto, jaki ma status, za co zapłacił i co poszło nie tak.
Baza danych to uporządkowane miejsce, w którym aplikacja przechowuje takie informacje. SQL to język, którym zadajesz tej bazie pytania. Nie pytasz komputera „co się stało?” w luźnej rozmowie. Zapisujesz precyzyjne pytanie: pokaż te kolumny, z tej tabeli, w tej kolejności.
Trzy szybkie przykłady z produktu
Ekran pokazuje „błędne dane logowania”, ale w bazie możesz sprawdzić, czy konto istnieje, czy jest aktywne i czy ma zapisany e-mail.
Użytkownik mówi, że zapłacił. W bazie sprawdzasz zamówienie, płatność i status dostępu do kursu.
Ktoś zgłasza brak maila. W bazie widzisz, czy mail w ogóle jest zapisany i czy rekord nie ma braków.
Panel pokazuje inną liczbę zamówień niż raport. SQL pomaga sprawdzić, które rekordy są liczone, a które wypadają z wyniku.
Sytuacja z pracy
Użytkownik pisze do supportu: „Nie mogę się zalogować do panelu”. Zanim ktokolwiek zacznie zgadywać, QA chce sprawdzić podstawowe fakty: czy konto istnieje, jaki ma status, czy ma zapisany e-mail i kiedy zostało utworzone.
Dane, które widzisz
Wyobraź sobie mały fragment tabeli users:
| id | status | created_at | |
|---|---|---|---|
| 1 | anna@example.com | active | 2026-04-01 |
| 2 | bartek@example.com | blocked | 2026-04-11 |
| 3 | NULL | pending | 2026-04-12 |
Nazwijmy to spokojnie
Zbiór tabel, w których aplikacja zapisuje fakty.
Jedna lista podobnych rzeczy, np. użytkowników w
users.Rodzaj informacji, np.
email, status, created_at.Jeden wiersz tabeli, czyli jeden konkretny użytkownik.
Pierwszy SQL, tylko jako podgląd
Na końcu lekcji zobaczysz najprostsze pytanie do tabeli. Nie diagnozujemy jeszcze problemu, tylko czytamy dane.
SELECT id, email, status
FROM users;Co taki wynik mówi QA-owi?
Widzisz, że konto Bartka istnieje i ma status blocked. To jeszcze nie jest pełna diagnoza.
Nie wiesz, kto zablokował konto, kiedy dokładnie ani z jakiego powodu. Ale masz pierwszy fakt, od którego
można zacząć rozmowę z devem, supportem albo produktem.
Jak czytać tę tabelę jak QA?
Status
blocked jest faktem. Przyczyna blokady to osobne pytanie.NULL przy e-mailu może tłumaczyć problemy z resetem hasła albo powiadomieniami.UI może coś ukrywać, ale baza pokazuje surowe fakty zapisane przez system.
„Konto ma status blocked” jest lepsze niż „logowanie jest zepsute”.
Mini-zadanie
- Wskaż nazwę tabeli.
- Wskaż kolumnę, w której trzymany jest e-mail.
- Wskaż cały rekord użytkownika Bartka.
- Wskaż wartość, która sugeruje, że konto jest zablokowane.
Ćwiczenie praktyczne
Napisz krótką notatkę supportową bez używania jeszcze żadnego filtrowania: „W tabeli users widzę, że...”. Chodzi o nauczenie się patrzenia na dane, nie o szybkie rzucanie składnią SQL.
Quiz
Czym jest tabela?
Uporządkowaną listą podobnych rzeczy, np. użytkowników.
Czym różni się kolumna od rekordu?
Kolumna to typ informacji, rekord to jeden konkretny wiersz danych.
Po co QA-owi SQL?
Żeby sprawdzać fakty w danych zamiast opierać diagnozę tylko na ekranie albo domysłach.
Co dalej?
W następnej lekcji nauczysz się świadomie wybierać kolumny. Nadal bez filtrów. Najpierw nauczymy się dobrze patrzeć na tabelę, dopiero potem będziemy zawężać wynik.