Powrót do: AI_Testers vol. 1 – Bonusy (aktywnie rozwijane)
W tym odcinku…
Boisz się baz danych? Czekasz na programistę, żeby wyciągnął Ci listę userów, bo nie pamiętasz, jak się robi LEFT JOIN?
Aby sprawdzić, czy aplikacja naprawdę zapisała użytkownika, tester musi zajrzeć do bazy danych. Wymaga to użycia języka SQL. Niestety, składnia tego języka bywa skomplikowana, a proszenie programistów o wyciągnięcie danych blokuje Twoją pracę.
To już koniec z tym problemem. Udowadniam w tym odcinku, że nie musisz znać składni SQL, żeby swobodnie “rozmawiać” z bazą danych. Wystarczy, że znasz język polski i logikę biznesową.
Dlaczego rozmowa z bazą przez AI ma sens?
Zamiast uczyć się na pamięć rodzajów JOIN-ów i dialektów, możesz opisać swój problem po polsku („połącz mi klienta z jego zamówieniem”). Aby to zadziałało, musisz podać AI kontekst — wkleić schemat swojej bazy (nazwy kolumn), żeby AI wiedziało, z jakich elementów buduje zapytanie.
📚 Pojęcia, które warto znać:
- SQL: Specjalny język służący do zadawania pytań bazom danych.
- JOIN: Komenda w SQL, która pozwala połączyć dane z dwóch różnych tabel (np. tabeli “Klienci” i tabeli “Zamówienia”), by wyświetlić je razem. Istnieją różne rodzaje łączyń (Inner, Left, Outer), co często sprawia trudność początkującym.
- Dialekt SQL: Bazy danych od różnych producentów (np. MySQL, PostgreSQL) minimalnie różnią się składnią. To, co działa w jednej, wyrzuci błąd w drugiej.
🚀 Czego się nauczysz?
-
🗣️ Natural Language to SQL (NL2SQL):
Jak zmienić zdanie “Pokaż mi userów z Wrocławia z ostatniego tygodnia” w bezbłędny kod SQL w 5 sekund. -
🔗 Koszmar JOIN-ów:
Łączenie tabel (np. Klienci + Zamówienia) bez zastanawiania się nad kluczami obcymi. Ty opisujesz relację biznesową (“Klienci, którzy kupili X”), a AI samo dobiera techniczne wiązania. -
🔍 Tłumacz Kodu (Reverse Engineering):
Dostałeś skomplikowane zapytanie od programisty? Wklej je do AI, żeby dowiedzieć się “po ludzku”, co ono robi i czy nie ma w nim błędów.
⚠️ Złota zasada bezpieczeństwa:
AI chętnie napisze dla Ciebie zapytania modyfikujące (np. komendy UPDATE, DELETE). Nigdy nie uruchamiaj ich na bazie produkcyjnej bez 100% pewności! Jeśli zapomnisz o warunku (WHERE), możesz wyczyścić całą bazę produkcyjną. Dlatego jako testerzy na bazach produkcyjnych zawsze używamy tylko bezpiecznej komendy SELECT (pobieranie danych).
Prompty z odcinka
-
Use Case 1: Zapytania w Języku Naturalnym (NL2SQL)
🔗 https://runsql.com/sql-validator/Screencast: Wklejasz bardzo uproszczony schemat tabel (np. Tabela Users: id, name, city, created_at).
Rola: Senior Database Admin. Zadanie: Napisz zapytanie SQL (PostgreSQL). Pokaż mi wszystkich użytkowników z Wrocławia, którzy zarejestrowali się w ciągu ostatnich 7 dni. Posortuj od najnowszych. Kontekst: Mam tabelę Users (kolumny: id, email, city, created_at).
-
Use Case 2: Koszmar JOIN-ów (Relacje)
Screencast: Wklejasz do czatu schemat dwóch tabel:Users (id, email, city) Orders (id, user_id, amount, status)
Rola: Ekspert SQL i Analizy Danych. Zadanie: Napisz zapytanie łączące tabele Users i Orders (użyj JOIN). Kontekst: Chcę znaleźć naszych klientów VIP. Wyciągnij e-maile użytkowników, którzy mają przynajmniej jedno zamówienie o statusie 'PAID' na kwotę powyżej 500 zł. Format: Tylko gotowy kod SQL.
-
Use Case 3: Wyjaśnij mi ten kod (Reverse Engineering)
Screencast: Wklejasz do czatu skomplikowane, brzydkie zapytanie SQL (tzw. “spaghetti code”).SELECT c.id, c.last_name, (SELECT COUNT(*) FROM orders o WHERE o.cust_id = c.id AND o.status NOT IN ('X', 'C')) as active_orders, CASE WHEN x.total_spent > 10000 THEN 'VIP' WHEN x.total_spent > 5000 THEN 'Gold' ELSE 'Standard' END as tier, p.prod_name FROM customers c, (SELECT cust_id, SUM(amount) as total_spent FROM orders WHERE order_date >= '2025-01-01' GROUP BY cust_id) x, order_items oi, products p WHERE c.id = x.cust_id AND c.status = 1 AND oi.order_id IN (SELECT id FROM orders WHERE cust_id = c.id) AND oi.prod_id = p.id AND p.category_id != 99 ORDER BY 3 DESC, 2 ASC;Rola: Nauczyciel SQL. Zadanie: Wytłumacz mi krok po kroku, co robi to zapytanie. Kontekst: Dostałam to od dewelopera i muszę przetestować, czy zwraca dobre dane. Przełóż to na ludzki język.
Linki i materiały dodatkowe
🎉 To był finał Starter Packa! Masz już komplet narzędzi technicznych (Dane, Vision, Logi, SQL).
|
Emilia Krzemińska-Komenda
Emilia to doświadczona inżynierka QA w Hicron Software, łącząca w swojej pracy analityczny umysł testera z pasją do automatyzacji. Mocno wierzy, że technologia, w tym sztuczna inteligencja, powinna służyć ludziom, dlatego aktywnie rozwija swoją wiedzę w kierunku testowania AI oraz dostępności cyfrowej. Wierzy, że testowanie to droga do tworzenia lepszych i bardziej inkluzywnych produktów. |

