Table of Contents

 1. What are the different types of manual testing

Manual testing has three types of testing: white-box, black-box and grey-box testing.

  • White-Box Testing: It is an approach that allows testers to inspect and verify the internal implementation of the software.
  • Black-Box Testing: It is an approach that allows testers to test without having any knowledge of the internal implementation. It is just to check whether it is meeting the customer’s requirements without any knowledge of the code.
  • Grey-Box Testing: In this approach, we test the software with some knowledge of the code. It is a blend of both white-box and black-box testing.

2. How do you explain STLC?

STLC stands for software testing life cycle. Software testing life cycle is the whole process of how testing is performed, and what are the phases involved. The testing life cycle consists of six phases:

  • Requirement analysis
  • Test planning
  • Test case development
  • Test environment setup
  • Test Execution
  • Test cycle closure.

So, it starts with the requirements gathering, where a requirement document is shared with the team. After going through the requirement documents, the test planning is done. The test plan is a document describing the approach, resources and scheduling of the testing activities. Next, we develop test cases for the functional and non-functional specifications in the test case development phase. After this phase, the environment is set feasible to start testing. After the environment is set, test cases are executed and lastly, the closure of the whole life cycle is done and a report is generated.

3. Can you explain SDLC?

SDLC stands for Software Development Life Cycle. The development process adopted in every project is according to its aims and goals. There are six phases involved in SDLC.

  • Requirements Gathering
  • Design
  • Development/implementation
  • Testing
  • Deployment
  •  Maintenance

SDLC starts with the requirements gathering, then the design is implemented as per the requirement analysis. After the design is ready, it’s been given to the development team for implementation. After implementation, the product goes into the testing phase. After the product is successfully tested, it is deployed. After deployment, the product is regularly maintained after the user starts using it.

4. Explain the Waterfall model.

This model is in a linear sequential manner. This development model involves executing each phase and then going into the next phase.


  • Suitable for small and mid-size products with fixed requirements.
  • Easy to determine the critical points in each phase.
  • Best when there are enough resources.


  • Testing happens at the end of the project, so the defects tracked are close to the implementation.
  • Not suitable for the projects having frequent changes in requirements.
  • Resources have to sit idle and wait for the phases to complete. For example, if the project is in the development phase, then testers have to sit idle and wait for the development phase to complete.
  • Backtracking is not possible as requirements are constant.

5. Explain V- Model.

As the name suggests, the testing and development life cycle run parallel, the one side of V is verification (development) and the other side is validation (verification). Hence this is also called the Verification and Validation model as well. This model is an extension of the waterfall model, the only difference is that the process steps are bent upwards after the coding phase, to form a typical V shape.


  • Designed for small and medium-sized projects.
  • Better than the waterfall model as it allows to test the software side by side.
  • V-model provides guidance that testing needs to begin as early as possible.
  • It has four Test levels- component, integration, system, and acceptance testing.
  • Defect tracking is easy.


  • Lack of flexibility.
  • Changing requirements at the later phase could cost high.
  • High business and development risk.

6. What are test cases?

It is a document that has the steps that have to be executed. This document is planned before the test case execution phase.

7. How do you explain the test case format?

A test case format has the following fields:

  • Test case ID
  • Test case Description
  • Severity
  • Priority
  • Test Data
  • Environment
  • Build Version
  • Steps to execute
  • Expected Results
  • Actual Results

8. What is a test plan?

Test planning is done before the start of testing activities. It is a document specifying the strategy, scope, approach, resources and schedule of the testing activities. It should cover the following details:

  • Test strategy
  • Test objective
  • Exit/suspension criteria
  • Resource planning
  • Test deliverables

9. Is it possible to do exhaustive testing? How much testing is sufficient.

It is impossible to test everything, instead, we can focus on prioritizing test cases. An extensive test that finds more bugs doesn’t mean we have discovered every defect. Since exhaustive testing is not practical, our best approach as a tester is to pick those test cases that are most likely to find bugs.

10. When should we start doing testing?

We should start testing as early as possible. The earlier a bug is tracked, the better it will be for the software. A bug tracked early can save money and time as well.

11. What is the difference between Quality Assurance (QA) and Quality Control (QC)?

Quality assurance involves process-oriented activities. It ensures the prevention of defects while developing software applications.

Quality Control involves product-oriented activities. It executes code to identify the defects in the software application.

12. Can you explain Bug Life Cycle?

Bug life cycle mainly refers to the entire phases of detecting a new bug/defect by a tester to closing that bug by the tester. Below diagram describes the stages for a bug life cycle:

In the first stage, a new bug is detected by the tester. The bug is documented by the tester and the tester shares the document with the development team. The project manager will then assign the bug to the development team and it comes under the “assigned” state. When the development team starts working on the defect, it is in an “open” state. In the open state, the bug is classified into different states, duplicate, rejected, deferred, not a bug.

Let’s discuss these states of bugs that developers can assign:

  • Rejected: If the defect is not considered as a genuine defect by the developer then it is marked as ‘Rejected’ by the developer.
  • Duplicate: If the developer finds the defect as same as any other defect or if the concept of the defect matches any other defect then the status of the defect is changed to ‘Duplicate’ by the developer.
  • Deferred: If the developer feels that the defect is not of very important priority and it can get fixed in the next releases or so in such a case, he can change the status of the defect as ‘Deferred’.
  • Not a Bug: If the defect does not have an impact on the functionality of the application then the status of the defect gets changed to ‘Not a Bug’.

Next, when the developer fixes the bug and assigns the state to “fixed”. After fixing the defect, when the developer shares the code to the tester for retesting, the tester assigns a stage “Pending Retest”. When the tester starts retesting, the state is “Retesting”. If the bug still persists, the tester assigns it again to the development team and the state is “Re-open”. If the tester verifies the bug and finds out it is fixed, then he assigns a state as “Verified”. If everything is done and the tester confirms the bug is fixed and he has completed re-testing and the bug no more exists, the bug is assigned to the “Closed” state.

13. What is the difference between Manual testing and A