What is Software Testing:

Software testing is a process, to evaluate the functionality of a software application with an intent to find
defects, and also to check whether the developed software met the specified requirements or not.

Software Testing Types:

Manual Testing: Manual testing is the process of testing the software manually to find the defects. Tester
should have the perspective of end users and to ensure all the features are working as mentioned in the
requirement document. In this process, testers execute the test cases and generate the reports manually
without using any automation tools.

How to perform Manual Testing

 First, tester examines all documents related to software, to select testing areas.
 Tester analyses requirement document to cover all requirements stated by the customer.
 Tester develops the test cases according to the requirement document.
 All test cases are executed manually by using Black box testing and white box testing.
 If bugs occurred then the testing team informs to the development team.
 Development team fixes bugs and handed software to the testing team for retesting.

Advantages of Manual Testing

 It does not require programming knowledge while using the Black box method.
 It is used to test dynamically changing GUI designs.
 Tester interacts with software as a real user so that they are able to discover usability and user
interface issues.
 It ensures that the software is a hundred percent bug-free.
 It is cost effective.
 Easy to learn for new testers.

Limitations of Manual Testing

 It requires a large number of human resources.

 It is very time-consuming.
 Tester develops test cases based on their skills and experience. There is no evidence that they have
covered all functions or not.
 Test cases cannot be used again. Need to develop separate test cases for each new software.
 It does not provide testing on all aspects of testing.
 Since two teams work together, sometimes it is difficult to understand each other's motives, it can
mislead the process.

Automation Testing: Automation testing is the process of testing the software using an automation tool to
find the defects. In this process, testers execute the test scripts and generate the test results automatically
by using automation tools. Some of the famous automation testing tools for functional testing are QTP/UFT
and Selenium.

Automation Testing

When the testing case suites are performed by using automated testing tools is known as Automation
Testing. The testing process is done by using special automation tools to control the execution of test cases
and compare the actual result with the expected result. Automation testing requires a pretty huge
investment of resources and money.

Generally, repetitive actions are tested in automated testing such as regression tests. The testing tools used
in automation testing are used not only for regression testing but also for automated GUI interaction, data
set up generation, defect logging, and product installation.

The goal of automation testing is to reduce manual test cases but not to eliminate any of them. Test suits
can be recorded by using the automation tools, and tester can play these suits again as per the
requirement. Automated testing suites do not require any human intervention.

Advantages of Automation Testing

1. Automation testing takes less time than manual testing.

2. A tester can test the response of the software if the execution of the same operation is repeated
several times.
3. Automation Testing provides re-usability of test cases on testing of different versions of the same
software.
4. Automation testing is reliable as it eliminates hidden errors by executing test cases again in the
same way.
5. Automation Testing is comprehensive as test cases cover each and every feature of the application.
6. It does not require many human resources, instead of writing test cases and testing them manually,
they need an automation testing engineer to run them.
7. The cost of automation testing is less than manual testing because it requires a few human
resources.

Limitations of Automation Testing

1. Automation Testing requires high-level skilled testers.

2. It requires high-quality testing tools.
3. When it encounters an unsuccessful test case, the analysis of the whole event is complicated.
4. Test maintenance is expensive because high fee license testing equipment is necessary.
5. Debugging is mandatory if a less effective error has not been solved, it can lead to fatal results.

Software Development Life Cycle (SDLC)

SDLC is a process that creates a structure of development of software. There are different phases within
SDLC, and each phase has its own different activity. It makes development team able to design, create and
deliver a high-quality product.

SDLC describes various phases of software development and the order of execution of phases. Each phase
requires deliverable from the previous phase in a life cycle of software development. Requirements are
translated into design, design into development and development into testing, after testing it is given to
the client.

Different phases of the software development cycle

1. Requirement Phase
2. Design Phase
 3. Build /Development Phase
4. Testing Phase
5. Deployment/ Deliver Phase
6. Maintenance

1. Requirement Phase

This is the most crucial phase of software development life cycle for the developing team as well as for the
project manager. During this phase, the client states requirements, specifications, expectations and any
other special requirement related to the product or software. All these are gathered by the business
manager or project manager or analyst of the service providing company.

Requirement includes how the product will be used and who will use the product to determine the load of
operations. All information gathered from this phase is critical to developing the product as per the
customer requirements.

2. Design Phase

Design phase includes a detailed analysis of new software according to the requirement phase. This is the
high priority phase in the development life cycle of a system because the logical designing of the system is
converted into physical designing. The output of requirement phase is a collection of things that are
required and design phase gives the way to accomplish these requirements. The decision of all required
essential tools such as programming language like Java, .NET, PHP; database like Oracle, MySQL, a
combination of hardware and software to provide a platform on which software can run without any
problem is taken in this phase.

There are several techniques and tools such as data flow diagrams, flowcharts, decision tables and decision
trees, Data dictionary, and the structured dictionary are used for describing the system design.

3. Build /Development Phase

After the successful completion of requirement and design phase, the next step is to implement the design
into the development of a software system. In this phase, work is divided into small units, and coding starts
by the team of developers according to the design discussed in the previous phase and according to the
requirements of client discussed in requirement phase to produce the desired result.

Front-end developers develop easy and attractive GUI and necessary interfaces to interact with back-end
operations and back-end developers do back-end coding according to the required operations. All is done
according to the procedure and guidelines demonstrated by the project manager.

Since, this is the coding phase it takes the longest time and more focused approach for the developer in the
software development life cycle.

4. Testing Phase

Testing is the last step of completing software system. In this phase, after getting the developed GUI and
back-end combination, it is tested against the requirements stated in the requirement phase. Testing
determines whether the software is actually giving the result as per the requirements addressed in the
requirement phase or not. Testing team makes a test plan to start the test. This test plan includes all types
of essential testing such as integration testing, unit testing, acceptance testing, and system testing. Non-
functional testing is also done in this phase.
If there are any defects in the software, or it is not working as per expectations, then testing team gives
information to the development team in detail about the issue. If it is a valid defect or worth to sort out, it
will be fixed and development team replaces it with the new one and it also needs to be verified.

5. Deployment/ Deliver Phase

When software testing is completed with satisfying result and there are no remaining issues in the working
of software, it is delivered to the customer for their use.

As soon as customers receive the product, they are recommended first to do the beta testing. In beta
testing, customer can require any changes which are not present in the software but mentioned in the
requirement document or any other GUI changes to make it more user-friendly. Besides this, if any type of
defect is encountered while a customer using the software; it will be informed to the development team of
that particular software to sort out the problem. If it is a severe issue, then the development team solves it
in a short time otherwise, if it is less severe, then it will wait for the next version.

After the solution of all type of bugs and changes, software finally deployed to the end user.

6. Maintenance

The maintenance phase is the last and long-lasting phase of SDLC because it is the process which continues
till the software's life cycle comes to an end. When a customer starts using software, then actual problems
start to occur, and at that time there's a need to solve these problems. This phase also includes making
changes in hardware and software to maintain its operational effectiveness like to improve its
performance, enhance security features and according to customer's requirements with upcoming time.
This process to take care of product time to time is called maintenance.

