There are a variety of steps that you may approach linearly or by hopping about to those that interest you most. It is a little different to the other testing pathways as it is:
- Specifically for non-testers
- Designed to help people with immediate questions like "How do I decide what to test?"
- Does not include exercises, instead assuming that the provided resources will be applied in practical situations within your development team
STEP - Why non-testers should be involved in testing
Agile development teams generally seek shared ownership of quality. In order to achieve this, the tester may have to yield some control and others in the team may need to be more willing to pick up testing activities. These teams want to move away from the tester as the only person who tests, towards an environment where the tester leads testing and empowers others to contribute too. These articles describe the shift in thinking towards testing as a shared activity:- 2011 - Testing is a whole team activity - Elisabeth Hendrickson
- 2013 - Agile Testing Mindset (slides) - Samantha Laing & Karen Greaves
- 2011 - Game - Test small, test often - Nanda Lankalapalli
- 2009 - Ten Principles for Agile Testing - Lisa Crispin & Janet Gregory
- 2014 - We're going to test like it's 1999 - James Whittaker
STEP - How to make an application testable
As developers and business analysts, the easiest first step to aid testing of the product is to understand the attributes that make it testable. Changing the way you specify solutions and design software can have significant impact on a tester's ability to verify and explore what is delivered. Learn to consider the various facets of testability:- 2002 - Design for Testability - Bret Pettichord
- 2012 - Design for Testability - George Dinwiddie
- 2015 - Heuristics of software testability - James Bach
- 2012 - Putting your testability SOCKS on - Adam Knight
STEP - How to decide what to test
When asked to pick up a testing task, the non-tester may wonder where to begin. Testers are often poor at explaining how they test an application, which can make testing seem like magic. In fact, testers will have their own set of testing heuristics, whether they can articulate them or not! Fortunately there are resources that provide common test heuristics to help you determine which tests you'd like to perform, or prompt you to think of your own ideas beyond these boundaries:- 2006 - Test Heuristics Cheat Sheet (PDF) - Elisabeth Hendrickson
- 37 sources for test ideas - Rikard Edgren, Martin Jansson and Henrik Emilsson
- 2010 - You are not done yet (PDF) - Michael Hunter
- 2010 - A software expert's heuristic for regression testing - Karen N. Johnson
- 1996 - Heuristic Test Strategy Model (PDF) - James Bach
- 2005 - Touring Heuristic - Michael D. Kelly
- 2005 - Testing without a map (PDF) - Michael Bolton
STEP - How to document your test ideas
One deterrent for a non-tester to test may be your perception of the amount of documentation required. Within your development team, the testers are likely to have an approach that you can adopt. However there may be freedom for you to utilize lightweight documentation to map out your thinking. Perhaps to simplify what you need to do, a tester might transfer your results into the wider ecosystem of test artifacts afterwards. These articles give practical examples of using mind mapping software for test planning and execution:- 2011 - Mind mapping 101 - Darren McMillan
- 2013 - Visual Test Models - Leah Stockley
- 2014 - Using mind-mapping software as a visual test management tool - Aaron Hodder
- 2014 - Three examples of visual test coverage modelling - Katrina Clokie
STEP - What to think about while testing
Testing isn't just about picking up and blindly applying the heuristics of others. When interacting with the software you may also want to consider what user persona to adopt, what bugs to raise, and what test evidence to collect. Though many of these decisions will be driven by collaborative interaction with your development team, these resources may help you understand the possible compromises being made and approaches that are possible:- 2009 - When do we stop a test? - Michael Bolton
- 2015 - The girl who cried wolf: Picking your battles - Nicola Owen
- 2014 - Generic Testing Personas - Katrina Clokie
- 2013 - 10 experiments to improve your exploratory testing note taking - Alan Richardson
- 2015 - Pair Testing - Katrina Clokie
STEP - How to debrief
A key aspect of getting non-testers to pick up test activities is following up with a post-testing debrief. This provides an opportunity for the tester and the non-tester to sit together and spend a few minutes discussing the testing activity that has occurred. These resources provide common questions that may be asked during a debrief:- 2009 - Questions to help clarify test status - Michael Kelly
- 2011 - Questions to ask during debriefs - Markus Gartner
- Session Debrief Checklist - James Bach
STEP - Where to automate
Finally, you may be asked to contribute towards automation. Agile teams will usually require automated checks to support their rapid delivery cycles so that testers have time to understand new functionality, explore the application and find interesting problems. These articles describe factors to consider when determining what to automate, where to implement and how to interpret the results:- 2015 - Hitting the pothole of trying to automate everything - Paul Holland
- 2009 - Agile anti-pattern: Using manual tests - Bob Hartman
- 2012 - Test pyramid - Martin Fowler
- 2015 - On red and On green - Michael Bolton
- 2008 - Agile-friendly test automation tools and frameworks - Elisabeth Hendrickson
- 1998 - When should a test be automated (PDF) - Brian Marick
No comments:
Post a Comment