In this webinar, Kevin looks at 10 simple improvements in the way we work which mean that we’re now either catching bugs before they get to the test environment, or, even better, preventing them from happening in the first place. View webinar recording - https://testhuddle.com/resource/striving-zero-bugs-test-environment/

1. Striving for
Zero Bugs
(On the Test Environment)
Kevin Harris
NewVoiceMedia

2. Introduction
So - why are we here..?

3. What’s so wrong about Raising Bugs?
Raising Bugs is a faff and is a huge
waste of time, and I’m too old and
bitter to spend an hour at a time
recreating bugs and filling in forms
which no one wants to read.

4. The Proposal:
We are now at a stage where it should
be possible to either prevent or find
all bugs* before the code actually gets
to the Test Environment.
* Well, nearly all…

5. Step 1: The Kick Off (1)
REQUIREMENT OVER SOLUTION
 Make sure you understand the requirement before
anyone starts discussing a solution.
 Use a version of Business Driven Development or
Specification By Example to ensure that you’re
concentrating primarily on the actual requirement
(and not on the solution).

6. Step 2: The Kick Off (2)
SMALL STORIES
 Make sure that your stories are as small as you
can make them (but still big enough to be
worthwhile).
 The ideal story has only a single moving part –
test that, then test the next moving part in the
next story.
 Think about how you slice bigger stories.

7. Step 3: The Kick Off (3)
ASK, ASK, ASK
 Be prepared!
 Don’t be afraid to ask questions. That’s your job
in the Kick Off.
 Keep asking until you have all the information
that you need to test the story – don’t wait until
you get the code delivered.
 What about security, performance, usability, etc?

8. Step 4: The Kick Off (4)
TELL, TELL, TELL
 What you’re going to test.
 How you’re going to test.
 What tools you’re going to use.
 What areas you’re going to regression test.
 Don’t keep information back for when you start
testing…

9. Step 5: The Kick Off (and beyond)
TEST AUTOMATION
 What automated tests are going in, and at what
level?
 Review them often, and suggest more.
 Ensure your acceptance criteria are automated.
 Watch the tests run.

10. Step 6: Development (1)
KEEP UP TO DATE WITH DEV
 Check in with the Developers at least every day.
 Get demos whenever there is something worth
demoing.
 Pair with the Developer for longer periods where
possible.

11. Step 7: Development (2)
TEST ON THE DEV MACHINE
 Physically pair with the Developer to test on the
Dev machine.
 Arrange access to test on their VM remotely.

12. Step 8: The Hand Over
IT’S NOT JUST A HAND OVER!
 Get a final demo on the Developer’s machine.
 Discuss any areas of risk
 Review the acceptance criteria one last time.
 Review the automated tests one last time.

13. Step 9: In General
EVERYBODY TESTS
 Ensure Developers are confident testing.
 Let Developers test other stories (pairs and solo).
 Teach the Developers testing techniques.
 Pair test with Developers.
 Get developers to talk you through how they
tested their code.

14. Step 10: The Test Environment
WHEN YOU DO FIND A BUG
 Don’t celebrate finding bugs!
 Examine why you didn’t prevent the bug, or find
it earlier.
 Have a 5-Whys for every bug you find on the Test
Environment.

15. Benefits:
Cleaner Code.
Quicker cycle time.
Functionality sooner.
Cheaper.
Can consider losing an environment.

16. What Could Possibly Go Wrong?
A Couple of things…
 Won’t be able to pick up all deployment errors.
 Won’t pick up environmental issues.
 Change in behaviour required for some people!

17. Thank You.