"So, all these are six phases of software development life cycle (SDLC) under which the process of
development of software takes place. All are compulsory phases without any one of the development
cannot be possible because development continues for the lifetime of software with maintenance phase".

V Model:
V-model is also known as Verification and Validation (V&V) model. In this each phase of SDLC must be
completed before the next phase starts. It follows a sequential design process same like waterfall model.
How the development team and test team involves in each phase of SDLC in V Model.

1. Once client sends BRS, both the teams (test and development) start their activities. The developers
translate the BRS to SRS. The test team involves in reviewing the BRS to find the missing or wrong
requirements and writes acceptance test plan and acceptance test cases.
2. In the next stage, the development team sends the SRS the testing team for review and the
developers start building the HLD (High Level Design Document) of the product. The test team
involves in reviewing the SRS against the BRS and writes system test plan and test cases.
3. In the next stage, the development team starts building the LLD (Low Level Design) of the product.
The test team involves in reviewing the HLD (High Level Design) and writes Integration test plan
and integration test cases.
4. In the next stage, the development team starts with the coding of the product. The test team
involves in reviewing the LLD and writes functional test plan and functional test cases.
5. In the next stage, the development team releases the build to the test team once the unit testing
was done. The test team carries out functional testing, integration testing, system testing and
acceptance testing on the release build step by step.
Advantages:
1. Testing starts in early stages of product development which avoids downward flow of defects and
helps to find the defects in the early stages
2. Test team will be ready with the test cases by the time developers release the software which in
turns saves a lot of time
3. Testing is involved in every stage of product development. It gives a quality product.
4. Total investment is less due to less or no rework.
Disadvantages:
1. Initial investment is more because test team involves right from the early stage.
2. Whenever there is change in requirement, the same procedure continues. It leads more
documentation work.
Applications:
 Long term projects, complex applications, When customer is expecting a very high quality product with
in stipulated time frame because every stage is tested and developers & testers are working in parallel

Testing Methods:

Static Testing

Dynamic Testing

Static Testing: It is also known as Verification in Software Testing. Verification is a static method of checking
documents and files. 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, Walkthroughs

Dynamic Testing: It is also known as Validation in Software Testing. Validation is a dynamic process of
testing the real product. 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 included in Verification and Validation Process:

The two major V&V activities are reviews, including, inspections and walkthroughs, and testing.

Reviews:

Reviews are conducted during and at the end of each phase of the life cycle to determine whether
established requirements, design concepts, and specifications have been met. Reviews consist of the
presentation of material to a review board or panel. Reviews are most effective when conducted by person
who have not been directly involved in the development of the software being reviewed.

Inspection:

Inspection involves a team of about 3-6 people, led by a leader, which formally reviews the documents and
work product during various phases of the product development life cycle. The work product and related
documents are presented in front of the inspection team, the members of which carry different
interpretations of the presentation. The bugs that are detected during the inspection are communicated to
the next level in order to take care of them.

Walkthroughs:

Walkthrough can be considered same as inspection without formal preparation (of any presentation or
documentations). During the walkthrough meeting, the presenter/author introduces the material to all the
participants in order to make them familiar with it. Even when the walkthroughs can help in finding
potential bugs, they are used for knowledge sharing or communication purpose.

Testing:

Testing is the operation of the software with real or simulated inputs to demonstrate that a product
satisfies its requirements and, if it does not, to identify the specific differences between expected and
actual results. There are varied levels of software tests, ranging from unit or element testing through
integration testing and performance testing, up to software system and acceptance tests.

Activities involved in this is Testing the software application

Smoke Testing

Smoke Testing comes into the picture at the time of receiving build software from the development team.
The purpose of smoke testing is to determine whether the build software is testable or not. It is done at the
time of "building software." This process is also known as "Day 0".

It is a time-saving process. It reduces testing time because testing is done only when the key features of the
application are not working or if the key bugs are not fixed. The focus of Smoke Testing is on the workflow
of the core and primary functions of the application.

Process to conduct Smoke Testing

Smoke testing does not require to design test cases. There's need only to pick the required test cases from
already designed test cases.

As mentioned above, Smoke Testing focuses on the workflow of core applications so; we choose test case
suits that covers the major functionality of the application. The number of test cases should be minimized
as much as possible and time of execution must not be more than half an hour.

Real Time Example:

Suppose, we are using an eCommerce site, and the core working of this site should be login, specific search,
add an item into the cart, add an item into the favorite, payment options, etc. Here we are testing function
to place an order. After testing, the tester has to be sure and confident about the functioning of the
function of the application.

Steps of the workflow are given below:

 Click on item
 Description page should be open.
 Click on Add to Cart
 The cart should be open
 Click on Buy Now
 Payment options should be displayed. Choose one of them.
 Order placed

Sanity Testing

Sanity testing performed at the time of receiving software build (with minor changes in code) from the
development team. The purpose of sanity testing is to ensure that all the defects have been fixed and no
further issues come in existence due to these changes. It's a kind of regression testing with a focus on a few
impacted functionalities only.

Sanity testing can be done in two situations: one in the case of enhancement in functionality and second in
the case of defect fixed. It makes sure that the changes made in code or functions have no impact on the
related modules, therefore, it can be applied only on related modules that can be impacted.

Process to conduct Sanity Testing

Likewise, the smoke testing tester doesn't need to design a separate test case suits for sanity testing. Tester
only needs to choose test cases from already designed test cases for the modified or defect fixed function.
The functions that are modified or defect fixed have tested once so; the tester uses the same test case that
he has done before.
Real-time Example:

Let's take the example as above. Take a function Account of any payment site. The tester modifies and fixes
some defects that might be occurred in an account function. The sanity testing performs the testing on the
modified function, i.e., account function in payment application to check whether the function is working
properly or not.

Sanity Testing

Sanity testing checks only modified or defect fixed functions, it does not check End to End functions. It is
the subset of regression testing.

Differences between Smoke Testing and Sanity Testing

Levels of Testing

Unit Testing

Unit testing involves the testing of each unit or individual component of the software application. It is the
first level of software testing. The aim behind unit testing is to validate unit component with its
performance.

A unit is a single testable part of a software system and tested during the development phase of the
application software.

This testing aims to test the correctness of isolated code. A unit component is an individual function or
code of the application. White box testing approach used for unit testing and usually done by the
developers.

In a testing level hierarchy, unit testing is the first level of testing done before integration and other
remaining levels of the testing. It uses modules for the testing process which reduces the dependency of
waiting for Unit testing frameworks, stubs, drivers and mock objects are used for assistance in unit testing.

The reason behind Unit Testing

Generally, software goes under four level of testing: Unit Testing, Integration Testing, System Testing, and
Acceptance Testing but sometimes due to time consumption software testers does minimal unit testing but
skipping of unit testing may lead to higher defects during Integration Testing, System Testing, and
Acceptance Testing or even during Beta Testing which takes place after the completion of software
application.

Some crucial reasons are listed below:

1. Unit testing helps tester and developers to understand the base of code that makes them able to
change defect causing code quickly.
2. Unit testing helps in the documentation.
3. Unit testing fixes defects very early in the development phase that's why there is a possibility to
occur a smaller number of defects in upcoming testing levels.
4. It helps with code reusability by migrating code and test cases.

Unit Testing Techniques:

Unit testing uses all white box testing techniques as it uses the code of software application:

1. Data flow Testing

2. Control Flow Testing
3. Branch Coverage Testing
4. Statement Coverage Testing
5. Decision Coverage Testing

Integration testing

Integration testing is the second level of the software testing process comes after unit testing. In this
testing, units or individual components of the software are tested in a group. The focus of the integration
testing level is to expose defects at the time of interaction between integrated components or units.

Unit testing uses modules for testing purpose, and these modules are combined and tested in integration
testing. The Software is developed with a number of software modules that are coded by different
developers or programmers. The goal of integration testing is to check the correctness of communication
among all the modules.

Incremental Approach

In the Incremental Approach, modules are added in ascending order one by one or according to need. The
selected modules must be logically related. Generally, two or more than two modules are added and tested
to determine the correctness of functions. The process continues until the successful testing of all the
modules.

Incremental Approach is carried out by further methods:

1. Top Down
2. Bottom Up
3. Hybrid Testing

Top-Down Method

The top-down testing strategy deals with the process in which higher level modules are tested with lower
level modules until the successful completion of testing of all the modules. Major design flaws can be
detected and fixed early because critical modules tested first.
Advantages:

1. Identification of defect is difficult.

2. An early prototype is possible.

Disadvantages:

1. Due to the high number of stubs, it gets quite complicated.

2. Lower level modules are tested inadequately.
3. Critical Modules are tested first so that fewer chances of defects.

Bottom Up Method

The bottom to up testing strategy deals with the process in which lower level modules are tested with
higher level modules until the successful completion of testing of all the modules. Top level critical modules
are tested at last, so it may cause a defect.

Advantages:

1. Identification of defect is easy.

2. Do not need to wait for the development of all the modules as It saves time.

Disadvantages:

1. Critical modules are tested last due to which the defects can occur.
2. There is no possibility of an early prototype.

Hybrid Testing Method

In this approach, both Top-Down and Bottom-Up approaches are combined for testing. In this process, top-
level modules are tested with lower level modules and lower level modules tested with high-level modules
simultaneously. There is less possibility of occurrence of defect because each module interface is tested.

Advantages:
 1. The hybrid method provides features of both Bottom Up and Top Down methods.
2. It is most time reducing method.
3. It provides complete testing of all modules.

Disadvantages:

1. This method needs a higher level of concentration as the process carried out in both directions
simultaneously.
2. Complicated method.

Guidelines for Integration Testing

1. First, determine the test case strategy through which executable test cases can be prepared
according to test data.
2. Examine the structure and architecture of the application and identify the crucial modules to test
them first.
3. Design test cases to verify each interface in detail.
4. Choose input data for test case execution. Input data plays a significant role in testing.
5. Fix defects and retest.

System Testing

System Testing includes testing of a fully integrated software system. Generally, a computer system is made
with the integration of software (any software is only a single element of a computer system). The software
is developed in units and then interfaced with other software and hardware to create a complete computer
system. In other words, a computer system consists of a group of software to perform the various tasks,
but only software cannot perform the task; for that software must be interfaced with compatible hardware.
System testing is a series of different type of tests with the purpose to exercise and examine the full
working of an integrated software computer system against requirements.

System testing falls under Black box testing as it includes testing of the external working of the software.
Testing follows user's perspective to identify minor defects.

System Testing includes the following steps.

1. Verification of input functions of the application to test whether it is producing the expected
output or not.
2. Testing of integrated software by including external peripherals to check the interaction of various
components with each other.
3. Testing of the whole system for End to End testing.
4. Behavior testing of the application via actual user's experience

Types of System Testing

Regression Testing

Regression testing is performed under system testing to confirm and identify that if there's any defect in
the system due to modification in any other part of the system. It makes sure, any changes done during the
development process have not introduced a new defect and also gives assurance; old defects will not exist
on the addition of new software over the time.

Load Testing
Load testing is performed under system testing to clarify whether the system can work under real-time
loads or not.

Functional Testing

Functional testing of a system is performed to find if there's any missing function in the system. Tester
makes a list of vital functions that should be in the system and can be added during functional testing and
should improve quality of the system.

Recovery Testing

Recovery testing of a system is performed under system testing to confirm reliability, trustworthiness,
accountability of the system and all are lying on recouping skills of the system. It should be able to recover
from all the possible system crashes successfully.

Migration Testing

Migration testing is performed to ensure that if the system needs to be modified in new infrastructure so it
should be modified without any issue.

Usability Testing

The purpose of this testing to make sure that the system is well familiar with the user and it meets its
objective for what it supposed to do.

Software and Hardware Testing

This testing of the system intends to check hardware and software compatibility. The hardware
configuration must be compatible with the software to run it without any issue. Compatibility provides
flexibility by providing interactions between hardware and software.

Why is System Testing Important?

1. System Testing gives hundred percent assurance of system performance as it covers end to end
function of the system.
2. It includes testing of System software architecture and business requirements.
3. It helps in mitigating live issues and bugs even after production.
4. System testing uses both existing system and a new system to feed same data in both and then
compare the differences in functionalities of added and existing functions so, the user can
understand benefits of new added functions of the system.

Regression Testing

Regression Testing is the process to test that, if code is changed in any function does not impact the
existing functions of the software application. The process confirms that the old functions still work with
the new modified functions.

Regression testing tests only modified or defect fixed functions and partially selected functions that can
adversely be affected due to the modification. The same test cases are executed for modified functions,
which has already been executed. The reason behind this, when the new version of any software is
released it tested under old test cases to ensure that all old features still working with correctness and in
the same manner. If any function is not working correctly, that means changing or adding new code have
introduced a new error.

Reason behind Regression Testing

Requirement of Regression Testing is when:

1. The code is changed or modified due to change or enhancement in Requirements.

2. There is software enhancement by adding new features.
3. Defect resolve or fixed.
4. Performance checking after fixing defects.

How to perform Regression Testing?

Regression Testing comes in a picture during the maintenance phase of a software application which
includes error corrections, enhancements, deletion and optimization of existing features. These variations
and modifications can introduce new errors, and these errors can cause incorrect working of the system.
That's why Regression Testing is essential.

Guidelines for Regression Testing

1. Collect the list of defects fixed or modified software applications.

2. Select prioritized test cases depending on critical & frequently used and business impact
functionalities.
3. Select remaining test cases if regression testing is necessary for them.
4. Perform regression testing by using automated tools.
5. If any defect is occurred then send it to the development team.

Functional Testing

Functional Testing is a branch of software testing, intended to verify the functionality of the software
application whether the function is operating according to the requirement specification. Each and every
function is tested by giving appropriate input value, determining the output and verifying the actual output
with the expected output.

Functional Testing includes testing via GUI (Graphical User Interface), API (Application Program Interface),
security, Database, client applications, server applications and functionality of the Application. Black Box
Testing method is used for functional testing in which working of internal logic is tested without peering
into internal code.

Goal of Functional Testing

The goal of functional testing is to check main entry functions, essential usable functions, easy flow of
screen GUI and displaying of error messages whether a user can easily navigate throughout the application.

Various steps of Functional Testing:

1. Tester does verification of requirement specifications.

