Department of CSE

Regulation : 2021
Semester : VI
CCS366
SOFTWARE TESTING AND AUTOMATION
Unit II Notes
 lOMoAR cPSD| 35867393

UNIT II TEST PLANNING 6

The Goal of Test Planning, High Level Expectations, Intergroup Responsibilities,
Test Phases, Test Strategy, Resource Requirements, Tester Assignments, Test
Schedule, Test Cases, Bug Reporting, Metricsand Statistics.

The Goal of Test Planning

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 goal of test planning is to define a comprehensive strategy and approach for testing a software
application or system. It involves determining the scope of testing, identifying testing objectives, defining
test objectives, identifying necessary resources, and creating a schedule for executing the tests.

The main objectives of test planning are as follows:

Understanding Testing Scope: Test planning helps in defining the scope of testing, including the features
 lOMoAR cPSD| 35867393

and functionalities to be tested. It involves analyzing requirements, design specifications, and other
project documents to identify what needs to be tested.

Defining Testing Objectives: Test planning involves setting clear and measurable testing objectives.
These objectives may include validating system functionality, identifying defects, assessing performance
and scalability, verifying security measures, and ensuring regulatory compliance, among others.

Identifying Test Techniques and Methods: Test planning involves selecting appropriate testing
techniques and methods to achieve the testing objectives. This includes determining whether manual or
automated testing is suitable, deciding on the types of tests to be conducted (e.g., functional,
performance, security), and identifying any specific tools or frameworks that may be required.

Allocating Testing Resources: Test planning helps in identifying the necessary resources for testing,
including personnel, hardware, software, and testing environments. It involves determining the skills
And expertise required for testing, estimating the effort and duration of testing activities, and ensuring
that therequired resources are available and allocated appropriately.

Creating Test Schedule: Test planning involves creating a timeline or schedule for executing the tests. It
includes defining milestones, setting deadlines, and establishing a sequence of testing activities. The test
schedule should consider dependencies on other project activities and take into account any constraints
or limitations.

Risk Assessment and Mitigation: Test planning involves identifying and assessing potential risks and
uncertainties associated with testing. This includes analyzing factors that could impact the success of
testing, such as technical challenges, resource constraints, time limitations, and external dependencies.
Risk mitigation strategies and contingency plans are developed to address these potential risks.

Documentation and Communication: Test planning involves documenting the test strategy, test
objectives, test approach, and other relevant information. It helps in communicating the testing plan to
stakeholders, including project managers, developers, and other team members. Clear documentation
ensures that everyone involved in the testing process has a shared understanding of the goals, scope,
and approach.

Overall, the goal of test planning is to ensure that testing activities are well-organized, efficient, and
effective in achieving the desired testing objectives within the given constraints and project requirements.
It provides a roadmap for the testing team, guides their efforts, and helps in delivering a high-quality
software product or system.

High Level Expectations

Explicit expectations. ..
 lOMoAR cPSD| 35867393

Implicit expectations. ..
Interpersonal expectations. ..
Digital expectations. ...
Dynamic performance expectations. ..
Fast Customer Service ...
Accurate Data by Self-Service ...
Easy-to-Use Websites and Apps.

High-level expectations refer to overarching goals or outcomes that are set for a project, task, or
individual. These expectations are typically broad and strategic, outlining the desired results rather than
specific details on how to achieve them. Here are a few examples of high-level expectations:

Performance: A high-level expectation for an employee could be to consistently meet or exceed

performance targets set by the company. This expectation focuses on the overall results and outcomes
achieved by the employee.

Quality: For a product development project, a high-level expectation might be to deliver a high-quality
product that meets customer requirements and industry standards. This expectation emphasizes the
overall quality of the final deliverable.

Customer Satisfaction: In a customer service role, a high-level expectation may be to ensure a high level
of customer satisfaction by providing timely and effective assistance. The emphasis here is on delivering
exceptional customer service experiences.

Innovation: An expectation for a research and development team could be to foster a culture of innovation
and consistently generate new ideas or solutions. This expectation encourages creativity and the
exploration of new possibilities.

Collaboration: In a team setting, a high-level expectation might be to promote collaboration and effective
communication among team members. This expectation emphasizes the importance of working together
to achieve common goals.

Growth and Development: An expectation for individual employees could be to continuously learn and
develop new skills to enhance their professional growth. This expectation encourages self-improvement
and ongoing learning.

It's important to note that high-level expectations should be clear, measurable, and aligned with the overall
goals and vision of the organization or project. They serve as guiding principles to help individuals and
teams understand what is expected of them and to focus their efforts on achieving the desired outcomes.

Intergroup Responsibilities

Software testing is an essential part of the software development

life cycle (SDLC). Playing a significant role in defining the success rate of a particular
 lOMoAR cPSD| 35867393

product, owing to the same reason the software testing team plays a crucial role even

after the product’s development is completed

Therefore, it is important to ensure that this software testing team includes a perfect mix

of talented as well as capable professionals who are also domain experts.

Being experts in the problem domain make it easier for them to create such test scripts

that make it easier to identify the problem in the product.

