Are you a test manager, QA lead, or in-house recruiter tasked with building and growing your QA team? Or, were you asked to find and recruit your company’s best next software tester, and quickly?

If so, then you may know that hiring testers can be a challenge. And making the right hiring decisions is crucial. Being saddled with an ineffective tester is often worse than having no tester at all. Here are some of the reasons why:

• They may fail to automate any tests, meaning that all testing will be manual and will be a bottleneck to releasing software.
• They may automate tests poorly, resulting in flaky tests that no one trusts and that require tons of ongoing maintenance.
• They may be inept at creating test strategies, resulting in the wrong things being tested and the right things not being tested at all.

Common interview questions for software testers

To hire a tester with the right strengths and skills, try asking the following interview questions. We also examine WHY you should ask these questions when recruiting a software tester.

Question 1: What are the stages in a Software Testing Life Cycle (STLC)?

STLC has six stages, each with its own deliverables and activities. These deliverables serve as the entry criteria for the next phase.

• Requirement Analysis
• Test Planning
• Test Case Development
• Environment Setup
• Test Execution
• Test Closure Activity

Reason to ask this question

This question allows an employer to understand the candidate’s exposure to a systematic process. It shows their understanding of the core activities testing needs to perform.

A tester working in an Agile SDLC may describe an Iterative or Scrum-based process – detailing the testing activities performed within the Agile methodology.

The candidate will likely describe the Fundamental Test Process if they have completed their ISTQB Foundation Certificate. The ISTQB Fundamental Test Process contains the following stages:

• Test Planning & Control
• Test Analysis & Design
• Test Implementation & Execution
• Evaluating Exit Criteria & Reporting
• Test Closure Activities.

The essential takeaway from this question is they understand that testing is a systematic process with crucial activities that need to be performed.

Question 2: Describe the different Project Test Stages

The following are the most common test stages:

• Unit/Component/Module Testing
• System Testing
• Integration Testing
• System Integration Testing
• Acceptance Testing

The candidate should not confuse test phases with test types.

Test types such as Blackbox and Whitebox are typically associated with a specific phase. For example, Whitebox testing is usually performed as part of Unit testing.

Reason to ask this question

Following up on the project test levels helps determine what kind of testing the candidate is familiar with. This question allows you to distinguish the candidate’s exposure to the various testing stages of a project. Some testers may have only focused on a specific test level, e.g., user acceptance testing.

Question 3: What is the difference between verification and validation?

Verification testing checks documents, design, code, and program to confirm that the software is built according to the requirements. The verification process involves activities like reviews, walk-throughs, and inspections.

Validation is checking what we are developing is the right product. Are we building the right product?

Reason to ask this question

The primary goal of this question is to identify if the candidate understands the difference between verification and validation. The candidate must know that there will be tests for specific functionalities and the overall product; therefore, validation can be subjective. Testers will be involved in both types of testing.

Question 4: How should tests be prioritised, and what factors might influence decisions?

The priority given to test cases depends on the importance of the test case to the overall product. Many factors such as the importance of a feature, the impact of production bugs on the end-users, stakeholder and user sentiment, and market conditions impact the prioritisation of tests. Considering different stakeholders’ perspectives ensures that a test case priority is considered across these multiple dimensions.

Prioritising a test case for execution will have a lower priority than retesting a critical bug crucial for the application’s core functionality. Additionally, if the end-users request a new feature, it will get priority over any other development.

Reason to ask this question

As testing needs constantly evolve and can change at a moment’s notice, knowing how to prioritise the assigned tests is crucial for effectively managing the workload. When the candidate understands the common factors that lead to changes in prioritisation, they can be more flexible in their job role and meet the changing demands accordingly.

Question 5: How do you know when it’s time to stop testing?

Testing can never be considered fully complete and needs to be carried out with each new improvement, feature, or bug fix. Testing can be regarded as completed when:

• All the requirements are tested (all possible test cases and combinations are tested)
• All the entry and exit criteria are met.
• No open critical and high bugs remain to be fixed.

Because testing needs to be completed within the allocated time, budget, and resources, it can be concluded when all agreed exit criteria have been met. The decision to “go live” is made by key stakeholders during a readiness or release meeting. This meeting is focused on whether sufficient risks have been mitigated by the outcomes reported from the testing effort.

Reason to ask this question

Understanding when to stop testing demonstrates the candidate knows how to properly scope the testing requirements according to the available resources. As an employer who can provide only a limited number of resources, a candidate who is better at managing resources while completing the tests will be preferable.

Question 6: How much time is enough time to test for a release?

A release can include features, optimisations, bug fixes, or a mixture of all these things. The time required for testing depends on what is being released and the risk it presents to the organisation.

To understand how much testing may be necessary, we need to assess the risks the release presents to the organisation. The following are some areas to consider to understand the risk testing needs to mitigate. This is by no means an exhaustive list:

• Size of the release, e.g. Is it impacting one system or many?
• Scope of changes included in the release, e.g. is the release delivering only new functionality or making enhancements to existing functionality?
• Will the release need to integrate with external parties? If it does, consideration must be given to connecting to their test environments.
• Data requirements and impacts, e.g. will production data need to be migrated from one system to another?
• Is the system using technology the organisation has not used in previous releases?
• Is the system “mission critical” to the organisation?
• Does the system have the potential to harm others?

