collaboration techniques: combining new approaches with ancient wisdom

TN PM Tutorial

4/30/13 1:00PM

Collaboration Techniques: Combining

New Approaches with

Ancient Wisdom

Presented by:

Rob Sabourin, AmiBug.com

Dorothy Graham, Software Test Consultant

Brought to you by:

340 Corporate Way, Suite 300, Orange Park, FL 32073

888-268-8770 ∙ 904-278-0524 ∙ [email protected] ∙ www.sqe.com

Rob Sabourin

Rob Sabourin, P. Eng., has more than thirty years of management experience leading teams of software development professionals. A well-respected member of the software engineering community, Rob has managed, trained, mentored, and coached hundreds of top professionals in the field. He frequently speaks at conferences and writes on software engineering, SQA, testing, management, and internationalization. Rob wrote I am a Bug!, the popular software testing children's book; works as an adjunct professor of software engineering at McGill University; and serves as the principle consultant (and president/janitor) of AmiBug.Com, Inc. Contact Rob at [email protected].

Dorothy Graham In testing for more than thirty years, Dorothy Graham is coauthor of four books—Software Inspection, Software Test Automation, Foundations of Software Testing, and Experiences of Test Automation: Case Studies of Software Test Automation. Dot was a founding member of the ISEB Software Testing Board, a member of the working party that developed the first ISTQB Foundation Syllabus, and served on the boards of conferences and publications in software testing. A popular and entertaining speaker at conferences and seminars worldwide, she has been coming to STAR conferences since the first one in 1992. Dot holds the European Excellence Award in Software Testing. Learn more about Dot at DorothyGraham.co.uk.

presented by Rob Sabourin and Dot Graham [email protected] [email protected]

© Robert Sabourin & Dorothy Graham 2013 www.AmiBugShare.com

www.DorothyGraham.co.uk

1

Forgotten Wisdom from Ancient Testers

Star East 2013, Orlando, Florida

Dorothy Graham [email protected] www.DorothyGraham.co.uk

Robert Sabourin [email protected] www.AmiBugShare.com

© Dorothy Graham, Robert Sabourin 2013

2

Forgotten Wisdom from Ancient Testers •  Collaboration has become a new testing cliché. But it is hard to do. Testers are challenged

to work directly with customers, programmers, business analysts and other stakeholders. They have less time with more at stake. They must apply skills outside their experience, knowledge and comfort zones.

•  Dorothy Graham (Dot) and Robert Sabourin (RobSab) have fostered excellent collaboration applying wisdom of some ancient testing concepts, born in the dark ages of software engineering, methods from a forgotten era of turbulence, flakey technology and overtly ambitious project managers.

•  “Static testing” practices like inspections, reviews and walkthroughs helped teams systematically learn, explore and evolve, by identifying concerns, and redirecting or refactoring development efforts as early as possible in lifecycles. Dot and Rob show how they have managed to capture excellence, identify weakness and learn from mistakes as part of testing tasks through interactions between team members, stakeholders and other unlikely contributors too.

•  Understand client needs and values by grooming stories. Brainstorm with programmers about design solutions and associated technical risks. Pair up with programmers, to focus on what can break, with other testers to avoid rat holes and with domain experts to assess correctness. Use examples to anchor understanding and highlight differences.




3

Contents

•  Objectives for today •  Some collaboration stories

– Software reviews at Sun Soft – Story grooming at Maple Solutions

•  Exercise •  More stories

– Buddy checks at Med Soft – Exploratory testing at Mud Slide

•  Concluding remarks

4

Objectives for today

Share experiential stories

Seek lessons from the past

Encourage wise practices




5

Software Reviews at Sun Soft

•  Desktop product development •  Merged from dozens of diverse sources

Business Context

•  Blend new & legacy technologies •  Frail code, huge regression risks

Technical Context

•  24 concurrent synchronized Scrum teams •  2 major releases per year

Development Lifecycle

6

Objectives and reviewers at SunSoft •  Clear objectives

–  break legacy code? –  conform to standards? –  features using modified

legacy code? –  focus regression testing

•  All changed code reviewed by architect team –  know the history and

evolution of the code base

•  Good objectives –  critical for review success –  use static analysis tools

to check vs standards? •  Choice of reviewers

–  Experts in this system – best choice

–  Dependence on individuals?

•  time / availability •  bus syndrome? •  (checklists)




7

Author’s role at Sun Soft •  Author did not

participate in the review –  not familiar enough with

the legacy code –  author corrects any

defects identified –  changes re-reviewed

•  Recommended more involvement of authors

•  Excluding the author is not good (in general) –  often done for the wrong

reasons –  author has the most to

learn –  author may also find the

most defects

8

Other aspects at Sun Soft •  Quick feedback (hours)

–  suggested improvements –  specific risks identified

•  Very successful –  minimized risk of

changes destabilizing legacy code

•  especially by new developers not familiar with the legacy system

•  Considered “anti-agile”

•  Feedback quickly for greatest benefit

•  Reviews have always been one of the most successful quality techniques –  and still are –  applied for your current

context –  even in agile!




9

Contents






10

Story Grooming at Maple Solutions

