Define testing.

Software testing is the process of evaluating a system to check if it satisfies its business
requirements. It measures the overall quality of the system in terms of attributes. Like –
correctness, completeness, usability, performance, etc.

Explain SDLC.
The Software Development Life Cycle (SDLC) is a structured process that enables the production
of high-quality, low-cost software, in the shortest possible production time. The goal of the SDLC
is to produce superior software that meets and exceeds all customer expectations and demands.
The SDLC defines and outlines a detailed plan with stages, or phases, that each encompass their
own process and deliverables.

Requirement Phase

Requirement gathering and analysis is the most important phase in the software development
lifecycle. Requirement phase is the first step of the SDLC. Business Analyst collects the requirement
from the Customer/Client as per the clients business needs and documents the requirements in the
Business Requirement Specification (document name varies depends upon the Organization. Some
examples are Customer Requirement Specification (CRS), Business Specification (BS), etc., and
provides the same to Development Team.

Analysis Phase

Once the requirement gathering and analysis is done the next step is to define and document the
product requirements and get them approved by the customer. This is done through the SRS
(Software Requirement Specification) document. SRS consists of all the product requirements to be
designed and developed during the project life cycle. Key people involved in this phase are Project
Manager, Business Analyst and Senior members of the Team. The outcome of this phase is the
Software Requirement Specification.

Design Phase

It has two steps:

HLD – High-Level Design – It gives the architecture of the software product to be developed and is
done by architects and senior developers
LLD – Low-Level Design – It is done by senior developers. It describes how each and every feature in
the product should work and how every component should work. Here, only the design will be there
and not the code
The outcome from this phase is High-Level Document and Low-Level Document which works as an
input to the next phase
Coding/Development Phase

Developers of all levels (seniors, juniors, freshers) involved in this phase. This is the phase where we
start building the software and start writing the code for the product. The outcome from this phase is
Source Code Document (SCD) and the developed product.

Testing Phase

When the software is ready, it is sent to the testing department where Test team tests it thoroughly
for different defects. They either test the software manually or using automated testing tools
depends on the process defined in STLC (Software Testing Life Cycle) and ensure that each and
every component of the software works fine. Once the QA makes sure that the software is error-free,
it goes to the next stage, which is Implementation. The outcome of this phase is the Quality Product
and the Testing Artifacts.

Deployment & Maintenance Phase

After successful testing, the product is delivered/deployed to the customer for their use. Deployment
is done by the Deployment/Implementation engineers. Once when the customers start using the
developed system then the actual problems will come up and needs to be solved from time to time.
Fixing the issues found by the customer comes in the maintenance phase. 100% testing is not
possible – because, the way testers test the product is different from the way customers use the
product. Maintenance should be done as per SLA (Service Level Agreement)

Explain STLC.
Software Testing Life Cycle (STLC) is a sequence of specific activities conducted during the testing
process to ensure software quality goals are met. STLC involves both verification and validation
activities. Contrary to popular belief, Software Testing is not just a single/isolate activity, i.e. testing. It
consists of a series of activities carried out methodologically to help certify your software product.
STLC stands for Software Testing Life Cycle.

Requirement Analysis
Test Planning
Test case development
Test Environment setup
Test Execution
Test Cycle closure
Activities in Requirement Phase Testing

Identify types of tests to be performed.

Gather details about testing priorities and focus.
Prepare Requirement Traceability Matrix (RTM).
Identify test environment details where testing is supposed to be carried out.
Automation feasibility analysis (if required).

Test Planning Activities

Preparation of test plan/strategy document for various types of testing

Test tool selection
Test effort estimation
Resource planning and determining roles and responsibilities.
Training requirement

Test Case Development Activities

Create test cases, automation scripts (if applicable)

Review and baseline test cases and scripts
Create test data (If Test Environment is available)

Test Environment Setup Activities

Understand the required architecture, environment set-up and prepare hardware and software
requirement list for the Test Environment.
Setup test Environment and test data
Perform smoke test on the build.

Test Execution Activities

Execute tests as per plan

Document test results, and log defects for failed cases
Retest the Defect fixes
Track the defects to closure

Test Cycle Closure Activities

Prepare test metrics based on the above parameters.

Document the learning out of the project
Prepare Test closure report
Qualitative and quantitative reporting of quality of the work product to the customer.
What is the fundamental test process?

● Planning and Control

● Analysis and Design
● Implementation and Execution
● Evaluating exit criteria and Reporting
● Test Closure Activities

Planning and Control

To determine the scope and risks and identify the objectives of testing.
To determine the required test resources like people, test environments etc.
To schedule test analysis and design tasks, test implementation, execution and evaluation.

Analysis and Design

To review the test basis. The test basis is the information on which test cases are based, such
as requirements, design specifications, product risk analysis, architecture and interfaces
To identify test conditions
To design the tests
To design the test environment set-up and identify the required infrastructure and tool

Implementation and Execution

To develop and prioritize test cases by using techniques and create test data for those tests.
To create test suites from the test cases for efficient test execution. Test suite is a collection of
test cases that are used to test a software program
To re-execute the tests that previously failed in order to confirm a fix.
To log the outcome of the test execution. A test log is the status of the test case (pass/fail).
To compare actual results with expected results.

Evaluating Exit criteria and Reporting

The exit criteria of each project comes into picture when

Maximum test cases are executed with certain pass percentage

The bug rate falls below certain level
The deadlines are achieved

The major tasks involved in evaluating exit criteria are as follows

To check the test logs against the exit criteria mentioned in test planning
To assess whether more tests are needed or if the exit criteria specified for the project should
be changed
To write a test summary report for the stakeholders or clients

Test Closure Activities

To check which planned deliverables are successfully delivered and to ensure that all the
incident reports found during testing have been successfully resolved
To finalize and archive testware such as scripts, test environments, etc. for later reuse
To handover the testware to the maintenance organization
To evaluate the coverage of testing and to learn useful information for future releases and
projects

What is Verification?
Verification is the process, to ensure that whether we are building the product right i.e., to
verify the requirements which we have and to verify whether we are developing the product
accordingly or not. Activities involved here are Inspections, Reviews, Walk-throughs.

What is Validation?
Validation is the process, whether we are building the right product i.e., to validate the product
which we have developed is right or not. Activities involved in this is Testing the software
application.

What is White Box Testing?

White Box Testing is also called as Glass Box, Clear Box, and Structural Testing. It is based
on applications internal code structure. In white-box testing, an internal perspective of the
system, as well as programming skills, are used to design test cases. This testing usually was
done at the unit level.

White Box Testing Techniques:

Statement Coverage
Branch Coverage
Path Coverage

Statement coverage:
It makes sure that each line of source code has been executed and tested.

Decision coverage:
It ensures that every decision (true/false) in the source code has been executed and tested.
Path coverage:
It ensures that every possible route through a given part of the code is executed and tested.

What is Black Box Testing?

Black Box Testing is a software testing method in which testers evaluate the functionality of
the software under test without looking at the internal code structure. This can be applied to
every level of software testing such as Unit, Integration, System and Acceptance Testing.

Black Box Testing Techniques (EBEDS)

1.Error guessing
2.Boundary value analysis
3.Equivalence partioning
4.Decision Table Technique
5.State Transition Technique
Following are some of the most common types of black-box testing techniques.

Cause-effect graph - A cause-effect graph testing is carried out using a graphical

representation of input i.e. cause and output i.e. effect. We can find the coverage of cause-effect
graphs based on the percentage of combinations of inputs tested out of the total possible
combinations.

Error Error guessing is a technique in which there is no specific method for identifying the error.

Guessing It is based on the experience of the test analyst, where the tester uses the experience to

Technique guess the problematic areas of the software.

Boundary Boundary Value Technique is used to test boundary values, boundary values are those that

Value contain the upper and lower limit of a variable. It tests, while entering boundary value

Technique whether the software is producing correct output or not.

. For example: If a particular field accepts the Values from 1 to 1000, then we test that field by
entering only 1, 1000, 0, 1001, 999, 2. I.e. we check on the boundaries and then Minimum-1,
minimum +1 and maximum+1, maximum-1

In boundary value analysis the answers are within specific boundaries. The two ends, the
inner and the outer limits are considered in this type of testing. For example, an offer is
valid for customers between the ages of 18 and 30 only. Therefore other values such as
17, 18, 30, or 31 can be tested to check whether the inputs are accepted.

Equivalence Equivalence partitioning is a technique of software testing in which input data divided

Partitioning into partitions of valid and invalid values, and it is mandatory that all partitions must

Technique exhibit the same behavior.

E.g. for software that finds the square of a number, we can have different equivalence classes
like – all positive numbers, negative numbers, decimal numbers, negative decimal numbers,
etc. Its advantage is – the overall test execution time reduces as the number of test data
greatly reduces.

Test Scenario- In order to get a driving license the age of applicant should be between 18 to
49 years. There will be 3 (three) partition where tester should check possibility

i) If applicant’s age is less than or equal to 17 years – Invalid