2. Tester makes a plan of testing.
3. Test cases designing according to functions is done in this step.
4. Make a document of Traceability Matrix.
5. Execution of designed test cases.
6. Coverage analysis is done to examine the covered testing area of the application.
7. Defect Management is done to manage defect resolving.

How to Perform Functional Testing

1. Understand the required task of the function.

2. Identify input values
 3. Calculate the expected outputs from identified input values.
4. Execute all test cases one by one.
5. Compare the actual output with expected output.

Advantages of Functional Testing

1. It ensures the satisfaction of the client or end user.

2. It ensures that all the functionalities have met according to their requirements.
3. It ensures the expected work performance of the software application.
4. It reduces the risks associated with the software.
5. It ensures safety and security.
6. Production of a defect-free software application is possible due to functional testing.

Acceptance testing

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. It is conducted
as a kind of Black Box testing where the number of required users involved to test the acceptance level of
the system. It is the fourth and last level of software testing.

However, the software has passed through three testing levels (Unit Testing, Integration Testing, System
Testing) But still there are some minor errors which can be identified when the system is used by the end
user in the actual scenario.

Acceptance testing is the squeezing of all the testing processes that have done previously.

Reason behind Acceptance Testing

Once the software has undergone through Unit Testing, Integration Testing and System Testing so,
Acceptance Testing may seem redundant, but it is required due to the following reasons.

1. During the development of a project if there are changes in requirements and it may not be
communicated effectively to the development team.
2. Developers develop functions by examining the requirement document on their own
understanding and may not understand the actual requirements of the client.
3. There's maybe some minor errors which can be identified only when the system is used by the end
user in the actual scenario so, to find out these minor errors, acceptance testing is essential.

Confirmation of objectives:

After successful completion of all testing processes, testing team confirms that the software application is
bug-free and it can be delivered to the client.

Advantages of Acceptance Testing

1. It increases the satisfaction of clients as they test application itself.

2. The quality criteria of the software is defined in an early phase so that the tester has already
decided the testing points. It gives a clear view to testing strategy.
3. The information gathered through acceptance testing used by stakeholders to better understand
the requirements of the targeted audience.
4. It improves requirement definition as client tests requirement definition according to his needs.

Disadvantages of Acceptance Testing

According to the testing plan, the customer has to write requirements in their own words and by
themselves but

1. Customers are not willing to do that; it defeats the whole point of acceptance testing.
2. If test cases are written by someone else, the customer does not understand them, so tester has to
perform the inspections by themselves only.

Alpha Testing

Alpha Testing is a type of software testing which is used to find the bugs before the releasing the software
to real users or a public. It gives a certificate of performance in an actual scenario. It is a type of acceptance
testing.

The objective of alpha testing is to rectify the software product by identifying and fixing errors that could
not discover in previous testing processes. It is done near the end of development and before beta testing
of the software.

Software engineers or quality assurance staff perform alpha testing. Generally, it has two phases, in the
first phase, developers use debugger software or hardware-assisted debuggers which helps to catch bugs
very quickly. During alpha testing, there is plenty of bugs, missing features, and crashes.

In the second phase, quality assurance staff perform alpha testing by involving both black box and white
box testing techniques. It is an additional testing environment.

Alpha Testing

Alpha testing is envisioned as an available online application that is not complete to use but can be opened
up to check performance and get initial feedback from the public. It can be referred to an early version or
upcoming version of the software application.

How to perform alpha testing

Alpha testing is done in a lab test environment on a separate computer system. A group consisting of
project manager and developers defines goals of alpha testing and integrate result of an evolving project.

1. Examine the functional requirements and designing specification of the software.

2. Develop test cases according to the functions.
3. Execute all test cases
4. Discover defects
5. Fix defects.

Advantages of Alpha testing

1. It reduces the delivery time of the project.

2. It provides a more comprehensive test plan and test cases.
3. Free the team quickly so that they can work on another project.
4. It provides better insight into the software's reliability and accountability.
5. Feedback is quick so that the quality of the software can be further improved.

Disadvantages of Alpha testing

1. It needs a tester who is skilled in both white box and black box testing.
2. It needs software tools for quick debugging.
 3. This test is done immediately after the development, so it is necessary to get the tester available
immediately.

Beta Testing

Beta Testing is a part of acceptance testing which is intended to validate the product for usability,
functionality, reliability, and compatibility by the end-user. It adds value to the software as user validates it
by providing real input values.

It helps in enhancement of the quality of software and leads it towards success. Also, helpful in deciding
whether the software is worthy to invest more in future versions or not.

It is not controlled activity since it happens at the user's side. It is considered as final testing before
delivering the software to the customers. Software released for beta testing is known as beta software.

How to perform Beta Testing

The user of the software performs beta testing by giving real-time input values to all the executable
functions. It is only users who can certify the application on required quality aspects. Users views are
considered as a testing result, and these are also helpful in performance improvement and quality
enhancement.

Beta testing lifecycle

Beta testing lifecycle starts from Plan and ends on Launch of the product as beta software. Design, Build,
Test, Review are also a part of the lifecycle of beta testing.

1. Plan- Includes planning of the software.

2. Design- Includes designing of the software.
3. Build- Includes development of the software.
4. Test- Includes testing of the software.
5. Review- Includes alpha testing of the software.
6. Launch- Includes launching of beta software.

Advantages of Beta Testing

1. Issues like confusing application flow and crashes that may be missed in previous testing processes
are detected by beta testing.
2. Beta testing uses customer validation approach which reduces product failure risk.
3. Customer feedback helps to improve product quality.
4. It is less expensive than other similar data gathering methods.
5. Beta testing focuses on customer's satisfaction.

Disadvantages of Beta Testing

1. Beta testing does not test the functionality of software in depth as software still under
development.
2. Usually, a user does not test the function that is less useful; it only focuses on the most useful
functions.
3. Testing on the feedback of some users who do not use the software themselves properly, waste
the tester's time and money.

Requirement Analysis:
In this step, the testing team analyzes requirement document to find out the objective of the developed
software. Test planning accomplished by using requirement document, Process Flow Diagrams, System
Requirements Specification, Business Use Cases, Business Requirements Document and Project Charter.

Test Plan Creation:

Test Plan Creation outlines the whole strategy of the testing process. This strategy is used to ensure and
verify whether the software is conforming specified requirements or not.

Test Case Designing:

This step includes the creation of test cases based on test plan documents. Test cases should be designed in
a way that can cover most of the acceptance testing scenario.

Test Case Execution:

Test Case Execution includes execution of test cases by using appropriate input values. The testing team
collects input values from the end user then all test cases are executed by both tester and end user to
make sure software is working correctly in the actual scenario.

Non-Functional Testing

Non-functional testing is a type of software testing to test non-functional parameters such as reliability,
load test, performance and accountability of the software. The primary purpose of non-functional testing is
to test the reading speed of the software system as per non-functional parameters. The parameters of non-
functional testing are never tested before the functional testing.

Non-functional testing is also very important as functional testing because it plays a crucial role in customer
satisfaction.

Why Non-Functional Testing

Functional and Non-functional testing both are mandatory for newly developed software. Functional
testing checks the correctness of internal functions while Non-Functional testing checks the ability to work
in an external environment.

