Manual scenario based IQ

1. What do you understand by software testing?

Software testing is a validation process which confirms that a system works as per the business
requirements. It qualifies a system on various aspects such as usability, accuracy,
completeness, efficiency, etc. ANSI/IEEE 1059 is the global standard that defines the basic
principles of testing.

2. When should you stop the testing process?

The testing activity ends when the testing team completes the following milestones.

Test case execution

The successful completion of a full test cycle after the final bug fix marks the end of the
testing phase.

Testing deadline

The end date of the validation stage also declares the closure of the validation if no critical or
high-priority defects remain in the system.

Code Coverage(CC) ratio

It is the amount of code concealed via automated tests. If the team achieves the intended level
of code coverage (CC) ratio, then it can choose to end the validation.

Mean Time Between Failure (MTBF) rate

Mean time between failure (MTBF) refers to the average amount of time that a device or
product functions before failing. This unit of measurement includes only operational time
between failures and does not include repair times, assuming the item is repaired and begins
functioning again. MTBF figures are often used to project how likely a single unit is to fail
within a certain period of time.
3. What do verification and validation mean in software testing?

In software testing, verification is a process to confirm that product development is taking

place as per the specifications and using the standard development procedures. The process
comprises the following activities:

 Inspections
 Reviews
 Walk-throughs
 Demos

Validation is a means to confirm that the developed product doesn’t have any bugs and is
working as expected. It comprises the following activities:

 Functional testing
 Non-functional testing

4. What is static testing? When does it start and what does it cover?

Static testing is a white-box testing technique that directs developers to verify their code with
the help of a checklist to find errors in it. Developers can start the static testing without
actually finalizing the application or program. Static testing is more cost-effective than
dynamic testing as it more areas than dynamic testing in a shorter time.

5. Define Black-box testing.

It is a standard software testing approach that requires testers to assess the functionality of the
software as per the business requirements. The software is treated as a black box and validated
as per the end user’s point of view.

6. What is a test plan and what does it include?

A test plan stores all possible testing activities to ensure a quality product. It gathers data from
the product description, requirement, and use case documents.

The test plan document includes the following:

 Testing objectives
 Test scope
 Testing the frame
 Environment
 Reason for testing
 Criteria for entrance and exit
 Deliverables
 Risk factors

7. What is meant by test coverage?

Test coverage is a quality metric to represent the amount (in percentage) of testing completed
for a product. It is relevant for both functional and non-functional testing activities. This
metric is used to add missing test cases.

8. Is it possible to achieve 100% testing coverage? How would you ensure it?

It’s considered not possible to perform 100% testing of any product. But you can follow the
below steps to come closer.

 Set a hard limit on the following factors:

o Percentage of test cases passed
o Number of bugs found
 Set a red flag if:
o Test budget is depleted
o Deadlines are breached
 Set a green flag if:
o The entire functionality gets covered in test cases
o All critical and major bugs must have a ‘CLOSED’ status

9. What are unit testing and integration testing?

Unit testing has many names such as module testing or component testing.

Many times, it is the developers who test individual units or modules to check if they are
working correctly.

Whereas, integration testing validates how well two or more units of software interact with
each other.

There are three ways to validate integration:

 Big Bang approach
 Top-down approach
 Bottom-up approach

10. Can we do system testing at any stage?

No. System testing should start only if all modules are in place and they work correctly.
However, it should be performed before UAT (user acceptance testing).

11. Mention the different types of software testing.

 Unit testing
 Integration testing
 Regression testing
 Shakeout testing
 Smoke testing
 Functional testing
 Performance testing

o Load testing
o Stress testing
o Endurance testing

 White-box and Black-box testing

 Alpha and Beta testing
 System testing

13. What is agile testing and why is it important?

Agile testing is a software testing process that evaluates software from the customers’ point of
view. It is favorable as it does not require the development team to complete coding for
starting QA. Instead, both coding and testing go hand in hand. However, it may require
continuous customer interaction.