ii) If applicant’s age is between 18 to 49 years. – Valid

iii) If applicant’s age is greater than or equal to 50 – Invalid

So there will be 3 possible scenarios where only one valid group of applicant having age is
between 18 to 49 years, will get driving license.
Decision Decision Table Technique is a systematic approach where various input combinations and

Table their respective system behavior are captured in a tabular form. It is appropriate for the

Technique functions that have a logical relationship between two and more than two inputs.

State State Transition Technique is used to capture the behavior of the software application

Transition when different input values are given to the same function. This applies to those types of

Technique applications that provide the specific number of attempts to access the application.
What are Positive and Negative Testing?
Positive Testing: It is to determine what system supposed to do. It helps to check whether the
application is justifying the requirements or not.

Negative Testing: It is to determine what system not supposed to do. It helps to find the
defects from the software.

What is Test Plan and contents available in a Test Plan? Link1 link2
Test plan document is a document which contains the plan for all the testing activities to be
done to deliver a quality product. Test Plan document is derived from the Product Description,
SRS, or Use Case documents for all future activities of the project. It is usually prepared by
the Test Lead or Test Manager.

1. Test plan identifier

2. References
3. Introduction
4. Test items (functions)
5. Software risk issues
6. Features to be tested
7. Features not to be tested
8. Approach
9. Items pass/fail criteria
10. Suspension criteria and resolution requirements
11. Test deliverables
12. Remaining test tasks
13.Environmental needs
14.Staff and training needs
15.Roles & Responsibility
16.Schedule
17.Plan risks and contingencies
18.Approvals
19.Glossaries