It sets the way for software installation, setup, and execution. The measurement and metrics used for
internal research and development are collected and produced under non-functional testing.

Non-functional testing gives detailed knowledge of product behavior and used technologies. It helps in
reducing the risk of production and associated costs of the software.

Parameters to be tested under Non-Functional Testing

Performance Testing

Performance Testing eliminates the reason behind the slow and limited performance of the software.
Reading speed of the software should be as fast as possible.

For Performance Testing, a well-structured and clear specification about expected speed must be defined.
Otherwise, the outcome of the test (Success or Failure) will not be obvious.

Load Testing
Load testing involves testing the system's loading capacity. Loading capacity means more and more people
can work on the system simultaneously.

Security Testing

Security testing is used to detect the security flaws of the software application. The testing is done via
investigating system architecture and the mindset of an attacker. Test cases are conducted by finding areas
of code where an attack is most likely to happen.

Portability Testing

The portability testing of the software is used to verify whether the system can run on different operating
systems without occurring any bug. This test also tests the working of software when there is a same
operating system but different hardware.

Accountability Testing

Accountability test is done to check whether the system is operating correctly or not. A function should give
the same result for which it has been created. If the system gives expected output, it gets passed in the test
otherwise failed.

Reliability Testing

Reliability test assumes that whether the software system is running without fail under specified conditions
or not. The system must be run for a specific time and number of processes. If the system is failed under
these specified conditions, reliability test will be failed.

Efficiency Testing

Efficiency test examines the number of resources needed to develop a software system, and how many of
these were used. It also includes the test of these three points.

1. Customer's requirements must be satisfied by the software system.

2. A software system should achieve customer specifications.
3. Enough efforts should be made to develop a software system.

Advantages of Non-functional testing

1. It provides a higher level of security. Security is a fundamental feature due to which system is
protected from cyber-attacks.
2. It ensures the loading capability of the system so that any number of users can use it
simultaneously.
3. It improves the performance of the system.
4. Test cases are never changed so do not need to write them more than once.
5. Overall time consumption is less as compared to other testing processes.

Disadvantages of Non-Functional Testing

1. Every time the software is updated, non-functional tests are performed again.
2. Due to software updates, people have to pay to re-examine the software; thus software becomes
very expensive.

Test Plan
A test plan is a detailed document which describes software testing areas and activities. It outlines the test
strategy, objectives, test schedule, required resources (human resources, software, and hardware), test
estimation and test deliverables.

The test plan is a base of every software's testing. It is the most crucial activity which ensures availability of
all the lists of planned activities in an appropriate sequence.

The test plan is a template for conducting software testing activities as a defined process that is fully
monitored and controlled by the testing manager.

Types of Test Plan

There are three types of the test plan

1. Master Test Plan

2. Phase Test Plan
3. Testing Type Specific Test Plans

Master Test Plan

Master Test Plan is a type of test plan that has multiple levels of testing. It includes a complete test
strategy.

Phase Test Plan

A phase test plan is a type of test plan that addresses any one phase of the testing strategy. For example, a
list of tools, a list of test cases, etc.

Specific Test Plans

Specific test plan designed for major types of testing like security testing, load testing, performance testing,
etc. In other words, a specific test plan designed for non-functional testing.

How to write a Test Plan

Making a test plan is the most crucial task of the test management process. According to IEEE 829, follow
the following seven steps to prepare a test plan.

1. First, analyze product structure and architecture.

2. Now design the test strategy.
3. Define all the test objectives.
4. Define the testing area.
5. Define all the useable resources.
6. Schedule all activities in an appropriate manner.
7. Determine all the Test Deliverables.

Test Plan Guidelines

1. Collapse your test plan.

2. Avoid overlapping and redundancy.
3. If you think that you do not need a section that is already mentioned above, then delete that section
and proceed ahead.
4. Be specific. For example, when you specify a software system as the part of the test environment,
then mention the software version instead of only name.
5. Avoid lengthy paragraphs.
 6. Use lists and tables wherever possible.
7. Update plan when needed.
8. Do not use an outdated and unused document.

Importance of Test Plan

1. The test plan gives direction to our thinking. This is like a rule book, which must be followed.
2. The test plan helps in determining the necessary efforts to validate the quality of the software
application under the test.
3. The test plan helps those people to understand the test details that are related to the outside like
developers, business managers, customers, etc.
4. Important aspects like test schedule, test strategy, test scope etc are documented in the test plan
so that the management team can review them and reuse them for other similar projects.

Test Scenario

The test scenario is a detailed document of test cases that cover end to end functionality of a software
application in liner statements. The liner statement is considered as a scenario. The test scenario is a high-
level classification of testable requirements. These requirements are grouped on the basis of the
functionality of a module and obtained from the use cases.

In the test scenario, there is a detailed testing process due to many associated test cases. Before
performing the test scenario, the tester has to consider the test cases for each scenario.

In the test scenario, testers need to put themselves in the place of the user because they test the software
application under the user's point of view. Preparation of scenarios is the most critical part, and it is
necessary to seek advice or help from customers, stakeholders or developers to prepare the scenario.

How to write Test Scenarios

As a tester, follow the following steps to create Test Scenarios-

1. Read the requirement document such as BRS (Business Requirement Specification), SRS (System
Requirement Specification) and FRS (Functional Requirement Specification) of the software which is
under the test.
2. Determine all technical aspects and objectives for each requirement.
3. Find all the possible ways by which the user can operate the software.
4. Ascertain all the possible scenario due to which system can be misused and also detect the users
who can be hackers.
5. After reading the requirement document and completion of the scheduled analysis make a list of
various test scenarios to verify each function of the software.
6. Once you listed all the possible test scenarios, create a traceability matrix to find out whether each
and every requirement has a corresponding test scenario or not.
7. Supervisor of the project reviews all scenarios. Later, they are evaluated by other stakeholders of
the project.

Features of Test Scenario

1. The test scenario is a liner statement that guides testers for the testing sequence.
2. Test scenario reduces the complexity and repetition of the product.
3. Test scenario means talking and thinking about tests in detail but write them in liner statements.
4. It is a thread of operations.
 5. Test scenario becomes more important when the tester does not have enough time to write test
cases, and team members agree with a detailed liner scenario.
6. The test scenario is a time saver activity.
7. It provides easy maintenance because the addition and modification of test scenarios are easy and
independent.

Test Case

The test case is defined as a group of conditions under which a tester determines whether a software
application is working as per the customer's requirements or not. Test case designing includes
preconditions, case name, input conditions, and expected result. A test case is a first level action and
derived from test scenarios.

Test case gives detailed information about testing strategy, testing process, preconditions, and expected
output. These are executed during the testing process to check whether the software application is
performing the task for that it was developed or not.

Writing of test cases is a one-time attempt that can be used in the future at the time of regression testing.

Test case helps the tester in defect reporting by linking defect with test case ID. Detailed test case
documentation works as a full proof guard for the testing team because if developer missed something,
then it can be caught during execution of these full-proof test cases.

Usually, there is no formal templet for test case writing, but the following components are always included
in every test case-