While every company follows a different structure of the testing team, there are a few

members who are common in every structure and fulfill the expectations of the team.

This includes:

1. QA Leader:

QA Leader is the most important member of the testing team. While it is extremely
 lOMoAR cPSD| 35867393

crucial for him/her to have a clear understanding of the testing process or methodology.

It is also essential for him/her to be familiar with the varied test-program concerns such

as test environment and data management, trouble reporting and resolution, etc.

The Main Roles and Responsibilities handled by the QA leader are:

Acts as a point of contact for inter and intra departmental interaction

Represents the software testing team as well as enables customer
relationship
Deciding the test budget and schedule
Identifying the testing activities for other team members like testers or test
engineers
Planning the entire testing process
Checking the availability of the resources to execute testing activities
Identifying if the process of testing is going in sync with the software
development
Preparing the status report of testing activities
Sharing updates on testing with the project manager
Planning pre and post-test meetings

2. Test Lead

With a clear understanding about the applications business area and its requirements, a

test lead is a person who is also familiar with the varied test-program issues such as

test data management, test design, and test development.

His/her expertise in numerous technical skills such as programming languages,

database technologies, and computer operating systems also enable him/her to deliver

the best at his/her job.

The Major Role and Responsibilities of a Test Lead include the following:
Technical expertise related to the test program and approach.
Provides support for customer interface, staff planning, and supervision, as
well as progress status reporting.
Validating the quality of the testing requirements such as testability, test
design, and script, test automation, etc.
Staying updated about the latest test approaches and tools
Assisting the software testing team to be aware of the latest trends in the
world of software testing.
Arranging walk-through for test design and procedure.
Implementing the test process.
Ensuring that test-product documentation is complete.
 lOMoAR cPSD| 35867393

3. Test Engineer

The role of a test engineer is to determine the best way to create a process that can

enable one to test a particular product in the best possible manner.

Test engineers can have different expertise based on which they are assigned a role in
a company.

Some of the common test engineers working in an organization are as mentioned

below:

a) Usability Test Engineer

These engineers are highly proficient in designing test suites as well as have a clear

understanding of the usability issues. With excellent interpersonal skills, they are also

skilled in test facilitation. Some of their common job roles include:

Designing the usability testing scenarios
Administering the process of usability testing
Developing test-product documentation
Participating in test-procedure walk-through

b) Manual Test Engineer

With a clear understanding of the Graphical User Interface (GUI) design and its

standards, manual test engineers are highly proficient in designing test suites and

various testing techniques. Some of the major responsibilities of these engineers

include:
Using associated test data to design and develop test procedures and cases
Manually executing the test procedures
Attending test-procedure walk-through
Following the required set standards

c) Automated Test Engineer

Also known as Automater/developer, these engineers also have a good understanding

of the GUI design and software testing. They can also be relied upon for designing the

effective test suites as well as efficiently working with test tools. Some of the common

roles handled by them are:

 lOMoAR cPSD| 35867393

Designing and developing test procedures on the basis of requirements

Following rest-design standards
Attending test procedure walk-throughs
Executing the tests and preparing reports for the same.
4. Network Test Engineer

With a high level of proficiency and expertise in a variety of technical skills such as

programming languages, database technologies, and computer operating systems,

network test engineers are good at product evaluation and integration skills.

Their Major Roles at an Organization include:

Performing network, database, and middle-ware testing
Developing load and stress test designs, cases and procedures
Implementing the performance monitoring tools on an ongoing basis
Conducting load and stress test procedures

5. Test Library and Configuration Specialist:

This job role requires one to have a network, database, and system administration

skills along with expertise in technical skills including programming languages, database

technologies, and computer operating systems. Their major job roles include the

following:
Managing the test-script change
Maintaining test-script version control
Upholding test-script reuse library
Creating test builds, wherever required

6. Tester

Having a sound knowledge about various concepts involved in test designing and

execution methodologies, a software tester is the one who is able to interact efficiently

with the development team. His/her major roles as a part of software testing team

includes:
Designing the testing scenarios for usability testing
Analyzing the testing results and submitting the report to the development
team
Creating test designs, processes, cases and test-product documentation
Conducting testing as per the set standards and procedures
Ensure that the testing is carried out as per the defined standards and
procedures
 lOMoAR cPSD| 35867393

Test Phases

Each phase of the software testing life cycle allows developers to

assess specific characteristics of the software and evaluate whether the software is
suitable for use. The various evaluations during testing can identify errors and deficits in
the application before it enters production and deployment. Finding and resolving such
issues early on helps preserve your reputation and clients' confidence in your work.

Early and effective software testing can also be financially beneficial. By allowing
developers to address flaws in software design, functionality and security as soon as
testers discover them, software testing spares the need for costly changes to the
software while it's in wide use. Resolving such problems during development also helps
ensure that customers have high regard for the software, potentially leading to
increased sales.

What are the 5 phases of testing software?

In the software testing life cycle, there are usually five phases of testing:

1. Static testing