Dla prostych przykładów to jest super, używam i polecam. Pytania o składnie, selecty, agregacja, joiny – działa świetnie…
…ale mam zagwostkę: Jak wykorzystać AI w bardziej skomplikowanych przypadkach?
Załóżmy, że mam 4 powiązane tabele, dużo pól w każdej, chcę wykonać jakąś bardziej skomplikowaną operację. wyciągnąć dane z każdej tabeli, a później zrobić jakiś update i dorzućmy do tego, że to dane projektowe, więc nie mogę wkleić tabel 1:1.
Teraz bym pewnie dodał warstwę abstrakcji, zaanonimizował nazwy pól i opisał o co mi chodzi, ale może znacie szybszy sposób na przekazywanie danych konkrentych tabel do chatu lub innego AI narzędzia? Może prompt, który ułoży mi zapytanie sql, które wyciągnie dane, które będę mógł przekazać do AI (z drobnymi modyfikacjami)?
Cześć!
Faktycznie, ręczne tworzenie warstwy abstrakcji dla 4 dużych tabel mija się z celem, bo tracisz cały czas, który miało zaoszczędzić AI.
Poniżej moja propozycja jak sobie z tym poradzić w bezpieczny sposób:
1. Wyciągaj tylko strukturę DDL, a nie dane
Sztuczna inteligencja, żeby ułożyć Ci świetnego JOINa czy UPDATE, wcale nie potrzebuje wszystkich wierszy z bazy. Potrzebuje tylko informacji o tym, jak tabele są ze sobą powiązane. Najszybszym sposobem jest wyeksportowanie Data Definition Language, czyli samego kodu tworzącego tabele (np. przez komendę SHOW CREATE TABLE nazwa_tabeli albo klikając w gotowe rozwiązanie w narzędziu typu DBeaver). Wrzucasz do AI sam schemat (nazwy kolumn i typy danych), a AI zrozumie architekturę bez ani jednego rekordu.
2. Prompt Kaskadowy do anonimizacji (jeśli nazwy kolumn też są tajne)
Same nazwy tabel i kolumn mogą zdradzać unikalne know-how projektu. Jeśli polityka bezpieczeństwa pozwala na wrzucenie struktury bazy (bez rekordów) do AI, otwórz nowy czat i spróbuj użyć promptu z taką bazą:
“Oto schemat moich tabel (DDL). Zmień nazwy wszystkich tabel na Tabela_A, Tabela_B itd., a nazwy kolumn na ogólne (np. id_klienta -> id_1), zachowując dokładnie ich typy danych i relacje. Zwróć mi tylko ten nowy, zanonimizowany kod.”
Uwaga: Jeśli masz absolutny zakaz wysyłania nawet nazw kolumn na zewnątrz, zrób to szybko przez “Znajdź i zamień” i ręcznie podmień wrażliwe tytuły. Z takim szkieletem-bazą wracasz do głównego czatu i prosisz o ułożenie skomplikowanej logiki.
3. “Wytłumacz mi swój tok myślenia”
Przy 4 tabelach i operacjach typu UPDATE, model lubi się pogubić. Zamiast prosić go od razu o gotowy kod, użyj promptu z taką bazą:
“Mam 4 tabele (wklejasz DDL). Chcę zaktualizować status w Tabeli D na podstawie danych z Tabel C i A. Rozpisz mi najpierw KROK PO KROKU, w punktach, jak połączysz te tabele, zanim napiszesz kod SQL.”
Dzięki temu weryfikujesz logikę sztucznej inteligencji, zanim wypluje Ci kod.
No i oczywiście ważna uwaga na koniec, którą pewnie znasz ale przypomnę:
Jeśli AI wygeneruje dla Ciebie zapytanie UPDATE (lub DELETE), nigdy nie uruchamiaj go od razu! Zawsze najpierw zamień słowo UPDATE na SELECT *, aby na własne oczy zobaczyć, które dokładnie wiersze zostaną zmodyfikowane. Dopiero gdy upewnisz się, że to te właściwe, odpalaj modyfikację.
Mam nadzieję, że to Ci pomoże 🙂
To była bardziej teoretyczna ciekawość, ale dziękuję za wyczerpującą odpowiedź, na pewno skorzystam z tych rad następnym razem, gdy trafię na taką sytuację. Spróbuję też przycisnąć ajaja, żeby sam zaproponował kilka sposób, jak łatwiej przekazać mu informacje w konkretnym kontekście 😀