•  Pioneer in virtual technologies •  Small technology driven venture

Business Context

•  All the latest technologies •  No legacy code •  Robust automated regression testing

Technical Context

•  One Scrum team •  Blends support and new development





11

Story Grooming at Maple 1 •  Goal: improve stories

–  high priority stories –  groomed before

implementation •  Time-boxed

–  fixed amount of time –  ok to not cover all stories

in one session •  Lack of information kills •  Get team buy-in

–  all participate –  BA facilitates meeting

•  Goal is good –  timing of session (not too

early or too late) •  Time spent

–  do most important stories first (in case not all covered)

•  Check readiness before •  Team participation good

–  dual role for BA, both needing full attention?

•  independent facilitator?

12

Story Grooming at Maple 2 •  Understand, clarify

–  clear up ambiguities –  clarify description –  compare existing function –  defined questions –  explore alternative

interpretations •  Elicit acceptance tests

–  examples from product owner

–  normal, alternative and error paths

•  How to do it –  compare to existing

functionality –  what about other stories,

previous changes, affected areas

–  gives objectivity –  alternatives: potential

mis-understandings •  Acceptance tests

–  also helps to clarify & understand




13

Story Grooming at Maple 3 •  Estimation

–  team sizes the story/stories –  decide whether to postpone

or pull a story •  Team building

–  teams works to all 4 objectives

–  all work is considered –  team buy-in –  changes implemented at

the time

•  Estimation problems? –  all necessary information

for estimation? –  right people there?

•  Teamwork –  good team spirit is worth

a lot –  have fun!

–  look back at the changes later (“sleep on it”)?

14

Contents









15

Contents






16

Buddy Checks at Med Soft

•  Software for diagnostic medicine •  Used by clinicians at the point of care

Business Context

•  Code base primarily C++ and Delphi •  Supports multiple database engines

Technical Context

•  2 Scrum teams •  Blends support and new developments





17

Buddy Checks at Med Soft 1 •  On check-in

–  author invites peer to review

•  Approach –  author explains context –  highlights and walks

through changes –  compare to relevant story

or bug report

•  Who to review? –  knowledgeable & friendly –  author needs to be ready

& happy with reviewer –  enough expertise? –  “preference war” –  ”pair-think”

•  Approach –  walkthrough of context –  strongest feature:

compare to other artifacts

18

Buddy Checks at Med Soft 2 •  Changes

–  required changes are acted upon on the spot

•  Identify risks –  changes done well? –  does artifact suit its

purpose? –  any superfluous changes

made?

•  Change now? –  good: done done –  but: “sleep on it” can help

to see other things •  Risks

–  prioritize by risk –  focus the review on

important stuff




19

Buddy Checks at Med Soft 3 •  Ask questions

–  how does this change solve the problem?

–  does it introduce new concerns?

•  Discuss alternatives –  what other approaches

were considered? –  why was this chosen?

•  Build process –  build breaks if peer

review was not done

•  Questions & alternatives –  asking questions gives

focus, finds different bugs –  “challenging” mentality –  also ask: what else might

be affected? •  Required

–  part of the process –  beware “lip service”

•  Missing? –  capture the best ideas,

learn from what’s missed

20

Contents









21

Exploratory Testing at Mud Slide

•  Server product development •  Acquired by a domain giant

Business Context

•  Spaghetti code •  Code share inconsistently across product areas

Technical Context

•  4 concurrent synchronized Scrum teams •  Constant conflicts in development across teams


22

Exploratory Testing at Mud Slide 1 •  Charter

–  mission statement of testing

–  scope of testing –  ties testing to purpose

•  Kickoff –  tester and developer

have short meeting –  review goals –  adapt to changing

context

•  Charter –  gives focus to what is

important

•  Kickoff –  reminder of what to look

at, how to do it –  opportunity for questions,

clarifications




23

Exploratory Testing at Mud Slide 2 •  Timing

–  session is time-boxed –  testing pauses after time

expires

•  Review –  immediately after session –  review the findings,

session notes & bugs –  ambiguities? –  missing information?

•  Stopping criteria –  stop when time’s up? –  better to decide at the

start what is DONE for this charter

•  Review –  done while still fresh –  focus on ambiguity,

clarity, omissions –  how do you know what is

missing? •  compared to what? •  story, other artifact

24

Exploratory Testing at Mud Slide 3 •  Next step

–  additional testing sessions needed?

–  have we learned enough?

–  different charter now?

•  Consolidate findings –  repository of findings –  gather information &

metrics to improve effectiveness & efficiency

•  Next step –  objective criteria for

deciding if more sessions –  planned with charter

•  Quality of findings –  quality of findings from

different sessions? •  template, guidelines •  collect exemplary

examples

–  use opportunity to critique, coach and teach




25

Concluding remarks

Agile collaboration is key

Wisdom from ancient technique

It’s all about people

26

•  Comments … •  Concerns … •  Share collaboration

stories …

Questions …

Thank you

[email protected] www.DorothyGraham.co.uk

[email protected] www.AmiBugShare.com

collaboration techniques: combining new approaches with ancient wisdom

Technology