lOMoARcPSD|44229688

CCS366 Software Testing and Automation-Unit1&II

Software testing and automation (Anna University)

Scan to open on Studocu

Studocu is not sponsored or endorsed by any college or university

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)
 lOMoARcPSD|44229688

UNIT I: FOUNDATIONS OF SOFTWARE TESTING

Why do we test Software?, Black-Box Testing and White-Box Testing, Software Testing Life Cycle,
V-model of Software Testing, Program Correctness and Verification, Reliability versus Safety, Failures,
Errors and Faults (Defects), Software Testing Principles, Program Inspections, Stages of Testing:
Unit Testing, Integration Testing, System Testing

Why do we test Software?

Software testing is a process of identifying the correctness of software by considering its all attributes
(Reliability, Scalability, Portability, Re-usability, Usability) and evaluating the execution of software
components to find the software bugs or errors or defects

Software testing provides an independent view and objective of the software and gives surety of fitness of
the software. It involves testing of all components under the required services to confirm that whether it
is satisfying the specified requirements or not. The process is also providing the client with information
about the quality of the software.
Testing is mandatory because it will be a dangerous situation if the software fails any of time due to lack
of testing. So, without testing software cannot be deployed to the end user.

What is Testing

Testing is a group of techniques to determine the correctness of the application under the
predefined script but, testing cannot find all the defect of application. The main intent of testing is
to detect failures of the application so that failures can be discovered and corrected. It does not
demonstrate that a product functions properly under all conditions but only that it is not working
in some specific conditions.

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

Testing furnishes comparison that compares the behavior and state of software against mechanisms
because the problem can be recognized by the mechanism. The mechanism may include past
versions of the same specified product, comparable products, and interfaces of expected purpose,
relevant standards, or other criteria but not limited up to these.

Testing includes an examination of code and also the execution of code in various environments,
conditions as well as all the examining aspects of the code. In the current scenario of software
development, a testing team may be separate from the development team so that Information
derived from testing can be used to correct the process of software development.

The success of software depends upon acceptance of its targeted audience, easy graphical user
interface, strong functionality load test, etc. For example, the audience of banking is totally
different from the audience of a video game. Therefore, when an organization develops a software
product, it can assess whether the software product will be beneficial to its purchasers and other
audience.

Black-box testing

Black box testing is a technique of software testing which examines the functionality of
software without peering into its internal structure or coding. The primary source of black box
testing is a specification of requirements that is stated by the customer.

In this method, tester selects a function and gives input value to examine its functionality, and
checks whether the function is giving expected output or not. If the function produces correct
output, then it is passed in testing, otherwise failed. The test team reports the result to the
development team and then tests the next function. After completing testing of all functions if there
are severe problems, then it is given back to the development team for correction.

Generic steps of black box testing

o The black box test is based on the specification of requirements, so it is examined in the
beginning.
o In the second step, the tester creates a positive test scenario and an adverse test scenario by
selecting valid and invalid input values to check that the software is processing them
correctly or incorrectly.

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

o In the third step, the tester develops various test cases such as decision table, all pairs test,
equivalent division, error estimation, cause-effect graph, etc.
o The fourth phase includes the execution of all test cases.
o In the fifth step, the tester compares the expected output against the actual output.
o In the sixth and final step, if there is any flaw in the software, then it is cured and tested
again.

Test procedure

The test procedure of black box testing is a kind of process in which the tester has specific
knowledge about the software's work, and it develops test cases to check the accuracy of the
software's functionality.

It does not require programming knowledge of the software. All test cases are designed by
considering the input and output of a particular function. A tester knows about the definite output
of a particular input, but not about how the result is arising. There are various techniques used in
black box testing for testing like decision table technique, boundary value analysis technique, state
transition, All-pair testing, cause-effect graph technique, equivalence partitioning technique, error
guessing technique, use case technique and user story technique. All these techniques have been
explained in detail within the tutorial.

Test cases

Test cases are created considering the specification of the requirements. These test cases are
generally created from working descriptions of the software including requirements, design parameters, and
other specifications. For the testing, the test designer selects both positive test scenario by taking valid input
values and adverse test scenario by taking invalid input values to determine the correct output.

Test cases are mainly designed for functional testing but can also be used for non-functional testing.
Test cases are designed by the testing team, there is not any involvement of the development team of software.

Techniques Used in Black Box Testing

Decision Table Decision Table Technique is a systematic approach where various input
Technique combinations and their respective system behavior are captured in a tabular form.
It is appropriate for the functions that have a logical relationship between two and
more than two inputs.

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

Boundary Value Boundary Value Technique is used to test boundary values, boundary values are
Technique those that contain the upper and lower limit of a variable. It tests, while entering
boundary value whether the software is producing correct output or not.

State Transition State Transition Technique is used to capture the behavior of the software
Technique application when different input values are given to the same function. This
applies to those types of applications that provide the specific number of attempts
to access the application.

All-pair Testing All-pair testing Technique is used to test all the possible discrete combinations of
Technique values. This combinational method is used for testing the application that uses
checkbox input, radio button input, list box, text box, etc.

Cause-Effect Cause-Effect Technique underlines the relationship between a given result and all
Technique the factors affecting the result.It is based on a collection of requirements.

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

Partitioning divided into partitions of valid and invalid values, and it is mandatory that all
Technique partitions must exhibit the same behavior.

Error Guessing Error guessing is a technique in which there is no specific method for identifying
Technique the error. It is based on the experience of the test analyst, where the tester uses the
experience to guess the problematic areas of the software.

Use Case Use case Technique used to identify the test cases from the beginning to the end
Technique of the system as per the usage of the system. By using this technique, the test team
creates a test scenario that can exercise the entire software based on the
functionality of each function from start to end

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

White-Box Testing

The box testing approach of software testing consists of black box testing and white box
testing. We are discussing here white box testing which also known as glass box is testing,
structural testing, clear box testing, open box testing and transparent box testing. It tests
internal coding and infrastructure of a software focus on checking of predefined inputs against
expected and desired outputs. It is based on inner workings of an application and revolves around
internal structure testing. In this type of testing programming skills are required to design test
cases. The primary goal of white box testing is to focus on the flow of inputs and outputs through
the software and strengthening the security of the software.

The term 'white box' is used because of the internal perspective of the system. The clear box or
white box or transparent box name denote the ability to see through the software's outer shell into
its inner workings.

Developers do white box testing. In this, the developer will test every line of the code of the
program. The developers perform the White-box testing and then send the application or the
software to the testing team, where they will perform the black box testing and verify the
application along with the requirements and identify the bugs and sends it to the developer.

The developer fixes the bugs and does one round of white box testing and sends it to the testing
team. Here, fixing the bugs implies that the bug is deleted, and the particular feature is working
fine on the application.

Here, the test engineers will not include in fixing the defects for the following reasons:

o Fixing the bug might interrupt the other features. Therefore, the test engineer
should always find the bugs, and developers should still be doing the bug fixes.
o If the test engineers spend most of the time fixing the defects, then they may beunable
to find the other bugs in the application.

The white box testing contains various tests, which are as follows:

o Path testing
o Loop testing
o Condition testing
o Testing based on the memory perspective
o Test performance of the program

Path testing

In the path testing, we will write the flow graphs and test all independent paths. Here writing the

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

flow graph implies that flow graphs are representing the flow of the program and also show how
every program is added with one another as we can see in the below image:

And test all the independent paths implies that suppose a path from main() to function G, first set
the parameters and test if the program is correct in that particular path, and in the same way test
all other paths and fix the bugs.

Loop testing

In the loop testing, we will test the loops such as while, for, and do-while, etc. and also check for
ending condition if working correctly and if the size of the conditions is enough.