During static testing, developers work to avoid potential problems that might arise later.
Without executing the code, they perform manual or automated reviews of the
supporting documents for the software, such as requirement specifications, searching
for any potential ambiguities, errors or redundancies. The goal is to preempt defects
before introducing them to the software system.

2. Unit testing

The next phase of software testing is unit testing. During this phase, the software
undergoes assessments of its specific units, or its functions and procedures, to ensure
that each works properly on its own. The developers may use white box testing to
evaluate the software's code and internal structure, commonly before delivering the
software for formal testing by testers. Unit testing can occur whenever a piece of code
undergoes change, which allows for quick resolution of issues.

3. Integration testing

Integration testing involves testing all the units of a program as a group to find issues
with how the separate software functions interact with one another. Through integration
testing, the developers can determine the overall efficiency of the units as they run
together. This phase is important because the program's overall functionality relies on
the units operating simultaneously as a complete system, not as isolated procedures.
 lOMoAR cPSD| 35867393

4. System testing

In the system testing phase, the software undergoes its first test as a complete,
integrated application to determine how well it carries out its purpose. For this, the
developers pass the software to independent testers who had no involvement in its
development to ensure that the testing results stem from impartial evaluations. System
testing is vital because it ensures that the software meets the requirements as
determined by the client.

5. Acceptance testing

Acceptance testing is the last phase of software testing. Its purpose is to evaluate the
software's readiness for release and practical use. Testers may perform acceptance
testing alongside individuals who represent the software's target audience. Acceptance
testing aims to show whether the software meets the needs of its intended users and
that any changes the software experiences during development are appropriate for use.
The representative individuals are crucial to this phase because they can offer insight
into what customers may want from the software. Once the software passes acceptance
testing, it moves on to production.

5 types of additional software tests

In addition to the five main phases of testing, you may also need additional tests to
evaluate software. The necessity of these tests depends on the type of company you
work for and the software you're creating. These tests include:

1. Performance testing

In performance testing, testers evaluate how well the software handles various
scenarios and workloads. There are several subtypes of performance testing. A
common performance test is load testing, which recreates real-life user conditions to
determine how the software performs in common scenarios. Another test is stress
testing, in which testers intentionally overload the software to discover how much it can
handle before it fails.

2. Regression testing

Regression testing is a procedure that occurs throughout the testing life cycle. After
developers implement a change to the software, testers perform regression testing to
ensure that previously tested and functional operations remain intact. This is a good
way to help guarantee consistency in functionality.
 lOMoAR cPSD| 35867393

3. Usability testing

Usability testing focuses on ease of use. Testers approach the software from the
perspective of end users, validating that its interface and design are simple to
understand and that the application is easy to operate. Ideally, the user can learn the
software on their own and enjoy a satisfying experience with it.

4. Compatibility testing

Compatibility testing evaluates the software's ability to function as intended in various

computing environments. These include operating systems, mobile platforms and web
browsers. Such environments have their own specifications for the software they run, so
it's important to confirm that the software meets all of those differing specifications.

5. Security testing

Security testing is an assessment of the software in terms of threats, risks and

vulnerabilities. Testers might examine the software for flaws that expose a user's
personal data to hackers or make the software susceptible to malware. If testers find
any such flaws, the developers can secure them with coding.

Test Strategy
A high-level document is used to validate the test types or levels to be executed for the
product and specify the Software Development Life Cycle's testing approach is
known as Test strategy document.

Once the test strategy has been written, we cannot modify it, and it is approved by
the Project Manager, development team.

The test strategy also specifies the following details, which are necessary while we write
the test document:

o What is the other procedure having to be used?

o Which module is going to be tested?
o Which entry and exit criteria apply?
o Which type of testing needs to be implemented?

In other words, we can say that it is a document, which expresses how we go about
testing the product. And the approaches can be created with the help of following
aspects:
 lOMoAR cPSD| 35867393

o Automation or not
o Resource point of view

We can write the test strategy based on development design documents.

The development design document includes the following documents:

o System design documents: Primarily, we will use these documents to write the
test strategy.
o Design documents: These documents are used to specify the software's
functionality to be enabled in the upcoming release.
o Conceptual design documents: These are the document which we used
Infrequently.

The Objective of Test Strategy

o The primary objective of writing the test strategy is to make sure that all purposes
are covered entirely and understood by all stakeholders, we should
systematically create a test strategy.
o Furthermore, a test strategy objective is to support various quality assurance
stockholders in respect of planning of resources, language, test and
integration levels, traceability, roles and responsibilities, etc

Features of Test Strategy Document

o In SDLC (Software Development Life Cycle), the test strategy document plays an
important role. It includes various significant aspects, such as who will implement
the testing, what will be tested, how it will be succeeded, and what risks and
incidents will be are related to it.
o Some of the additional characteristics of the Test Strategy document are as
follows:

o The test strategy document is approved and reviewed by the following's peoples:
o Test Team Lead
o Development Manager
o Quality Analyst Manager
o Product Manager
 lOMoAR cPSD| 35867393

