Top 20 Technical Interview Questions for Junior Manual QA
In this article, we look at technical questions that are often asked at Junior Manual QA interviews. These questions cover basic QA theory, test documentation, bug reports, types and levels of testing, working with requirements, prioritizing checks, and tools that a beginner tester may encounter.
The goal of this article is to help you understand not only the questions themselves, but also the interviewer’s logic: why they ask a particular question, what knowledge they want to check, and how you can answer calmly, clearly, and in a structured way.
This material will be useful for those preparing for their first QA interview and wanting to revise hard skills: basic testing concepts, practical QA tasks, and typical work situations that a junior specialist may face on a project.
The goal of this article is to help you understand not only the questions themselves, but also the interviewer’s logic: why they ask a particular question, what knowledge they want to check, and how you can answer calmly, clearly, and in a structured way.
This material will be useful for those preparing for their first QA interview and wanting to revise hard skills: basic testing concepts, practical QA tasks, and typical work situations that a junior specialist may face on a project.
1. What is software testing and quality assurance?
Why they ask this question:
The interviewer wants to understand whether the candidate knows the basic concepts of testing and QA — Quality Assurance. They also check whether the candidate understands the difference between testing and the broader process of working on product quality.
What to talk about in your answer:
Software testing is the process of checking a product: whether it works correctly and whether it meets the requirements and user expectations.
QA — Quality Assurance — is a broader process. It helps maintain product quality at different stages of development. QA includes working with requirements, identifying risks, preparing test documentation, testing itself, creating bug reports, and communicating with the team.
The main difference is that testing is part of QA. Testing helps check the product and find problems, while QA helps improve the quality of both the product and the development process as a whole.
2. What is the role of a QA engineer in a development team?
Why they ask this question:
The interviewer checks whether the candidate understands how QA interacts with developers, analysts, designers, product managers, and other team members.
What to talk about:
A QA engineer is responsible not only for testing completed functionality, but also for helping the team create a quality product at all stages of development. QA can become involved as early as the requirements analysis stage: asking clarifying questions, finding unclear points, contradictions, or missing scenarios. This helps prevent mistakes before development even begins.
During development, QA works closely with developers, checks implemented functionality, reports found defects, and helps reproduce problems. QA also cooperates with analysts and managers to make sure that the product meets requirements and user expectations.
The main role of QA in a team is to reduce risks, identify problems as early as possible, and help improve product quality. A good QA thinks not only about whether a feature works, but also whether it is convenient for the user, whether the logic is clear, whether there are hidden problems, and whether the solution matches business goals.
Example interview answer:
QA in a development team helps ensure product quality at different stages. This is not only about finding bugs after development, but also about participating in requirement discussions, clarifying unclear points, analyzing possible risks, and checking completed functionality. QA interacts with developers, analysts, and managers, helps find problems earlier, and makes the product more stable and user-friendly.
3. What is a bug?
Why they ask this question:
They check the candidate’s basic understanding of QA terminology and whether the candidate can explain in simple words what is considered a problem in a product.
What to talk about:
A bug is a mismatch between the actual result and the expected result, requirements, or normal system behavior.
For example, if according to the requirements a form should open after clicking a button, but nothing happens, this is a bug. If a user enters the correct login and password but cannot log in to the system, this is also a bug. A bug can also be incorrect error text, an incorrect calculation, broken design, a validation problem, or a situation where the system does not work as the user expects.
It is important to understand that the QA’s task is not only to find a bug, but also to describe it correctly. A good bug report should help the developer quickly understand and reproduce the problem. That is why it usually needs reproduction steps, expected result, actual result, environment, and, if necessary, a screenshot, video, or logs.
4. What is the difference between severity and priority?
Why they ask this question:
This question checks whether the candidate understands that bugs can differ by their impact on the system and by the urgency of fixing them. Not every serious bug needs to be fixed immediately, and not every urgent bug is necessarily critical for the system.
What to talk about:
Severity is the seriousness of a bug — how strongly the defect affects the application or system.
For example:
High Severity — the application crashes, the user cannot perform a main action, or an important business function, such as payment or registration, does not work.
Medium Severity — the function generally works, but there is an error in logic, calculations, data display, or one of the scenarios.
Low Severity — small visual issues, typos, incorrect spacing, minor UI issues that do not prevent the user from performing main actions.
Priority is the urgency of fixing a bug — how quickly the team should fix it.
For example:
High Priority — the bug should be fixed as soon as possible because it is important for the business, release, or users.
Medium Priority — the bug should be fixed, but it does not block the release or the main system functionality.
Low Priority — the bug can be fixed later when there is time, because it does not have a serious impact.
It is important to say that severity is usually assessed by QA because QA analyzes the technical impact of the bug on the system. Priority is more often defined by the manager, product owner, or the whole team, because it depends on business importance, release deadlines, and current tasks.
5. What levels of testing do you know?
Why they ask this question:
They check whether the candidate understands the structure of testing and that product quality is checked at different levels. It is important to show that testing does not start only with checking the finished interface, but can also happen at the level of individual parts of code, interaction between modules, and the entire system.
What to talk about:
I know the main testing levels: component, integration, system, and acceptance testing.
Component testing, or unit testing, is checking separate small parts of the system, for example, a function, method, class, or component. Usually, developers write such tests to make sure that a specific part works correctly separately from other parts of the system.
Integration testing is checking the interaction between components, modules, or systems. For example, we can check that the frontend correctly sends a request to the backend, the backend processes the data correctly, and returns the required response.
System testing is testing the whole system as one complete product. At this level, we check how the product works as a single application: main user scenarios, business logic, errors, UI, API, and other important parts of the system.
Acceptance testing checks whether the product meets the requirements and is ready to be used by users or the customer. Here, it is important to make sure that the implemented functionality really solves the business task and works as expected.
These levels help gradually check product quality: from separate parts of the system to a full check of the completed product.
6. What is a test case?
Why they ask this question:
They check knowledge of test documentation.
What to talk about:
A test case is a documented description of a specific check. It usually contains the steps to perform, test data, preconditions, and expected result.
A test case helps QA check functionality consistently and clearly. Thanks to test cases, the same scenario can be repeated several times, and another person on the team can also perform the check and understand exactly what needs to be tested.
7. What is a test report?
Why they ask this question:
They check whether the candidate understands that testing is not only about finding bugs, but also about recording work results. A test report helps the team understand what was checked, what problems were found, how ready the product is for release, and whether there are any risks.
What to talk about:
A test report is a report on testing results. In it, QA shows which part of the functionality was checked, which tests were executed, which passed, which failed, which bugs were found, and what the general state of the product is at the moment.
A test report usually includes: what was tested, in which environment, during what period, how many test cases were executed, how many passed, failed, or were blocked. It can also include a list of found defects, their severity and priority, links to bug reports, and a short description of the main risks.
It is important that a test report is needed not only by QA. Developers, the product owner, project manager, or business team may read it. That is why it should be clear, structured, and show the real picture of product quality.
8. What should be included in a good bug report?
Why they ask this question:
This question checks whether the candidate understands how to correctly describe found defects. It is important for the team that a bug report is clear, complete, and helps the developer quickly reproduce the problem without extra questions.
What to talk about:
A good bug report should give the team all necessary information about the problem: what happened, where it happened, how to reproduce it, and what result was expected. Usually, a bug report should include:
- Title / Summary — a short and clear description of the problem.
- Steps to reproduce — specific actions that need to be performed to see the bug.
- Actual result — what actually happened.
- Expected result — what should have happened according to the requirements or system logic.
- Environment — where the problem was found: browser, device, operating system, application version, test environment.
- Additional materials — screenshots, videos, logs, links, test data, if they help understand or reproduce the problem faster.
Severity and priority are also often included in a bug report, but this depends on the team’s process.
9. How would you test a login form?
Why they ask this question:
They check whether the candidate can think like a tester: see not only one positive scenario, but also different types of system behavior. It is important to show that QA checks functionality, validation, errors, user convenience, and basic security risks.
What to talk about:
I would start with a positive scenario: enter a correct email or login and a correct password, click the “Log in” button, and check that the user successfully enters the system.
Then I would check negative scenarios: empty email, empty password, both fields empty, incorrect password, non-existing user, invalid email format, too short or too long password. It is also important to check what error messages are shown to the user and whether they are clear.
Separately, I would check the behavior of form elements: whether the “Log in” button is active, whether the form can be submitted by pressing Enter, whether password show/hide works, whether fields are not cleared unexpectedly after an error, and whether the “Forgot password” link works correctly.
I would also pay attention to security: the password should be hidden, and the error message should not reveal too much information, for example, whether such a user exists. If there is a limit on the number of login attempts, I would check that too.
Additionally, the form can be checked on different devices and in different browsers to make sure it is displayed and works correctly.
10. What would you do if the requirements for testing a task are incomplete or unclear?
Why they ask this question:
They check whether the candidate can work with uncertainty and does not start testing “randomly”. In real work, requirements are not always perfectly described: some information may be in the task, some in the design, and some with the analyst, developer, or product owner. It is important to show that QA can clarify details, analyze available information, and reduce risks.
What to talk about:
First, I would carefully study the requirements, task, designs, acceptance criteria, and related documentation. If there are still unclear points after that, I would formulate specific questions and contact the analyst, product owner, developer, or another team member.
It is important not just to say “the requirements are unclear”, but to explain what exactly is unclear: what the expected behavior should be, which data is valid, what errors should be displayed, and what should happen in edge cases.
If an answer is needed urgently, I would document my assumptions and agree on them with the team so that everyone understands the logic according to which testing will be performed. I would also highlight the risks: for example, that because of incomplete requirements, some scenarios may be missed or behavior may be implemented differently from what the business expects.
11. What should you do if a developer does not agree with a bug?
Why they ask this question:
This question checks not only technical understanding, but also the candidate’s communication skills. In QA work, there are often situations where a developer thinks that something is not a bug, but expected behavior, an implementation detail, or a problem that is not important enough. The interviewer wants to understand whether the candidate can calmly discuss disputed situations and support their position with arguments.
What to talk about:
If a developer does not agree with a bug, it is important not to argue emotionally, but to calmly discuss the situation and rely on facts. First, you need to make sure that the bug is described correctly: there are clear reproduction steps, actual result, expected result, environment, and screenshots or videos if needed.
Then it is worth checking the requirements or other documentation. If the system behavior contradicts the requirements, QA can show this to the developer and explain why they consider the situation a bug. If there is no exact description in the requirements, it is better to discuss the question with the analyst, product owner, or manager. Maybe it is not a technical bug, but an unclear requirement or a product question.
It is important to remember that the goal of QA is not to “prove that the developer is wrong”, but to help the team make the right decision for the product and the user.
12. How would you decide which bugs to retest first?
Why they ask this question:
They check whether the candidate can prioritize when retesting fixed bugs, especially when there is little time before release.
What to talk about:
First, you need to retest the bugs that have the strongest impact on the user, business, and release. I would start with critical and blocking bugs: for example, if the application crashed, the user could not log in, pay, register, or perform a main action. Then I would check bugs with high priority, especially if they are related to important business functions or the upcoming release.
I would also consider how many users are affected by the problem, how often it was reproduced, in which part of the product the bug was found, and how risky the fix was.
13. What would you do if you do not have enough time to test everything before release?
Why they ask this question:
This question checks whether the candidate understands real project limitations. In practice, QA does not always have enough time to check absolutely everything. That is why it is important to be able to prioritize, assess risks, and inform the team about the situation in time.
What to talk about:
If I understand that I do not have enough time to test everything before release, I would not just continue testing silently. First, I would inform the team or manager that there is not enough time and explain which parts of the product have already been checked, which have not been checked yet, and what risks remain.
Then I would focus on the most important and risky scenarios:
- Critical functionality — login, registration, payment, order placement, main business processes.
- Functionality that was changed before the release — because the risk of new bugs is higher there.
- Frequently used user scenarios — what most users use.
I would also clarify with the team what is more important to check first if there are doubts. After that, we can document what was tested, what we did not have time to cover, and what risks remain before the release.
14. What practical QA tasks did you perform on study projects or during an internship?
Why they ask this question:
They check how well the candidate understands what they can already do in practice, even if they do not yet have commercial experience.
What to talk about:
It is worth talking about study projects, practice during the course, testing applications, writing test documentation, and working with bugs.
Example interview answer:
I have practical experience that I gained during my studies. I tested training applications, analyzed requirements, created checklists and test cases, reported bugs, and learned to describe defects clearly for the team. I also practiced different types of testing and understand the basic QA process: from analyzing a task to checking the result and documenting found problems.
If I had an internship, I would talk about which QA tasks I performed in practice. For example, I worked with requirements, created checklists and test cases, tested application functionality, found bugs, and created bug reports. I could also participate in retesting fixed defects and discussing unclear points. Such an internship helped me better understand the real testing process, learn to analyze the product more carefully, and describe found problems more clearly.
15. What tools have you used as a QA engineer?
Why they ask this question:
This question helps understand whether the candidate has practical contact with the profession. The interviewer wants to see that the candidate not only knows theory, but has also worked with tools that are used in QA processes.
What to talk about:
I used different tools depending on the task. For working with tasks and bugs, I used YouTrack: it allows tracking tasks, creating bug reports, and checking their statuses. For API testing, I worked with Postman and Swagger: through Swagger, I studied API documentation, and in Postman, I sent requests and checked responses, status codes, and data.
I also had experience with Playwright for test automation, where I wrote checks for user scenarios in the browser. For working with databases, I used SQL and DBeaver, for example, to check that data was saved correctly in tables. In addition, I used Git for version control and working with code.
16. What is smoke testing?
Why they ask this question:
They check whether the candidate understands how to quickly assess the basic stability of a product or new build before deeper testing. For a Junior QA, it is important to understand that testing does not always start with detailed checks of all scenarios. Sometimes, first you need to make sure that the main functions work at all.
What to talk about:
Smoke testing is a quick check of the most important application functions. Its goal is to understand whether further testing can continue or whether the build is too unstable.
For example, if we are testing an online store, smoke testing may include checking that the website opens, login works, product search works, a product can be added to the cart, and an order can be placed. If login does not work or the website does not open at this stage, there is no point in immediately moving on to detailed testing of smaller scenarios.
Example answer:
Smoke testing is a quick basic check of the product’s key functions. It helps understand whether the build is stable and whether deeper testing can continue. For example, I would check whether the application opens, whether login works, whether main pages work, and whether the most important user scenarios work.
17. What is regression testing?
Why they ask this question:
They check whether the candidate understands that after changes in the product, it is necessary to check not only the new functionality, but also the existing parts of the system. In real work, bugs often appear not only in new code, but also in old functionality that previously worked correctly.
What to talk about:
Regression testing is re-checking existing functionality after changes in the application. Its goal is to make sure that new changes, bug fixes, or updates have not broken what worked before.
For example, if developers changed payment logic, QA should check not only the new payment scenario, but also old scenarios: successful payment, error with incorrect card data, payment cancellation, order status display, and other related functions.
18. What is the difference between functional and non-functional testing?
Why they ask this question:
They check whether the candidate understands different types of testing and the difference between checking functionality and checking general quality characteristics of the product.
It is important to show that testing is not only about answering the question “does the function work or not?” Besides functional requirements, a product also has non-functional requirements: performance, usability, security, stability, reliability, and clarity for the user.
What to talk about:
Functional testing checks what the system does. In other words, whether the functionality meets the requirements.
For example: the user can register, log in, add a product to the cart, place an order, and change the password.
Non-functional testing checks how the system works. In other words, it evaluates product characteristics: performance, usability, security, stability, compatibility with browsers and devices.
For example: whether the page loads quickly, whether the form is convenient to use, whether the system can handle a high load, and whether the application works correctly in different browsers.
19. What are positive and negative testing?
Why they ask this question:
They check whether the candidate can think not only about the ideal scenario, but also about situations where the user enters incorrect data or acts in an unexpected way. For QA, it is important to check both successful and error scenarios.
What to talk about:
Positive testing is checking the system with correct data and expected user actions. We check that the application works correctly when the user does everything “as expected”.
For example: the user enters a correct email and password and successfully logs in.
Negative testing is checking the system with incorrect data or incorrect actions. We check how the application handles errors and whether it shows clear messages to the user.
For example: the user leaves fields empty, enters an incorrect password, uses an invalid email format, or tries to submit a form with incorrect data.
20. What is an API and what can be checked through Postman?
Why they ask this question:
They check whether the candidate understands the basic idea of API testing and whether they are familiar with tools that are often used in QA. Even for a Junior Manual QA, it is useful to understand that testing can be performed not only through the interface, but also at the level of requests between the client and the server.
What to talk about:
An API is an interface that the backend provides for interaction with other parts of the system or external applications. Through an API, the frontend, mobile application, or another service can send requests to the backend and receive the required data or operation result.
For example, when a user clicks a button in the interface, the frontend sends an API request to the backend. The backend processes this request and returns a response: data, operation status, or an error message.
Postman is a tool that helps send API requests and check server responses. With it, you can check the endpoint, request method, status code, response body, data, errors, and system behavior with different input data.
For example, you can send a login request and check that with correct data, the server returns a successful status and a token, and with an incorrect password, it returns an authorization error.
How Tallinn Learning helps with preparation
At Tallinn Learning, these questions are covered in detail both as part of the course itself and in the career support module. Students study not only QA theory, but also real situations that a Junior QA may face at work: how to analyze requirements, write checklists and test cases, create bug reports, work with tools, communicate with the team, and explain their decisions.
Students also learn not just to memorize ready-made interview answers, but to understand the logic behind the questions: why an employer asks a particular question, what exactly they want to hear, and how to correctly demonstrate knowledge, practical experience, motivation, and readiness to grow.
During preparation, students discuss typical questions for Junior QA, practice formulating answers, and talk about their learning experience, internship, teamwork, and practical assignments. This helps them feel more confident at their first interviews and answer calmly, clearly, and in a structured way.
At Tallinn Learning, these questions are covered in detail as part of the career support module. Students learn to understand the logic of the questions instead of memorizing answers, and confidently pass their first QA interviews.
Conclusion
A Junior Manual QA interview becomes much clearer when the candidate understands not only the questions themselves, but also their purpose. When it is clear why the interviewer asks a question and what answer they expect to hear, the interview becomes less stressful.
Good preparation helps the candidate speak more confidently about their knowledge, practice, tools, teamwork, and readiness to grow in QA.