For example: we have one program where the developers have given about 50,000 loops.

1. {
2. while(50,000)
3. ……
4. ……
5. }

We cannot test this program manually for all the 50,000 loops cycle. So we write a small program
that helps for all 50,000 cycles, as we can see in the below program, that test P is written in the
similar language as the source code program, and this is known as a Unit test. And it is written by
the developers only.

1. Test P
2. {
3. ……
4. …… }

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

As we can see in the below image that, we have various requirements such as 1, 2, 3,
4. And then, the developer writes the programs such as program 1,2,3,4 for the parallel conditions. Here
the application contains the 100s line of codes.

The developer will do the white box testing, and they will test all the five programs line by line of
code to find the bug. If they found any bug in any of the programs, they will correct it. And they
again have to test the system then this process contains lots of time and effort and slows down the
product release time.
Now, suppose we have another case, where the clients want to modify the requirements, then the
developer will do the required changes and test all four program again, which take lots of time and
efforts.

These issues can be resolved in the following ways:

In this, we will write test for a similar program where the developer writes these test code in the
related language as the source code. Then they execute these test code, which is also known as
unit test programs. These test programs linked to the main program and implemented as
Programs

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

Therefore, if there is any requirement of modification or bug in the code, then the developer makes
the adjustment both in the main program and the test program and then executes the test program.

Condition testing

In this, we will test all logical conditions for both true and false values; that is, we will verify for
both if and else condition.

For example:

1. if(condition) - true
2. {
3. …..
4. ……
5. ……
6. }
7. else - false
8. {
9. …..

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

10. ……
11. ……
12. }

The above program will work fine for both the conditions, which means that if the
condition is accurate, and then else should be false and conversely.

Testing based on the memory (size) perspective

The size of the code is increasing for the following reasons:

o The reuse of code is not there: let us take one example, where we have four programs of
the same application, and the first ten lines of the program are similar. We can write these
ten lines as a discrete function, and it should be accessible by the above four programs as
well. And also, if any bug is there, we can modify the line of code in the function rather
than the entire code.
o The developers use the logic that might be modified. If one programmer writes code and
the file size is up to 250kb, then another programmer could write a similar code using the
different logic, and the file size is up to 100kb.
o The developer declares so many functions and variables that might never be used in any
portion of the code. Therefore, the size of the program will increase.

For example,

1. Int a=15;
2. Int b=20;
3. String S= "Welcome";
4. ….
5. …..
6. …..
7. ….
8. …..
9. Int p=b;
10. Create user()
11. {
12. ……

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

13. ……
14. 200's line of code
15. }

In the above code, we can see that the integer a has never been called anywhere in the program,
and also the function Create user has never been called anywhere in the code. Therefore, it leads
us to memory consumption.

We cannot remember this type of mistake manually by verifying the code because of the large
code. So, we have a built-in tool, which helps us to test the needless variables and functions. And,
here we have the tool called Rational purify.

Suppose we have three programs such as Program P, Q, and R, which provides the input to S. And
S goes into the programs and verifies the unused variables and then gives the outcome. After that,
the developers will click on several results and call or remove the unnecessary function and the
variables.
This tool is only used for the C programming language and C++ programming language; for
another language, we have other related tools available in the market.

o The developer does not use the available in-built functions; instead they write the full
features using their logic. Therefore, it leads us to waste of time and also postpone the
product release.
10

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

Test the performance (Speed, response time) of the program

The application could be slow for the following reasons:

o When logic is used.

o For the conditional cases, we will use or & and adequately.
o Switch case, which means we cannot use nested if, instead of using a switch case.

As we know that the developer is performing white box testing, they understand that the code is
running slow, or the performance of the program is also getting deliberate. And the developer
cannot go manually over the program and verify which line of the code is slowing the program.

To recover with this condition, we have a tool called Rational Quantify, which resolves these
kinds of issues automatically. Once the entire code is ready, the rational quantify tool will go
through the code and execute it. And we can see the outcome in the result sheet in the form of thick
and thin lines.

Here, the thick line specifies which section of code is time-consuming. When we double- click on
the thick line, the tool will take us to that line or piece of code automatically, which is also
displayed in a different color. We can change that code and again and use this tool. When the order
of lines is all thin, we know that the presentation of the program has enhanced. And the developers
will perform the white box testing automatically because it saves time rather than performing
manually.

11

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

Test cases for white box testing are derived from the design phase of the software development
lifecycle. Data flow testing, control flow testing, path testing, branch testing, statement and
decision coverage all these techniques used by white box testing as a guideline to create an error-
free software.

White box testing follows some working steps to make testing manageable and easy to understand
what the next task to do. There are some basic steps to perform white box testing.

Generic steps of white box testing

o Design all test scenarios, test cases and prioritize them according to high priority number.
o This step involves the study of code at runtime to examine the resource utilization, not
accessed areas of the code, time taken by various methods and operations and so on.
o In this step testing of internal subroutines takes place. Internal subroutines such as
nonpublic methods, interfaces are able to handle all types of data appropriately or not.
o This step focuses on testing of control statements like loops and conditional statements to
check the efficiency and accuracy for different data inputs.
o In the last step white box testing includes security testing to check all possible security
loopholes by looking at how the code handles security.

Reasons for white box testing

o It identifies internal security holes.

o To check the way of input inside the code.

12

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

o Check the functionality of conditional loops.

o To test function, object, and statement at an individual level.

Advantages of White box testing

o White box testing optimizes code so hidden errors can be identified.

o Test cases of white box testing can be easily automated.
o This testing is more thorough than other testing approaches as it covers all code paths.
o It can be started in the SDLC phase even without GUI.

Disadvantages of White box testing

o White box testing is too much time consuming when it comes to large-scale
programming applications.
o White box testing is much expensive and complex.
o It can lead to production error because it is not detailed by the developers.
o White box testing needs professional programmers who have a detailed
knowledge and understanding of programming language and implementation.

Techniques Used in White Box Testing

Data Flow Data flow testing is a group of testing strategies that examines the control flow of
Testing programs in order to explore the sequence of variables according to the sequence of
events.

Control Flow Control flow testing determines the execution order of statements or instructions of the
Testing program through a control structure. The control structure of a program is used to
develop a test case for the program. In this technique, a particular part of a large
program is selected by the tester to set the testing path. Test cases represented by the
control graph of the program.

Branch Branch coverage technique is used to cover all branches of the control flow graph. It
Testing covers all the possible outcomes (true and false) of each condition of decision point at
least once.

13

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

Statement Statement coverage technique is used to design white box test cases. This technique
Testing involves execution of all statements of the source code at least once. It is used to
calculate the total number of executed statements in the source code, out of total
statements present in the source code.

Decision This technique reports true and false outcomes of Boolean expressions. Whenever there
Testing is a possibility of two or more outcomes from the statements like do while statement,
if statement and case statement (Control flow statements), it is considered as decision
point because there are two outcomes either true or false.

Difference between white-box testing and black-box testing

Following are the significant differences between white box testing and black box testing:

White-box testing Black box testing

The developers can perform white box testing. The test engineers perform the black box testing.

To perform WBT, we should have an To perform BBT, there is no need to have an

understanding of the programming languages. understanding of the programming languages.

In this, we will look into the source code and In this, we will verify the functionality of the
test the logic of the code. application based on the requirement specification.

In this, the developer should know about the In this, there is no need to know about the internal
internal design of the code. design of the code.

14

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

Software Testing Life Cycle

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 Prepare the list of all requirements and List of all the necessary tests
requirement specification, queries, and get resolved from Technical for the testable requirements
application architecture document Manager/Lead, System and Test

