Lecture 6: Testing Methods

- Agile
- V-shaped

Agile Testing
What is Agile Testing?
Agile Testing is a type of software testing that follows the principle of agile software
development. It is an iterative development methodology and the requirements evolve
through collaboration between the customer and self-organizing teams.

An agile team works as a single team towards a common objective of achieving Quality.
Agile Testing has shorter time frames that are known as iterations.

Principles of Agile Testing

The different principles involved in Agile Testing include:
Testing is continuous: Agile team performs testing continuously because it is the only way to
ensure continuous progress of the product.
Continuous feedback: Agile testing provides feedback on an ongoing basis so that your
product can meet the business needs.
Tests performed by the whole team: In the software development life cycle, only the test team
is responsible for testing. But in agile testing, the developers and the business analysts also
test the application.
Decrease time of feedback response: The business team is involved in each iteration in agile
testing. So continuous feedback reduces the time of feedback response.
Simplified & clean code: The defects raised by the agile team are fixed in the same iteration.
This helps in keeping the code clean and simplified.
Less documentation: Agile teams use a reusable checklist and the team focuses on the test
instead of the incidental details.
Test Driven: In agile methods, you need to perform testing at the time of implementation. But
in the traditional process, the testing is performed after implementation.

Advantages of Agile Testing

The benefits of Agile Testing approach include:
- It saves time and money
- Agile testing reduces documentation
- It is flexible and highly adaptable to changes
- It provides a way for receiving regular feedback from the end user
- Better determination of issues through daily meetings
Q. Write the disadvantages

Agile Testing Methods

There are three main agile testing methods
i. Behavior Driven Development (BDD) – It improves communication amongst
project stakeholders so that all members correctly understand each feature before
the development process starts. There is continuous example-based
communication between developers, testers, and business analysts.
 ii. Acceptance Test Driven Development (ATDD) – It focuses on involving team
members with different perspectives such as the customer, developer, and tester.
The meetings are held to formulate acceptance tests incorporating perspectives of
the customer, development, and testing.

iii. Exploratory Testing – It emphasizes working software over comprehensive

documentation. The individuals and interactions are more important than the
process and tools. Customer collaboration holds greater value than contract
negotiation.

Life Cycle of Agile Testing

There are 5 different phases in the Agile Testing life cycle such as:

Impact Assessment – In the first phase you have to gather inputs from stakeholders and users.
Now this will be taken as feedback for the next deployment cycle.
Agile Testing Planning – Here, the stakeholders come together to plan the schedule of the
testing process, meeting frequency, and deliverables.
Release Readiness – At this stage, you have to review the features that have been developed
and check if they are ready to go live or not.
Daily Scrums – This phase includes the everyday morning meetings to check on the status of
testing and set the goals for the day.
Test Agility Review – The final phase involves the weekly meetings with the stakeholders to
review and assess the progress against milestones.
Agile Test Plan & Quadrants
The test plan is written and updated for every release for agile testing. It includes:
The scope of the testing
Consolidating new functionalities to be tested
Types of testing/Levels of testing
Performance & load testing
Consideration of infrastructure
Risks Plan
Planning of resources
Deliverables & Milestones
Quadrants
The agile testing quadrants separate the whole process in four Quadrants. So this helps you in
understanding the process of agile testing.

V-MODEL
In the V model, the development and QA activities are done simultaneously. Here, testing
starts right from the requirement phase. The verification and validation activities occur
simultaneously. Let’s look at the figure below to understand V model

Fig: Verification & Validation model – Software Testing Tutorial

In a typical development process, the left-hand side shows the development activities and the
right-hand side shows the testing activities. It should not be wrong if I say that in the
development phase both verification and validation are performed along with the actual
development activities.
LHS
As mentioned earlier, left-hand side activities are development activities. Normally we
feel, what testing can we do in the development phase? But this is the essence of this model
which illustrates that testing can be done in all phase of development activities as well.
RHS
The testing activities or the Validation Phase is carried out in the Right-hand side of the
model.
As you have gained some insights on this, let’s move further with this software testing
tutorial and see what are the different methods in which the software can be tested.

LECTURE 7: TESTING TECHNIQUES

With the help of below image, we can easily understand the type of software testing:

Manual testing
The process of checking the functionality of an application as per the customer needs without
taking any help of automation tools is known as manual testing. While performing the
manual testing on any application, we do not need any specific knowledge of any testing tool,
rather than have a proper understanding of the product so we can easily prepare the test
document.
Manual testing can be further divided into three types of testing, which are as follows:
White box testing
Black box testing
Gray box testing
Automation testing
Automation testing is a process of converting any manual test cases into the test scripts with
the help of automation tools, or any programming language is known as automation testing.
With the help of automation testing, we can enhance the speed of our test execution because
here, we do not require any human efforts. We need to write a test script and execute those
scripts.

Black Box Testing

Black Box Testing is a software testing method in which the functionalities of software
applications are tested without having knowledge of internal code structure, implementation
details and internal paths. Black Box Testing mainly focuses on input and output of software
applications and it is entirely based on software requirements and specifications. It is also
known as Behavioral Testing.