o For different testing activities, the test strategy document specifies the resources,
scope, plan, methodology, etc.
o In order to direct how testing will be achieved, it is used by the project test team
once it is ready or completed.
o Primarily, it is obtained from the BRS (Business Requirements
Specifications) documents.
o The test strategy document is a high-level document, which generally remains
constant, implying no frequent and pointless modification is made in the
document.
o The respective team easily accomplishes the objectives of testing with the help of
a test strategy document.
o The respective team easily accomplishes the objectives of testing with the help of
test strategy document.

Components of Test Strategy Document

We understand that the test strategy document is made during the requirements phase
and after the requirements have been listed.

Like other testing documents, the test strategy document also includes various
components, such as:
 lOMoAR cPSD| 35867393

o Scope and Overview

o Testing Methodology
o Testing Environment Specifications
o Testing Tools
o Release Control
o Risk Analysis
o Review and Approvals

Let's see them one by one for our better understanding:

1. Scope and Overview

o The first component of the test strategy document is Scope and Overview.
o The overview of any product contains the information on who should approve,
review and use the document.
 lOMoAR cPSD| 35867393

o The test strategy document also specified the testing activities and phases that
are needed to be approved.

2. Testing Methodology
o The next module in the test strategy document is Testing methodology, which
is mainly used to specify thelevels of testing, testing procedure, roles, and
responsibilities of all the team members.
o The testing approach also contains the change management process involving
the modification request submission, pattern to be used, and activity to manage
the request.
o Above all, if the test strategy document is not established appropriately, then it
might lead to errors or mistakesin the future.

3. Testing Environment Specifications

o Another component of the test strategy document is Testing Environment
Specification.
o As we already aware of the specification of the test datarequirements is
exceptionally significant. Hence, clear guidelines on how to prepare test data are
involved in the testing environment specification of the test strategy document.
o This module specifies the information related to the number of environments
and the setup demanded.
o The backup and restore strategies are also offered to ensure that there is no data
loss because of the coding or programming issues.

4. Testing Tools
o Testing toolsare another vital component of the test strategy document, as it
stipulates the complete information about the test
management and automation tools necessary for test execution activity.;
o For security, performance, load testing, the necessary methodologies, and
tools are defined by the details of the open-source or commercial tool and the
number of users that can be kept by it.

5. Release Control
o Another important module of the test strategy document is Release Control.
 lOMoAR cPSD| 35867393

o It is used to ensure that the correct and effective test executionand release
management strategies should be systematically developed.

6. Risk Analysis

o The next component of the test strategy document is Risk Analysis.

o In the test strategy document, all the possible risks are described linked to the
project, which can become a problem in test execution.
o Furthermore, for inclining these risks, a clear strategy is also formed in order to
make sure that they are undertaking properly.
o We also create a contingency plan if the development team faces these risks in
real-time.

7. Review and Approvals

o The last component of the Testing strategy document is Review and Approval.
o When all the related testing activities are specified in the test strategy document,
it is reviewed by the concerned people like:
o System Administration Team
o Project Management Team
o Development Team
o Business Team
o Together with the correct date, approver name, comment, andsummary of the
reviewed variations should be followed while starting the document.
o Likewise, it should be constantly reviewed and updated with the testing process
improvements.

Types of Test Strategies

Here, we are discussing some of the significant types of test strategies document:
 lOMoAR cPSD| 35867393

o Methodical strategy
o Reactive strategy
o Analytical strategy
o Standards compliant or Process compliant strategy
o Model-based strategy
o Regression averse strategy
o Consultative strategy

Let's understand them one by one in detail:

1. Methodical Strategy
o The first part of test strategy document is 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 The next type of test strategy is known as 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 defectsin the
existing system.
 lOMoAR cPSD| 35867393

o Suppose, we have used the exploratory testing, and the test approvals are
established derived from the existing aspects and performances.
o These test approvals are restructured based on the outcome of the testing which
is implemented by the test engineer.

3. Analytical strategy
o Another type of test strategy is Analytical strategy, which is used to perform
testing based on requirements, and requirements are analyzed to derive the test
conditions. And then tests are designed, implemented, and performedto
encounter those requirements. For example, risk-based
testing or requirements-based testing.
o 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 of test strategy, 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 Suppose any project follows the ScrumAgile technique. In that case, the test
engineer will generate its complete test strategy, beginning from classifying test
criteria, essential test cases, performing tests, report status, etc., around
each user story.
o Some good examplesof the standards-compliant process are Medical systems
following US FDA (Food and Drugs Administration) standards.

5. Model-based strategy
o The next type of test strategy is a model-based strategy. The testing team
selects the current or expected situationand 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.
 lOMoAR cPSD| 35867393

6. Regression averse strategy

o In the regression averse strategy, 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
regressionissues for the particular application. The testing team can develop the
test automation for both typical and exceptional use cases for this scenario.
o And to facilitate the tests can be run whenever the application is reformed, the
testing team can use GUI-based automation tools.

7. Consultative strategy
o The consultative strategy is used to consultkey investors as input to choose
the scope of test conditions as in user-directed testing.
o In order of priority, 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 strategy selection

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

o The selection of test strategy depends on the Organization type and size.
o We can select the test strategy based on the Project requirements, such
as safety and security related applications require rigorous strategy.
o We can select the test strategy based on the Product development model.