15

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

and well-defined acceptance Architecture, Business Analyst and environment details

criteria should be available. 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 Test strategy document.

Document of the software. List down Testing Effort estimation documents are the
methods involved in testing. 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.

16

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

Entry Criteria Activities Deliverable

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

Test case Execution:

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. Execution of Test execution result.

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

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.

17

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

Entry Criteria Activities Deliverable

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

Entry Criteria Activities Deliverable

Test case It evaluates the completion criteria of the software based on test coverage, Closure
execution report. quality, time consumption, cost, and critical business objectives. report
Defect report Defect logging analysis finds out defect distribution by categorizing in Test metrics
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.

V- modelof Software Testing

There are the various phases of Verification Phase of V-model:

1. Business requirement analysis: This is the first step where product

requirements understood from the customer's side. This phase contains detailed

18

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

Developers’ life cycle Tester’s life cycle

Verification phase
Verification

communication to understand customer's expectations and exact requirements.

2. System Design: In this stage system engineers analyze and interpret the business of
the proposed system by studying the user requirements document.

19

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

3. Architecture Design: The baseline in selecting the architecture is that it should understand
all which typically consists of the list of modules, brief functionality of each module, their
interface relationships, dependencies, database tables, architecture diagrams, technology
detail, etc. The integration testing model is carried out in a particular phase.
4. Module Design: In the module design phase, the system breaks down into small modules.
The detailed design of the modules is specified, which is known as Low-Level Design
5. Coding Phase: After designing, the coding phase is started. Based on the requirements, a
suitable programming language is decided. There are some guidelines and standards for
coding. Before checking in the repository, the final build is optimized for better
performance, and the code goes through many code reviews to check the performance.

There are the various phases of Validation Phase of V-model:

1. Unit Testing: In the V-Model, Unit Test Plans (UTPs) are developed during the module
design phase. These UTPs are executed to eliminate errors at code level or unit level. A
unit is the smallest entity which can independently exist, e.g., a program module. Unit
testing verifies that the smallest entity can function correctly when isolated from the rest
of the codes/ units.
2. Integration Testing: Integration Test Plans are developed during the Architectural Design
Phase. These tests verify that groups created and tested independently can coexist and
communicate among themselves.
3. System Testing: System Tests Plans are developed during System Design Phase. Unlike
Unit and Integration Test Plans, System Tests Plans are composed by the client’s business
team. System Test ensures that expectations from an application developer are met.
4. Acceptance Testing: Acceptance testing is related to the business requirement analysis
part. It includes testing the software product in user atmosphere. Acceptance tests reveal
the compatibility problems with the different systems, which is available within the user
atmosphere. It conjointly discovers the non- functional problems like load and performance
defects within the real user atmosphere.

20

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

When to use V-Model?

o When the requirement is well defined and not ambiguous.

o The V-shaped model should be used for small to medium-sized projects where
requirements are clearly defined and fixed.
o The V-shaped model should be chosen when sample technical resources are available
with essential technical expertise.

Advantage (Pros) of V-Model:

1. Easy to Understand.
2. Testing Methods like planning, test designing happens well before coding.
3. This saves a lot of time. Hence a higher chance of success over the waterfall model.
4. Avoids the downward flow of the defects.
5. Works well for small plans where requirements are easily understood.

Disadvantage (Cons) of V-Model:

1. Very rigid and least flexible.

2. Not a good for a complex project.
3. Software is developed during the implementation stage, so no early prototypes of the
software are produced.
4. If any changes happen in the midway, then the test documents along with the
required documents, has to be updated.

Program Correctness and Verification

Definition. Software correctness testing is. [t]he process of executing a program with the
intent of finding errors and is aimed primarily at improving quality assurance, verifying and validating
described functionality, or estimating reliability.

Important rules:
Below are some of the important rules for effective programming which are consequences of the
program correctness theory.

21

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

• Defining the problem completely.

• Develop the algorithm and then the program logic.
• Reuse the proved models as much as possible.
• Prove the correctness of algorithms during the design phase.
• Developers should pay attention to the clarity and simplicity of your program.
• Verifying each part of a program as soon as it is developed.

Verification evaluates software artifacts (such as requirements, design, code, etc.) to ensure they
meet the specified requirements and standards. It ensures the software is built according to the
needs and design specifications. Validation evaluates software to meet the user's needs and
requirements

Program correctness and verification are important aspects of software development and aim to
ensure that a program behaves as intended and produces correct results. Verification involves the
process of evaluating a program or system to determine if it meets specified requirements, while
correctness refers to the program's adherence to its intended behavior.

There are several approaches to program correctness and verification, including:

Testing: Testing involves executing a program with various inputs and checking if the outputs
match the expected results. Test cases are designed to cover different scenarios and edge cases to
uncover potential bugs or errors. While testing can help identify defects, it does not guarantee the
absence of errors in the program.

Static Analysis: Static analysis involves examining the program's source code or intermediate
representation without executing it. Various techniques are used to analyze the code for potential
issues, such as syntax errors, type violations, or common programming mistakes. Static analysis
tools can help identify potential problems early in the development process.

Formal Methods: Formal methods involve the use of mathematical techniques to formally specify,
model, and reason about the behavior of a program. This includes

22

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

techniques such as formal verification, where mathematical proofs are used to demonstrate the
correctness of a program with respect to its specification. Formal methods are typically used for
critical systems where high assurance and reliability are required.

Model Checking: Model checking is a technique that involves exhaustively exploring the state
space of a system to verify if certain properties hold. It is particularly useful for systems with finite
state spaces. Model checking tools can automatically explore all possible system states and verify
properties specified in temporal logic, such as safety and liveness properties.

Design by Contract: Design by Contract is an approach where a program's behavior is specified

using preconditions, postconditions, and invariants. Preconditions define the conditions that must
hold before a function is executed, postconditions specify the expected behavior and output after
execution, and invariants are properties that hold throughout the execution of a program. Design
by Contract allows for runtime checks to verify if the program adheres to its contract.

Code Reviews and Inspections: Code reviews involve manual examination of the source code by
developers or peers to identify potential defects, such as coding errors, logic flaws, or violations
of coding standards. Code inspections can be performed using checklists or guidelines to ensure
consistent quality and adherence to best practices.

Program correctness and verification techniques can be used individually or in combination to

increase the confidence in the reliability and correctness of software systems. The choice of
approach depends on the nature of the system, its criticality, and the resources available for
verification.

Reliability versus Safety

Reliability is the probability that a system or component will perform its intended function
for a prescribed time and under stipulated environmental conditions. Reliability may thus be determined
by the probability of failure per demand, whilst safety is also determined by the consequences of these
failures.Reliability and safety are both important aspects of software and system development, but they
focus on different aspects of the system.

Reliability refers to the ability of a system to perform its intended function consistently and predictably over time.
It involves ensuring that the system operates without failures, errors, or unexpected behavior. Reliability is often
measured in terms of metrics such as availability, mean time between failures (MTBF), mean time to repair
23

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

(MTTR), and overall system uptime.

Safety, on the other hand, concerns the protection of users, operators, and the environment from harm or damage
caused by the system's operation. Safety is especially crucial in critical systems, such as those used in aviation, healthcare,
nuclear power plants, and transportation. It involves identifying potential hazards, assessing risks, and implementing
measures to prevent accidents or mitigate their consequences.

While reliability and safety are related, they have different priorities and requirements:

Reliability may focus on ensuring that a system operates correctly under normal conditions, delivering the expected
results consistently. It involves techniques like testing, monitoring, fault tolerance, and error handling to minimize
failures and maximize system availability.

