How to Build Your First SQL Testing Project

Let’s be real – how many times have you filled out a contact form on a website and wondered, “Did my information actually go somewhere, or is it floating in digital limbo?” As testers, we often focus on making sure the front-end validation works (you know, those red error messages when you forget to add your email), but what happens after you hit that submit button is just as important.

That’s exactly what this project is about – testing what happens behind the scenes when a form is submitted. I used SQL to simulate the kind of backend validation a QA might perform on a billing, support, or service request form. And here’s a bonus: this ties directly into the SQL testing questions I’ve been asked in almost every entry-level QA interview.

The Setup: What I’m Actually Testing Here

Let me break down what I built for this project:

Goal: Validate that user-submitted form data is accurately saved in the database (because what good is a form if the data gets lost or mangled?)

Tech: SQLite in DB Fiddle + manual SQL queries (keeping it simple but effective)

What I tested:

• Does a valid submission actually get stored?
• How are optional fields handled? (Think: phone number that isn’t required)
• Is bad or blank data rejected as it should be?
• Do table relationships work correctly? (JOINs, people, JOINs!)

This is the kind of QA testing that happens every day in financial systems, CRMs, and support platforms – basically anywhere that collects and stores user data.

Tech Toolkit of the Week: DB Fiddle

For this project, I used DB Fiddle as my SQL playground. If you haven’t used it before, it’s a free online tool that lets you write and test SQL without setting up a whole database environment.

What I love about it for QA projects:

• Zero setup time
• Lets you create tables, insert data, and run queries all in one place
• Supports multiple database types (I used SQLite for simplicity)
• You can save and share your work – perfect for portfolio projects

My Learning Moment: When I first started looking at SQL for QA, I thought I’d need to set up some complex local database. Tools like DB Fiddle make it super accessible for learning and demonstration.

The Database Structure: What We’re Working With

I kept the structure intentionally simple but realistic. Here’s what I created:

sqlCREATE TABLE service_types (
    id INTEGER PRIMARY KEY,
    name TEXT NOT NULL
);

CREATE TABLE submissions (
    id INTEGER PRIMARY KEY,
    full_name TEXT NOT NULL,
    email TEXT NOT NULL,
    phone TEXT,
    message TEXT NOT NULL,
    service_id INTEGER,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (service_id) REFERENCES service_types(id)
);

Then I populated the tables with some test data to simulate real form submissions:

sql-- Service types
INSERT INTO service_types (id, name) VALUES
(1, 'Technical Support'),
(2, 'Billing Question'),
(3, 'Feature Request');

-- Sample submissions
INSERT INTO submissions (full_name, email, phone, message, service_id) VALUES
('Nicole Nealy', 'nicole@example.com', '555-123-4567', 'Having trouble logging in', 1),
('Chris Barnes', 'chrisb@example.com', NULL, 'Need to update billing info', 2),
('Tanya Rodriguez', 'tanya@example.com', '555-987-6543', 'Would love to see dark mode', 3);

Career Changeup Tip: Even if your background isn’t in databases, your experience with spreadsheets and data organization in previous roles is directly transferable to SQL testing. It’s all about tracking and validating information, just with different tools.

The Test Cases: Thinking Like a Backend QA

I wrote five test cases focused on different aspects of backend validation. Each test case included:

1. What a user might do on the frontend
2. What should happen in the database as a result
3. The SQL query to verify the expected behavior

TC01: Confirm Valid Submission is Stored

Scenario: User completes all form fields and submits

Expected Result: All data is stored correctly with timestamp

SQL Query:

SELECT * 
FROM submissions 
WHERE full_name = 'Nicole Nealy';

This query returned my test record with all fields intact, confirming that a standard form submission saves correctly:

id    full_name       email                phone          message      service_id   created_at
1     Nicole Nealy    nicole@example.com   555-123-4567   Having       1            2023-09-15 14:22:17
                                                          trouble 
                                                          logging in

Why This Matters: This is your baseline “happy path” test. If this fails, nothing else really matters because the core functionality is broken.

TC02: Missing Phone Saved as NULL

Scenario: User doesn’t provide an optional phone number

Expected Result: Record saves with phone field as NULL

SQL Query:

SELECT full_name, phone 
FROM submissions 
WHERE email = 'chrisb@example.com';

The query confirmed that the system correctly handled the missing phone number:

full_name                     phone 
Chris Barnes                  NULL

My Learning Moment: Testing NULL handling is crucial! I’ve seen many real-world bugs where optional fields either prevent submission or get filled with placeholder data instead of properly storing NULL.

TC03: Check for Missing or Blank Emails

Scenario: Form is submitted without a required email

Expected Result: No records should exist with blank emails (if frontend validation is bypassed)

SQL Query:

SELECT * 
FROM submissions 
WHERE email IS NULL OR email = '';

This query returned zero rows, confirming our database integrity:

(0 rows returned)

Why This Matters: Even if your frontend has validation, testing at the database level ensures you have multiple layers of protection against bad data.

TC04: Join to Show Service Type Name

Scenario: User selects a service type from dropdown

Expected Result: Service type name is correctly associated with submission

SQL Query:

SELECT 
    s.full_name, 
    s.email, 
    st.name AS service_type
FROM 
    submissions s
JOIN 
    service_types st 
    ON s.service_id = st.id;

Results showed all submissions correctly joined with their service types:

full_name                   email                               service_type
Nicole Nealy                nicole@example.com                  Technical Support
Chris Barnes                chrisb@example.com                  Billing Question
Tanya Rodriguez             tanya@example.com                   Feature Request

Side Hustle Strategy: Getting comfortable with JOINs in SQL will set you apart in QA interviews. Many candidates can handle basic queries, but showing you understand relationships between tables demonstrates deeper technical knowledge.

TC05: Count Submissions by Service Type

Scenario: We want to analyze what types of requests are most common

Expected Result: Accurate count of submissions by category

SQL Query:

sqlSELECT 
    st.name AS service_type, 
    COUNT(*) AS total_submissions
FROM 
    submissions s
JOIN 
    service_types st 
    ON s.service_id = st.id
GROUP BY 
    st.name;

Results showed the distribution across service types:

service_type              total_submissions 
Technical Support         1
Billing Question          1
Feature Request           1

Why This Matters: Aggregation queries like this are essential for testing reporting features. As a QA, you might need to verify that dashboards or admin reports are displaying accurate counts.

What This Project Actually Proves

Beyond just showing that I can write SQL queries, this project demonstrates several important QA skills:

1. Backend validation thinking – I’m not just testing what users see, but what the system actually does with their data
2. Data integrity validation – I’m checking that relationships between tables work correctly and required fields are enforced
3. Test case design for databases – I’ve created specific, targeted tests that validate different aspects of data handling
4. Real-world application – These are the exact same techniques used to test payment processing systems, CRMs, and support ticketing systems

Ask a Tester: Community Q&A

Q: Do I really need to know SQL for QA roles? Can’t I just focus on UI testing?

A: Based on my interview experiences, SQL knowledge is becoming a standard expectation even for entry-level QA roles. In my recent interviews, I was asked to write SQL queries in 7 out of 10 technical assessments. While you don’t need to be a database expert, understanding basic queries to validate data is increasingly considered a core skill rather than a “nice-to-have.”

Where This Project Could Go Next

If I were to expand this project (which I might!), I’d add:

1. Python automation to run these SQL validation queries as part of a test suite
2. Negative test cases like attempting to insert records with invalid foreign keys
3. Performance testing scenarios to see how the database handles larger volumes of submissions
4. A mock API that would simulate the connection between the front-end form and the database

Let’s Wrap This Up

Not all QA projects need to be complicated to be valuable. This relatively simple SQL project demonstrates critical thinking about data integrity, which is at the heart of many business applications.

Remember that “Submit” button on a form isn’t the end of the testing story – it’s actually where some of the most important validation begins. Looking at what happens to data after it’s submitted is a key part of thorough QA testing.

Have you done any SQL testing in your QA journey? Or are you just getting started with database validation? Drop your questions or experiences in the comments!

---

#TestLikeAGirl #SQLTesting #QAPortfolio #DatabaseValidation #DataIntegrity

Join our community! Sign up for the weekly TestLikeAGirl newsletter for exclusive transition tips, job opportunities, and virtual coffee chats with women who’ve successfully made the leap into tech.