Learn Manual Testing From Scratch Part 2
Definition of Software Testing
It is a process of finding
or identifying defects in s/w is called s/w testing. It is verifying the functionality
(behavior) of the application(s/w) against requirements specification. It is
the execution of the s/w with the intention of finding defects. It is checking
whether the s/w works according to the requirements.
There
are 3 types of s/w testing, namely,
1)
White box testing
– also called unit testing or structural testing or glass box testing or transparent testing or open-box testing
2)
Grey box testing
3)
Black box testing – also
called as functional testing or behavioral testing
WHITE BOX TESTING (WBT)
Entire WBT is done by
developers. It is the testing of each and every line of code in the program.
Developers do WBT, sends the s/w to testing team. The testing team does black
box testing and checks the
s/w against requirements
and finds any defects and sends it to the developer. The developers fixes the
defect and does WBT and sends it to the testing team. Fixing defect means the
defect is removed and the feature is working fine.
Test
engineers should not be involved in fixing the bug because,
1) if they spend time in
fixing the bug, they lose time to catch some more other defects in the s/w
2) fixing a defect might
break a lot of other features. Thus, testers should always identify defects and
developers should always be involved in fixing defects.
WBT
consists of the following tests :
a) Path testing
Write flow graphs and test
all the independent paths.
Writing flow graphs means – flow graphs means representing the flow of the program, how each program is interlinked with one another.
Test all independent paths – Consider a path from
main( ) to function 7. Set the parameters and test if the program is correctly
in that path. Similarly test all other paths and fix defects.
b) Condition testing
Test all the logical
conditions for both true and false values i.e, we check for both “if” and
“else” condition.
If(
condition) - true
{
…….
…….
}
Else
- false
{
…..
…..
}
The program should work
correctly for both conditions i.e, if condition is true, then else should be
false and vice-versa
c) Loop testing
Test the loops(for, while,
do-while, etc) for all the cycles and also check for terminating condition if
working properly and if the size of the condition is sufficient enough.
For ex, let us consider a
program where in the developer has given about 1lakh loops.
{
While ( 1,00,000 )
…….
…….
}
We cannot test this
manually for all 1lakh cycles. So we write a small program,
Test
A
{
……
…… }
Which checks for all 1lakh loops. This Test A is known as unit
test. The test program is written in the same language as the source code
program. Developers only write the test program.
Let us consider the above case as
shown in the figure. Suppose the project consists of Requirement A,B,C,D,E.
Then the developer writes the Codes A,B,C,D,E for the corresponding
requirements. The program consists of 100s of lines of code.
As
developers do WBT, they test the 5 programs line by line of code for
defects. If in any the program, there is a defect, the developers identify the
defect and rectifies it, and they again have to test the program and all the
programs again. This involves a lot of time and effort and slows down the
project completion time.
Let us consider another case. Suppose
the client asks for requirement changes, then the developers have to do the
necessary changes and test the entire 5 programs again. This again involves a
lot of time and effort.
This drawback
can be corrected in the following manner.
The collection of test programs is
known as test suite.
As early as we catch the bug, cost of
fixing the bug will be less. If we delay in catching the bug, cost of fixing
the bug increases exponentially.
Let us consider a program for the
calculator. Let us consider the addition function.
The other test programs are,
Y = callAdd.myAdd (10.5, 5.2)
If ( Y = 15.7)
{
Print
(“test is pass”)
}
Else
{
Print(“test
is fail”)
}
Similarly we do for,
Z = 9,00,000 and 1,00,000
P = -10, -5
In all the above test programs, the
variables of X, Y, Z, P are calling the function add.java and getting the add.
We do the addition manually and check for the remaining results. We can see
that the test programs are more tedious and lengthy and time consuming.
Thus, we have readymade programs.
Like, for example, we have a ready-made program named Junit which has a feature named Assert which runs the above and
compares the 2 values and automatically prints pass or fail.
Thus we can replace the test programs
with these simple programs,
Import Junit
X = callAdd.myAdd (10, 5)
Call
Assert (X, 15)
It automatically prints pass or fail.
Similarly we can do for the other tests for Y, Z and P.
d) From
memory point of view of testing
The size of code of a program
increases because,
i) The logic used by the programmer may
vary. If one developer writes a code of 300kb file size, then another developer
may write the same program using different logic and write of code of 200kb file
size.
iii ) Developers declare so many
variables, functions which may never be used in any part of the program. Thus,
the size of the program increases.
For ex,
Int i = 10 ;
Int j = 15 ;
String S = “hello” ;
. . . . .
. . . . .
. . . . .
.
. . .
. . . . .
Int a = j ;
Create user
{
.
. . .
.
. . . 100 lines of code
.
. . .
}
In the above program, we
can see that the integer i has never been called anywhere in the program and
also the function create user has never
been called anywhere in the program. Thus this leads to memory wastage.
Programs A, B, and C is
given as input to D. D goes into the programs and checks for unused variables.
It then gives the result. The developer can then click on the various results
and call or delete the unused variables and functions.
This tool is specific only
for C, C++ languages. For other languages, we have other similar tools.
iv
) The
developer doesn’t use already existing inbuilt functions and sits and writes
the entire function using his logic. Thus leads to waste of time and also
delays.
Let us consider there is an
already inbuilt function sort ( ).
Instead the developer sits and writes his own program mysort ( ). This leads to waste of time and effort. Instead he
could have used a single function call
sort ( ).
e ) Test for response time/ speed/ performance of the
program
The reasons for slow
performance could be,
i ) Logic used
ii ) Switch case – Do not
use nested if, instead use switch case
As the developer is doing
WBT, he sees that the program is running slow or the performance of the program
is slow. The developer cannot go manually through the code and check which line
of the code is slowing the program.
We have a tool by name Rational Quantify to do this job
automatically. As soon as all the programs are ready. This tool will go into
the program and runs all the programs. The result is shown in the result sheet
in the form of thick and thin lines. Thick lines indicate that the piece of
code is taking longer time to run. When we double-click on the thick line, then
the tool automatically takes us to the line/piece of code which is also colored
differently. We can modify that code and again use rational quantify. When the
sequence of lines are all thin, we know that the performance of the program has
improved.
Developers do a lot of WBT automatically rather than manually because it saves time.
Comments
Post a Comment