Safety, on the other hand, emphasizes the identification and prevention of hazards, as well as the mitigation of
risks associated with the system's operation. Safety-critical systems often employ techniques such as fault
tolerance, redundancy, safety analysis, and compliance with safety standards and regulations.

In some cases, achieving high reliability can contribute to safety. For example, redundant systems or error-
detection mechanisms can improve both reliability and safety by providing backup options or alerting users to
potential hazards. However, a reliable system may still have safety concerns if it does not adequately address
potential hazards or risks.

It's important to note that safety-critical systems require a more rigorous approach to verification, validation,
and certification compared to non-critical systems. They often involve specialized techniques, such as formal
methods, extensive testing, simulation, risk analysis, and compliance with safety standards and regulations.

In summary, reliability focuses on consistent and predictable system operation, while safety concentrates on
preventing harm and minimizing risks. Both aspects are crucial for building trustworthy and robust systems,
but safety-critical systems require additional measures and considerations to ensure the well-being of users and
the environment.

Failures, Errors and Faults (Defects)

Many defects lead to the software's failure, which means that a loss specifies a
fatal issue in software/ application or in its module, which makes the system unresponsive or
broken.In other words, we can say that if an end-user detects an issue in the product, then that
particular issue is called a failure.

24

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

Possibilities are there one defect that might lead to one failure or several failures.For example, in
a bank application if the Amount Transfer module is not working for end- users when the end-user
tries to transfer money, submit button is not working. Hence, this is a failure.

The Problem in code leads to errors, which means that a mistake can occur due to the developer's
coding error as the developer misunderstood the requirement or the requirement was not defined
correctly. The developers use the term error.

Failures, Errors and Faults (Defects)

The fault may occur in software because it has not added the code for fault tolerance, making an application act

Up.fault may happen in a program because of the following reasons

o A ack of resources
o An invalid step
o Inappropriate data definition

25

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

Bug Vs. Defect Vs. Error Vs. Fault Vs. Failure

Comparis Bug Defect Error Fault Failure

on basis

Definition It is an The Defect is An Error is a The Fault is a state If the software

informal name the difference mistake made in the that causes the has lots of
specified to the between the code; that's why we software to fail to defects, it leads to
defect. actual outcomes cannot execute or accomplish its failure or causes
and expected compile code. essential function. failure.
outputs.

Raised The Test The Testers ide The Developers Human mistakes The failure
by Engineers sub ntify the defect. andautomation test cause fault. finds by the
mit the bug. And it was also engineers raise the manual test
solved by the error. engineer
developer in the through
development The
phase or stage. developmen t
cycle.

26

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

Diffe Different type Different type of Different type of Different type of -----
rent of bugs are as Defects are as Error is as below: Fault are as follows:
types follows: follows: o Syntactic o Business
o Logic
Based
on priority: Error Logic Faults
bugs o User o Functional
o High
o Algorit interface and Logical
hmic o Medium
error Faults
bugs o Low
o Flow control o Faulty GUI
o Resour error
And based on the o Performanc
ce bugs severity: o Error e Faults
o Critical handling o Security
error Faults
o Major
o Calculation Software/
o Minor o
error hardware
o Trivial
o Hardware fault
error
o Testing error

Rea Following are The below The reasons for The reasons behind the Following
sons reasons which reason leads to having fault are as are
behi may cause the defects: an error are as follows: some of
nd the bugs: Giving incorrect follows: A Fault may occur by the
Missing coding and wrong Errors in the an improper step in the most
Wrong coding inputs. code. initial stage, process, or impor
Dilemmas and The Mistake of data tant reasons

behin
d the failure:
Environmenta
l condition

27

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

Extra coding errors in the some values. definition. System

us
age
outside If a developer is Inconsistency or Users
behavior and unable to issue in the program. Human error
inside structure compile or run An irregularity or
and design. a program loophole in the
An error in successfully. software that leads
coding or logic Confusions and the software to
affects the issues in perform improperly.
software and programming.
causes it to Invalid login,
breakdown or loop, and syntax.
the failure. Inconsistency
between actual
and expected
outcomes.
Blunders in
design or
requirement
actions.
Misperception in
understanding
the requirements
of the
application.

Way to Following are With the help of Below are ways The fault can be The way
to
prev the way to the following, to prevent prevented with the prevent failure
ent a
the stop the bugs: we can prevent the Errors: help of the following: re as
follows:
reas Test-driven the Defects: Enhance the Peer review. Confirm
ons
re-
development. Implementing software quality Assess the functional testing.
Offer several with system necessities of the Review

the
programming innovative review and software. requirements
28

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

language programming programming. Execute the detailed and

revisit
the
support. methods. Detect the issues code analysis. specifications.
Adjusting, Use of primary and prepare a Verify the Implement
advanced, and and correct suitable correctness of current
operative software mitigation plan. software design and protective
development development Validate the fixes programming. techniques.
procedures. techniques. and verify their Categorize
and
Evaluating the Peer review It quality and Evaluate
code is executing precision. errors and
systematically. consistent code issues.
reviews to
evaluate its
quality and
correctness.

Software Testing Principles

Software testing is a procedure of implementing software or the application to identify the defects or

bugs. For testing an application or software, we need to follow some principles to make our product defects free,

and that also helps the test engineers to test the software with their effort and time. Here, in this section, we are

going to learn about the seven essential principles of software testing.

Let us see the seven different testing principles, one by one:

o Testing shows the presence of defects

o Exhaustive Testing is not possible
o Early Testing
o Defect Clustering
o Pesticide Paradox
o Testing is context-dependent
o Absence of errors fallacy
Testing shows the presence of defects

The test engineer will test the application to make sure that the application is bug or defects free.
29

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

While doing testing, we can only identify that the application or software has any errors. The
primary purpose of doing testing is to identify the numbers of

unknown bugs with the help of various methods and testing techniques because the entire test
should be traceable to the customer requirement, which means that to find any defects that might
cause the product failure to meet the client's needs.

By doing testing on any application, we can decrease the number of bugs, which does not mean
that the application is defect-free because sometimes the software seems to be bug-free while
performing multiple types of testing on it. But at the time of deployment in the production server,
if the end-user encounters those bugs which are not found in the testing process.

Exhaustive Testing is not possible

Sometimes it seems to be very hard to test all the modules and their features with effective and
non- effective combinations of the inputs data throughout the actual testing process.

Hence, instead of performing the exhaustive testing as it takes boundless determinations and most
of the hard work is unsuccessful. So we can complete this type of variations according to the
importance of the modules because the product timelines will not permit us to perform such type
of testing scenarios.

Early Testing

Here early testing means that all the testing activities should start in the early stages of the software
development life cycle's requirement analysis stage to identify the defects because if we find the
bugs at an early stage, it will be fixed in the initial stage itself, which may cost us very less as
compared to those which are identified in the future phase of the testing process.

To perform testing, we will require the requirement specification documents; therefore, if the
requirements are defined incorrectly, then it can be fixed directly rather than fixing them in another
stage, which could be the development phase.

Defect clustering
30

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

The defect clustering defined that throughout the testing process, we can detect the numbers of
bugs which are correlated to a small number of modules. We have various reasons for this, such
as the modules could be complicated; the coding part may be complex, and so on.

These types of software or the application will follow the Pareto Principle, which states that we
can identify that approx. Eighty percent of the complication is present in 20 percent of the
modules. With the help of this, we can find the uncertain modules, but this method has its
difficulties if the same tests are performing regularly, hence the same test will not able to identify
the new defects.

Pesticide paradox