1. Test case ID
2. Pre-conditions
3. Purpose
4. Steps
5. Actual outcome
6. Expected outcome
7. Assumptions
8. Product module
9. Product version
10. Revision history
11. Post-conditions

Test Suit

Many test cases can be derived from one test scenario, and sometimes multiple test cases are written for a
single function of software, these multiple test cases are known as test suit.

Software Testing Life Cycle (STLC)

The procedure of software testing is also known as STLC (Software Testing Life Cycle) which includes phases
of the testing process. The testing process is executed in a well-planned and systematic manner. All
activities are done to improve the quality of the software product.

Software testing life cycle contains the following steps:

1. Requirement Analysis
 2. Test Plan Creation
3. Environment setup
4. Test case Execution
5. Defect Logging
6. Test Cycle Closure

Requirement Analysis:

The first step of the manual testing procedure is requirement analysis. In this phase, tester analyses
requirement document of SDLC (Software Development Life Cycle) to examine requirements stated by the
client. After examining the requirements, the tester makes a test plan to check whether the software is
meeting the requirements or not.

Entry Criteria Activities Deliverable

For the planning of test plan
requirement specification,
application architecture
document and well-defined
acceptance criteria should be
available.
Prepare the list of all List of all the necessary tests for
requirements and queries, and the testable requirements and
get resolved from Technical Test environment details
Manager/Lead, System
Architecture, Business Analyst
and Client.
Make a list of all types of tests
(Performance, Functional and
security) to be performed.
Make a list of test environment
details, which should contain all
the necessary tools to execute
test cases.

Test Plan Creation:

Test plan creation is the crucial phase of STLC where all the testing strategies are defined. Tester
determines the estimated effort and cost of the entire project. This phase takes place after the successful
completion of the Requirement Analysis Phase. Testing strategy and effort estimation documents provided
by this phase. Test case execution can be started after the successful completion of Test Plan Creation.

Entry Criteria Activities Deliverable

Requirement Define Objective as well as the scope of Test strategy document.

Document the software. Testing Effort estimation documents
List down methods involved in testing. are the deliverables of this phase.
Overview of the testing process.
Settlement of testing environment.
Preparation of the test schedules and
 control procedures.
Determination of roles and
responsibilities.
List down testing deliverables, define risk
if any.

Environment setup:

Setup of the test environment is an independent activity and can be started along with Test Case
Development. This is an essential part of the manual testing procedure as without environment testing is
not possible. Environment setup requires a group of essential software and hardware to create a test
environment. The testing team is not involved in setting up the testing environment, its senior developers
who create it.

Entry Criteria Activities Deliverable

Test strategy and test plan
document.
Test case document.
Testing data.
Test case Execution:
Prepare the list of software and hardware by analyzing Execution
requirement specification. report.
After the setup of the test environment, execute the Defect report.
smoke test cases to check the readiness of the test
environment.

Test case Execution takes place after the successful completion of test planning. In this phase, the testing
team starts case development and execution activity. The testing team writes down the detailed test cases,
also prepares the test data if required. The prepared test cases are reviewed by peer members of the team
or Quality Assurance leader.

RTM (Requirement Traceability Matrix) is also prepared in this phase. Requirement Traceability Matrix is
industry level format, used for tracking requirements. Each test case is mapped with the requirement
specification. Backward & forward traceability can be done via RTM.

Entry Criteria Activities Deliverable

Requirement Creation of test cases. Test execution result. 

Document Execution of test cases. List of functions with the detailed
Mapping of test cases according to explanation of defects.
requirements.
Defect Logging:

Testers and developers evaluate the completion criteria of the software based on test coverage, quality,
time consumption, cost, and critical business objectives. This phase determines the characteristics and
drawbacks of the software. Test cases and bug reports are analyzed in depth to detect the type of defect
and its severity.
Defect logging analysis mainly works to find out defect distribution depending upon severity and types. If
any defect is detected, then the software is returned to the development team to fix the defect, then the
software is re-tested on all aspects of the testing.

Once the test cycle is fully completed then test closure report, and test metrics are prepared.

Entry Criteria Activities Deliverable

Test case execution It evaluates the completion criteria of the software based on Closure report
report. test coverage, quality, time consumption, cost, and critical Test metrics
Defect report business objectives. 
Defect logging analysis finds out defect distribution by
categorizing in types and severity.

Test Cycle Closure:

The test cycle closure report includes all the documentation related to software design, development,
testing results, and defect reports.

This phase evaluates the strategy of development, testing procedure, possible defects in order to use these
practices in the future if there is a software with the same specification.

Entry Criteria Activities Deliverable

All document and reports Evaluates the strategy of development, testing Test closure report
related to software. procedure, possible defects to use these
practices in the future if there is a software with
the same specification

Defect Management Process in Agile

In agile software development formal defect management processes help to build quality
software. The core purpose of defect management is to make the software more effective and
efficient in order to increase its quality. There are several methods for handling defects like defect
prevention, defect discovery and resolution which are used by software developers and testers.
Refactoring keeps the system clean by identifying and removing quality defects. To gain the full
confidence of the customer defect management should be involved at every stage of
development. Agile methodologies focus on delivering the software in form of short iterations.
Thus each iteration helps to overcome defects and leads better development and end user
satisfaction.
What is Defect 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.
Defect Status or Bug Status in defect life cycle is the present state from which the defect or a bug
is currently undergoing. The goal of defect status is to precisely convey the current state or
progress of a defect or bug in order to better track and understand the actual progress of the
defect life cycle.

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

Defect Life Cycle Explained

 1. Tester finds the defect
2. Status assigned to defect- New
3. A defect is forwarded to Project Manager for analyze
4. Project Manager decides whether a defect is valid
5. Here the defect is not valid- a status is given "Rejected."
6. So, project manager assigns a status rejected. If the defect is not rejected then the next
step is to check whether it is in scope. Suppose we have another function- email
functionality for the same application, and you find a problem with that. But it is not a part
of the current release when such defects are assigned as a postponed or deferred status.
7. Next, the manager verifies whether a similar defect was raised earlier. If yes defect is
assigned a status duplicate.
8. If no the defect is assigned to the developer who starts fixing the code. During this stage,
the defect is assigned a status in- progress.
9. Once the code is fixed. A defect is assigned a status fixed
10. Next, the tester will re-test the code. In case, the Test Case passes the defect is closed. If
the test cases fail again, the defect is re-opened and assigned to the developer.
11. Consider a situation where during the 1st release of Flight Reservation a defect was found
in Fax order that was fixed and assigned a status closed. During the second upgrade release
the same defect again re-surfaced. In such cases, a closed defect will be re-opened.

Difference between defect, bug, error and failure

What is a defect?
The variation between the actual results and expected results is known as defect.
If a developer finds an issue and corrects it by himself in the development phase then it’s called a defect.
What is a bug?
If testers find any mismatch in the application/system in testing phase then they call it as Bug.
What is an error?
We can’t compile or run a program due to coding mistake in a program. If a developer unable to
successfully compile or run a program then they call it as an error.
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 failure

Defect Severity And Priority In Software Testing

Severity and priority are the two things we have to choose once the bug is found. Whenever we find a bug,
we select the bug severity and bug priority. Usually, Testers select the severity of the bug and the Project
Manager or Project Lead selects the bug priority.

