The junior QA bar keeps rising — and here is what each requirement is actually for

Twelve years ago, a route into testing could look like this: turn up at a conference, listen to a talk, walk up to the speaker afterwards and ask one good question. An offer arrives the following week.

That is not nostalgia talking. It was ordinary. There were more openings than people, the industry was growing faster than anyone could train for, and companies hired for the ability to think and planned to teach the rest on the job.

Today the same position asks for test design techniques, an understanding of HTTP, the ability to write a SQL query with a join, some idea of what XSS and SQL injection are, experience with Postman, and increasingly "automation is a plus".

The first reaction to that list is usually: is this reasonable? Let us be honest about it — some of those requirements are earned, some are not, and the difference is worth knowing.

Why the bar went up

The ratio of applicants to openings inverted. In 2013 someone with English and a willingness to learn was scarce. Now a junior posting draws hundreds of applications. The interview stopped being a conversation and became a filter, and filters need criteria — preferably formal ones that are easy to compare across candidates.

The job itself changed. A QA engineer twelve years ago mostly clicked through a UI against a script and filed bugs. Today the same junior opens devtools, watches the Network tab, goes to Postman to see what the backend actually returned, and to the database to confirm it was stored. Not because it is fashionable, but because products became distributed and half the defects no longer live on the screen.

The runway for learning got shorter. Teams are smaller and release more often. A junior used to have six quiet months growing next to a senior. Now they are expected to be useful by the second sprint, and companies try to buy that readiness at the door.

And part of it is simply requirement inflation. Once every posting says "SQL knowledge", the next one says it too, because leaving it out looks like advertising for someone weaker. That is how things a junior will never touch in the role end up in the requirements for it.

That last point matters and we will come back to it. First, the parts of the list that are there for a reason.

What each requirement is actually for

Test design techniques

These get treated as theory for the sake of theory: learn equivalence partitioning, recite it, forget it.

In practice the technique answers the one question you will be asked constantly at work: why did you test that, and why is that enough?

Without a technique the answer is "well, I clicked through the main flows". That is not an argument — it cannot be checked or challenged. With one it becomes: "the field takes 18 to 65, I tested one value from each class plus the boundaries — six tests instead of a hundred and twenty, and here is why the rest add nothing."

The second, less obvious point: techniques are how you fit into the time you have. Testing everything is never an option. Test design is a tool for cutting scope defensibly, not an academic subject.

SQL

The usual objection is "why does a tester need the database, I test the interface".

The interface shows you what the frontend rendered. It does not show you what was stored.

The classic case: a user saves their profile, the page says "saved", you move on. In the database the field is still empty, because the backend returned 200 for a request that changed nothing. A customer finds it a week later.

The second use is more frequent still — test data. You need a user with an expired subscription, three orders and one returned item. Through the UI that is half a day of clicking. As a query it is a minute.

The volume a junior actually needs is small: select with where, sorting, a join across two tables, count with group by. That is not "knowing SQL", it is four constructs.

API and HTTP

The reason here is the simplest of all. The core of a junior QA's job is not finding the defect. It is localising it.

"It does not work" is not a bug report. A developer will spend an hour establishing what you could have established in a minute: did the request go out, what came back, is this a 400 caused by your input or a 500 caused by their code.

That is where the questions about status codes, devtools and Postman come from. It is not trivia, it is being able to say whose side the problem is on. A tester who can do that saves the team hours every week, which is exactly why it is asked at the door.

There is also functionality with no interface at all. A payment provider integration, a webhook from an external service, a background job — the only way to check those is with a request.

XSS, injection and basic security

This looks like the least junior item on the list. But the reason is not depth, it is the cost of the miss.

A missed layout bug is a bug. A missed XSS is an incident: leaked data, a notification to users, sometimes a fine. The difference is not difficulty, it is consequences.

And the cheapest checks cost nothing. Paste <script>alert(1)</script> into a name field and see whether it executes. Put a single quote in a search box and see whether the query falls over with a database error. It is a five-item checklist that takes ten minutes and closes off the cheapest class of attack there is.

Nobody expects a junior to run a penetration test. They expect you not to walk past the obvious.

Environments and logs

Questions about dev, staging and production, and about how to read logs, get the same puzzled reaction. The reason is practical again: half of all "bugs" are not bugs but the wrong environment, a stale build, or a config difference.

A tester who checks which build reproduces it and what the logs say before filing files less noise. And noise in the tracker costs the team more than it looks like it does.

And what is genuinely excess

Now the honest part.

Asking a junior manual QA about the layers of the OSI model, replication in SQL Server, or the difference between SIP and PRI is not an assessment of readiness for the job. It is either a list copied from somewhere or an attempt to filter somehow when two hundred people applied.

The test for a healthy interview is simple: for every question, the interviewer can say how it will come up in the first month of work. "You will be checking data in the database" — they can. "You will be configuring replication" — not in a junior role.

If most of the questions fail that test, it tells you something about the company's hiring process rather than about you. That is a perfectly good reason not to regret the rejection.

What to do about it

The bar is not coming down; the old ratio of people to openings is not coming back. But the list of what you genuinely need is far shorter than the postings suggest.

The minimum that clears most junior interviews:

• Test design — equivalence partitioning, boundaries, decision tables. With worked examples on concrete fields, not definitions.
• HTTP — methods, status code classes, the Network tab, being able to say whose side an error is on.
• API — Postman, GET and POST, reading a response, checking the things the UI does not show.
• SQL — select, where, order by, join, count with group by. Four constructs.
• Security — a five-item checklist: XSS in input fields, a quote in the search box, another user's record by id in the URL, password masking, and an error message that does not reveal whether a login exists.
• Bug reports — and understanding that the preconditions matter more than the screenshot.

That is a few weeks of focused preparation, not a year of study. Most rejections happen not because the candidate has never heard of these things, but because they know them as "I have read about that" rather than "I can apply it and say why it matters".

One last thing. Every item above is worth being able to say out loud. Written down, your reasoning looks complete. Said for the first time in an interview, it comes out in a different order and half of it goes missing. That is not a knowledge problem, and reading does not fix it.

---

We put together Manual QA interview questions with model answers — split by junior and middle, free to read. And we built Prepair, where you answer those questions instead of reading them and get scored on each one. Three interviews a month are free.