The final document of the test strategy contains important details about the following
factors:

o Scope and Overview

o Re-usability of both software and testing work products.
 lOMoAR cPSD| 35867393

o Details of different Test levels, relationships between the test levels, and
procedure to integrate different test levels.
o Testing environment
o Testing techniques
o Level of automation for testing
o Different testing tools
o Risk Analysis
o For each test level Entry as well exit conditions
o Test results reports
o Degree of independence of each test
o Metrics and measurements to be evaluated during testing
o Confirmation and regression testing
o Managing defects detected
o Managing test tools and infrastructure configuration
o Roles and responsibilities of Test team members

Conclusion

After understanding the test strategy document, at last, we can say that the test
strategy document provides a vibrant vision of what the test team will do for the whole
project.

The test strategy document could prepare only those who have good experience in
the product domain because the test strategy document will drive the entire team.

And it cannot be modified or changed in the complete project life cycle as it is a static
document.

Before any testing activities begin, the Test strategy document can distribute to the
entire testing team.

If the test strategy document is written correctly, it will develop a high-quality system
and expand the complete testing process.

Resource Requirements
 lOMoAR cPSD| 35867393

Resource requirement is a detailed summary of all types of resources required to

complete project task. Resource could be human, equipment and materials needed to
complete a project.
The resource requirement and planning is important factor of the test planning because
helps in determining the number of resources (employee, equipment…) to be used for
the project. Therefore, the Test Manager can make the correct schedule & estimation
for the project.
Some of the following factors need to be considered:
Machine configuration (RAM,processor,disk)needed to run the product under
test.
Overheads required by test automation tools, if any
Supporting tools such as compilers, test data generators, configuration
management tools.
The different configurations of the supporting software(e.g. OS)that must be
present
Special requirements for running machine-intensive tests such as load tests and
performance tests.
Appropriate number of licenses of all the software

No. Member Tasks

1 Test Manager Manage the whole project Define project directions Acquire appropriate
resources

2 Tester Identifying and describing appropriate test techniques/tools/automation

architecture Verify and assess the Test Approach Execute the tests,
Log results, Report the defects. Tester could be in-sourced or out-
sourced members, base on the project budget For the task which
required low skill, I recommend you choose outsourced members to
save project cost

3. Developer in Implement the test cases, test program, test suite etc.
Test
 lOMoAR cPSD| 35867393

No. Member Tasks

4. Test Builds up and ensures test environment and assets are managed and
Administrator maintained Support Tester to use the test environment for test
execution

5. SQA Take in charge of quality assurance Check to confirm whether the

members testing process is meeting specified requirements

OR

Human Resource: The following table represents various members in your project
team
System Resource: For testing, a web application, you should plan the resources as
following tables:

No. Resources Descriptions

1 Server Install the web application under test This includes a separate web server,
database server, and application server if applicable

2 Test tool The testing tool is to automate the testing, simulate the user operation,
generate the test results There are tons of test tools you can use for this
project such as Selenium, QTP…etc.

3. Network You need a Network include LAN and Internet to simulate the real
business and user environment
 lOMoAR cPSD| 35867393

No. Resources Descriptions

4. Computer The PC which users often use to connect the web server

Tester Assignments

They may be involved in or even be the primary people identifying test conditions and
creating test designs, test cases, test procedure specifications and test data, and may
automate or help to automate the tests.

Tester assignments typically refer to the process of assigning individuals or teams to

test specific components, features, or aspects of a product or system. Testing is an
essential part of software development, quality assurance, and product validation.
Assigning testers to different tasks helps ensure thorough and efficient testing coverage.
Here are some considerations for tester assignments:

Test plan and strategy: Begin by creating a test plan and strategy that outlines the
testing objectives, scope, and approach. This will help identify the different types of tests
required and the specific areas that need to be covered.

Test case creation: Testers can be assigned to create test cases based on the test plan
and requirements. Test cases should cover different scenarios and use cases to ensure
comprehensive testing.

Testing types: Identify the different types of testing needed, such as functional testing,
performance testing, security testing, usability testing, etc. Assign testers with the relevant
expertise and skills for each type of testing.

Test environment: Assign testers to set up and configure the test environment, including
any necessary hardware, software, or network configurations. This ensures that the testing
environment accurately reflects the production environment.

Test execution: Assign testers to execute the test cases and document the results.
Testers should follow the test plan and report any issues or bugs they encounter during the
testing process.

Bug reporting and tracking: Assign testers to report identified bugs or issues in a
structured manner, including detailed descriptions, steps to reproduce, and any supporting
documentation. Testers may also be responsible for tracking the status and resolution of
reported issues.
 lOMoAR cPSD| 35867393

Regression testing: After bug fixes or changes are made, assign testers to perform
regression testing to ensure that the fixes or changes did not introduce new issues or break
existing functionality.

Collaboration and communication: Assign testers to collaborate with developers,

product managers, and other stakeholders to ensure clear communication and
understanding of testing requirements, priorities, and progress.