This principle defined that if we are executing the same set of test cases again and again over a
particular time, then these kinds of the test will not be able to find the new bugs in the software or
the application. To get over these pesticide paradoxes, it is very significant to review all the test
cases frequently. And the new and different tests are necessary to be written for the implementation
of multiple parts of the application or the software, which helps us to find more bugs.

Testing is context-dependent

Testing is a context-dependent principle states that we have multiple fields such as e- commerce
websites, commercial websites, and so on are available in the market. There is a definite way to
test the commercial site as well as the e-commerce websites because every application has its own
needs, features, and functionality. To check this type of application, we will take the help of various
kinds of testing, different technique, approaches, and multiple methods. Therefore, the testing
depends on the context of the application.

Program Inspections

Inspections are a formal type of review that involves checking the documents
thoroughly before a meeting and is carried out mostly by moderators. A meeting is then held to
review the code and the design. Inspection meetings can be held both physically and virtually

The stages in the inspections process are: Planning, Overview meeting, Preparation, Inspection
meeting, Rework and Follow-up. The Preparation, Inspection meeting and Rework stages might
be iterated.

Code inspection in software engineering is the process of reviewing the code in an application to
check for defects. Its purpose is to correct the issues in the programming language so the software
performs at its highest potential

31

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

Program inspections, also known as code inspections or peer reviews, are a systematic and
structured approach to examining source code to identify defects, improve code quality, and ensure
adherence to coding standards. Inspections involve a group of developers or peers reviewing the
code, discussing potential issues, and suggesting improvements. The primary goal of program
inspections is to catch errors early in the development process, before they manifest as problems
in the running system.

Here are some key aspects of program inspections:

Process: Program inspections typically follow a well-defined process. The process involves
planning and scheduling the inspection, selecting participants, conducting the inspection meeting,
documenting the findings, and following up on the identified issues. The process may be guided
by specific inspection guidelines or checklists to ensure consistent and thorough review.

Participants: Inspections involve a group of participants who review the code. The participants
may include the code author, other developers, and peers with relevant expertise. The participation
of multiple individuals with different perspectives helps in identifying diverse issues and
promoting collective learning.

Goals: The primary goals of program inspections are to identify defects, improve code quality, and
ensure adherence to coding standards. Defects can include logic errors, incorrect algorithms, poor
error handling, or violations of coding conventions. Inspections also provide an opportunity to
share knowledge, validate design decisions, and identify potential optimizations.

Code Understanding: Inspections require participants to thoroughly understand the code being
reviewed. They need to comprehend the code's purpose, its interaction with other components, and
its compliance with requirements and specifications. Code understanding is crucial for identifying
potential issues and proposing effective solutions.

Defect Identification: During the inspection, participants actively search for defects or issues in
the code. This may involve examining the code for syntax errors, logic flaws, performance
bottlenecks, security vulnerabilities, or violations of coding best practices. The focus is on
identifying defects that could impact the system's functionality, reliability, maintainability, or
performance.

Communication and Collaboration: Inspections facilitate communication and collaboration among

participants. Reviewers can discuss their findings, ask questions, and provide feedback to the code
author. The inspection process encourages constructive criticism, open discussions, and
knowledge sharing, which can lead to improved code quality and developer skill enhancement.

Documentation and Follow-up: The findings of the inspection, including identified

32

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

defects and suggested improvements, are documented. The code author is responsible for
addressing the identified issues, either by making necessary code changes or providing
justifications for not making changes. The inspection process may include a follow-up review to
ensure that the identified issues have been appropriately resolved.

Program inspections complement other software development practices, such as testing and static
analysis, by providing a human-focused, qualitative review of the code. They can help identify
defects that may not be easily captured through automated techniques and contribute to overall
code quality and reliability.

Stages of Testing: Unit Testing

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

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

The purpose of unit testing is 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.

Whenever the application is ready and given to the Test engineer, he/she will start checking every
component of the module or module of the application independently or one by one, and this
process is known as Unit testing or components testing.

33

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

Why Unit Testing?

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.

Generally, the 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:

o Unit testing helps tester and developers to understand the base of code that makes
them able to change defect causing code quickly.
o Unit testing helps in the documentation.

34

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

o 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.
o It helps with code reusability by migrating code and test cases.

Example of Unit testing

Let us see one sample example for a better understanding of the concept of unit testing:

For the amount transfer, requirements are as follows:

1. Amount transfer

1.1 From account number (FAN)→ Text Box

1.1.1 FAN→ accept only 4 digit

1.2 To account no (TAN)→ Text Box

1.2.1 TAN→ Accept only 4 digit

35

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

1.3 Amount→ Text Box

1.3.1 Amount → Accept maximum 4 digit

1.4 Transfer→ Button

1.4.1 Transfer → Enabled

1.5 Cancel→ Button

1.5.1 Cancel→ Enabled

Below are the application access details, which is given by the customer

o URL→ login Page

o Username/password/OK → home page
o To reach Amount transfer module follow the below

Loans → sales → Amount transfer

While performing unit testing, we should follow some rules, which are as follows:

o To start unit testing, at least we should have one module.

o Test for positive values
o Test for negative values
o No over testing
o No assumption required

When we feel that the maximum test coverage is achieved, we will stop the testing.

Now, we will start performing the unit testing on the different components such as

o From account number(FAN)

o To account number(TAN)

36

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

o Amount
o Transfer
o Cancel
o
For the FAN components

Values Description

1234 accept

4311 Error message→ account valid or not

blank Error message→ enter some values

5 digit/ 3 digit Error message→ accept only 4 digit

Alphanumeric Error message → accept only digit

Blocked account no Error message

Copy and paste the value Error message→ type the value

Same as FAN and TAN Error message

37

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

For the TAN component

o Provide the values just like we did in From account number (FAN) components

For Amount component

o Provide the values just like we did in FAN and TAN components.

For Transfer component

o Enter valid FAN value

o Enter valid TAN value
o Enter the correct value of Amount
o Click on the Transfer button→ amount transfer successfully( confirmation message)

For Cancel Component

o Enter the values of FAN, TAN, and amount.

o Click on the Cancel button → all data should be cleared.

Unit Testing Tools

We have various types of unit testing tools available in the market, which are as follows:

o NUnit
o JUnit
o PHPunit
o Parasoft Jtest
o EMMA

When we have to find and authenticate the particular module or unit of the code, we need the unit
testing tools. With the help of these tools, we can build secure design and documentation and
decrease the bug count.

Generally, unit testing is a manual process, but now some of the organization has automated the
unit test with the help of these tools. By using unit testing tools, we can cover the maximum
coverage, performance, compatibility, and integration testing.

38

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

All the unit testing tool is implemented as a plug-in for the eclipse. Unit testing tools are used by
the developers to test the source code of the application or to achieve the source code of the
application.

Following are the most commonly used tools of unit testing:

o NUnit
o JUnit
o TestNG
o Mockito
o PHPUnit

NUnit

One of the most commonly used unit testing tools is NUnit. It is an open-source tool and initially
ported from the JUnit, which works for all .Net languages. NUnit was written entirely in the C#
language and fully redesigned to get the advantage of many .Net language features. Like custom
attributes and other reflection related capabilities.

39

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

Features of NUnit
o It powerfully supports the data-driven tests.
o In this, we can execute the tests parallelly.
o It allows assertions as a static method of the asset class.
o It uses a console runner to load and execute tests.
o NUnit supports various platforms such as Silverlight, Xamarin mobile, .NET core, and
compact framework.

JUnit

It is another open-source unit testing framework, which was written in Java programing language.
It is mainly used in the development of the test-driven environment. Junit offers the annotation,
which helps us to find the test method. This tool helps us to enhance the efficiency of the developer,
which provides the consistency of the development code and reduces the time of the debugging.

