Seek  where  you  can  add  value,  deliver  it  and  make  it  visible    Published  in  “the  little  book  of  testing  wishdom-­‐  25  Tips  from  Friends  of  EuroSTAR”-­‐  December  2017.  See  also  https://conference.eurostarsoftwaretesting.com/25-­‐years-­‐eurostar-­‐pocketbook/  

   The  most  constant  advice  that  I  have  been  given  over  the  previous  year  is  beyond  doubt  to  seek  where  you  can  add  value,  deliver  it  and  make  it  visible.  In  order  achieve  this  we  need  to  align  with  our  stakeholder  and  find  out  what  they  need.  This  advice  seems  to  run  like  a  common  thread  through  all  my  publications  and  presentations.  In  this  article  I  share  some  tips  on  how  to  implement  this  advice  and  explain  the  value  it  has  within  modern  software  development.    I  am  a  professional,  take  me  serious  When  I  started  testing  in  1997  the  profession  had  a  strong  focus  on  methods  and  techniques.  The  community  did  quite  an  effort  to  organize  and  structure  the  trade.  Test  plans,  risk  assessment,  test  design  techniques  and  a  proper  process  seemed  natural  components  in  this  period.  The  “I  am  a  professional  tester  and  want  to  be  taken  seriously”  cry  was  dominant.  In  order  to  be  taken  seriously  we  tried  to  become  better  organized  in  our  testing.  By  2005  I  stated  that  rather  than  improve  the  testing,  I  wanted  to  improve  our  recognition.  The  quality  of  our  testing  wasn’t  the  bottleneck,  the  way  we  could  convince  our  added  value  to  the  organization  was.    My  first  book  “TestGoal”  (SDU  2007,  Springer  2008)  was  my  aim  to  define  the  attitude  of  the  result  driven  tester  who,  rather  than  follow  the  textbook,  aims  to  contribute  to  the  project  goal.  The  book  introduces  ten  principles  (see  figure  1)  that  are  used  throughout  the  book  to  show  how  various  test  activities  contribute  to  the  goals  of  the  organization.  If  we  master  our  profession,  build  trust.  If  we  collaborate  with  various  disciplines  in  order  to  provide  overview  and  insight  throughout  the  ICT  lifecycle  we  can  convince  them  of  our  place  within  software  development.    

   

Figure  1:  Test  principles  defining  the  attitude  of  a  result  driven  tester  

 We  can  be  heroes  With  the  first  book  I  was  trying  hard  to  bridge  the  business-­‐IT  gap.  Reaching  out  to  our  stakeholders,  but  still  reasoning  from  the  testers  perspective.  The  book  “Grip  on  IT  -­‐  The  hero  that  guards  my  nightly  rest”  (Academic  Services,  2011)  corrects  that.  It  promotes  the  personal  approach  which  is  typical  for  Valori:  Recognize  that  stakeholders  have  worries  and  fears  that  influence  how  they  look  at  testing  and  that  have  a  great  influence  on  the  decisions  they  make.  We  can’t  ignore  these  factors.  Let’s  take  their  needs  as  starting  point.  Talk  about  testing  in  a  way  that  relates  to  their  world.  E.g.  Don’t  talk  about  risks,  but  ask  stakeholders  for  “the  bugs  you  do  not  want  to  find  in  production”  (TBYDWTFIP)  or  to  explain  their  worst  nightmare.  Let’s  not  talk  about  passed  test,  but  try  to  eliminate  their  worries.  Testers  can  be  hero’s  if  they  carefully  listen  to  their  stakeholders  and  if  they  show  how  they  try  to  fulfilling  these  needs.  This  is  depicted  in  figure  2.  The  approach  enables  testers  to  explain  how  their  activities  like  risk  analysis,  reviews,  test  sessions  and  clear  reporting  are  to  the  advantage  of  the  stakeholders  since  they  provide  overview,  insight  and  comfort.  When  stakeholders  are  convinced  they  personally  benefit  by  our  work  they  support  it  and  give  us  the  commitment,  time  and  the  chance  to  do  even  a  better  job.    

     Figure  2:  Testing  with  the  stakeholder’s  goals,  needs,  worries  and  fears  as  both  a  starting  and  end  point.    Agile  Testing  A  lot  has  changed  since  then,  but  in  agile  development  we  still  need  to  align  with  our  stakeholders.  Testing  has  become  a  responsivity  of  the  whole  development  team.  Many  testers  wonder  what  their  role  is  now  that  everyone  is  testing.  The  advice  that  I  gave  over  the  years  still  holds  today.  We  should  master  the  profession,  no  doubt.  But  stakeholders  should  experience  that  we  add  value.  Agile  development  gives  us  many  opportunities  to  make  them  do  so.    

