Testing Artifacts 

Certain number of test artifacts (documents, models, etc.) are created and used
during the testing.

The most common test artifacts are:

● The Test Plan is a document describing the entire scope of testing, beginning with
the description of the object, strategy, timetable, criteria for starting and ending
testing, up to the necessary equipment, special knowledge, and risk assessment
with options for their resolution.
● The Case & Test suite test is a sequence of actions by which you can check
whether the function under test meets the requirements.
● Bug Reports / Defects are documents describing a situation or a sequence of
actions that led to an incorrect operation of the test object, indicating the causes
and expected result.

Test Plan

Purpose of Test Plan

Making Test Plan document has multiple benefits

● Help people outside the test team such as developers, business managers,
customers understand the details of testing.
● Test Plan guides our thinking. It is like a rule book, which needs to be
followed.
● Important aspects like test estimation, test scope, Test
Strategy are documented in Test Plan, so it can be reviewed by
Management Team and re-used for other projects.

How to write a Test Plan

You already know that making a Test Plan is the most important task of Test
Management Process. Follow the seven steps below to create a test plan as per
IEEE 829

1. Analyze the product

2. Design the Test Strategy
 3. Define the Test Objectives
4. Define Test Criteria
5. Resource Planning
6. Plan Test Environment
7. Schedule & Estimation
8. Determine Test Deliverables

Test Plan Template

1. Introduction
Test Plan Objectives
2. Scope
It provides an insight into the approved scope of work for the QA team and works
as an excellent reference for reporting.

● Features to be
● Features not to be tested 

3. Test Strategy
The primary objective of a test plan is to communicate the testing
approach/methods to the reader. This section must list the types and number of
rounds of testing, the defect tracking process and list of tools to be used for the
project.

The selection of the test strategy may depend on the below aspects:

o Organization type and size.

o Project requirements, such as safety and security related applications
require rigorous strategy.
o Product development model.

4. Environment Requirements
These are the environments where we will test the application, and here we
have two types of environments, which are
of software and hardware configuration.. e.g Operating system, browser,
database server,web server etc.

5. Test Schedule
Having a schedule is an essential part of any project success. A QA manager must
schedule all QA activities, and note them in the test plan. 

6. Control Procedures
Procedures followed for and documents used for
● Bug Reporting
● Change Request

7. Functions To Be Tested

For example, Suppose we have a Gmail application to test, where features to be

tested such as Compose mail, Sent Items, Inbox, Drafts 
We can use following ways to describe Functions To Be Tested
o By writing the high-level scenarios
o By writing the flow graph

By writing the high-level scenarios

For example, suppose we are testing the Gmail application:
o Login to Gmail- sends an email and check whether it is in the Sent Items
page
o Login to …….

By writing the flow graph

The flow graph is written because writing the high-level scenarios are bit time
taking process, as we can see in the below image:
 o

8. Role and Responsibilities

It defines the complete task which needs to be performed by the entire testing
team. Test Manager, Test Lead, Junior/senior Test Engineers

Role: Test Manager Name: Ryan

Responsibility:

o Prepare( write and review) the test plan

o Conduct the meeting with the development team, testing team,
customer
o Sign off release note
o Handling Escalations and issues

Role: Test Lead Name: Harvey

Responsibility:

o Prepare( write and review) the test plan

o Conduct daily stand up meeting
o Review and approve the test case
o Prepare the RTM and Reports
o Assign modules
o Handling schedule
 Role: Test Engineer 1, Test Engineer 2 and Test Engineer 3

Name: Louis, Jessica, Donna

Assign modules: M1, M2, and M3

Responsibility:

o Write, Review, and Execute the test documents which consists of test
case and test scenarios
o Read, review, understand and analysis the requirement
o Write the flow of the application
o Execute the test case
o RTM for respective modules
o Defect tracking
o Prepare the test execution report and communicate it to the Test Lead.

9. Deliverables

These are the documents which are the output from the testing Testing process:

i. Test Cases
ii. Test Scripts
iii. RTM(Requirement Traceability Matrix)
iv. Defect Report
v. Test Execution Report
vi. Graphs and metrics
vii. Release Notes