Test coverage analysis: Assign testers to analyze the test coverage and identify any
gaps or areas that require additional testing. This helps ensure that all critical features and
functionalities are adequately tested.

Test automation: Assign testers with automation skills to develop and maintain
automated test scripts, which can help increase testing efficiency and coverage.

It's important to consider the skills, experience, and availability of testers when making
assignments. Regular communication and coordination among testers and other team
members are crucial to ensure effective testing and timely feedback.

Test Schedule

It is used to explain the timing to work, which needs to be done or this attribute covers when
exactly each testing activity should start and end? And the exact data is also mentioned for every
testing activity for the particular date.
 lOMoAR cPSD| 35867393

Therefore as we can see in the below image that for the particular activity, there will be a starting
date and ending date; for each testing to a specific build, there will be the specified date.

For example

o Writing test cases

o Execution process

Test Cases

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.

It is an in-details document that contains all possible inputs (positive as well as

negative) and the navigation steps, which are used for the test execution process.
Writing of test cases is a one-time attempt that can be used in the future at the time of
regression testing.

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.

Test case helps the tester in defect reporting by linking defect with test case ID.
 lOMoAR cPSD| 35867393

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
To write the test case, we must have the requirements to derive the
inputs, and the test scenarios must be written so that we do not miss out on any
features for testing. Then we should have the test case template to maintain the
uniformity, or every test engineer follows the same approach to prepare the test
document.

Generally, we will write the test case whenever the developer is busy in writing the
code.

When do we write a test case?

We will write the test case when we get the following:

o When the customer gives the business needs then, the developer starts
developing and says that they need 3.5 months to build this product.
o And In the meantime, the testing team will start writing the test cases.
o Once it is done, it will send it to the Test Lead for the review process.
o And when the developers finish developing the product, it is handed over to the
testing team.
o The test engineers never look at the requirement while testing the product
document because testing is constant and does not depends on the mood of the
person rather than the quality of the test engineer.

Why we write the test cases?

We will write the test for the following reasons:

o To require consistency in the test case execution

o To make sure a better test coverage
o It depends on the process rather than on a person
o To avoid training for every new test engineer on the product

To require consistency in the test case execution: we will see the test case and start
testing the application.

To make sure a better test coverage: for this, we should cover all possible scenarios
and document it, so that we need not remember all the scenarios again and again.
 lOMoAR cPSD| 35867393

It depends on the process rather than on a person: A test engineer has tested an
application during the first release, second release, and left the company at the time of
third release. As the test engineer understood a module and tested the application
thoroughly by deriving many values. If the person is not there for the third release, it
becomes difficult for the new person. Hence all the derived values are documented so
that it can be used in the future.

To avoid giving training for every new test engineer on the product: When the test
engineer leaves, he/she leaves with a lot of knowledge and scenarios. Those scenarios
should be documented so that the new test engineer can test with the given scenarios
and also can write the new scenarios.

Test case template

The primary purpose of writing a test case is to achieve the efficiency of the application.
 lOMoAR cPSD| 35867393

As we know, the actual result is written after the test case execution, and most of the
time, it would be same as the expected result. But if the test step will fail, it will be
different. So, the actual result field can be skipped, and in the Comments section, we
can write about the bugs.

And also, the Input field can be removed, and this information can be added to
the Description field.

The above template we discuss above is not the standard one because it can be
different for each company and also with each application, which is based on the test
engineer and the test lead. But, for testing one application, all the test engineers should
follow a usual template, which is formulated.

The test case should be written in simple language so that a new test engineer can also
understand and execute the same.

In the above sample template, the header contains the following:

Step number

It is also essential because if step number 20 is failing, we can document the bug report
and hence prioritize working and also decide if it’s a critical bug.

Test case type

It can be functional, integration or system test cases or positive or negative or positive

and negative test cases.

Release

One release can contain many versions of the release.

Pre-condition

These are the necessary conditions that need to be satisfied by every test engineer
before starting the test execution process. Or it is the data configuration or the data
setup that needs to be created for the testing.

For example: In an application, we are writing test cases to add users, edit users, and
delete users. The per-condition will be seen if user A is added before editing it and
removing it.

Test data

These are the values or the input we need to create as per the per-condition.
 lOMoAR cPSD| 35867393

For example, Username, Password, and account number of the users.

The test lead may be given the test data like username or password to test the
application, or the test engineer may themself generate the username and password.

Severity

The severity can be major, minor, and critical, the severity in the test case talks about
the importance of that particular test cases. All the text execution process always
depends on the severity of the test cases.

We can choose the severity based on the module. There are many features include in a
module, even if one element is critical, we claim that test case to be critical. It depends
on the functions for which we are writing the test case.

For example, we will take the Gmail application and let us see the severity based on
the modules:

Modules Severity

Login Critical

Help Minor

Compose mail Critical

Setting Minor

Inbox Critical

Sent items Major

Logout Critical

And for the banking application, the severity could be as follows:

 lOMoAR cPSD| 35867393

Modules Severity

Amount transfer critical

Feedback minor

Brief description