Black-Box can be any software system you want to test. For Example, an operating system
like Windows, a website like Google, a database like Oracle or even your own custom
application. Under Black Box Testing, you can test these applications by just focusing on the
inputs and outputs without knowing their internal code implementation.
How to do BlackBox Testing
Here are the generic steps followed to carry out any type of Black Box Testing.
Initially, the requirements and specifications of the system are examined.
Tester chooses valid inputs (positive test scenario) to check whether SUT processes them
correctly. Also, some invalid inputs (negative test scenario) are chosen to verify that the SUT
is able to detect them.
Tester determines expected outputs for all those inputs.
Software tester constructs test cases with the selected inputs.
The test cases are executed.
Software tester compares the actual outputs with the expected outputs.
Defects if any are fixed and re-tested.
Types of Black Box Testing
There are many types of Black Box Testing but the following are the prominent ones –
Functional testing – This black box testing type is related to the functional requirements of a
system; it is done by software testers.
Non-functional testing – This type of black box testing is not related to testing of specific
functionality, but non-functional requirements such as performance, scalability, usability.
Regression testing – Regression Testing is done after code fixes, upgrades or any other
system maintenance to check the new code has not affected the existing code.
Tools used for Black Box Testing:
Tools used for Black box testing largely depends on the type of black box testing you are
doing.
For Functional/ Regression Tests you can use – QTP, Selenium
For Non-Functional Tests, you can use – LoadRunner, Jmeter
Black Box Testing Techniques
Following are the prominent Test Strategy amongst the many used in Black box Testing
Equivalence Class Testing: It is used to minimize the number of possible test cases to an
optimum level while maintains reasonable test coverage.
Boundary Value Testing: Boundary value testing is focused on the values at boundaries. This
technique determines whether a certain range of values are acceptable by the system or not. It
is very useful in reducing the number of test cases. It is most suitable for the systems where
an input is within certain ranges.
Decision Table Testing: A decision table puts causes and their effects in a matrix. There is a
unique combination in each column.
Comparison of Black Box and White Box Testing:

Black Box Testing White Box Testing

the main focus of black box testing is on the White Box Testing (Unit Testing) validates internal
validation of your functional requirements. structure and working of your software code
 To conduct White Box Testing, knowledge of underlying
Black box testing gives abstraction from code
programming language is essential. Current day software
and focuses on testing effort on the software
systems use a variety of programming languages and
system behavior.
technologies and its not possible to know all of them.
Black box testing facilitates testing White box testing does not facilitate testing communication
communication amongst modules amongst modules

Black Box Testing and Software Development Life Cycle (SDLC)

Black box testing has its own life cycle called Software Testing Life Cycle (STLC) and it is
relative to every stage of Software Development Life Cycle of Software Engineering.
Requirement – This is the initial stage of SDLC and in this stage, a requirement is gathered.
Software testers also take part in this stage.
Test Planning & Analysis – Testing Types applicable to the project are determined. A Test
Plan is created which determines possible project risks and their mitigation.
Design – In this stage Test cases/scripts are created on the basis of software requirement
documents
Test Execution– In this stage Test Cases prepared are executed. Bugs if any are fixed and re-t

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:
- 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.
- If the test engineers spend most of the time fixing the defects, then they may be
unable to find the other bugs in the application.

The white box testing contains various tests, which are as follows:
- Basis Path testing
- Loop testing
- Condition testing
 - Testing based on the memory perspective\
- 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
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.
For example: we have one program where the developers have given about 50,000 loops.
{
while(50,000)
……
……
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.

Test P
{
……
…… }

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.

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
{

…..

……

……

else - false

…..

……

……

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:
- 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.
- 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.
- 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,
Int a=15;
Int b=20;
String S= "Welcome";
….
…..
Int p=b;

Create user()

{
……
……
….. 200's line of code
}
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.
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
releases.

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

The application could be slow for the following reasons:
When logic is used.
For the conditional cases, we will use or & and adequately.
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 too
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.

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
Design all test scenarios, test cases and prioritize them according to high priority number.
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.
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.
This step focuses on testing of control statements like loops and conditional statements to
check the efficiency and accuracy for different data inputs.
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

It identifies internal security holes.
To check the way of input inside the code.
Check the functionality of conditional loops.
To test function, object, and statement at an individual level.
Advantages of White box testing
White box testing optimizes code so hidden errors can be identified.
Test cases of white box testing can be easily automated.
This testing is more thorough than other testing approaches as it covers all code paths.
It can be started in the SDLC phase even without GUI.
Disadvantages of White box testing
White box testing is too much time consuming when it comes to large-scale programming
applications.
White box testing is much expensive and complex.
It can lead to production error because it is not detailed by the developers.
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
Testing control flow of programs in order to explore the sequence of variables
according to the sequence of events.

Control Control flow testing determines the execution order of statements or

Flow instructions of the program through a control structure. The control
Testing 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
Testing flow graph. It covers all the possible outcomes (true and false) of each
condition of decision point at least once.

Statement Statement coverage technique is used to design white box test cases.
Testing This technique 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

Testing expressions. Whenever there 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.