When  the  whole  team  is  testing,  testers  can  shift  our  attention  from  execution  to  guiding  the  team.  Free  some  time  and  start  a  dialogue  with  your  stakeholders  in  order  to  translate  their  needs  into  tests  that  we  could  do  as  a  team.  A  lot  of  our  tests  will  be  automated,  but  we  still  should  be  able  to  explain  why  we  invest  in  writing,  maintaining  and  executing  those  tests.  This  requires  good  insight  in  what  tests  have  value.  These  can  be  user  centered  tests  but  among  our  stakeholders  are  also  compliance  and  security  officers  that  demand  other  tests.  Testers  can  guide  the  team,  ensure  that  the  right  tests  are  done  and  even  coach  the  developers  so  they  do  a  good  tester’s  job.    With  two  week  sprints  it  is  much  easier  to  run  through  the  five  steps  that  are  depicted  in  figure  2.  With  each  sprint  review  we  get  the  chance  to  tell  our  tester’s  story.  Do  not  only  demo  the  new  features,  but  explain  how  the  teams  ensures  quality.  Not  by  just  referring  to  the  definition  of  done,  but  to  be  transparent  about  the  activities  we  undertook  and  how  these  align  with  the  risks  or  worries  that  the  stakeholders  shared  with  you.  Review  sessions  are  a  good  platform  to  initiate  a  dialogue.  A  great  thing  about  the  agile  approach  is  that  we  can  change  our  course  and  adapt  when  a  stakeholder  shares  a  new  need  or  concern.    Ideally  Scrum  teams  execute  all  tests  during  the  sprint.  In  practice  not  all  tests  fit  the  sprint.  I  have  been  in  many  organizations  where  integration,  security  and  performance  tests  are  organized  separately.  In  a  Scrum  of  Scrum  inter-­‐team  dependencies  are  discussed.  An  ideal  place  to  create  transparency  about  the  quality  and  progress.  I  use  subway  mapping  (figure  3)  to  create  overview  and  insight  and  to  trigger  discussions  and  take  action.    I  know  people  are  struggling  with  the  high  speed  and  short  cycles  in  agile,  since  they  lose  track  of  the  bigger  picture.    As  tester  I  have  overview  on  the  status  of  various  parts  of  the  system,  and  feel  appreciated  when  I  use  this  to  re-­‐assess  the  backlog,  address  dependencies  or  discuss  the  upcoming  release.        

     Figure  3:  Example  of  a  subway  map  used  to  create  transparency  to  the  quality  and  progress  of  the  upcoming  releases    

   Agile  development  provides  testers  with  another  great  opportunity  to  understand  our  stakeholders  and  that  is  during  refinement.  Testers  are  good  in  providing  examples  and  scenario’s  that  will  identify  undefined  situations.  Asking  critical  questions  may  lead  to  new  solutions  that  match  the  business  needs  better  than  the  initial  solution,  or  at  least  will  contribute  to  better  defined  user  stories.  Did  you  ever  ask  during  the  refinement  session  how  the  new  feature  should  be  tested  of  what  should  be  demonstrated  in  order  to  prove  its  quality?  Good  questions  that  often  startle  the  attendees.  Unnecessary  to  explain  that  these  “how  to  demo”  and  “how  to  test”  questions  are  a  great  starting  point  for  understanding  the  real  challenges  and  concerns  that  your  stakeholder  might  have.    A  great  piece  of  advise  Software  development  has  changed  a  lot  over  the  years  and  testing  has  evolved  with  it.  Organizations  have  become  more  value  driven.  Quality  is  embedded  in  the  approach  and  we  find  our  stakeholders  have  become  more  involved.  But  that  does  not  mean  that  we  ask  them  the  right  questions.  Even  in  agile  organizations  the  test  principles  that  are  depicted  in  figure  1  still  hold,  since  they  remind  us  to  keep  a  focus  on  the  result  and  build  bridges  to  our  stakeholders.    We  need  a  personal  approach  to  build  trust  and  we  should  keep  a  keen  eye  their  needs.  Stakeholder  alignment  means  that  they  understand  how  our  activities  contribute  to  their  goals.  In  short  we  need  to  seek  where  we  can  add  value,  deliver  it  and  make  it  visible.  If  we  do  this  right  we’ll  get  commitment,  time  and  resources  to  do  it  in  a  better  way,  to  further  improve  and  master  our  profession.  This  will  increase  the  perceived  value  we  deliver  as  team,  department  or  organization  even  further  and  give  us  more  fulfillment.  Let  me  close  with  referring  to  the  last  principle.  Testing  might  have  changed,  but  this  way  it  sure  is  fun!    Bio  Derk-­‐Jan  de  Grood  works  for  Valori  as  senior  test  manager  and  agile  coach.  He  helps  originations  with  their  Scrum  optimisation  and  embedding  the  agile  quality  strategy.  He  is  an  experienced  trainer,  workshop  host  and  a  regular  speaker  at  conferences.  He  wrote  several  successful  books  on  software  testing  and  frequently  publishes  articles  and  columns  for  the  major  magazines.  On  his  own  blog  he  shares  his  knowledge  and  experience  for  everyone  to  benefit.  In  2014  he  won  the  EuroSTAR  Testing  Excellence  Award.  In  2016  he  published  a  new  book:  Agile  in  the  real  world,  starting  with  Scrum.