The test engineer has written a test case for a particular feature. If he/she comes and
reads the test cases for the moment, he/she will not know for what feature has written it.
So, the brief description will help them in which feature test case is written.

Example of a test case template

Here, we are writing a test case for the ICICI application’s Login module:
 lOMoAR cPSD| 35867393

Types of test cases

We have a different kind of test cases, which are as follows:

o Function test cases

o Integration test cases
o System test cases

The functional test cases

Firstly, we check for which field we will write test cases and then describe accordingly.

In functional testing or if the application is data-driven, we require the input column else;
it is a bit time-consuming.
 lOMoAR cPSD| 35867393

Rules to write functional test cases:

o In the expected results column, try to use should be or must be.

o Highlight the Object names.
o We have to describe only those steps which we required the most; otherwise, we
do not need to define all the steps.
o To reduce the excess execution time, we will write steps correctly.
o Write a generic test case; do not try to hard code it.

Let say it is the amount transfer module, so we are writing the functional test cases for it
and then also specifies that it is not a login feature.

The functional test case for amount transfer module is in the below Excel file:
 lOMoAR cPSD| 35867393

Integration test case

In this, we should not write something which we already covered in the functional test
cases, and something we have written in the integration test case should not be written
in the system test case again.

Rules to write integration test cases

o Firstly, understand the product

o Identify the possible scenarios
o Write the test case based on the priority
 lOMoAR cPSD| 35867393

When the test engineer writing the test cases, they may need to consider the following
aspects:

If the test cases are in details:

o They will try to achieve maximum test coverage.

o All test case values or scenarios are correctly described.

o They will try to think about the execution point of view.
o The template which is used to write the test case must be unique.

System test cases

We will write the system test cases for the end-to-end business flows. And we have the
entire modules ready to write the system test cases.

The process to write test cases

The method of writing a test case can be completed into the following steps, which are
as below:
 lOMoAR cPSD| 35867393

System study

In this, we will understand the application by looking at the requirements or the SRS,
which is given by the customer.

Identify all scenarios:

o When the product is launched, what are the possible ways the end-user may use
the software to identify all the possible ways.
o I have documented all possible scenarios in a document, which is called test
design/high-level design.
o The test design is a record having all the possible scenarios.

Write test cases

Convert all the identified scenarios to test claims and group the
scenarios related to their features, prioritize the module, and write test cases by
applying test case design techniques and use the standard test case template, which
means that the one which is decided for the project.

Review the test cases

Review the test case by giving it to the head of the team and, after that, fix the review
feedback given by the reviewer.

Test case approval

After fixing the test case based on the feedback, send it again for the approval.

Store in the test case repository

After the approval of the particular test case, store in the familiar place that is known as
the test case repository.
 lOMoAR cPSD| 35867393

Metrics and Statistics.

Software Testing metrics are quantitative steps taken to evaluate the software testing
process's quality, performance, and progress. This helps us to accumulate reliable data
about the software testing process and enhance its efficiency. This will allow
developers to make proactive and precise decisions for upcoming testing procedures.
What is a metric in software testing metrics?
A Metric is a degree to which a system or its components retains a given attribute.
Testers don't define a metric just for the sake of documentation. It serves greater
purposes in software testing. For example, developers can apply a metric to assume
the time it takes to develop software. It can also be assigned to determine the numbers
of new features and modifications, etc., added to the software.
Importance of Software Testing Metrics
As mentioned, test metrics are crucial to measuring the quality and performance of the
software. With proper software testing metrics, developers can−

Determine what types of improvements are required to deliver a defect-free,

quality software
Make sound decisions about the subsequent testing phases, such as
schedulingupcoming projects as well as estimating the overall cost of those
projects
Evaluate the current technology or process and check whether it needs further
modifications
Types of software testing metrics
There are three types of software testing metrics−

Process Metrics: Process metrics define the characteristics and execution of a

project. These characteristics are essential to the improvement and
maintenanceof the process in the SDLC (Software Development Life Cycle).
Product Metrics: Product metrics define the size, design, performance,
quality,and complexity of a product. By using these characteristics, developers
can enhance their software development quality.
Project Metrics: Project Metrics determine the overall quality of a project. It is
used to calculate costs, productivity, defects and estimate the resource and
deliverables of a project.
It is incredibly vital to identify the correct testing metrics for the process. Few factors to
consider−

Choose your target audiences wisely before preparing the metrics

Downloaded by Dr.Palaniappan S ([email protected])

 lOMoAR cPSD| 35867393

Define the goal behind designing the metrics

Prepare metrics by considering the specific requirements of the project
Evaluate the financial gain behind each metrics
Pair the metrics with the project lifestyle phase that delivers optimum
outputSoftware testing can be further divided into manual and automated testing.
In manual testing, the test is performed by QA analysts in a step-by-step process.
Meanwhile, in automated testing, tests are executed with the help of test automation
frameworks, tools, and software.
Both manual and automated testing has its strength and weakness.
Manual testing is a slow process, but it allows testers to handles complex scenarios.
The most significant advantage of automated testing is that it enables testers to run
more testing in less time, covering a substantial level of permutations, which is nearly
impossible to calculate manually.
Types of Manual Test Metrics
Manual Test Metrics are of two types−
Base Metrics
Base metrics are data collected by analysts during test case development and
execution. These metrics are submitted to test leads and project managers by
preparing a project status report. It is quantified by using calculated metrics −
Number of test cases
Number of test cases executed
Calculated Metrics
Calculated metrics are derived using data from base metrics. The test lead gathers
these data and converts them to more meaningful information for tracking the progress
of projects at the module level, tester level, etc.