14. What do you know about data flow testing?

It is one of the white-box testing techniques.

Data flow testing emphasizes for designing test cases that cover control flow paths around
variable definitions and their uses in the modules. It expects test cases to have the following
attributes:

1. The input to the module

2. The control flow path for testing
3. A pair of an appropriate variable definition and its use
4. The expected outcome of the test case

15. What is the purpose of the end-to-end testing?

End-to-end testing is a testing strategy to execute tests that cover every possible flow of an
application from its start to finish. The objective of performing end-to-end tests is to discover
software dependencies and to assert that the correct input is getting passed between various
software modules and sub-systems.

17. What will you do when a bug turns up during testing?

When a bug occurs, we can follow the below steps.

 We can run more tests to make sure that the problem has a clear description.
 We can also run a few more tests to ensure that the same problem doesn’t exist with
different inputs.
 Once we are certain of the full scope of the bug, we can add details and report it.

18. Why is it impossible to test a program thoroughly?

Here are the two principal reasons that make it impossible to test a program entirely.

 Software specifications can be subjective and can lead to different interpretations.

 A software program may require too many inputs, outputs, and path combinations.
19. How do you test a product if the requirements are yet to be freezed?

If the required specifications are not available for a product, then a test plan can be created
based on the assumptions made about the product. But we should get all assumptions well-
documented in the test plan.

20. If a product is in the production stage and one of its modules gets updated, then is it
necessary to ret

It is suggested to perform a regression testing and run tests for all the other modules as well.
Finally, the QA should also carry out a system testing.

21. How will you overcome the challenges faced due to the unavailability of proper
documentation for testing?

If the standard documents like System Requirement Specification or Feature Description

Document are not available, then QAs may have to rely on the following references, if
available.

 Screenshots
 A previous version of the application
 Wireframes

Another reliable way is to have discussions with the developer and the business analyst. It
helps in solving the doubts, and it opens a channel for bringing clarity on the requirements.
Also, the emails exchanged could be useful as a testing reference.

Smoke testing is yet another option that would help verify the main functionality of the
application. It would reveal some very basic bugs in the application. If none of these work,
then we can just test the application from our previous experiences.

22. Is there any difference between retesting and regression testing?

Possible differences between retesting and regression testing are as follows:

 We perform retesting to verify the defect fixes. But, the regression testing assures that the
bug fix does not break other parts of the application.
 Regression test cases verify the functionality of some or all modules.
 Regression testing ensures the re-execution of passed test cases.
Whereas, retesting involves the execution of test cases that are in a failed state.
 Retesting has a higher priority over regression. But in some cases, both get executed in
parallel.

23. As per your understanding, list down the key challenges of software testing.

Following are some of the key challenges of software testing:

 The lack of availability of standard documents to understand the application

 Lack of skilled testers
 Understanding the requirements: Testers require good listening and understanding
capabilities to be able to communicate with the customers the application requirements.
 The decision-making ability to analyze when to stop testing
 Ability to work under time constraints
 Ability to decide which tests to execute first
 Testing the entire application using an optimized number of test cases

24. What are the different types of functional testing?

Functional testing covers the following types of validation techniques:

 Unit testing
 Smoke testing
 UAT
 Sanity testing
 Interface testing
 Integration testing
 System testing
 Regression testing

25. What are functional test cases and non-functional test cases?

 Functional testing: It is testing the ‘functionality’ of a software or an application under

test. It tests the behavior of the software under test. Based on the requirement of the client,
a document called a software specification or requirement specification is used as a guide
to test the application.
 Non-functional testing: In software terms, when an application works as per the user’s
expectation, smoothly and efficiently under any condition, then it is stated as a reliable
application. Based on quality, it is very critical to test these parameters. This type of
testing is called non-functional testing.

26. What do you understand by STLC?