What is Test Scenario?

Test Scenario gives the idea of what we have to test. Test Scenario is like a high-level test
case.
What is Test Case?
Test cases are the set of positive and negative executable steps of a test scenario which has
a set of pre-conditions, post-conditions, expected results, actual results and test data.
Click for more

What is Test Environment?

Test Environment is the combination of hardware and software on which Test Team performs
testing.

Example:

Application Type: Web Application

OS: Windows
Web Server: IIS
Web Page Design: Dot Net
Client Side Validation: JavaScript
Server Side Scripting: ASP Dot Net
Database: MS SQL Server
Browser: IE/Firefox/Chrome

What is Test Data?

Test data is the data that is used by the testers to run the test cases. Whilst running the test
cases, testers need to enter some input data. To do so, testers prepare test data. It can be
prepared manually and also by usin g tools.

For example, To test a basic login functionality having a user id, password fields. We need to
enter some data in the user id and password fields. So we need to collect some test data.

What is Test Harness?

Test Harness in Software Testing is a collection of stubs, drivers and other supporting tools
required to automate test execution. Test harness executes tests by using a test library and
generates test reports. Test harness contains all the information needed to compile and run a
test like test cases, target deployment port(TDP), source file under test, stubs, etc.

What is Test Closure?

Test Closure is the note prepared before test team formally completes the testing process.
This note contains the total no. of test cases, total no. of test cases executed, total no. of
defects found, total no. of defects fixed, total no. of bugs not fixed, total no of bugs rejected
etc.
What are the tasks of Test Closure activities in Software Testing?
Test Closure activities fall into four major groups.

Test Completion Check: To ensure all tests should be either run or deliberately skipped and all
known defects should be either fixed, deferred for a future release or accepted as a
permanent restriction.

Test Artifacts handover: Tests and test environments should be handed over to those
responsible for maintenance testing. Known defects accepted or deferred should be
documented and communicated to those who will use and support the use of the system.

Lessons learned: Analyzing lessons learned to determine changes needed for future releases
and projects. In retrospective meetings, plans are established to ensure that good
practices can be repeated and poor practices are not repeated

Archiving results, logs, reports, and other documents and work products in the CMS
(configuration management system).

What is test coverage?

Test coverage helps in measuring the amount of testing performed by a set of tests.
Test coverage can be done on both functional and non-functional activities. It assists testers to
create tests that cover areas which are missing.
OR

Test coverage is defined as a technique which determines whether our test cases are
actually covering the application code and how much code is exercised when we run those
test cases.

If there are 10 requirements and 100 tests created and if 90 tests are executed then test
coverage is 90%. Now, based on this metric, testers can create additional test cases for
remaining tests.

What is Code coverage?

Code coverage is about unit testing practices that must target all areas of the code at least
once. It is usually done by developers or unit testers.
List out Test Deliverables.
Test Deliverables are the test artifacts which are given to the stakeholders of a software
project during the SDLC (Software Development Life Cycle). A software project which follows
SDLC undergoes the different phases before delivering to the customer. In this process, there
will be some deliverables in every phase. Some of the deliverables are provided before the
testing phase commences and some are provided during the testing phase and rest after the
testing phase is completed.

1. Test Strategy
2. Test Plan
3. Effort Estimation Report
4. Test Scenarios
5. Test Cases/Scripts
6. Test Data
7. Requirement Traceability Matrix (RTM)
8. Defect Report/Bug Report
9. Test Execution Report
10. Graphs and Metrics
11. Test summary report
12. Test incident report
13. Test closure report
14. Release Note
15. Installation/configuration guide
16. User guide
17. Test status report
18. Weekly status report (Project manager to client)

