Upload
test-huddle
View
407
Download
0
Embed Size (px)
Citation preview
Striving for Zero Bugs(On the Test Environment)
Kevin HarrisNewVoiceMedia
IntroductionSo - why are we here..?
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.
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…
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).
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.
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?
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…
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.
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.
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.
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.
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.
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.
Benefits:
Cleaner Code.Quicker cycle time.Functionality sooner.Cheaper.Can consider losing an
environment.
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!
Thank You.