Feature of JUnit
o It offers the assertions for testing expected results.
o In this tool, we can quickly develop a code that enhances the quality of the code.
o This tool can be structured in the test suites, which have the test cases.
o To run the test, it gives the test runners.
o It will take less time to run the test cases.

40

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

TestNG

It is an open-source tool, which supports Java and .Net programming languages. Test Next
Generation (TestNG) is an advance unit testing tool, which is stimulated from JUnit and NUnit
testing frameworks. Still, few new functionalities (Additional Annotation, Parallel Execution,
Group Execution, Html Report, and Listener) make a TestNG more powerful tool.

For the automation process, TestNG will be used to handle the framework component and achieve
the batch execution without any human interference.

Feature of TestNG

Following are the some commonly used features of TestNG:

o TestNG support various instance of the same test cases, parameterized,

annotation, data-driven, functional, integration, and unit testing.
o In the case of development, TestNG will be used to develop a unit test case, and each
unit test case will test the business logic of the source code.
o It will provide a flexible test configuration.
o It will have the Dependent methods for application server testing
o With the help of TestNG, we have full control over the test cases and the
execution of the test cases.
o It is supported by multiple plug-in and tools such as IDEA, Eclipse, and Maven, and so
on

Mockito

It is a mocking framework that is used in the unit testing, and it was written in the Java programing
language. Mockito is also an open-source tool introduced by the MIT (Massachusetts
Institute of Technology) License.

41

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

With the help of Mockito, we can develop the testable application. The primary objective of using
this tool is to simplify the development of a test by mocking external dependencies and use them
in the test code. It can be used with other testing frameworks such as TestNG and Junit.

Feature of Mockito
o It will be used to support exceptions.
o With the help of the annotation feature, we can produce the mocks.
o We do not need to write the mocks object on our own.
o It will support return values.
o It provides multiple methods like verify(), mock(), when(), etc., which are helpful to test
Java applications.

PHPUnit

Another unit testing tool is PHPUnit, which was written in PHP programing language. It is an
instance of the xUnit architecture and based on the JUnit framework. It can generate the test results
output in many various formats with JSON, JUnit XML, TestDox, and Test anything protocol. We
can run the test cases on the cross-platform operating system.

Features of PHPUnit
o PHPUnit will provide the logging, code coverage analysis.
o Its development is hosted on GitHub.
o PHPUnit uses assertionsto validate the performance of the specific component.

42

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

o With the help of this tool, developers can identify the issues in their newly
developed code.

Unit Testing Techniques:

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

o Data flow Testing

o Control Flow Testing
o Branch Coverage Testing
o Statement Coverage Testing
o Decision Coverage Testing

How to achieve the best result via Unit testing?

Unit testing can give best results without getting confused and increase complexity by
following the steps listed below:

o Test cases must be independent because if there is any change or enhancement in

requirement, the test cases will not be affected.
o Naming conventions for unit test cases must be clear and consistent.
o During unit testing, the identified bugs must be fixed before jump on next phase of the
SDLC.
o Only one code should be tested at one time.
o Adopt test cases with the writing of the code, if not doing so, the number of
execution paths will be increased.
o If there are changes in the code of any module, ensure the corresponding unit test is
available or not for that module.

Advantages and disadvantages of unit testing The

pros and cons of unit testing are as follows:

43

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

Advantages
o Unit testing uses module approach due to that any part can be tested without waiting
for completion of another parts testing.
o The developing team focuses on the provided functionality of the unit and how
functionality should look in unit test suits to understand the unit API.
o Unit testing allows the developer to refactor code after a number of days and ensure
the module still working without any defect.

Disadvantages

o It cannot identify integration or broad level error as it works on units of the code.
o In the unit testing, evaluation of all execution paths is not possible, so unit testing is not
able to catch each and every error in a program.
o It is best suitable for conjunction with other testing activities.

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 coders or programmers. The goal of integration testing is to check the correctness of
communication among all the modules.

Once all the components or modules are working independently, then we need to check the data
flow between the dependent modules is known as integration testing

Let us see one sample example of a banking application, as we can see in the below image of amount
transfer.

44

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

o First, we will login as a user P to amount transfer and send Rs200

amount, the confirmation message should be displayed on the screen as amount
transfer successfully. Now logout as P and login as user Q and go to amount balance page
and check for a balance in that account = Present balance + Received Balance. Therefore,
the integration test is successful.
o Also, we check if the amount of balance has reduced by Rs200 in P user account.
o Click on the transaction, in P and Q, the message should be displayed regarding the data
and time of the amount transfer.

Guidelines for Integration Testing

o We go for the integration testing only after the functional testing is completed on each
module of the application.
o We always do integration testing by picking module by module so that a proper
sequence is followed, and also we don't miss out on any integration scenarios.
o First, determine the test case strategy through which executable test cases can be
prepared according to test data.
o Examine the structure and architecture of the application and identify the crucial modules
to test them first and also identify all possible scenarios.
o Design test cases to verify each interface in detail.

45

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

o Choose input data for test case execution. Input data plays a significant role in testing.
o If we find any bugs then communicate the bug reports to developers and fix defects
and retest.
o Perform positive and negative integration testing.

Here positive testing implies that if the total balance is Rs15, 000 and we are transferring Rs1500
and checking if the amount transfer works fine. If it does, then the test would be a pass.

And negative testing means, if the total balance is Rs15, 000 and we are transferring Rs20, 000
and check if amount transfer occurs or not, if it does not occur, the test is a pass. If it happens, then
there is a bug in the code, and we will send it to the development team for fixing that bug.

For example: In the Gmail application, the Source could

be Compose, Data could be Email and the Destination could be the Inbox.

Example of integration testing

Let us assume that we have a Gmail application where we perform the integration testing.

First, we will do functional testing on the login page, which includes the various components
such as username, password, submit, and cancel button. Then only we can perform integration
testing.

The different integration scenarios are as follows:

Scenarios1:

o First, we login as P users and click on the Compose mail and performing the
functional testing for the specific components.

46

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

o Now we click on the Send and also check for Save Drafts.
o After that, we send a mail to Q and verify in the Send Items folder of P to check if the
send mail is there.
o Now, we will log out as P and login as Q and move to the Inbox and verify that if the
mail has reached.

Secanrios2: We also perform the integration testing on Spam folders. If the particular contact has
been marked as spam, then any mail sent by that user should go to the spam folder and not in the
inbox.

As we can see in the below image, we will perform the functional testing for all the text
fields and every feature. Then we will perform integration testing for the related functions. We
first test the add user, list of users, delete user, edit user, and then search user.

Note:

o There are some features, we might be performing only the functional testing, and there
are some features where we are performing both functional and
integration testing based on the feature's requirements.
o Prioritizing is essential, and we should perform it at all the phases, which means we will
open the application and select which feature needs to be tested first. Then go to that feature
and choose which component must be tested first. Go to those components and
determine what values to be entered first. And don't apply the same rule everywhere

47

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

because testing logic varies from feature to feature.

o While performing testing, we should test one feature entirely and then only proceed to
another function.
o Among the two features, we must be performing only positive integrating testing or both
positive and negative integration testing, and this also depends on the features need.

Reason Behind Integration Testing

Although all modules of software application already tested in unit testing, errors still exist
due to the following reasons:

1. Each module is designed by individual software developer whose programming logic may
differ from developers of other modules so; integration testing becomes essential to
determine the working of software modules.
2. To check the interaction of software modules with the database whether it is an erroneous
or not.
3. Requirements can be changed or enhanced at the time of module development. These new
requirements may not be tested at the level of unit testing hence integration testing becomes
mandatory.
4. Incompatibility between modules of software could create errors.
5. To test hardware's compatibility with software.
6. If exception handling is inadequate between modules, it can create bugs.