What are the most common components of a defect report?

1. Project Name
2. Module Name
3. Defect ID
4. Defect detected on
5. Defect detected by
6. Priority
7. Severity
8. Defect resolved on
9. Defect resolved by
10.Steps to reproduce
What are the levels of testing?
In software testing, there are four testing levels.

Unit Testing or component level testing

Integration Testing
System Testing
Acceptance Testing

What is Unit Testing?

Unit Testing is also called Module Testing or Component Testing. It is done to check whether
the individual unit or module of the source code is working properly. It is done by the
developers in the developer’s environment. Learn more about Unit Testing in detail.

What is Integration Testing?

Integration Testing is the process of testing the interface between the two software units.
Integration testing is done in three ways. Big Bang Approach, Top-Down Approach,
Bottom-Up Approach. Learn more about Integration Testing in detail.

Click here for more details.

What is System Testing?

Testing the fully integrated application to evaluate the system’s compliance with its specified
requirements is called System Testing AKA End to End testing. Verifying the completed
system to ensure that the application works as intended or not.

Check this post Difference Between System Testing and Integration Testing

What is Big Bang Approach?

Combining all the modules once and verifying the functionality after completion of individual
module testing.

Top-down and bottom-up are carried out by using dummy modules known as Stubs and
Drivers. These Stubs and Drivers are used to stand in for missing components to simulate
data communication between modules.

What is Top-Down Approach?

Testing takes place from top to bottom. High-level modules are tested first and then low-level
modules and finally integrating the low-level modules to a high level to ensure the system is
working as intended. Stubs are used as a temporary module if a module is not ready for
integration testing.
What is Bottom-Up Approach?
It is a reciprocate of the Top-Down Approach. Testing takes place from bottom to up. Lowest
level modules are tested first and then high-level modules and finally integrating the high-level
modules to a low level to ensure the system is working as intended. Drivers are used as a
temporary module for integration testing.

What is Functional Testing?

In simple words, what the system actually does is functional testing. To verify that each
function of the software application behaves as specified in the requirement document.
Testing all the functionalities by providing appropriate input to verify whether the actual output
is matching the expected output or not. It falls within the scope of black box testing and the
testers need not concern about the source code of the application.

Learn more about Functional Testing here

What is Non-Functional Testing?

In simple words, how well the system performs is non-functionality testing. Non-functional
testing refers to various aspects of the software such as performance, load, stress, scalability,
security, compatibility etc., Main focus is to improve the user experience on how fast the
system responds to a request.

What is Acceptance Testing?

It is also known as pre-production testing. This is done by the end-users along with the
testers to validate the functionality of the application. After successful acceptance testing.
Formal testing conducted to determine whether an application is developed as per the
requirement. It allows the customer to accept or reject the application. Types of acceptance
testing are Alpha, Beta & Gamma

The major aim of this test is to evaluate the compliance of the system with the business
requirements and assess whether it is acceptable for delivery or not. Standard Definition of
Acceptance Testing:

“It is a formal testing according to user needs, requirements and business processes
conducted to determine whether a system satisfies the acceptance criteria or not and
to enable the users, customers or other authorized entities to determine whether to
accept the system or not.”

Acceptance testing is formal testing based on user requirements and function processing. It determines
whether the software is conforming specified requirements and user requirements or not.

What Is UAT Testing?

User acceptance testing is the last step in software testing that verifies whether the software
is fulfilling the initial goals according to user requirements.

During UAT, the users check the specified business behaviors and functionalities of the
system. At this stage, real-world scenarios are implemented on behalf of end-users to verify
the software is working according to requirements.

What is Alpha Testing?

Alpha testing is done by the in-house developers (who developed the software) and testers
before we ship the software to the customers. Sometimes alpha testing is done by the client
or outsourcing team with the presence of developers or testers. It is a part of User Acceptance
Testing. The purpose of doing this is to find bugs before the customers start using the
software.

What is Beta Testing?

Beta testing is done by a limited number of end-users before delivery. It is done after the
Alpha Testing. Usually, it is done in the client’s place. Learn more about Beta Testing here.

What is Smoke Testing?

Smoke Testing is done to make sure if the build we received from the development team is
testable or not. It is also called as “Day 0” check. It is done at the “build level”. It helps not to
waste the testing time to simply testing the whole application when the key features don’t work
or the key bugs have not been fixed yet.

What is Sanity Testing?

Sanity Testing is done during the release phase to check for the main functionalities of the
application without going deeper. It is also called as a subset of Regression testing. It is done
at the “release level”. At times due to release time constraints rigorous regression testing can’t
be done to the build, sanity testing does that part by checking main functionalities.