The time required to mitigate the identified risks is then impacted by the number of available testers and resources needed for testing.

For example, a few days may be sufficient for a simple bug fix that affects a single component or one or two functional areas of the system. Compare this to a significant release where the test coverage must include regression, functional, and performance testing.

Reason to ask this question

Time management is crucial for any STLC. Understanding that the time required for testing depends on what is tested, which can take weeks or months. This demonstrates that the candidate is aware of the reality of a test environment and will not have unrealistic expectations.

Additionally, if the candidate mentions automation, it indicates they are somewhat familiar with the concept and can be utilised for automation if needed.

Question 7: What kind of challenges can testing present?

Testing can present multiple challenges, the primary one satisfying all the use cases. Despite how thoroughly the requirements are analysed and test cases created, there will be instances where an end-user will use the system in an unexpected way, only to discover a bug.

The other challenge is maintaining a balance between what can be tested and what should be tested. Testing should not be done for the sake of testing, and testing every aspect for even a minor change is not a scalable approach.

Deciding what should and needs to be tested is another challenge in the testing phase of development. It directly correlates to how best you can utilise the available resources to perform the necessary testing without overburdening testers.

Reason to ask this question

The candidate can be more effective when creating test cases if they understand the need for maintaining balance in what can and should be tested while adhering to scalability. It also demonstrates the candidate’s ability to manage available resources while adequately meeting the challenges in the test environment.

In most cases, candidates who know these factors will create test cases with reusability and scalability in mind. These two considerations assist in eliminating one-off test cases, organically improving the efficiency of the test environment.

Question 8: Tell me why bugs can still leak into production.

There will always be bugs that reach production without being caught in the testing stage. The following are some reasons why bugs “escape” from a testing stage:

• The prepared test cases did not capture the use case or behaviour adequately.
• The usage of the system by the end-users was not captured adequately enough in the use cases or requirements.
• The test analysis coverage and, therefore, the subsequent test techniques applied weren’t sufficient to capture the possible failure modes of the system.

Reason to ask this question

This question tests if the candidate knows there can be bugs that will not be captured during the testing phase. Acknowledging this factor shows that the candidate is honest and accepts that mistakes can happen or things can simply get missed when executing test cases. A candidate’s inability to accept this fact will most likely negatively impact their performance.

Question 9: What is the purpose of a test plan, and what should be included in a typical test plan?

A test plan is a document that details the activities planned for a testing project or a specific testing phase. A typical test plan document will consist of the following contents:

• The Scope of the Testing (systems, functionality, interfaces to be covered)
• The risks that the test plan is mitigating
• Roles and responsibilities
• The test objectives (as they apply to the test plan scope)
• The test strategy and approach
• The tools that will be used
• The test environment that will be needed
• Resources needed
• Testing schedule
• The deliverables to be produced
• The defect management process
• Exit and entry criteria for the test plan.

Reason to ask this question

This question will enable you to understand how the candidate has been performing testing in their current organisation – as well as identify their level of responsibility. A candidate can smoothly adapt to a new test organisation if they know the type of content found in a typical test plan. As the employer, reducing the time required for training allows you to gain the benefits of the new hire quickly.

The candidate may omit some of the above-listed items, so the employer needs to drill down further to understand why these items were not listed. The most common reason is that some test plan items are reusable across multiple projects and/or test phases. For example, the defect management process should be consistent and followed by everyone on the project. Instead of rewriting the defect process every time a new test plan is created, a reference to the defect management process document is added in the appropriate section.

Question 10: What is usability testing?

This testing method is used to better understand how the end-users interact with the software and the user experience (UX). Usability testing assesses the software for its user-friendliness and intuitiveness. It also considers whether the users find the software aesthetically pleasing, easy to navigate, and with consistent behaviour. The software design should be self-explanatory and easy to learn.

This testing can be done in the initial stages of the development pipeline using a prototype or mock-up software.

Reason to ask this question

The reason behind this question is twofold. Firstly, it helps identify if the candidate is familiar with usability testing.

Secondly, if they mention factors like prototypes or mock-up software, it shows that they are familiar with using them. A candidate familiar with these concepts will be effective for testing from a user-centric Point of View (POV).

Key skills of software testers

In today’s Agile software teams, the tester acts more like a quality coach for all their teammates. They help them think like testers and do exploratory testing to find bugs that may be present on any given project or task before it is completed – they will contribute to the automation code.

Software testers very often have unique perspectives that help them identify critical problems quickly, which develop over time with practice and experience. Whatever their view, transparency and integrity are two of the mandatory skills needed. And being an advocate for quality – being able to speak up when the situation calls for it.

Without these skills, the candidate is likely not well suited to undertake the role of a tester.

Curing the recruitment headache

If your hiring process is taking too long, then let luvo Talent help you find the skilled people you need. As a specialist recruitment agency that focuses on staffing for IT and digital roles, we can help build your IT team quickly. Please contact Luvo’s Talent Team to find out more.