Software testing life cycle (STLC) proposes the test execution in a planned and systematic
manner. In the STLC model, many activities occur to improve the quality of the product.

The STLC model lays down the following steps:

1. Requirement Analysis
2. Test Planning
3. Test Case Development
4. Environment Setup
5. Test Execution
6. Test Cycle Closure

27. In software testing, what does a fault mean?

Fault is a condition that makes the software fail to execute while performing the considered
function.

28. Difference between Bug, Defect, and Error.

A slip in coding is indicated as an error. The error spotted by a manual tester becomes a defect.
The defect which the development team admits is known as a bug. If a built code misses on
the requirements, then it is a functional failure.
29. How do severity and priority relate to each other?

Severity: It represents the gravity/depth of a bug. It describes the application point of view.

Priority: It specifies which bug should get fixed first. It defines the user’s point of view.

30. List the different types of severity.

The criticality of a bug can be low, medium, or high depending on the context.

 User interface defects – Low

 Boundary related defects – Medium
 Error handling defects – Medium
 Calculation defects – High
 Misinterpreted data – High
 Hardware failures – High
 Compatibility issues – High
 Control flow defects – High
 Load conditions – High

Advanced Interview Questions

31. What do you mean by defect detection percentage in software testing?

Defect detection percentage (DDP) is a type of testing metric. It indicates the effectiveness of
a testing process by measuring the ratio of defects discovered before the release and reported
after the release by customers.

For example, let’s say, the QA has detected 70 defects during the testing cycle and the
customer reported 20 more after the release. Then, DDP would be: 70/(70 + 20) = 72.1%

32. What does defect removal efficiency mean in software testing?

Defect removal efficiency (DRE) is one of the testing metrics. It is an indicator of the
efficiency of the development team to fix issues before the release.
It gets measured as the ratio of defects fixed to total the number of issues discovered.

For example, let’s say, there were 75 defects discovered during the test cycle while 62 of them
got fixed by the development team at the time of measurement. The DRE would be 62/75 =
82.6%

33. What is the average age of a defect in software testing?

Defect age is the time elapsed between the day the tester discovered a defect and the day the
developer got it fixed.

While estimating the age of a defect, consider the following points:

 The day of birth of a defect is the day it got assigned and accepted by the development
team.
 The issues which got dropped are out of the scope.
 Age can be both in hours or days.
 The end time is the day the defect got verified and closed, not just the day it got fixed by
the development team.

34. How do you perform automated testing in your environment?

Automation testing is a process of executing tests automatically. It reduces human intervention

to a great extent. We use different test automation tools like QTP, Selenium, and WinRunner.
Testing tools help in speeding up the testing tasks. These tools allow you to create test scripts
to verify the application automatically and also to generate the test reports.

35. Is there any difference between quality assurance, quality control, and software
testing. If so, what is it?

Quality Assurance (QA) refers to the planned and systematic way of monitoring the quality of
the process which is followed to produce a quality product. QA tracks the test reports and
modifies the process to meet the expectation.
Quality Control (QC) is relevant to the quality of the product. QC not only finds the defects
but suggests improvements too. Thus, a process that is set by QA is implemented by QC. QC
is the responsibility of the testing team.

Software testing is the process of ensuring that the product which is developed by developers
meets the users’ requirements. The aim of performing testing is to find bugs and make sure
that they get fixed. Thus, it helps to maintain the quality of the product to be delivered to the
customer.

39. Tell me the key elements to consider while writing a bug report.

An ideal bug report should consist of the following key points:

 A unique ID
 Defect description: A short description of the bug
 Steps to reproduce: They include the detailed test steps to emulate the issue. They also
provide the test data and the time when the error has occurred
 Environment: Add any system settings that could help in reproducing the issue
 Module/section of the application in which the error has occurred
 Severity
 Screenshots
 Responsible QA: This person is a point of contact in case you want to follow-up regarding
this issue

40. Is there any difference between bug leakage and bug release?