10. Entry / Exit Criteria

It is a necessary condition, which needs to be satisfied before starting and stopping
the testing process.
Entry Criteria
The entry criteria may contain the following conditions:
 o Understand and analyze the requirement and prepare the test documents or
when the test documents are ready.
o Test data should be ready.
o Build or the application must be prepared
o Modules or features need to be assigned to the different test engineers.
o The necessary resource must be ready.

Exit Criteria
The exit criteria contain the following conditions:
o When all the test cases are executed.
o Most of the test cases must be passed.
o Depends on severity of the bugs which means that there must not be any
blocker or major bug, whereas some minor bugs exist.

11. Dependencies
List any dependencies identified during the development of this Test Plan that
may affect its successful execution if those dependencies are
not honored.

13. Risks
List any risks that may affect the successful execution of this Test Plan, and
identify mitigation and contingency strategies for each risk. 
Contingency
Risk Mitigation Strategy
(Risk is realized)
<Tester> will define the
prerequisites that must be met
before Load Testing can start. ● meet outstanding
Prerequisite
Entry Criteria is prerequisites
not met. <Customer> will endeavor to meet ● consider Load Test Failure
prerequisites indicated by
<Tester>.
Test data <Customer> will ensure a full set ● redefine test data
proves to be of suitable and protected test data ● review Test Plan and modify
inadequate. is available. Components (that is, scripts)
 <Tester> will indicate what is
● consider Load Test Failure
required and will verify suitability
of test data.
<System Administrator> will
Database ● restore data and restart
endeavor to ensure that the
requires a ● clear Database
Database is regularly refreshed as
refresh.
required by the <Tester>.

14. Tools

Tools from a software testing context can be defined as a product that supports one
or more test activities right from planning, requirements, creating a build, test
execution, defect logging and test analysis.

15. Documentation

16. Approvals
Specify the names and titles of all the people who must approve this plan. Provide
space for the signatures and dates.

Name (In Capital Letters) Signature Date:

Test Strategies and approach

1. Methodical Strategy
o In this, the test teams follow a set of test conditions, pre-defined quality
standard(like ISO25000), checklists.
o The Standard checklists is occurred for precise types of testing, such
as security testing.

2. Reactive Strategy
o In this, we can design the test and execute them only after the real software
is delivered, Therefore, the testing is based upon the identified defects in the
existing system.
3. Analytical strategy
o is used to perform testing based on requirements, and requirements are
analyzed to derive the test conditions. And then tests are designed,
implemented, and performed to encounter those requirements Even the
outcomes are recorded in terms of requirements, such as requirements tested
and passed.

4. Standards compliant or Process compliant strategy

o In this type the test engineer will follow the procedures or guidelines created
by a panel of industry specialists or committee standards to find test
conditions, describe test cases, and put the testing team in place.
o Medical systems following US FDA (Food and Drugs Administration)
standards.

5. Model-based strategy

o The testing team selects the current or expected situation and produces a

model for it with the following aspects: inputs, outputs, processes, and
possible behavior.
o And the models are also established based on the current data speeds,
software, hardware, infrastructure, etc.

6. Regression averse strategy

o Regression is a feature that works but no longer works after new code
releases. This issue is caused by several factors such as system upgrades,
feature enhancements,
o the test engineer mainly emphasizes decreasing regression
risks for functional or non-functional product shares.
o For example, suppose we have one web application to test the regression
issues for the particular application.

7. Consultative strategy

o The consultative strategy is used to consult key investors as input to choose

the scope of test conditions as in user-directed testing.
o the client will provide a list of browsers and their versions, operating
systems, a list of connection types, anti-malware software, and also the
contradictory list, which they want to test the application.
 o As per the need of the items given in provided lists, the test engineer may
use the various testing techniques, such as equivalence partitioning

