GKV Software Solution

Manual Testing Interview Questions

The Top 15 Manual Testing Interview Questions

Do you have a Manual Testing Interview coming up? Personally, having attended diverse testing interviews, I have gathered the most common questions that I have faced on multiple occasions. Irrespective of the organization or candidate’s seniority, these questions are asked quite regularly and therefore require preparation before the QA interview.

1. What is the difference between verification and validation?

Answer:Verification is a checking process that involves evaluation of documents, design, code and program alongside checking whether specified requirements have been set. It is essentially, asking, are we building the product right?

Validation is a process of checking the final product against business requirements and user needs. It evaluates, are we building the right product?

It is important to note that verification comes first, proceeding validation and both processes are critical to complete quality assurance.

2. Discuss the disparity between defect severity and defect priority.

Answer: A defect’s severity is described by the impact it has on an application’s functionality. It’s usually classified into:

Critical: System failure, data corruption.

Major: A key feature does not work as anticipated

Minor: UI and spelling errors

Trivial: Cosmetic changes

Priority defines the necessity to fix a defect.

High: Fix immediately

Medium: Fix in current version or release.

Low: Future releases will not address the issue.

Defects may possess high severity yet low priority — a critical fault in a seldom-used feature — and conversely, low severity and high priority – an inconsequential yet visually blatant error on the homepage frequently accessed by users.

3. What are the differences between functional and non-functional testing?

Answer:Functional testing checks whether each function of the software is working according to the requirement specification. It pays attention to what the system does.

Non-functional testing looks into performance, usability, reliability, and security. It concentrates more on how well the system works rather than on particular actions.

For instance, confirming that a login feature correctly authenticates users is functional testing. Assessing the maximum number of users that can simultaneously log in without reducing performance is non-functional testing.

4. Explain regression testing and when should it be performed.

Answer: Regression testing involves re-executing functional and non-functional test cases in order to determine whether the software still works properly after changes have been made. The following changes may require regression testing:

Error corrections

Additions of new features

Refinements of software or systems

Alterations in configuration

Software Patches or changes in the environment

Regression testing is important in all cases where there is a modification regardless of the intent to ensure that the changes made do not disrupt already established operations.

5. What is a test case? What are the key components of a good test case?

Answer: A test case is defined as a predicated set of conditions and/or variables that will be used during an interaction to determine if the application operates as expected.

Key components of a good test case include:

Test Case ID and Title

Objective/Description

Pre-Requisites

Test Steps (Actions)

Expected Outcomes

Actual Outcomes

Evaluation Status (Pass/Fail)

Test environment specifics

Other factors related to the test

Prerequisites for the test data.

A test case should be reproducible, easy to understand, unambiguous, identifiable, cross-referenced with acceptable surveillance levels, and most importantly, adaptable.

6. What distinguishes black box, white box, and gray box testing from one another?

Answer:

Black Box Testing: This means the tester does not have knowledge of the internal structure or code. It centers on the given inputs and produced outputs. No knowledge of computer programming is needed from the testers.

White Box Testing: It is the exact opposite of black box. The tester has complete knowledge of the internal structure or code. Some programming knowledge is required to trace all the paths through the code.

Grey Box Testing: This is a blend of the two techniques. It is where the tester has some knowledge of the inner workings. For instance, a tester may appreciate the database tables but not the actual coding.

As a manual tester, I mostly execute black box testing, but knowing a little about the architecture aids in developing more robust test cases.

7. How do you respond to changes in requirements while still in the testing phase?

Answer: Whenever requirements evolve when one is already doing the testing:

Make sure you approve the changes and document them properly

Assess the impact of the changes on existing test cases and test plans

Amend the test documentation as required

Notify the relevant stakeholders about the possible effects on the set timelines

Do not forget to change priorities in the testing of the altered requirements

Think of the need for regression testing

Amend the matrix of the requirements that were initially outlined in the test cases when the new prerequisites were added.

It is essential to be flexible, but a change in management processes should be stored with documentation and will ensure that quality isn’t compromised.

8. Describe the life cycle of bugs.

Answer:In general, the life cycle of a bug has the following stages:

New – The bug is reported.

Assigned – It is assigned to a developer.

Open – The developer begins to work on it.

Fixed – The developer has implemented the fix.

Ready for Testing/Retest – QA has to verify the fix.

Verified – The QA has confirmed that the bug has indeed been altered.

Closed – The bug is said to be done.

Reopened – If the bug occurs again or the fix is considered not complete.

Deferred – The fix has been postponed.

Rejected – It has been deemed that this does not constitute a bug.

While the process may differ from one organization to another, these are the main states a defect goes through.

9. What is the difference between end-to-end testing and system testing?

Answer: End-to-end testing and system testing both have their specificities, however system testing is performed first. System testing evaluates the complete integrated software system and checks whether the system meets the requirements. It is performed on a software environment that replicates production as closely as possible.