Integration Testing Techniques

Any testing technique (Blackbox, Whitebox, and Greybox) can be used for Integration Testing;
some are listed below:

Black Box Testing

o State Transition technique
o Decision Table Technique
o Boundary Value Analysis
o All-pairs Testing
o Cause and Effect Graph
o Equivalence Partitioning
o Error Guessing
48

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

White Box Testing

o Data flow testing
o Control Flow Testing
o Branch Coverage Testing
o Decision Coverage Testing

Types of Integration Testing

Integration testing can be classified into two parts:

o Incremental integration testing

o Non incremental integration testing

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.

OR

In this type of testing, there is a strong relationship between the dependent modules. Suppose we
take two or more modules and verify that the data flow between them is working fine. If it is, then
add more modules and test again.

49

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

For example: Suppose we have a Flipkart application, we will perform incremental integration
testing, and the flow of the application would like this:

Flipkart→ Login→ Home → Search→ Add cart→Payment → Logout Incremental

integration testing is carried out by further methods:

o Top-Down approach
o Bottom-Up approach

Top-Down Approach

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. In this type of method,
we will add the modules incrementally or one by one and check the data flow in the same order.

50

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

In the top-down approach, we will be ensuring that the module we are adding is the child
of the previous one like Child C is a child of Child B and so on as we can see in the below
image:

Advantages:

o Identification of defect is difficult.

o An early prototype is possible.

Disadvantages:

51

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

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

o Lower level modules are tested inadequately.
o 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. Or we can say that we will be adding
the modules from bottom to the top and check the data flow in the same order.

In the bottom-up method, we will ensure that the modules we are adding are the parent of the
previous one as we can see in the below image:

52

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

Advantages

o Identification of defect is easy.

o Do not need to wait for the development of all the modules as it saves time.

Disadvantages

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

In this, we have one addition approach which is known as hybrid testing. 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.

53

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

Advantages

o The hybrid method provides features of both Bottom Up and Top Down methods.
o It is most time reducing method.
o It provides complete testing of all modules.

Disadvantages

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

Non- incremental integration testing

We will go for this method, when the data flow is very complex and when it is difficult to find
who is a parent and who is a child. And in such case, we will create the data in any module bang
on all other existing modules and check if the data is present. Hence, it is also known as the Big
bang method.

54

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

Big Bang Method

In this approach, testing is done via integration of all modules at once. It is convenient for small
software systems, if used for large software systems identification of defects is difficult.

Since this testing can be done after completion of all modules due to that testing team has less time
for execution of this process so that internally linked interfaces and high- risk critical modules can
be missed easily.

Advantages:

o It is convenient for small size software systems.

55

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

Disadvantages:

o Identification of defects is difficult because finding the error where it came from is a
problem, and we don't know the source of the bug.
o Small modules missed easily.
o Time provided for testing is very less.
o We may miss to test some of the interfaces.

Let us see examples for our better understanding of the non-incremental integrating testing or big
bang method:

Example1

In the below example, the development team develops the application and sends it to the CEO of
the testing team. Then the CEO will log in to the application and generate the username and
password and send a mail to the manager. After that, the CEO will tell them to start testing the
application.

Then the manager manages the username and the password and produces a username and
password and sends it to the test leads. And the test leads will send it to the test engineers for
further testing purposes. This order from the CEO to the test engineer is top-down incremental
integrating testing.

In the same way, when the test engineers are done with testing, they send a report to the test leads,
who then submit a report to the manager, and the manager will send a report to the CEO. This
process is known as Bottom-up incremental integration testing as we can see in the below
image:

56

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

Example2

The below example demonstrates a home page of Gmail's Inbox, where we click on the Inbox
link, and we are moved to the inbox page. Here we have to do non- incremental integration
testing because there is no parent and child concept.

Note

Stub and driver

The stub is a dummy module that receives the data and creates lots of probable data, but it performs
like a real module. When a data is sent from module P to Stub Q, it receives the data without
confirming and validating it, and produce the estimated outcome for the given data.

57

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

The function of a driver is used to verify the data from P and sends it to stub and also checks the
expected data from the stub and sends it to P.

The driver is one that sets up the test environments and also takes care of the communication,
evaluates results, and sends the reports. We never use the stub and driver in the testing process.

In White box testing, bottom-up integration testing is ideal because writing drivers is accessible.
And in black box testing, no preference is given to any testing as it depends on the application.

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.

58

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

To check the end-to-end flow of an application or the software as a user is known as System
testing. In this, we navigate (go through) all the necessary modules of an application and check if
the end features or the end business works fine, and test the product as a whole system.

It is end-to-end testing where the testing environment is similar to the production environment.

There are four levels of software testing: unit testing, integration testing, system testing and
acceptance testing, all are used for the testing purpose. Unit Testing used to test a single software;
Integration Testing used to test a group of units of software, System Testing used to test a whole
system and Acceptance Testing used to test the acceptability of business requirements. Here we
are discussing system testing which is the third level of testing levels

Hierarchy of Testing Levels

59

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

There are mainly two widely used methods for software testing, one is White box testing which
uses internal coding to design test cases and another is black box testing which uses GUI or user
perspective to develop test cases.

o White box testing

o Black box testing

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.

o Verification of input functions of the application to test whether it is producing the

expected output or not.
o Testing of integrated software by including external peripherals to check the
interaction of various components with each other.
o Testing of the whole system for End to End testing.
o Behavior testing of the application via auser's experience

Example of System testing

Suppose we open an application, let say www.rediff.com, and there we can see that an
advertisement is displayed on the top of the homepage, and it remains there for a

60

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

few seconds before it disappears. These types of Ads are done by the Advertisement Management
System (AMS). Now, we will perform system testing for this type of field.

The below application works in the following manner:

o Let's say that Amazon wants to display a promotion ad on January 26 at precisely 10:00
AM on the Rediff's home page for the country India.
o Then, the sales manager logs into the website and creates a request for an advertisement
dated for the above day.
o He/she attaches a file that likely an image files or the video file of the AD and applies.
o The next day, the AMS manager of Rediffmail login into the application and verifies the
awaiting Ad request.
o The AMS manager will check those Amazons ad requests are pending, and then he/she
will check if the space is available for the particular date and time.
o If space is there, then he/she evaluate the cost of putting up the Ad at 15$ per second, and
the overall Ad cost for 10 seconds is approximate 150$.
o The AMS manager clicks on the payment request and sends the estimated value along with
the request for payment to the Amazon manager.
o Then the amazon manager login into the Ad status and confirms the payment request, and
he/she makes the payment as per all the details and clicks on the Submit and Pay
o As soon as Rediff's AMs manager gets the amount, he/she will set up the Advertisement
for the specific date and time on the Rediffmail's home page.

The various system test scenarios are as follows:

Scenario1: The first test is the general scenario, as we discussed above. The test engineer will do
the system testing for the underlying situation where the Amazon manager creates a request for
the Ad and that Ad is used at a particular date and time.

Scenario2: Suppose the Amazon manager feels that the AD space is too expensive and cancels
the request. At the same time, the Flipkart requests the Ad space on January 26 at 10:00 AM. Then
the request of Amazon has been canceled. Therefore, Flipkart's promotion ad must be arranged on
January 26 at 10 AM.

61

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

After all, the request and payment have been made. Now, if Amazon changes their mind and they
feel that they are ready to make payment for January 26 at 10 AM, which should be given because
Flipkart has already used that space. Hence, another calendar must open up for Amazon to make
their booking.