We can combine the two or more strategies as per the needs of the product and
organization's requirements. And it is not necessary to use any one of the above
listed test strategies for any testing project.
Test cases and Test Scenarios:
●A test scenario is a process wherein the tester tests a software application
from an end-user perspective.
● One Test Scenario can have multiple ‘Test Cases’. It can be figured as a big
panoramic image and test cases are the small parts that are important to
complete the panorama.
● Test scenarios determine the business process flow of the software 
● Test Scenarios thus assist in evaluating the software application as per the
real-world situations.
Test Scenario is a high level functionality. Test cases are detailed procedure
to test the high level functionality.
Example:
Test Scenario: Make the payment for the cab service availed.
This will have multiple test cases as stated below:
Payment method to be used: PayPal, Paytm, Credit/Debit Card.
(ii) The payment done is successful.
(iii) Payment done is unsuccessful.
(iv) The payment process aborted in between.
(v) Not able to access payment methods.
(vi) The application breaks down in between.

Use Case in Testing

o A Use Case is a brief description of a particular use of the software
application by an actor or user. Use cases are made on the basis of user
actions and the response of the software application to those user actions. It
is widely used in developing test cases at system or acceptance level.

o Use Case Testing is a software testing technique that helps to identify test
cases with help of use cases that cover entire system.
o Use case testing is interactions between users and software application.

o
Software Testing Metrics

Metrics can be defined as “STANDARDS OF MEASUREMENT”.

Test metrics include:
● How many defects exist within the module?
● How many test cases are executed per person?
● What is Test coverage %?
Test Metrics are used to,
● Take the decision for the next phase of activities such as, estimate the cost &
schedule of future projects.
● Understand the kind of improvement required to success the project
● Take a decision on the Process or Technology to be modified etc.
Example:

Test Report

It is a document that records data obtained from an evaluation experiment in an

organized manner, describes the environmental or operating conditions, and shows
the comparison of test results with test objectives.
 ● It helps in appraising how well testing was performed and identifying the
reasons behind a failed/negative test report. The data derived from the report
is crucial for the business.
● the quality of the tested product or feature, and help them in the decision
making regarding their product release.
● with the help of test reporting analysis, the stakeholders like testers,
developers, analysts, product managers understand the quality of overall
testing and test automation activities. It helps them figure out the origin of
the issue or at what stage it arose.
● The objective of good test reporting should be to be able to answer important
questions like, what is the value achieved through testing activities? Is your
team skilled enough to identify the issues well in advance? Are the tests
stable? Are you avoiding unnecessary testing?

A Sample Test Report

1.0 Introduction:

2.0 Test Items:

3.0 Reference documents:

Test Plan, Test Case documents, Opened and Closed Defect Reports, Metrics docs,
Review Reports.

4.0 Target Audience:

Project Manager, Release Team, Maintenance Team and Customer (End Users).

5.0 Test Summary

5.1 Test Suite Information:

•    Test suites planned: 42

•    Test suites implemented: 39
•    Test suites executed: 38

5.2 Test Case Information: 

•    Test cases planned: 983
•    Test cases implemented: 978
•    Test cases executed: 967
•    Test cases passed: 940 (Final)
•    Test cases failed: 14 (Final)
•    Test Cases pending: 3

5.3 Defect/bug Report Information

Test ID Pass/Fail Comment Action

Needed
(Same ID as in
test plan)

6.0 Approvals

Name Role Responsibility Date & Signature

—--------------------------

Configuration management

● Configuration management determines clearly about the items that make up the
software or system. These items include source code, test scripts, third-party
software, hardware, data and both development and test documentation.
● Configuration management is also about making sure that these items are
managed carefully, thoroughly and attentively during the entire project and
product life cycle.
● Configuration management has a number of important implications for testing.
Like configuration management allows the testers to manage their testware and
test results using the same configuration management mechanisms.

Test Monitoring?
Test Monitoring in test execution is a process in which the testing activities and
testing efforts are evaluated in order to track current progress of testing activity,
finding and tracking test metrics, estimating the future actions based on the test
metrics and providing feedback to the concerned team as well as stakeholders
about current testing process.

Test Control?

Test Control in test execution is a process of taking actions based on results of the
test monitoring process. In the test control phase, test activities are prioritized, test
schedule is revised, test environment is reorganized and other changes related to
testing activities are made in order to improve the quality and efficiency of future
testing process.