It comprises a significant part of SDLC and empowers developers to make vital

improvements in software.
Most used Metrics
Below are the types of metrics, popularly used by developers and testers
Defect metrics: This metric allows developers to understand the various
qualityaspects of software, including functionality, performance, installation
stability, usability, compatibility, etc.
Defects finding rate: It is used to identify the pattern of defects during a specific
timeframe
Defect severity: It enables the developer to understand how the defect is
goingto impact the quality of the software.
 lOMoAR cPSD| 35867393

Defect cause: It is used to understand the root cause of the defect.

Test Coverage: It defines how many test cases are assigned to the program.
This metric ensures the testing is conducted to its full completion. It further aids
inchecking the code flow and test functionalities.
Defect fixing time: It determines the amount of time it takes to resolve a defect
Test case efficiency: It tells the efficiency rate of test cases in finding defects
Schedule adherence: Its primary motive is to figure out the time
differencebetween the planned schedule and the actual time of executing a
schedule.
Test Metrics Life Cycle
The life cycle of test metrics consists of four stages−

Analysis: In this stage, developers identify the required metrics and define them.
Communicate: Once metrics are identified, developers have to explain
theirimportance to stakeholders and the testing team.
Evaluation: This stage includes quantifying and verifying the data. Then testers
have to use the data to calculate the value of the metric.
Report: Once the evaluation process is finished, the development team needs
tocreate a report including a detailed summary of the conclusion. Then the report
isdistributed among stakeholders and relevant representatives. The stakeholders
then give their feedback after reading the information carefully.

Metrics and statistics play a vital role in measuring and evaluating various aspects of performance, progress,
and outcomes in different domains. They provide objective and quantifiable data that can be used to assess
the effectiveness, efficiency, and quality of processes, systems, or initiatives. Here are some common
metrics and statistics used in different contexts:

Key Performance Indicators (KPIs): KPIs are specific metrics that organizations use to measure progress
toward their goals and objectives. KPIs vary depending on the industry and the specific objectives being
measured. Examples include sales revenue, customer satisfaction scores, website traffic, employee
turnover rate, and production efficiency.

Quality Metrics: These metrics assess the quality of products or services. They can include defect rates,
customer complaints, return rates, and customer satisfaction ratings. Quality metrics help organizations
identify areas for improvement and track their progress in delivering high-quality offerings.

Financial Metrics: Financial metrics measure the financial health and performance of a business or
 lOMoAR cPSD| 35867393

organization. Examples include revenue growth, profit margins, return on investment (ROI), cash flow, and
debt-to-equity ratio. Financial metrics help evaluate profitability, liquidity, and overall financial sustainability.

Customer Metrics: These metrics focus on understanding and evaluating the customer experience and
satisfaction. Examples include Net Promoter Score (NPS), customer retention rate, customer lifetime value,
and customer complaints. Customer metrics provide insights into customer loyalty, preferences, and
perceptions.

Productivity Metrics: Productivity metrics assess the efficiency and output of individuals, teams, or
processes. Examples include units produced per hour, average handling time for customer inquiries,
response time to support tickets, and employee utilization rates. Productivity metrics help identify
bottlenecks, optimize resource allocation, and improve overall efficiency.

User Engagement Metrics: These metrics are used in digital and online contexts to assess user engagement
and interaction. Examples include website traffic, page views, bounce rate, click-through rate, time spent on
a page, and social media engagement (likes, shares, comments). User engagement metrics help evaluate
the effectiveness of digital marketing efforts, user experience, and content performance.

Risk and Compliance Metrics: Risk and compliance metrics assess an organization's adherence to
regulatory requirements, internal policies, and risk management practices. Examples include compliance
violation incidents, risk exposure levels, audit findings, and cybersecurity incidents. These metrics help
organizations monitor their risk posture and ensure compliance with legal and regulatory obligations.

Process Efficiency Metrics: These metrics evaluate the efficiency and effectiveness of specific processes
within an organization. Examples include cycle time, throughput, defect rate, and rework rate. Process
efficiency metrics help identify areas of improvement, streamline operations, and reduce waste.

Market and Industry Statistics: These statistics provide insights into market trends, customer demographics,
industry benchmarks, and competitive landscape. Examples include market size, market share, growth
rates, customer segmentation data, and industry-specific performance indicators. Market and industry
statistics assist in strategic decision-making, market analysis, and competitive positioning.

It's important to note that the selection of metrics and statistics should align with the specific objectives,
context, and requirements of the organization or domain being measured. They should be relevant,
measurable, and provide actionable insights to drive improvement and informed decision-making.