Bug leakage: Bug leakage is something, when the bug is discovered by the end user/customer
and missed by the testing team to detect while testing the software. It is a defect that exists in
the application and not detected by the tester, which is eventually found by the customer/end
user.

Bug release: A bug release is when a particular version of the software is released with a set
of known bug(s). These bugs are usually of low severity/priority. It is done when a software
company can afford the existence of bugs in the released software but not the time/cost for
fixing it in that particular version.
41. What is the difference between performance testing and monkey testing?

Performance testing checks the speed, scalability, and/or stability characteristics of a system.
Performance is identified with achieving response time, throughput, and resource-utilization
levels that meet the performance objectives for a project or a product.

Monkey testing is a technique in software testing where the user tests the application by
providing random inputs, checking the behavior of the application (or trying to crash the
application).

42. What is exploratory testing?

Exploratory testing is an approach to software testing, wherein testers learn simultaneously

about the test design and test execution. In other words, it is a hands-on approach where testers
are involved more in the test execution part than in planning.

43. What is meant by system testing?

System testing is a black-box testing technique, used on a complete integrated system, where it
will test the system compliance as per the requirement.

44. What are the benefits of test reports?

Test reports will help us find the current status of a project and its quality. This can help
stakeholders and customers take necessary actions. The complete documentation of test reports
will help analyze different phases of the project.

45. What is meant by latent defect?

A latent defect is a hidden defect in an application/software, which cannot be identified by a

user. However, this will not cause any failure to the application because the conditions will
never be met.
Q.46.If we are getting bugs in every builds what will be the first approach
Ans:
1. the First step will be to log the bugs.
2. Will first test the critical and high priority test cases
3. One person should start retesting the bugs and another person should start regression. Once
the 1st guy has finished the retesting of bugs he can join you in regression.
4. It seems a deployment issue or the environment of QA environment is different from Prod.

 if you need more time to complete any task and the given time is very less what will you
do as a tester?
 you have 20 bugs and you need to fix it as well as u need to run the regression and you
are only 2 people in a team how will you do it and which one you will give priority?
if some function is working in the testing environment and the same is not working in
production what will be your approach?
 Scenario-based questions … please suggest your approach
 A scenario 1000 links in the webpage and some links are open in a new tab and some
links are open in a new window. How to handle this scenario.

What is Test Release Document and Test Report Document?

Ans: Test Release Document is a document that covers all the testing related information like
what are the features/module are tested and types of testing done on the product also what
types of testing not done on the product, also what is the environment on which product is
tested and all the release information related to that product.
Test Report Document is a document that covers no. of the pass, no. of fails, the percentage of
pass and percentage of fail, etc.

What is the difference between Project Testing and Product Testing?

Ans: Project testing defines that we are testing the developed software or application
according to a specific client requirement or a customer requirement. In Project testing, we
only test a part of the requirement document, which used in that particular project only.
Product testing defines that we are testing the developed software or application according to
the market demand or analysis(requirement) of multiple customers. Product testing, we test all
the required documents used in the whole product.
How many Test cases can you execute at the time of doing Regression Testing?
Ans: It depends on how many test cases we have identified for doing regression testing, also
depends on the timeframe within which we need to execute. If we are performing Unit
Regression Testing on the application, then we are testing a particular feature in a form where
that particular feature is not dependent upon the other features of the application. For example,
If a help document has a defect and PDF file was not opening, then the tester will test only that
defect why PDF file was not opening because it was not dependent upon the other part of the
application again, if a developer did a mistake and type “Username” instead of typing
“UserName” than the tester will test only the UserName function because it was not dependent
upon the other parts of the application. In this case, I have to execute fewer test cases, i.e., 4-5
test cases per day are enough. Again, If we are performing Regional Regression Testing on the
application, i.e., we are testing a particular feature in an application regionally where the
features are dependent upon only some regions of that particular application, but not
dependent upon the other regions of that particular application. For example, if the Compose
feature has a defect and it was not working properly in Gmail Application, then it will cause an
effect on the Inbox feature, Sent Item feature, Draft feature, Spam feature, and Trash feature
only. As Username feature, Forgot Password feature, Help feature, and Settings feature are not
dependent on the Compose feature. So, we can’t perform Regional Regression Testing on
Username feature, Forgot Password feature, Help feature, and Settings feature. We will
perform Regional Regression Testing only on Inbox feature, Sent Item feature, Draft feature,
Spam feature, and Trash feature.

