1. What do you understand with testing? 

Testing is a set of activities to test the software with the intent to find maximum defects. It is a mapping between the expected result with the actual result. Finding defects helps deliver quality software that meets users’ requirements.

2. What is the role of testing?

The role of testing is to ensure key functional and non-functional user requirements. Testing comes after the development phase in software development. It is very important to do the right amount of testing so that the user gets a quality and bug-free product.

3. What are the different types of testing?

There are two types of testing, Manual and Automation. And then, there are subsets 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.

4. What are the different testing levels?

Software testing is a process of testing software to ensure that the product is delivered bug-free to the customer. Levels of software testing ensure that no component is left without testing. There are different levels of testing, each has its own role to perform.

There are four levels of testing:

• Unit/component testing
• Integration testing
• System testing
• Acceptance testing

5. Can you explain the difference between STLC and SDLC?

The software development life cycle is the process of the overall software development process beginning from requirements gathering to the deployment and the maintenance of the product.

Whereas,

Testing is a phase of the development life cycle and the processes involved in the testing come under the software testing life cycle.

6. How do you explain STLC?

• 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.

7. 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.

8. What are the software testing principles?

There are seven principles of software testing:

• Testing shows the presence of defects:
• Testing can show that there are defects present, but it cannot prove that there are no defects. Testing reduces the probability of defects in the software, but if no defect is found, it’s no proof of correctness either.
• Exhaustive testing is possible:
• Testing everything (all possible inputs and preconditions) is not feasible except for trivial cases. Instead of an exhaustive test, the focus should be more on prioritizing the tests according to the risks involved.
• Early testing:
• Testing activities should start as early as possible. Defects found in the early stages will save more money and time in later stages.
• Defect clustering:
• It is also known as the “Pareto principle” and it says that approximately 80% of defects are found in about 20% of the module. It depends on system/software complexity, volatile code, effects of change upon change, development staff experience, development staff inexperience.
• Pesticide paradox:
• If the same set of tests is repeated over and over again, they may no longer be able to find any defects. To overcome this problem, test cases need to be reviewed and revised regularly.
• Testing is context-dependent:
• Testing is done differently in different circumstances/contexts. Risk can be a larger factor in determining the type of testing involved to test in different scenarios. The higher the possibility of losses, the more we need to invest in testing the software before it is implemented. E-commerce and online book websites are entirely different from each other, so is testing.
• Absence-of-errors fallacy:
• Finding and fixing defects will not help if the system doesn’t meet the user requirements. Software with no known errors is not necessarily ready to be implemented.

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. What are test cases?

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

11. 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

12. 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

13. 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.

14. 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.

15. 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.

16. What is the difference between Manual testing and Automation testing?

Manual Testing is verifying the software manually and finding defects without the intervention of any tools. The tester has to execute each test case one by one. They manually verify the software as an end-user would. They give input and manually verify the output.

Automation Testing is testing the software with the help of some automation tools like Selenium. The code is run for automating tests and the input data is given to the tool. The output data is then compared with the expected results. Automation testing is generally performed for repeated tasks so that the time can be saved.

17. What do you understand by Unit Testing?

Testing the smallest piece of code is called unit testing.

18. What is Verification and Validation?

Verification is a static testing technique. Testing is done without executing the code in verification. Examples are reviews, walkthroughs and inspection.

Validation is a dynamic testing technique where testing is done by executing the code. Examples are functional and non-functional testing techniques.

 In the V model, both these activities go simultaneously.

19. How can you explain the difference between Black Box Testing and White Box Testing?

White-Box Testing is an approach that allows testers to inspect and verify the internal implementation of the software.

Black-Box Testing 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.

20. What is your understanding of Regression Testing?

Regression Testing is performed after re-testing. It is performed on the unchanged part after the bug fixes. In regression testing, software application is tested to make sure that a change is not going to affect the functionality.

21. What is the difference between System Testing and User Acceptance Testing (UAT)?

User Acceptance Testing (UAT) is the last step before the product goes live or before the delivery of the product is accepted. UAT is done after the product itself is thoroughly tested.

System Testing is the level of testing where complete and integrated software is tested. The purpose of this test is to evaluate the system’s compliance with the specified requirements.

22. 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.
• 
  

Merits:

• 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.

Demerits:

• 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.

23. 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.

Merits:

• 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.

Demerits:

• Lack of flexibility.
• Changing requirements at the later phase could cost high.

24. What is the need for Automation Testing?

Automation testing has some benefits over manual testing.

• Performed when there is a need for test cases to be run repeatedly for a long duration of time.
• Performed when the tests include repetitive steps.
• Enables parallel execution and encourages unattended execution.
• Saves time and money.
• Improves accuracy thereby reducing human-generated errors.

25. Why Selenium is a preferred tool for Automation Testing?

Selenium is preferred because it is open-source software and it supports major languages like Java, C#, Python, Ruby etc. It is used for automating the tests carried out on web browsers. Selenium supports major OS like Windows, Mac and Linux. It is also a preferred tool as it supports major browsers like Mozilla Firefox, Microsoft Bing, Google Chrome, Safari and Opera. It can be integrated with the tools like TestNG and Junit for managing test cases and generating reports. It can be integrated with Maven, Jenkins and Docker to achieve continuous testing.

26. Why do you want to choose software testing as your career?

Testing might not be very appealing but It’s a role where one gets to know about cutting edge technologies and gain cross-functional skills that can be used across the whole software development life cycle. Testing is a flexible career because of the business and technically-focused roles. As a tester you work on projects from start to end, you get an opportunity to interact with high-level stakeholders. Interacting with different groups of people improves communication skills as well.

27. Suppose you find a bug in production. How would you make sure that the same bug is not introduced again?

Finding a bug in production can be very challenging. To make sure the same bug is not introduced again, we need to add that uncaught functionality to regression test cases. If we have an automated regression suite, then we need to write a new script that validates the above functionality.

28. What is your approach when you have a very high priority release to be delivered in a way short period of time?

When having a high priority release to be delivered and the time is less, then a tester must keep certain things in mind:

• He/she must run automation suites.
• He/she must run unit tests.
• A tester must do the manual testing on high-level priority business test cases.

29. What are your daily activities as a member of the automation test team in your office?

As a member of the automation test team, the daily activities performed can be:

• Running smoke suite on daily basis and sending the mail to the team on health of the application
• Verify defects assigned to you and take appropriate actions.
• Working on manual and automation testing for the user stories in the current sprint, assuming that you are working on agile methodology.

30. How do you solve if there is any conflict with your peer QA on any technical aspect?

There should be an argument but only up to a certain extent with your peer on why you are correct. If the conflict still persists then involve the team and discuss the conflict issues with larger audiences that may be other QAs, development team and scrum masters. In the meeting, you can have open suggestions and get the right direction. You must accept any decision made from the team meeting with a smile.