What is Severity?
Bug/Defect severity can be defined as the impact of the bug on customer’s business. It can be Critical,
Major or Minor. In simple words, how much effect will be there on the system because of a particular
defect.
What are the types of Severity?
Severity can be categorized into three types:
As mentioned above the type of severity are categorized as Critical, Major, and Minor
Critical:
A critical severity issue is an issue where a large piece of functionality or major system component is
completely broken and there is no workaround to move further.
For example, Due to a bug in one module, we cannot test the other modules because that blocker bug has
blocked the other modules. Bugs which affects the customers business are considered as critical
Major:
A major severity issue is an issue where a large piece of functionality or major system component is
completely broken and there is a workaround to move further.
Minor:
A minor severity issue is an issue that imposes some loss of functionality, but for which there is an
acceptable & easily reproducible workaround.
For example, font family or font size or color or spelling issue
Trivial:
A trivial severity defect is a defect which is related to enhancement of the system.

What is Priority?
Defect priority can be defined as how soon the defect should be fixed. It gives the order in which a defect
should be resolved. Developers decide which defect they should take up next based on the priority. It can
be High, Medium or Low.
Most of the times the priority status is set based on the customer requirement.
What are the types of Priority?

Priority can be categorized into three types:

As mentioned above the type of severity are categorized as High, Medium, and Low
Let’s see how can we segregate a bug into these types:
High:
A high priority issue is an issue which has a high impact on the customers business or an issue which affects
the system severely and the system cannot be used until the issue was fixed. These kinds of issues must be
fixed immediately. Most of the cases as per the user perspective, the priority of the issue is set to high
priority even though the severity of the issue is minor.
Medium:
Issues which can be released in the next build comes under medium priority. Such issues can be resolved
along with other development activities.
Low:
An issue which has no impact on the customer business comes under low priority.

High Priority & High Severity:

A critical issue where a large piece of functionality or major system component is completely broken.
For example,
1. Submit button is not working on a login page and customers are unable to login to the application
2. On a bank website, an error message pops up when a customer clicks on transfer money button.
3. Application throws an error 500 response when a user tries to do some action.
500 Status Codes:
The server has problems in processing the request and these are mainly server errors and not with the
request.
These kinds of showstoppers come under High Priority and High Severity.
There won’t be any workaround and the user can’t do the further process.
Low Priority & High Severity:

An issue which won’t affects customers business but it has a big impact in terms of functionality.
For example,
1. Crash in some functionality which is going to deliver after couple of releases
2. There is a crash in an application whenever a user enters 4 digits in the age field which accepts max 3
digits.

High Priority & Low Severity:

A minor issue that imposes some loss of functionality, but for which there is an acceptable & easily
reproducible workaround. Testing can proceed without interruption but it affects customers reputation.

For example,
1. Spelling mistake of a company name on the homepage
2. Company logo or tagline issues

It is important to fix the issue as soon as possible, although it may not cause a lot of damage.
Low Priority & Low Severity:
A minor issue that imposes some loss of functionality, but for which there is an acceptable & easily
reproducible workaround. Testing can proceed without interruption.
For example,
1. FAQ page takes a long time to load.
2. Font family or font size or color or spelling issue in the application or reports (Spelling mistake of
company name on the home page won’t come under this Low Priority and Low Severity)
These kinds of issues won’t bother the customers much.
Some more points:
Development team takes up the high priority defects first rather than of high severity.
Generally, severity is assigned by Tester / Test Lead & priority is assigned by Developer/Team Lead/Project
Lead.
Software Test Metrics:
Software test metrics is to monitor and control process and product. It helps to drive the project towards
our planned goals without deviation.
Software test metrics are classified into two types
1. Process metrics
2. Product metrics
Test Case Preparation Productivity:
It is used to calculate the number of Test Cases prepared and the effort spent for the preparation of Test
Cases.
Formula:
1. Test Case Preparation Productivity = (No of Test Case)/ (Effort spent for Test Case Preparation)
E.g.: No. of Test cases = 240
Effort spent for Test case preparation (in hours) = 10*8
Test Case preparation productivity = 240/80 = 3 test cases/hour
Test Design Coverage:
It helps to measure the percentage of test case coverage against the number of requirements
Formula:
Test Design Coverage = ((Total number of requirements mapped to test cases) / (Total number of
requirements)*100
E.g.: Total number of requirements: 100
Total number of requirements mapped to test cases: 98
Test Design Coverage = (98/100)*100 = 98%
Test Execution Productivity:
It determines the number of Test Cases that can be executed per hour
Formula:
(No of Test cases executed)/ (Effort spent for execution of test cases)
E.g.: No of Test cases executed = 180
Effort spent for execution of test cases = 10
Test Execution Productivity = 180/10 = 18 test cases/hour
Test Execution Coverage:
It is to measure the number of test cases executed against the number of test cases planed.
Formula:
Test Execution Coverage = (Total no. of test cases executed / Total no. of test cases planned to
execute)*100
E.g.: Total no. of test cases planned to execute = 240
Total no. of test cases executed = 160
Test Execution Coverage = (180/240)*100 = 75%
Test Cases Passed:
It is to measure the percentage no. of test cases passed
Formula:
Test Cases Pass = (Total no. of test cases passed) / (Total no. of test cases executed) * 100
E.g.: Test Cases Pass = (80/90)*100 = 88.8 = 89%
Test Cases Failed:
It is to measure the percentage no. of test cases failed
Formula: Test Cases Failed = (Total no. of test cases failed) / (Total no. of test cases executed) * 100
E.g.: Test Cases Failed= (10/90)*100 = 11.1 = 11%
Test Cases Blocked:
It is to measure the percentage no. of test cases blocked
Formula:
Test Cases Blocked = (Total no. of test cases blocked) / (Total no. of test cases executed) * 100
E.g.: Test Cases Blocked = (5/90)*100 = 5.5 = 6%

Product metric:
Software Test Metrics used in the process of defect analysis phase of STLC.

It is to determine the effectiveness of the test cases.

Formula:
Error Discovery Rate = (Total number of defects found /Total no. of test cases executed)*100
E.g.: Total no. of test cases executed = 240
Total number of defects found = 60
Error Discovery Rate = (60/240)*100 = 25%
Defect Fix Rate:
It helps to know the quality of a build in terms of defect fixing.
Formula:
Defect Fix Rate = (Total no of Defects reported as fixed - Total no. of defects reopened) / (Total no of
Defects reported as fixed + Total no. of new Bugs due to fix)*100
E.g.: Total no of defects reported as fixed = 10
Total no. of defects reopened = 2
Total no. of new Bugs due to fix = 1
Defect Fix Rate = ((10 – 2)/(10 + 1))*100 = (8/11)100 = 72.7 = 73%
Defect Density:
It is defined as the ratio of defects to requirements.
Defect density determines the stability of the application.
Formula:
Defect Density = Total no. of defects identified / Actual Size (requirements)
E.g.: Total no. of defects identified = 80
Actual Size= 10
Defect Density = 80/10 = 8
Defect Leakage:
It is used to review the efficiency of the testing process before UAT.
Formula:
Defect Leakage = ((Total no. of defects found in UAT)/(Total no. of defects found before UAT)) * 100
E.g.: No. of defects found in UAT = 20
No. of Defects found before UAT = 120
Defect Leakage = (20 /120) * 100 = 16.6 = 17%
Defect Removal Efficiency:
It allows us to compare the overall (defects found pre and post-delivery) defect removal efficiency
Formula:
Defect Removal Efficiency = ((Total no. of defects found pre-delivery) /( (Total no. of defects found pre-delivery )+
(Total no. of defects found post-delivery)))* 100
E.g.:
Total no. of defects found pre-delivery = 80
Total no. of defects found post-delivery = 10
Defect Removal Efficiency = ((80) / ((80) + (10)))*100 = (80/90)*100 = 88.8 = 89%

Requirements Traceability Matrix (RTM)

Requirements Traceability Matrix (RTM) is used to trace the requirements to the tests that are needed to
verify whether the requirements are fulfilled.
Requirement Traceability Matrix AKA Traceability Matrix or Cross Reference Matrix.
Types of Requirements Traceability Matrix (RTM):
Forward Traceability: Mapping requirements to test cases is called Forward Traceability Matrix. It is used
to ensure whether the project progresses in the desired direction. It makes sure that each requirement is
tested thoroughly.
Backward or Reverse Traceability: Mapping test cases to requirements is called Backward Traceability
Matrix. It is used to ensure whether the current product remains on the right track. It makes sure that we
are not expanding the scope of the project by adding functionality that is not specified in the requirements.
Bi-directional traceability (Forward + Backward): Mapping requirements to test cases (forward
traceability) and test cases to requirements (backward traceability) is called Bi-directional Traceability
Matrix. It is used to ensure that all the specified requirements have appropriate test cases and vice versa.
Advantage of Requirements Traceability Matrix (RTM):
1. 100% test coverage
2. It allows to identify the missing functionality easily
3. It allows to identify the test cases which needs to be updated in case of change in requirement
4. It is easy to track the overall test execution status

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.
The following are list of test deliverables:
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)