What is Retesting?
To ensure that the defects which were found and posted in the earlier build were fixed or not
in the current build. Say, Build 1.0 was released. Test team found some defects (Defect Id
1.0.1, 1.0.2) and posted. Build 1.1 was released, now testing the defects 1.0.1 and 1.0.2 in
this build is retesting.

What is Regression Testing?

Repeated testing of an already tested program, after modification, to discover any defects
introduced or uncovered as a result of the changes in the software being tested or in another
related or unrelated software components.

Usually, we do regression testing in the following cases:

New functionalities are added to the application
Change Requirement (In organizations, we call it as CR)
Defect Fixing
Performance Issue Fix
Environment change (E.g., Updating the DB from MySQL to Oracle)

What do you mean by confirmation testing in software testing?

A confirmation test involves retesting a software product to see if the previously reported bugs
have been fixed. A bug is usually reported by testers when a test fails. A new version of the
software is released after the development team fixes the defect. Now that the new software
build has been released, the testing team will retest it in order to ensure that the reported bug
was actually fixed. It is also referred to as retesting.

What is Localization Testing (L10N Testing)?

Localization is a process of adapting globalization software for a specific region or language
by adding local-specific components.

What is Compatibility Testing?

It is to deploy and check whether the application is working as expected in a different
combination of environmental components.

What is Exploratory Testing?

Usually, this process will be carried out by domain experts. They perform testing just by
exploring the functionalities of the application without having the knowledge of the
requirements. Check our detailed guide on Exploratory Testing and also don’t miss these
popular Exploratory Testing Tools.

What is Monkey Testing?

Perform abnormal action on the application deliberately in order to verify the stability of the
application. Check our in-depth guide on Monkey Testing.
What is Usability Testing?
To verify whether the application is user-friendly or not and was comfortably used by an
end-user or not. The main focus in this testing is to check whether the end-user can
understand and operate the application easily or not. An application should be self-exploratory
and must not require training to operate it. Check this guide to learn how to perform Usability
Testing.

What is Security Testing?

Security testing is a process to determine whether the system protects data and maintains
functionality as intended.

Explain Performance testing.

Performance testing is done to check responsiveness and stability of application.

Performance testing is a type of non-functional testing in which the performance of the system is
evaluated under expected or higher load. The various performance parameters evaluated during
performance testing are – response time, reliability, resource usage, scalability (RRRS), etc. The
different types of performance testing are – Load, Stress, Endurance, Spike, and Volume Testing.
https://usersnap.com/blog/types-user-acceptance-tests-frameworks/

LOAD TESTING - To measure the performance under expected load.

STRESS TESTING - To measure performance under load much higher than expected.

SPIKE TESTING - To check behavior of the system on suddenly increasing the users.

ENDURANCE - To check if the system can sustain the expected load for long duration.

VOLUME TESTING - To measure performance with high volume of data.

What is Interface Testing?

Interface testing is performed to evaluate whether two intended modules pass data and
communicate correctly to one another.
What is A/B Testing?
A/B Testing is a method to compare two versions of an application against each other to
determine which one performs better.

What are the principles of Software Testing?

Testing shows presence of defects

Exhaustive testing is impossible
Early testing
Defect clustering
Pesticide Paradox
Testing is context dependent
Absence of error fallacy

Exhaustive Testing
Testing all the functionalities using all valid and invalid inputs and preconditions is known as
Exhaustive testing.

Early Testing
Defects detected in early phases of SDLC are less expensive to fix. So conducting early
testing reduces the cost of fixing defects.

Defect clustering
Defect clustering in software testing means that a small module or functionality contains most
of the bugs or it has the most operational failures.

Pesticide Paradox
Pesticide Paradox in software testing is the process of repeating the same test cases, again
and again, eventually, the same test cases will no longer find new bugs. So to overcome this
Pesticide Paradox, it is necessary to review the test cases regularly and add or update them
to find more defects.

Testing is context-dependent
Testing approach depends on the context of the software we develop. We do test the software
differently in different contexts. For example, online banking application requires a different
approach of testing compared to an e-commerce site.

Absence of error fallacy

99% of bug-free software may still be unusable, if wrong requirements were incorporated into
the software and the software is not addressing the business needs.
The software which we built not only be a 99% bug-free software but also it must fulfill the
business needs otherwise it will become an unusable software.

These are the seven principles of Software Testing every professional tester should know.

What is Walk Through?

A walkthrough is an informal meeting conducts to learn, gain understanding, and find defects.
The author leads the meeting and clarifies the queries raised by the peers in the meeting.

What is Inspection?
Inspection is a formal meeting lead by a trained moderator, certainly not by the author. The
document under inspection is prepared and checked thoroughly by the reviewers before the
meeting. In the inspection meeting, the defects found are logged and shared with the author
for appropriate actions. Post inspection, a formal follow-up process is used to ensure a timely
and corrective action.

