Introduction To

Software Engineering
LECTURER: SYED HASNAIN ABBAS BUKHARI
Testing Strategies

q So3ware   tes6ng   is   the   process   to   uncover   requirement,  

design  and  coding  errors  in  the  program.  
q It   is   used   to   iden6fy   the   correctness,   completeness,  
security   and   quality   of   so3ware   products   against   a  
specifica6on.  
q Two  basic  approaches  of  so3ware  tes6ng  are  
q  Black  Box  Tes6ng  
q  White  Box  Tes6ng  

q A  various  approaches  to  BBT  are:  

q  Equivalence  Par66oning    
q  Boundary  Value  analysis    

S y e d   H a s n a i n   A b b a s   B u k h a r i  
Black Box Testing

q Method  that  examines  the  func6onality  of  an  applica6on,  

without  looking  at  its  structure.  

q The   tester   does   not   ever   examine   the   programming  

code   and   does   not   need   any   further   knowledge   of   the  
program  other  than  its  specifica6ons.  

q You   can   begin   planning   for   black   box   tes6ng   immediately  

a3er  the  requirements  and  the  func6onal  specifica6ons  are  
available.  

S y e d   H a s n a i n   A b b a s   B u k h a r i  
Test  Data  Genera+on    
q Given  constraints  on  6me  and  cost,  the  key  issue  of  tes6ng  
becomes:  

What  subset  of  all  possible  test  cases  has  the  highest  
probability  of  detec4ng  the  most  errors?  

q We   need   to   have   a   set   of   thought   processes   that   let   us   select  

test  data  more  intelligently.  

S y e d   H a s n a i n   A b b a s   B u k h a r i  
Test  Data  Genera+on  
q Exhaus6ve   black-­‐box   and   white-­‐box   tes6ng   are,   in   general,  
impossible,   but   suggested   that   a   reasonable   tes6ng   strategy  
might  be  elements  of  both.  

S y e d   H a s n a i n   A b b a s   B u k h a r i  
Black Box Testing

q Equivalence  Par++oning  
q A  good  test  case  is  one  that  has  a  reasonable  probability  of  
finding   an   error,   and   the   fact   is   that   an   exhaus6ve-­‐input  
tes6ng  of  a  program  is  impossible.  

q Of   course,   then,   we   want   to   select   the   right   subset-­‐the  

subset   with   the   highest   probability   of   finding   the   most  
errors.  

S y e d   H a s n a i n   A b b a s   B u k h a r i  
Equivalence Partitioning

q The   input   domain   of   a   program   is   par66oned   into   a   finite   number   of  

equivalence   classes   such   that   we   can   reasonably   assume   that   a   test   of   a  
representa6ve   value   of   each   class   is   equivalent   to   a   test   of   any   other  
value.  
q That  is,  if  one  test  case  in  an  equivalence  class  detects  an  error,  all  other  test  
cases  in  the  equivalence  class  would  be  expected  to  find  the  same  error.    

q Conversely,  if  a  test  case  did  not  detect  an  error,  we  would  expect  that  
no   other   test   cases   in   the   equivalence   class   would   fall   within   another  
equivalence  class,  since  equivalence  classes  may  overlap  one  another.  

S y e d   H a s n a i n   A b b a s   B u k h a r i  
Equivalence Partitioning

q In  other  words,  our  tes6ng  6me  is  best  spent  

elsewhere.  

q Test-­‐case  design  by  equivalence  par66oning  

proceeds  in  two  steps:    
q iden6fying  the  equivalence  classes  and    

q defining  the  test  cases.  

 

S y e d   H a s n a i n   A b b a s   B u k h a r i  
 Equivalence Class Partitioning
   Following  are  the  guidelines  for  iden6fying  the  equivalence  classes  
1.  If  an  input  condi6on  specifies  a  range  of  values  (for  example,  “the  item  count  can  
be   from   1   to   999”),   iden6fy   valid   equivalence   class   (1   <   item   count   <   999)   and  
invalid  equivalence  classes  (item  count  <  1  and  item  count  >  999).i.e.  