In this case, I have to execute a little bit number of test cases, i.e., 10-12 test cases per day are
enough because at first, we have to identify the impacted regions. Then we perform Regional
Regression Testing only on those regions. Again, If we are performing Full Regression
Testing on the application, i.e., we go and test the whole application whenever the application
changes or new features added. Here, we are re-executing the same test cases on different
build and releases to ensure new features added or modification done has not introduced a
defect in the older part of the application. For example, we have to perform Full Regression
Testing on ICICI bank software because their entire business is dependent on that software.
Again, if “wscript.exe” has any defect, then we have to perform Full Regression Testing on
that because entire VB Scripting is dependent on “wscript.exe.” In this case, I have to execute
the number of test cases, i.e., 15-20 test cases per day are enough.
Explain the Bug Lifecycle?
Ans: Defect: A fault in a program, which causes the program to perform in an unintended or unanticipated
manner. Defect Life Cycle (Bug Lifecycle) is the journey of a defect from its identification to its closure. The
Life Cycle varies from organization to organization and governed by the software testing process, the
organization or project follows and/or the Defect tracking tool being used.

 New: When QA files a new bug.

 Assigned: ‘Assigned to’ field is set by the lead or manager and assigns the bug to the
developer.
 Could not reproduce: If the developer is not able to reproduce the bug by the steps given in
the bug report by QA, then the developer can mark the bug as ‘CNR.’ QA needs action to
check if the bug is reproduced and can assign to a developer with detailed reproducing steps.
 Need more information: If the developer is not clear about the bug reproduce steps provided
by QA to reproduce the bug, then he/she can mark it as “Need more information’. In this case,
QA needs to add detailed reproducing steps and assign the bug back to dev for the fix.
 Deferred: If the bug is not related to current build or cannot be fixed in this release or bug is
not important to fix immediately, then the project manager can set the bug status as deferred.
 Rejected/Invalid: Sometimes, the developer or team lead can mark the bug as Rejected or
invalid if the system is working according to specifications and bug is just due to some
misinterpretation.
 Resolved/Fixed: When a developer makes necessary code changes and verifies the changes,
then he/she can make bug status as ‘Fixed,’ and the bug passed to the testing team.
 Reopen: If QA is not satisfied with the fix and if the bug is still reproducible even after fix,
then QA can mark it as ‘Reopen’ so that the developer can take appropriate action.
 Closed: If the QA team verifies the bug and if the fix is ok and the problem is solved, then QA
can mark the bug as ‘Closed.’

What is the test plan? .

Ans: The Test Plan document derived from the Product Description, Software Requirement Specification
SRS, or Use Case Documents. The Test Lead or Test Manager usually prepare the Test Plan document, and
the focus of the document is to describe what to test, how to test when to test and who will do what test. It is
common to have one Master Test Plan, which is a common document for the test phases and each test phase
have their Test Plan documents. Typically Test Plan will have the following.
 Test Plan id
 Introduction
 Test items
 Features to be tested
 Features not to be tested
 Test techniques
 Testing tasks
 Suspension criteria
 Features pass or fail criteria
 Test environment (Entry criteria, Exit criteria)
 Test deliverable
 Staff and training needs
 Responsibilities
 Schedule

This is a standard approach to prepare test plan, but things can vary company
company-to-company
company.
Q.smoke ans sanity.

Q.SDLC AND STLC

Q.RTM