Scenario3: in this, first, we login as AMS manger, then click on Set Price page and set the price
for AD space on logout page to 10$ per second.

Then login as Amazon manager and select the date and time to put up and Ad on the logout page.
And the payment should be 100$ for 10 seconds of an Ad on Rediffmail logout page.

62

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

we can see in the above image, we have three different modules like Loans, Sales, and
Overdraft. And these modules are going to be tested by their assigned test engineers only because
if data flow between these modules or scenarios, then we need to clear that in which module it is
going and that test engineer should check that thing.

Let us assume that here we are performing system testing on the interest estimation, where
the customer takes the Overdraft for the first time as well as for the second time

63

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

Scenario 2

Now, we test the alternative scenario where the bank provides an offer, which says that a customer
who takes Rs45000 as Overdraft for the first time will not charge for the Process fee. The
processing fee will not be refunded when the customer chooses another overdraft for the third time.

We have to test for the third scenario, where the customer takes the Overdraft of Rs45000 for the
first time, and also verify that the Overdraft repays balance after applying for another overdraft for
the third time.

Scenario 3

In this, we will reflect that the application is being used generally by all the clients, all of a sudden
the bank decided to reduce the processing fee to Rs100 for new customer, and we have test
Overdraft for new clients and check whether it is accepting only for Rs100.

But then we get conflicts in the requirement, assume the client has applied for Rs15000 as
Overdraft with the current process fee for Rs200. Before the Manager is yet to approve it, the bank
decreases the process fee to Rs100.

Now, we have to test what process fee is charged for the Overdraft for the pending customer. And
the testing team cannot assume anything; they need to communicate with the Business Analyst or
the Client and find out what they want in those cases.

64

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

Therefore, if the customers provide the first set of requirements, we must come up with the
maximum possible scenarios.

Types of System Testing

System testing is divided into more than 50 types, but software testing companies typically uses
some of them. These are listed below:

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.

65

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

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.

n this testing, we will test the application to check how well it recovers from the crashes or
disasters.

Recovery testing contains the following steps:

o Whenever the software crashes, it should not vanish but should write the crash log message
or the error log message where the reason for crash should be mentioned. For example:
C://Program Files/QTP/Cresh.log
o It should kill its own procedure before it vanishes. Like, in Windows, we have the Task
Manager to show which process is running.
o We will introduce the bug and crash the application, which means that someone will lead
us to how and when will the application crash. Or By experiences, after few months of
involvement on working the product, we can get to know how and when the application
will crash.
o Re-open the application; the application must be reopened with earlier settings.

For example: Suppose, we are using the Google Chrome browser, if the power goes off, then we
switch on the system and re-open the Google chrome, we get a message asking whether we want
to start a new session or restore the previous session. For any developed product, the developer
writes a recovery program that describes, why the software or the application is crashing, whether
the crash log messages are written or not, etc.

66

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

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?

o System Testing gives hundred percent assurance of system performance as it covers end to
end function of the system.
o It includes testing of System software architecture and business requirements.
o It helps in mitigating live issues and bugs even after production.
o 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 thesystem.

67

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

Testing Any Application Here, we are going to test the Gmail application to understand how functional
integration, and System testing works.

Suppose, we have to test the various modules such as Login, Compose, Draft, Inbox, Sent
Item, Spam, Chat, Help, Logout of Gmail application.

We do Functional Testing on all Modules First, and then only we can perform integration testing
and system testing.

In functional testing, at least we have one module to perform functional testing. So here we have
the Compose Module where we are performing the functional testing.

Compose

The different components of the Compose module are To, CC, BCC, Subject, Attachment,
Body, Sent, Save to Draft, Close.

o First, we will do functional testing on the To

Input Results

Positive inputs

mike@gmail.com Accept

68

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

Mike12@gmail.com Accept
Mike@yahoo.com Accept
Negative inputs
Mike@yahoocom Error
Mike@yaho.com Error

o For CC & BCC components, we will take the same input as To component.
o For Subject component, we will take the following inputs and scenarios:

Input Results

Positive inputs

Enter maximum character Accept

Enter Minimum character Accept

Blank Space Accept

69

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

URL Accept

Copy & Paste Accept

Negative inputs

Crossed maximum digits Error

Paste images / video / audio Error

o Maximum character
o Minimum character
o Flash files (GIF)
o Smiles
o Format
o Blank
o Copy & Paste
o Hyperlink
o Signature

o For the Attachment component, we will take the help of the below scenarios and test the
component.
o File size at maximum
o Different file formats
o Total No. of files
o Attach multiple files at the same time
o Drag & Drop
o No Attachment
o Delete Attachment
o Cancel Uploading
o View Attachment
o Browser different locations

70

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

o Attach opened files

o For Sent component, we will write the entire field and click on the Sent button, and
the Confirmation message; Message sent successfully must be displayed.
o For Saved to Drafts component, we will write the entire field and click on aved to
drafts, and the Confirmation message must be displayed.
o For the Cancel component, we will write all fields and click on the Cancel button, and the
Window will be closed or moved to save to draft or all fields must be refreshed.

Once we are done performing functional testing on compose module, we will do the Integration
testing on Gmail application's various modules:

Login

o First, we will enter the username and password for login to the application and Check the
username on the Homepage.

Compose

o Compose mail, send it and check the mail in Sent Item [sender]
o Compose mail, send it and check the mail in the receiver [Inbox]
o Compose mail, send it and check the mail in self [Inbox]
o Compose mail, click on Save as Draft, and check-in sender draft.
o Compose mail, send it invalid id (valid format), and check for undelivered
message.
o Compose mail, close and check-in Drafts.

Inbox

o Select the mail, reply, and check in sent items or receiver Inbox.
o Select the mail in Inbox for reply, Save as Draft and check in the Draft.
o Select the mail then delete it, and check in Trash.

Sent Item

o Select the mail, Sent Item, Reply or Forward, and check in Sent item or receiver inbox.
o Select mail, Sent Item, Reply or Forward, Save as Draft, and verify in the Draft.
o Select mail, delete it, and check in the Trash.

71

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

Draft

o Select the email draft, forward and check Sent item or Inbox.
o Select the email draft, delete and verify in Trash.

Chat

o Chat with offline users saved in the inbox of the receiver.

o Chat with the user and verify it in the chat window.
o Chat with a user and check in the chat history.

72

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

UNIT II TEST PLANNING

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
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
73

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

expertise required for testing, estimating the effort and duration of testing activities, and ensuring that the
required 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. ...

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

74

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

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

75

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

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

76

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

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

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

77

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

• 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:

• 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

78

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

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

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:

79

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

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.

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
80

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

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.

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.

81

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

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:

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:
82

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

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

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:

83

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

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.

84

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

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.

85

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

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:

86

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

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.

87

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

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.

88

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

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.

89

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

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

90

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

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

91

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

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 testing
members 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

92

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

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.

93

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

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.

94

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

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

95

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

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.

96

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

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.

97

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

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.

98

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

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:

99

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

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:

Types of test cases

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

o Function test cases

o Integration test cases

100

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

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.

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:

101

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

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

102

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

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:

103

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

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

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

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
scheduling upcoming 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 maintenance of 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

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
output Software 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

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

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 quality aspects 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
time frame
Defect severity: It enables the developer to understand how the defect
is goingto impact the quality of the software.
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
Difference between 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
their importance to stakeholders and the testing team.

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

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 to create a report including a detailed summary of the conclusion.
Then the report is distributed 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
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

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)

 lOMoARcPSD|44229688

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.

Downloaded by CSE 25 Bhaarat Krish J (bhaaratstudentmail@gmail.com)