What is a Defect?
The variation between the actual results and expected results is known as a defect. If a
developer finds an issue and corrects it by himself in the development phase then it’s called a
defect. Click here for more details.

What is a Bug?
If testers find any mismatch in the application/system in testing phase then they call it as Bug.
Click here for more details.

What is an Error?
We can’t compile or run a program due to a coding mistake in a program. If a developer
unable to successfully compile or run a program then they call it as an error. Click here for
more details.

What is a Failure?
Once the product is deployed and customers find any issues then they call the product as a
failure product. After release, if an end user finds an issue then that particular issue is called
as a failure. Click here for more details.

Severity: It is the extent to which the defect can affect the software. In other words it defines
the impact that a given defect has on the system. For example: If an application or web page
crashes when a remote link is clicked, in this case clicking the remote link by an user is rare
but the impact of application crashing is severe. So the severity is high but priority is low.

Priority: It defines the priority in which the defects should be resolved. if there are multiple
defects, the priority decides which defect has to be fixed and verified immediately versus
which defect can be fixed a bit later. It is usually set by the lead

Few very important scenarios related

High Priority & High Severity: An error which occurs on the basic functionality of the
application and will not allow the user to use the system. (Eg. A site maintaining the student
details, on saving record if it, doesn’t allow to save the record then this is high priority and high
severity bug.)

Low Priority and Low Severity: Any cosmetic or spelling issues which is within a paragraph or
in the report (Not on cover page, heading, title).

High Priority & Low Severity: The spelling mistakes that happens on the cover page or
heading or title of an application.

Low Priority & High Severity : An error which occurs on the functionality of the application (for
which there is no workaround) and will not allow the user to use the system but on click of link
which is rarely used by the end user.

What is Bug Life Cycle?

Defect Life Cycle or Bug Life Cycle in software testing is the specific set of states that defect
or bug goes through in its entire life. The purpose of Defect life cycle is to easily coordinate
and communicate current status of defect which changes to various assignees and make the
defect fixing process systematic and efficient.

● New: When a new defect is logged and posted for the first time. It is assigned a status as
NEW.
● Assigned: Once the bug is posted by the tester, the lead of the tester approves the bug and
assigns the bug to the developer team
● Open: The developer starts analyzing and works on the defect fix
● Fixed: When a developer makes a necessary code change and verifies the change, he or
she can make bug status as “Fixed.”
● Pending retest: Once the defect is fixed the developer gives a particular code for retesting
the code to the tester. Since the software testing remains pending from the testers end, the
status assigned is “pending retest.”
● Retest: Tester does the retesting of the code at this stage to check whether the defect is
fixed by the developer or not and changes the status to “Re-test.”
● Verified: The tester re-tests the bug after it got fixed by the developer. If there is no bug
detected in the software, then the bug is fixed and the status assigned is “verified.”
● Reopen: If the bug persists even after the developer has fixed the bug, the tester changes
the status to “reopened”. Once again the bug goes through the life cycle.
● Closed: If the bug is no longer exists then tester assigns the status “Closed.”
● Duplicate: If the defect is repeated twice or the defect corresponds to the same concept of
the bug, the status is changed to “duplicate.”
● Rejected: If the developer feels the defect is not a genuine defect then it changes the defect
to “rejected.”
● Deferred: If the present bug is not of a prime priority and if it is expected to get fixed in the
next release, then status “Deferred” is assigned to such bugs
● Not a bug:If it does not affect the functionality of the application then the status assigned to
a bug is “Not a bug”.
What is an entry criteria?
The prerequisites that must be achieved before commencing the testing process. Click here
for more details.

What is an exit criteria?

The conditions that must be met before testing should be concluded. Click here for more
details.

Different testing models

Links

What are the categories of defects?

Categories of defects are: Errors of commissions, Errors of omissions, Errors of clarity, and
Error of speed and capacity.

These are explained as following below.

Error of Commission: Commission means instruction or some kind of command given. Now
the error in commission means the error in made in command or instruction. For example,
suppose I wrote a loop that I was trying to run 10 times but I command it to run more than 10
times by mistake this is the error of commission.

Errors of Omissions: As name is already describing error of omission is some thing which
happens accidentally. Omission word means something left out or executed. Practical most
common example of this error is suppose we make a function in programming open its
bracket but forget to close at the end.

Error of Clarity: The most common error in the natural languages. This error happens due to
miss understanding between the developer and client. It travels most of the time from the
requirements to the software.

