Exercise Modules for Build Quality In: Sharing Testing Expertise for Product Success

by Janet Gregory and Lisa Crispin, these are slides prepared to help participants learn and transfer different skills. We did not use all these in the workshop, since we did the topics participants chose. Contact us if you need info on the ones we did in the workshop that aren't in this deck.

Transcript

1. Build  Quality  In Agile  Tes)ng  Days  2015   Potsdam     Lisa  Crispin                                          Janet  Gregory   @lisacrispin                                    @janetgregoryca   Sharing  Tes5ng  Exper5se  for  Product  Success
2. Skills  transfer  modules •  Depending  on  what  the  group  wants  to  explore,  we   may  use  some  of  them  during  the  day.   •  You  may  find  them  helpful  later  for  the  topics  we   don’t  get  to  today.    We’ll  hand  them  later.   2  
3. 3   Collaboration
4. Skill:  Collabora5on 4   • Explain  why  collabora)on  is  important.   What  are  the  benefits?   • Give  some  examples  of  ways  to  collaborate    
5. Communica5ng Testers  oQen  deliver  bad  news!   Instead,  try  a  collabora)ve  approach  –  “Show   me”  or  “Let  me  show  you”.   Technical  awareness,  domain  knowledge,   examples  all  help.  
6. The  Whole-­‐Team  Approach 6  
7. 7   Ways  to  collaborate                     Pair:   Tester-­‐Coder   Tester-­‐Tester   Any  role  –  any  role     Mob  programming,   tes)ng,  “group  hugs”  
8. Teaching  Method:  Game 8   We’re  going  to  draw   2  itera)ons   •  First  one  without  collabora)on   •  Second  one  with     Thanks  to  the  members  of  the  agile-­‐games  group  and  Kane  Mar  for  ideas  &   pictures  for  this  game  
9. 9 Collabora5on  Exercise:  Itera5on  1 1.  Form  teams  of  four:  coder,  tester,  customer,  and   observer   2.  Coder  faces  away  from  customer  and  tester   3.  Customer  tells  the  coder  what  to  draw,  all  at  one   )me.   4.  Coder  draws  the  shapes  based  on  what  the   customer  explained.   •  No  talking  during  ‘coding’!   5.  Tester  “tests”  the  drawing,  reports  “bugs”  on   index  cards     6.  Coder  fixes  the  “bugs”     7.  How  long  did  it  take?  Is  the  customer  happy?      
10. 10 Collabora5on  Exercise:  Itera5on  2 1.  Collaborate!   2.  Customer  tells  coder  what  to  draw,  and  watches   the  coder  draw,  answer  ques)ons   3.  Don’t  show  the  coder  the  drawing,  that  makes  it   too  easy,  we’re  trying  to  simulate  real  coding   4.  Tester  points  out  ‘defects’  for  programmer  to  fix   immediately     5.  How  long  did  it  take?  Is  the  customer  happy?   6.  How  did  that  feel  compared  to  Itera)on  1?        
11. 11   Automation
12. Skill:    Technical  Awareness •  Programming  concepts   •  High  level  architecture   •  IDEs,  other  tools   •  Database  knowledge   •  Maintaining  test  environments   •  Domain  knowledge  
13. Agile  Tes5ng  Pyramid push   the   tests   lower   Automate  at   the  feature   level   Automate   at  the  story   level   Automate   at  the  task   level  
14. Test  Technical  Debt  Volcano From  Mad   Barcomb  
15. •  Enables  testers  /   business  to  define  tests   •  test  code  can  be  in   programming  language   •  Programmers  can  run   tests  as  they  code   •  Testers  can  ask   programmers  for  help   •  Takes  )me  from  ‘coding’   produc)on  code   •  Tests  are  usually  through   the  UI   •  Programmers  aren’t   usually  willing  to  help   •  Tests  are  implemented   aQer  the  code  is  wriden   •  Testers  create  and   implement  all  tests  
16. Teaching  Method:    Team  Collabora5on 16   •  Based  on  real  problem   •  To  get  understanding     •  Can  we  think  of  an  easy  story  to  automate  –  and  have   team  discuss  what  tests  need  to  be  run.    Or  maybe  supply   some  scenarios  /  examples….     •  Where  should  they  run?  –  what  level.   •  What  should  be  automated   •  What  should  be  run  manually?  
17. Exercise:    Discussion 17  
18. 18   Testing Techniques
19. Skill:  Test  Techniques  -­‐  Communica5ng • Use  models  for  communica)ng   •  To  internal  team  members   •  To  external  stakeholders   • Use  models  for  visibility   • Use  models  as  a  thinking  tool   • Use  models  to  get  a  common  language  
20. Teaching  Method:  Models Pictures  are  worth  a  thousand  words  “they  say”,   so  ..              Instead  of  talking  about  tes)ng  in  terms  of                Gray  box,  white  box,  black  box                or  gejng  hung  up  on  terms  like                Valida)on  vs.  verifica)on     Let’s  make  our  tes)ng       VISIBLE    
21. Agile  Tes5ng  Quadrants  (original  by  Brian  Marick)
22. Gojko  Adzic’s  adapta)on  
23. Examples  of  quality  aOributes 23
25. Exercise:  Group  Collabora5on 1.  Write  the  types  of  tes)ng  you  do  in  your  team   2.  One  per  s)cky  note   3.  Discuss  in  your  groups  whether  Gojko’s   adapta)on  fits  beder  to  your  way  of  working,   or  Brian  Marick’s  version   4.  Place  your  tes)ng  types  in  one  of  the  models   in  the  quadrant  you  think  fits  best.  
26. 26   Exploratory Testing
28. •  Know  your  customers   •  Make  them  real   •  Plan  your  exploratory   tes)ng  using  them   •  Picture  –  from  Jeff  Padon’s   Pragma)c  Personas  weekly   column  on  S)cky  Minds   (1/25/2010)   28   Personas
29. Charters  …  different  ways 29   Explore  edi)ng  profiles     With  invalid  usernames   To  discover  if  there  are  any  instances  where   username  constraints  are  not  enforced     Analyze  the  edit  menu  func)onality  of  Product  X,   and  report  on  areas  of  poten)al  risk  in   Windows  8  OS.  
30. Teaching  Method:  Pairing,  Coaching • Create  pairs  or  small  groups  (of  3  –  maybe  4)   • Preferably  one  who  has  a  good  understanding   of  exploratory  tes)ng   • And  one  is  anxious  to  learn  more  
31. Teaching  Method:  Pairing,  Groups Each  pair  or  group   • Choose:     •  a  website  (paper  based)   •   or  a  game   •  The  ATD  conference  website   • Create  a  charter(s)  –  perhaps  using  a  persona   • Now  try  it   •  Don’t  forget  to  coach  each  other  and  ask  ques)ons   • Remember  to  take  notes  
32. 32   Eliciting requirements Asking questions
33. Skill:  Asking  ques5ons  to  build  the  right  thing 33   It’s  about  gejng  a  shared  understanding  of   what  you  are  building     •  Example  mapping   •  7  dimensions  
34. func5onal nonfunc5onal www.DiscoverToDeliver.com/visual-­‐language.php   Source: Discover To Deliver, Gottesdiener & Gorman, 2012
35. •  To  elicit  requirements   •  To  reduce  uncertainty   •  To  test  people’s  understanding  of  the  requirement   35   Use  examples  ….. Credit  and  thanks  to  Brian  Marick   “That’s  not  right”    can  be  music  to  your  ears   Examples  ….. •  Can  become  the  actual  tests   •  Are  a  form  of  specifica)on  
36. Teaching  Method:  Training  Simula5on   36   Think  about  the  roles  in  your  group   •  PO/customer   •  Programmer   •  Tester,  BA   •  Designer   Goal:  Build  shared  understanding  of  a  story    
37. 37   As  the  security  dude,   I  want  to  enforce  strong  password   rules  for  customer  log-­‐in   So  that  we  have  limited  risk  for   idenBty  theD  
38. Exercise:  Example  mapping 38   1.  Pick  a  partner  table  group   2.  Using  the  blue  index  cards,  write  3  business  rules   for  “Create  a  strong  password”  story   3.  Write  3  examples  to  express  those  rules   4.  Now  pass  them  to  your  partner  table   5.  Guess  the  rules  based  on  the  examples  –  write   them  on  s)cky  notes,  and  pass  them  back.   6.  Stop  and  reflect  
39. Exercise:  Example  mapping  con5nued 39   Write  more  examples  to  clarify  the  rules  –  s)ll  no   conversa)on  except  yes  or  no.   •  Pass  them  and  forth  back  to  your  partner  table   trying  to  guess  the  rules.     Now  you  can  have  the  conversa)on  
40. Stop  and  Reflect 40   What  did  this  exercise  show  you?     What  did  you  learn?     Are  rules  or  examples  beder?   Why  or  why  not?  
41. 41   Example  mapping  -­‐  a  discovery  workshop
42. As  the  security  dude,  I  want  to  enforce  strong   password  rules  for  customer  log-­‐in,     So  that  we  have  limited  risk  for  idenBty  theD   Examples  of  what  you  might  have  done 42   Story   Rules   Examples   Ques)ons   1.  At  least  8  characters  long   2.  Maximum  of  32  characters   3.  Contains  at  least    1  special  char  and  1  number   Valid:  p4ssw0rd!,  pa55w#rdp   Invalid:  P4ssw0rd1,  p4ssw@d   Where  to  put  focus  if  an  invalid  password  is  entered?   What  happens  if  they  have  a  certain  number  of  invalid   passwords?