Test  Data  
◦   Valid  class=  1  <  item  count  <  999  

◦  In  valid  class=  item  count  <  1  and  item  count  >  999  

2.  If  an  input  condi6on  specifies  the  number  of  values  (for  example,  “one  through  
six  owners  can  be  listed  for  the  automobile”),  iden6fy  valid  equivalence  class  and  
invalid  equivalence  classes  (no  owners  and  more  than  six  owners).  

S y e d   H a s n a i n   A b b a s   B u k h a r i  
Equivalence Class Partitioning
3.  If   an   input   condi6on   specifies   a   set   of   input   values   and   there   is   reason   to  
believe   that   the   program   handles   each   differently   (e.g.   “type   of   vehicle  
must  be  BUS,  TRUCK,  TAXICAB,  PASSENGER,  or  MOTORCYCLE”),  iden6fy  a  
valid   equivalence   class   for   each   and   one   invalid   equivalence   class  
(“TRAILER,”  for  example).    
Test  Data  
◦  Valid  class=  BUS,  TRUCK,  TAXICAB,  PASSENGER,  or  MOTORCYCLE  
◦  In  valid  class=  Outside  Valid  Class….e.g.  (Trailer)  

4.  If   an   input   condi6on   specifies   a   “must   be”   situa6on,   such   as   “first  

character   of   the   iden6fier   must   be   a   lefer,”   iden6fy   one   valid  
equivalence  class  (it  is  a  lefer)  and  one  invalid  equivalence  class  (it  is  not  
a  lefer).   S y e d   H a s n a i n   A b b a s   B u k h a r i  
  Test  Data  Genera+on    

q The   reason   that   individual   test   cases   should   cover  

invalid   cases   is   that   certain   erroneous-­‐input   checks  
mask  or  supersede  other  erroneous  input  checks.    

S y e d   H a s n a i n   A b b a s   B u k h a r i  
Test Case (Important Things To Know)

1.  Test  Case  ID  

2.  Input  

3.  Par66on  Tested  

4.  Expected  Output  

NOTE:  None  of  the  above  should  be  missing  in  any  test  case  

S y e d   H a s n a i n   A b b a s   B u k h a r i  
Example
Equivalence Class Partitioning

q Employees   of   an   organiza6on   are   allowed   to   get  

accommoda6on  expenses  while  traveling  on  official  tours.  
q T he   program   for   valida6ng   expenses   claims   for  
accommoda6on  has  the  following  requirements  
q There   is   an   upper   limit   of   Rs.   3,000   for   accommoda6on  
expense  claims  
q Any  claim  above  Rs.  3,000  should  be  rejected  and  cause  an  
error  message  to  be  displayed  
q All   expense   amount   should   be   greater   than   zero   and   an  
error  message  to  be  displayed  if  this  is  not  the  case  
S y e d   H a s n a i n   A b b a s   B u k h a r i  
 Equivalence Class Partitioning
 
q Inputs:    Accommoda6on  Expense  
         
q Par++on  the  Input  Values:  
q Test  Data  
     Expense  ≤  0   Invalid  Class  

     0  <  Expense  ≤  3,000   Valid  Class  

     Expense  >  3,000   Invalid  Class  

S y e d   H a s n a i n   A b b a s   B u k h a r i  
 Equivalence Class Partitioning
 
q Inputs:    Accommoda6on  Expense  
       
q Par++on  the  Input  Values:  
q Test  Data  
   Valid  
     {0,…9}  
     11  digits  
   InValid  
     Outside  Valid    
       
       

S y e d   H a s n a i n   A b b a s   B u k h a r i  
Equivalence Class Partitioning
   
Test  Case                          1      2      3  
 
Input  (Expenses)                2000      350                    3500  
 
 
P.  tested              0<Expense<3000            0<Expense<3000    Expense>3000  
 
 
Exp-­‐output                                OK            OK    Error  Message  

S y e d   H a s n a i n   A b b a s   B u k h a r i