Error of Speed or Capacity : The name of the error is itself enough i think to tell about it this
error. Your software is working fine but not working in the required time this is the error of
speed. When it comes to capacity it can be relevant to memory. For example, a small integer
is declared where the long integer was required.
What is RTM?
Requirements Traceability Matrix (RTM) is used to trace the requirements to the tests that are needed
to verify whether the requirements are fulfilled. We have to ensure that every requirement has atleast
1 test case. Requirement Traceability Matrix AKA Traceability Matrix or Cross Reference Matrix.

Why is Requirement Traceability Important?

Requirements traceability is important to effectively manage your requirements.

Meeting Goals
When done well, traceability follows the life of a requirement. It starts at the time a requirement
originates. And it continues on through fulfillment of the requirement. So, it makes sure that your
requirements fulfill your original goals. For example, it gives you proof that you met compliance
requirements.

Running the Right Tests

Requirement traceability also helps your quality assurance (QA) team understand what needs to be
tested. This improves test coverage by mapping test cases back to each requirement. So, QA will be
able to test all of the right things. And, as a result, you’ll be able to show that your requirements have
been properly implemented.

Making Decisions
Traceability can also be used for decision-making throughout product development. You’ll be able to
understand how product design will be impacted by requirements. And, if a requirement changes,
you’ll be able to analyze the impact of that change across development.

When to stop testing?

Deadlines (release deadlines, testing deadlines, etc.)
Test cases completed with certain percentage passed
When the test budget is depleted
Coverage of code or functionality or requirements reaches a specified point
Bug rate falls below a certain level
When Beta or alpha testing period ends

What is API Testing?

API testing is a type of software testing where application programming interfaces (APIs) are tested
to determine if they meet expectations for functionality, reliability, performance, and security. In
simple terms, API testing is intended to reveal bugs, inconsistencies or deviations from the expected
behavior of an API.

Which test cases are written first white boxes or black box?
The simple answer is black-box test cases are written first.

Let’s see why black-box test cases are written first compared to white box test cases.
Prerequisites to start writing black-box test cases are Requirement documents or design
documents. These documents will be available before initiating a project.
Prerequisites to start writing white box test cases are the internal architecture of the
application. The internal architecture of the application will be available in the later part of the
project i.e., designing.

What is Random testing?

In random testing is a form of black-box software testing technique where the application is
testing by generating random data.

Write some common mistakes that lead to major issues.

Poor Scheduling
Underestimating
Ignoring small issues
Not following the exact process
Improper resource allocation

Why developers shouldn’t test the software they wrote?

This is because someone testing something they created may bring unconscious or
unintentional bias into the testing process. Software developers lack the objectivity to be able
to test their own work.

They Don't Have Time.

Slows Down Release Times.
QA Testers Are Specially Trained.

What is static software testing?

Static testing is a technique in which you test the software without actually executing it. It
involves doing code walkthroughs, code reviews, peer-reviews, or using sophisticated tools
such as eslint, StyleCop to perform static analysis of the source code. Static testing is
typically performed during software development.

What is confirmation testing in software testing?

A confirmation test involves retesting a software product to see if the previously reported
bugs have been fixed. A bug is usually reported by testers when a test fails. A new version of
the software is released after the development team fixes the defect. Now that the new
software build has been released, the testing team will retest it in order to ensure that the
reported bug was actually fixed. It is also referred to as retesting.

What is a testbed in manual testing?

An environment configured for testing. Test bed consists of hardware, software, network
configuration, an application under test, other related software.

What are the advantages of manual testing?

It is a cheaper way of testing
GUI testing can be done more accurately.
East to learn for new people.
It is highly suitable for short-term projects.
Best suited when the project is at the early stages.

What is configuration management?

Software configuration management (SCM) is a set of processes, policies, and tools that
organize, control, coordinate, and track:

code
documentation
problems
change requests
designs and tools
compilers and libraries

What do you mean by the term QA (Quality Assurance)?

Quality assurance is used to boost customer confidence, the organization’s ability, and work
efficiency. It is a methodology used in the development of products that make sure a certain
level of quality.

QA monitors the process to be done for project development. It also tracks the results of the
process to meet the expectations. It helps in preventing mistakes and defects in
manufactured products and avoiding problems when delivering products or services to
customers.

What is a test log?

A test log is a chronological record of relevant details about the execution of test cases. It
provides detailed information about the success of each test performed to validate the quality,
performance, and functionality of the software.

What do you mean by Quality Control?

Quality control is an activity based on product orientation. It is used to define the error in a
particular software application. Quality Control is a systematic set of processes used to
ensure the quality of software products or services. It aims to ensure that the software
product meets the actual requirements by testing and reviewing its functional and
non-functional requirements.

What kind of test do you do on the web-based application?

Usability testing
Load and stress testing
Security testing
Functionality testing
Configuration testing

Explain what is Entry and Exit criteria?

Entry Criteria- It is defined as the process which requires to be run when the testing begins. It
involves:

Test plans
Test cases
Use cases
Software Requirement Specification (SRS)
Functional Requirement Specification (FRS)
Exit Criteria- It is used when a product is completely testing and when it is ready to be
released. It involves:

Metrics
Defect Analysis Report
Test Summary Reports
Define some of the common software testing approaches.

Common Software Testing Approaches

Black box testing For a given input, the output is tested

White-box testing Testing of source code is done

Acceptance testing Expectations vs reality testing

Automated testing The test is done with recurring scripts

Regression testing The test verifies the existing working of a system and
compares with the way it used to work previously

Functional testing Helpful in testing functionalities

Exploratory testing The test is done within certain areas only and no
specified test cases are done

What is Adhoc Testing?

Ad-hoc testing is quite opposite to the formal testing. It is an informal testing type. In Adhoc
testing, testers randomly test the application without following any documents and test design
techniques. This testing is primarily performed if the knowledge of testers in the application
under test is very high. Testers randomly test the application without any test cases or any
business requirement document
What is the purpose of maintenance testing?

Maintenance Testing is done on the already deployed software.Request from the end-users to
add new features to the existing software.

End-users may want to migrate from one platform to another such as upgrading their
environment like operating system, database, etc

The Testing done during this enhancement,change and migration cycle is known as
maintenance testing. Once the software is deployed in operational environment it needs some
maintenance from time to time in order to avoid system breakdown,most of the banking
software systems needs to be operational 24*7*365. So it is very necessary to do
maintenance testing of software applications.

What is use case testing?

A use case is a description of how a person who actually uses that process or system will accomplish a
goal. It's typically associated with software systems, but can be used in reference to any process. For
example, imagine you're a cook who has a goal of preparing a grilled cheese sandwich. The use case
would describe through a series of written steps how the cook would go about preparing that sandwich. A
use case helps you understand where errors could occur in the process and design features to resolve
those errors.

Three elements that a use case must contain:

1. Actor, which is the user, which can be a single person or a group of people, interacting with a
process
2. System, which is the process that's required to reach the final outcome
3. Goal, which is the successful user outcome
Use case is a representation of actions which describes the behaviour of system to do a particular task.
Defect States

#1) New: This is the first state of a defect in the Defect Life Cycle. When any new defect is found, it falls in a ‘New’
state, and validations & testing are performed on this defect in the later stages of the Defect Life Cycle.

#2) Assigned: In this stage, a newly created defect is assigned to the development team to work on the defect.
This is assigned by the project lead or the manager of the testing team to a developer.

#3) Open: Here, the developer starts the process of analyzing the defect and works on fixing it, if required.

If the developer feels that the defect is not appropriate then it may get transferred to any of the below four states
namely Duplicate, Deferred, Rejected, or Not a Bug-based upon a specific reason. We will discuss these four
states in a while.

#4) Fixed: When the developer finishes the task of fixing a defect by making the required changes then he can
mark the status of the defect as “Fixed”.

#5) Pending Retest: After fixing the defect, the developer assigns the defect to the tester to retest the defect at
their end, and until the tester works on retesting the defect, the state of the defect remains in “Pending Retest”.

#6) Retest: At this point, the tester starts the task of retesting the defect to verify if the defect is fixed accurately by
the developer as per the requirements or not.

#7) Reopen: If any issue persists in the defect, then it will be assigned to the developer again for testing and the
status of the defect gets changed to ‘Reopen’.

#8) Verified: If the tester does not find any issue in the defect after being assigned to the developer for retesting
and he feels that if the defect has been fixed accurately then the status of the defect gets assigned to ‘Verified’.

#9) Closed: When the defect does not exist any longer, then the tester changes the status of the defect to
“Closed”.

A Few More:

● Rejected: If the defect is not considered 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”.
What is Software Testing Life Cycle?
Software Testing Life Cycle (STLC) is a sequence of activities performed by testers such as
Requirement & Analysis – Understanding the client’s requirement and what actually requires,
How to test the requirements,
Test Planning – what should be tested in an application, How and who will test the application
Test Case Design – test scenarios, mapping with requirement traceability matrix, test case
creation, and test data used
Test Environment Setup – what hardware and software need to install or configure to build
test environment.
Test Execution – running the application in order to verify features as per test case designed,
reporting bugs, track the bugs and regression test till it gets resolved.
Test Closure – Creation of test reports, total bugs pending, critical bugs if any, justification for
releasing application to client.

What is Stubs and drivers?

What is RTM ?
Requirement Traceability Matrix (RTM) is a document that maps and traces user requirement
with test cases. It captures all requirements proposed by the client and requirement traceability in
a single document, delivered at the conclusion of the Software developement life cycle. The main
purpose of Requirement Traceability Matrix is to validate that all requirements are checked via
test cases such that no functionality is unchecked during Software testing.