Yes, SQL is worth learning for a software testing internship, and about 14 days is enough to reach a useful level. A tester mainly needs SELECT, WHERE, JOIN, GROUP BY and a few checks for duplicates, nulls and orphan records, then a disciplined way to record what each query proved. This guide gives you a sample schema, a worksheet of verification queries, and a template for documenting data validation results.
Why testers use SQL to check what the screen shows
A user interface can show “Order placed successfully” while the database holds a wrong amount, a missing row or two copies of the same record. Testers use SQL to look behind the screen and confirm that what the application claims matches what was stored. Typical situations:
- After a registration form is submitted, confirm exactly one user row exists with the right values.
- After a cancellation, confirm the order status changed and no related rows were left in an inconsistent state.
- After a data migration or bulk upload, confirm row counts and totals match the source.
- After a bug fix, confirm bad data was not created again.
Most of this uses read-only queries. As a beginner, you should write SELECT statements only. Changing data in a shared test environment without permission can break other people’s work.
The sample schema used in this worksheet
The schema below is a small, illustrative online course store. It is invented for practice and does not represent any real system. You can create it in free tools such as SQLite, MySQL Community Edition or PostgreSQL on your own laptop.
| Table | Columns | Rules a tester should know |
|---|---|---|
| students | student_id (PK), full_name, email, city, created_on | email must be unique and not null |
| courses | course_id (PK), title, price, is_active | price must be zero or more |
| orders | order_id (PK), student_id (FK), order_date, status, total_amount | status is one of PLACED, PAID, CANCELLED |
| order_items | item_id (PK), order_id (FK), course_id (FK), quantity, unit_price | quantity must be at least 1; orders.total_amount should equal the sum of quantity x unit_price |
Before writing any query, read the table rules. A validation query is simply a rule turned into a question the database can answer.
Free 2-Week CareerSwami Internship
Online, 14 days, with a free offer letter and a free completion certificate once you finish the work. Check with your college that it fits your requirement before you enrol.
SQL basics a testing intern needs in the first week
- SELECT and WHERE: fetch specific rows and filter them.
- ORDER BY and LIMIT: look at the latest records after a test action.
- COUNT, SUM, MIN, MAX: compare totals with what the application reports.
- GROUP BY and HAVING: find duplicates and unusual groups.
- INNER JOIN and LEFT JOIN: connect tables and find missing relationships.
- IS NULL checks: find fields that should never be empty.
- Subqueries: compare a value against a calculated result.
You do not need stored procedures, indexing theory or performance tuning to be useful in a short internship.
Worksheet: 20 SQL queries that verify data
Each row gives the check, the query and what a clean result looks like. Syntax is standard SQL and may need small changes for your database (for example, date functions differ). These are illustrative and written for the sample schema above.
| # | Check | Query | Expected if data is healthy |
|---|---|---|---|
| 1 | Row count in a table | SELECT COUNT(*) FROM students; |
Matches the source or expected count |
| 2 | Latest record after a UI action | SELECT * FROM students ORDER BY created_on DESC LIMIT 1; |
Values equal what you typed in the form |
| 3 | Exactly one row for a test email | SELECT COUNT(*) FROM students WHERE email = 'test01@example.com'; |
1 |
| 4 | Duplicate emails | SELECT email, COUNT(*) FROM students GROUP BY email HAVING COUNT(*) > 1; |
No rows |
| 5 | Null in mandatory field | SELECT * FROM students WHERE email IS NULL OR full_name IS NULL; |
No rows |
| 6 | Empty strings that look filled | SELECT * FROM students WHERE TRIM(full_name) = ''; |
No rows |
| 7 | Negative prices | SELECT * FROM courses WHERE price < 0; |
No rows |
| 8 | Invalid status values | SELECT * FROM orders WHERE status NOT IN ('PLACED','PAID','CANCELLED'); |
No rows |
| 9 | Orders without a student (orphans) | SELECT o.order_id FROM orders o LEFT JOIN students s ON o.student_id = s.student_id WHERE s.student_id IS NULL; |
No rows |
| 10 | Items without an order | SELECT i.item_id FROM order_items i LEFT JOIN orders o ON i.order_id = o.order_id WHERE o.order_id IS NULL; |
No rows |
| 11 | Orders with no items | SELECT o.order_id FROM orders o LEFT JOIN order_items i ON o.order_id = i.order_id WHERE i.item_id IS NULL; |
No rows (unless the business allows empty orders) |
| 12 | Quantity below minimum | SELECT * FROM order_items WHERE quantity < 1; |
No rows |
| 13 | Order total equals item sum | SELECT o.order_id, o.total_amount, SUM(i.quantity * i.unit_price) AS calc FROM orders o JOIN order_items i ON o.order_id = i.order_id GROUP BY o.order_id, o.total_amount HAVING o.total_amount <> SUM(i.quantity * i.unit_price); |
No rows |
| 14 | Item price differs from course price | SELECT i.item_id, i.unit_price, c.price FROM order_items i JOIN courses c ON i.course_id = c.course_id WHERE i.unit_price <> c.price; |
No rows, or only rows explained by a discount rule |
| 15 | Orders by status | SELECT status, COUNT(*) FROM orders GROUP BY status; |
Counts agree with the application report |
| 16 | Revenue of paid orders | SELECT SUM(total_amount) FROM orders WHERE status = 'PAID'; |
Equals dashboard figure |
| 17 | Future-dated orders | SELECT * FROM orders WHERE order_date > CURRENT_DATE; |
No rows |
| 18 | Inactive courses still being sold | SELECT i.item_id FROM order_items i JOIN courses c ON i.course_id = c.course_id JOIN orders o ON i.order_id = o.order_id WHERE c.is_active = 0 AND o.status = 'PLACED'; |
No rows if business rules block it |
| 19 | Students with no orders | SELECT s.student_id FROM students s LEFT JOIN orders o ON s.student_id = o.student_id WHERE o.order_id IS NULL; |
Rows are allowed; compare with expectations |
| 20 | Email format sanity | SELECT * FROM students WHERE email NOT LIKE '%_@_%._%'; |
No rows |
How to read an empty result
For checks designed to find bad data (queries 4 to 14, 17, 18, 20), zero rows means the rule held for the data tested. For count and total checks, a number is only meaningful when compared with an independent expected value, such as the source file or the screen.
Worked example: verifying a cancelled order (illustrative)
Suppose the test case says: “When a student cancels a PLACED order, the status becomes CANCELLED and the order total stays unchanged.” The figures below are made up for illustration; no query was actually run.
- Before the action: run
SELECT order_id, status, total_amount FROM orders WHERE order_id = 1042;and note the result, for example PLACED and 1,498.00. - Perform the action in the application: cancel order 1042.
- After the action: run the same query. Expected: CANCELLED and 1,498.00.
- Check related data: run
SELECT COUNT(*) FROM order_items WHERE order_id = 1042;The item rows should still exist if the rule is to keep history; confirm that rule with the requirement. - Check for side effects: run query 8 to confirm no invalid status values appeared.
If step 3 returned PAID or the amount changed to 0, you have a defect, and the before and after outputs are your evidence.
A template for documenting data validation results
A query without a record is easy to dispute. Use one row per check in a spreadsheet or document:
| Field | What to write | Illustrative entry |
|---|---|---|
| Check ID | Unique reference | DV-007 |
| Requirement or test case link | What rule this verifies | TC-Cancel-03 |
| Environment and date | Where and when you ran it | Test server, 13 Nov 2026 |
| Test data used | IDs or inputs | order_id 1042 |
| Query | Exact SQL, copied not retyped | SELECT status FROM orders WHERE order_id = 1042; |
| Expected result | Written before running | CANCELLED |
| Actual result | Paste output or screenshot reference | PAID |
| Status | Pass, Fail or Blocked | Fail |
| Notes or defect ID | Anything a reviewer needs | Status not updated after cancel |
Rules for writing the record
- Write the expected result before you run the query, so you cannot bend it to fit.
- Keep sensitive values out of screenshots; use test data and mask any real personal details.
- Record the database and schema name, since the same table name can exist in several environments.
- Save queries in a numbered file so another person can rerun them.
Madurai Kamaraj University students: planning SQL practice around your internship
No university-specific rules were verified for this article, so nothing here should be read as an MKU regulation. What matters for you is practical: whether a short online internship can be reported to your department, and in what form. Rules on internships, project work, credit and documentation can differ between departments, affiliated colleges and academic schemes, and they change by regulation year.
Since SQL practice needs only a laptop and free software, you can start it regardless of your semester timetable. The part to settle early is how your work will be recognised. If you join the free two-week online internship from CareerSwami, you receive a free offer letter and a free completion certificate after successful completion. That is separate from your university, and it does not by itself earn academic credit or imply any approval by the university.
A well-kept validation log from the worksheet above also gives you something concrete to show in a viva, a project review or an interview.
Verification steps for MKU students before you rely on the internship
- Ask your department office or project coordinator, in writing, whether an online internship is permitted and whether it counts toward any requirement.
- Request the current internship or project regulation document for your programme and note its scheme year.
- Ask which proof is required (offer letter, certificate, report, mentor signature) and in what format.
- If you study at an affiliated college, check whether the college or the university sets the rule.
- Check your academic calendar for semester break dates so the 14 days do not clash with exams or lab sessions.
- Keep copies of replies in email so you can show them later.
A 14-day plan to learn SQL for data validation
| Days | Focus | Output |
|---|---|---|
| 1-2 | Install a database, create the sample schema, insert 10 to 20 rows | Working practice database |
| 3-4 | SELECT, WHERE, ORDER BY, LIMIT; queries 1 to 3 | First entries in your validation log |
| 5-6 | COUNT, GROUP BY, HAVING; queries 4 to 8, 15, 16 | Duplicate and invalid-value checks |
| 7-8 | INNER and LEFT JOIN; queries 9 to 11, 19 | Orphan record checks |
| 9-10 | Calculation checks; queries 12 to 14, 17, 18, 20 | Business rule checks |
| 11-12 | Insert deliberately bad rows in your own copy and prove your queries catch them | Evidence that each query works |
| 13 | Write 5 test cases that pair a UI action with a SQL verification | Test case sheet |
| 14 | Clean the log, add notes, write a one-page summary | Portfolio-ready document |
Mistakes that make SQL test evidence unreliable
- Using SELECT * everywhere. Choose the columns the rule concerns so the result is easy to read.
- Forgetting the WHERE clause. An unfiltered query on a large table can be slow and confusing.
- Trusting JOIN counts. An INNER JOIN silently drops unmatched rows; use LEFT JOIN when hunting for missing relationships.
- Comparing NULL with =. Use IS NULL instead.
- Testing only the happy path. Also check boundary values such as quantity 0, price 0 and very long names.
- Running write statements in a shared environment. Ask before any INSERT, UPDATE or DELETE.
Frequently Asked Questions
How much SQL does a software testing intern really need?
Comfort with SELECT, WHERE, JOIN, GROUP BY, HAVING and NULL checks covers most day-to-day verification. The 20 queries in the worksheet use only these.
Can I practise database testing without access to a company database?
Yes. Create the sample schema in SQLite, MySQL or PostgreSQL on your laptop, add test rows, and deliberately insert bad data to see whether your queries catch it.
What is the difference between checking the UI and checking the database?
The UI shows what the application chooses to display. The database shows what was stored. A mismatch between them, such as a wrong total or a duplicate row, is often a real defect.
How do I find duplicate records with SQL?
Group by the column that should be unique and keep groups with a count above one, as in query 4. Any rows returned are duplicates to report.
Why use LEFT JOIN instead of INNER JOIN to find orphan records?
INNER JOIN returns only matched rows, so orphans disappear. LEFT JOIN keeps every row from the first table, and a NULL on the other side reveals the missing match.
What should a data validation record contain?
The check ID, linked requirement, environment, test data, exact query, expected result, actual result, status and notes. Write the expected result before running the query.
Will SQL practice from a short online internship be accepted by my university?
That depends on your department and the regulation for your programme. Ask in writing, as outlined in the verification steps above, before assuming it counts for anything.
Which free internship can I use to apply these SQL skills in a testing track?
CareerSwami offers a free two-week online internship across 26 tracks, including testing-related work. You can use the worksheet and validation log in this article as practice material alongside it.
Ready to put this into practice?
Join the free two-week CareerSwami online internship in Software Testing. The internship, the offer letter and the completion certificate are free.