Agile Scrum Methodology

Agile Scrum Methodology is one of the popular Agile software development methods. There are
some other agile software development methods but the popular one which is using widely is
Agile Scrum Methodology. The Agile Scrum Methodology is a combination of both Incremental
and Iterative model for managing product development.
In Scrum, the project is divided into Sprints.
Sprint: Each Sprint has a specified time line (2 weeks to 1 month). This time line will be agreed by a Scrum
Team during the Sprint Planning Meeting. Here, User Stories are split in to different modules. End result of
every Sprint should be potentially shippable product.
The three important aspects involved in Scrum such as Roles, Artifacts and Meetings:

ROLES IN AGILE SCRUM METHODOLOGY:

Product Owner:

Product Backlog
Product Owner usually represents the Client and acts as a point of contact from Client side. The one who
prioritizes the list of Product Backlogs which Scrum Team should finish and release.
Scrum Master:

Scrum Master acts as a facilitator to the Scrum Development Team. Clarifies the queries and organizes the
team from distractions and teach team how to use scrum and also concentrates on Return on Investment
(ROI).
Scrum Development Team:
Developer’s, QA’s. Who develops the product. Scrum development team decides the effort estimation to
complete a Product Backlog Item.
Scrum Team:
A cross-functional, self-organizing group of dedicated people (Group of Product Owner, Business Analyst,
Developer’s and QA’s). Recommended size of a scrum team is 7 plus or minus 2 (i.e., between 5 to 9
members in a team)
ARTIFACTS IN AGILE SCRUM METHODOLOGY:
User Stories:
User Stories are not like a traditional requirement documents. In User Stories, stake holder mention what
features they need and what they want to achieve.
Product Backlog:
Product Backlog is a repository where the list of Product Backlog Items stored and maintained by the
Product Owner. The list of Product Backlog Items are prioritized by the Product Owner as high and low and
also could re-prioritize the product backlog constantly.
Sprint Backlog:
Group of user stories which scrum development team agreed to do during the current sprint (Committed
Product Backlog items).

Product Burn down Chart:

graph which shows how many Product Backlog Items (User Stories) implemented/not implemented.

Sprint Burn down Chart:

A graph which shows how many Sprints implemented/not implemented by Scrum Team.
Release Burn down Chart:
A graph which shows List of releases still pending, which Scrum Team have planned.

Defect Burn down Chart:

A graph which shows how many defects identified and fixed.
Sprin Identifie Fixe
t d d Carry Forward
1 13 6 7
2 5 6 6
3 4 6 4
4 2 6 0

Note: Burn Down Charts provide proof that the project is on track or not.

MEETINGS IN AGILE SCRUM METHODOLOGY:

Sprint Planning Meeting:
The first step of Scrum is Sprint Planning Meeting where the entire Scrum Team attends. Here the Product
Owner selects the Product Backlog Items (User Stories) from the Product Backlog.
Most important User Stories at the top of the list and least important User Stories at the bottom. Scrum
Development Team decides and provides the effort estimation.
Daily Scrum Meeting: (Daily Stand-up)
Daily Scrum is also known as Daily Stand-up meeting. Here each team member reports to the peer team
member on what he/she did yesterday, what he/she going to do today and what obstacles are impeding in
their progress. Reporting will be between peers not to Scrum Master or Product Owner. Daily Scrum will be
approximately 15 mins.
Sprint Review Meeting:
In the Sprint Review Meeting, Scrum Development Team presents a demonstration of a potentially
shippable product. Product Owner declares which items are completed and not completed. Product Owner
adds the additional items to the product backlog based on the stakeholders feedback.
Sprint Retrospective Meeting:
Scrum Team meets again after the Sprint Review Meeting and documents the lessons learnt in the earlier
sprint such as “What went well”, “What could be improved”. It helps the Scrum Team to avoid the mistakes
in the next Sprints.
When do we use Agile Scrum Methodology?
The client is not so clear on requirements
The client expects quick releases
The client doesn’t give all the requirements at a time
Conclusion:
In an Agile Scrum Methodology, all the members in a Scrum Team gathers and finalize the Product Backlog
Items (User Stories) for a particular Sprint and commits time line to release the product. Based on the Daily
Scrum meetings, Scrum Development Team develops and tests the product and presents to the Product
Owner on Sprint Review Meeting. If the Product Owner accepts all the developed User Stories then the
Sprint is completed and the Scrum Team goes for the next Sprint in a same manner.

Principles Agile Software Development

Agile testing is a software testing practice that follows the principles agile software development. It is an
iterative software development methodology where requirements keep changing as per the customer
needs. Testing is done in parallel to the development of an iterative model. Test team receives frequent
code changes from the development team for testing an application.
12 principles Agile Software Development:
1. Highest priority is to satisfy the customer through early and continuous delivery of business
valuable software
2. Welcome changing requirements, even late in development
3. Deliver working software frequently
4. Business people and developers must work together daily without transparency throughout the
project
5. Build projects around motivated individuals
6. The best form of communication is to do face-to-face conversation
7. Working software is the primary measure of progress
8. Able to maintain a constant pace
9. Continuous attention to technical excellence
10. Simplicity – the art of maximizing the amount of work not done – is essential
11. Self-organizing teams
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its
behavior accordingly