Verifies whether the entire application functions from beginning to the end. End-to-end testing encompasses all integrations with external interfaces and data flows throughout the system, as well as user workflows spanning numerous subsystems.

End-to-end testing makes use of external dependencies and real-world scenarios, while system testing is done on the system as a singular entity.

10. How do you test a new feature when you don’t have much time?

Answer:In time-constrained situations:

Conduct a risk analysis to define the worst-case scenarios for the feature.

Focus on the test cases that include:

Primary functionality of the system cores

Top failure risk spots

Most commonly used routes

Critical business path scenarios

Utilize equivalence partitioning and boundary value analysis for test case reduction while maintaining coverage.

Exploratory testing allows efficient defect discovery, focus on gaps within existing features.

Proactively manage stakeholder communication and define the testing boundary and risks.

Provide coverage for time-constrained scenarios above that with documentation showing what was blocked due to time constraints.

Achieve the best quality assurance possible given the available resources.

11. What is exploratory testing and when would you use it?

Answer: Exploratory testing is simultaneous learning, test design, and test execution. Rather than following predefined test cases, the tester actively controls the testing process, designing and executing tests on the fly based on their understanding of the application.

I would use exploratory testing:

  • Early in development when requirements might be fluid
  • When documentation is limited
  • After formal testing to find edge cases
  • For time-constrained testing situations
  • When testing complex scenarios difficult to script in advance
  • To complement scripted testing for better coverage

Exploratory testing requires good domain knowledge and analytical skills to be effective.

12. How do you make sure that test coverage is sufficient?

Answer: So, for proper test coverage, the following steps can be applied.

Design a traceability matrix that shows the link between requirements and the test cases.

Apply different techniques to design the test like,

  • Equivalence partitioning
  • Boundary value analysis
  • Decision tables
  • State Transition Testing

Balance between positive and negative scenarios, cover all user workflows and business workflows, and retire all user business processes workflows:

Review test cases with colleagues and ensure all peer and stakeholder comments are incorporated.

Monitor cases with requirements using the total number of user requirements that are covered.

Use different types of testing such as functional, UI, performance, and others.

Apply risk based testing and focus on those areas that will have the greatest impact if left untested.

13.What is the difference between UAT and system testing?

Answer: A testing team conducts system testing to ensure that a specified system requirement is implemented.

This testing is about observing how the entire system behaves as a whole – its interactions and functionality. This is done within a controlled test environment framework.

User Acceptance Tests (UAT) is undertaken by a client or group of end users to ensure a developed software system meets their business needs before going live. UAT is interested in whether the software performs as required or expected in the intended environment, and actual scenarios and use-cases which resembles what will happen when it goes live. This is also referred to as a production-like or pre-production environment.

System testing, however, is focused on technical precision of the system checks, whereas for UAT testing, it’s about determining is the business problem intended solves the reasoning behind building the system.

14. What is UAT and how is it different from system testing?

Answer:The testing team validates the developed system during System Testing to check if it is meeting the requirements which have already been documented. It involves checking the interaction of every component within a system in a designated test environment.

This is done in the case of User Acceptance Testing (UAT) by the end user or client. This is conducted to check whether the system is aligning with their business needs in order to enable them to go Live. UAT emphasizes on the scenarios which are likely to be encountered once deployed and is conducted in an Environment similar to Production.

UAT ensures that the business problems faced are adequately addressed while system testing focuses most on confirming that all technical aspects of a system’s operation are functioning correctly.

15.Describe a challenging bug you found that was difficult to reproduce.

Answer: I once faced a bug with a financial application where the calculations seemed to become inaccurate. It was difficult due to the fact that the issue:

Happened seemingly at random every 50 to 60 calculations executed.

Was agnostic to any specific input.

Had no relation to system load.

Could not be replicated in a dev environment.

After sifting through the problem, I found the issue was reliant on matching several other criteria, such as:

Calculations needed to be completed in succession (under a second)

Decimal specifics needed to be certain in the preceding calc.

The locale had to be set to certain regions.

Once I documented the grotesque and outrageous requirements needed to create a scenario, I simplified it by parsing various decimal values across locales. It turned out the development team uncovered a bug where two threads competing for resources required to format a number that was only prepared if these very specific criteria were met.

From this problem, I learned how vital it is to accurately observe the conditions around the intermittent issues.

Conclusion:

The above highlighted manual testing interview questions should help you showcase both your experience and knowledge. Keep in mind that interviewers are not only interested in hearing the right answer but also your reasoning towards your answer, how you go about solving problems, and your hands-on experience with the scenarios.

For all the questions, emphasize the specifics of your experience/your background in testing to reinforce your expertise. Best of luck with your prep work for the interview!

×

Request a Quote