About
Everyone involved in developing a product brings different perspectives to testing it. Developers wrote the code, so they have unique knowledge with which to test that. Testers didn’t write the code, so they are uniquely motivated to learn things about the product so they can test it. Some people who test are coders, so they find it natural to write code to help themselves find more problems. Other people who test are not coders, so they find it natural to see the product from the point of view of the business, or of the users.
In this two-day, interactive workshop, Michael Bolton will show you how these perspectives can be observed and practiced through four frames: Intention, Discipline, Testability, and Realization. Each of these is a context for testing activity. Developers and managers tend to focus on testing as contributing to the discipline of good development. While worthy, this goal pushes testing towards automatable output checks that find only shallow, easy bugs at the unit or component level. Testers (and users) focus on the actual, completed, built, realized product — and things that contribute to or threaten its value. This perspective both requires and encourages deeper testing that may be hard to fit into a continuous delivery regime.
The differences between perspectives create tension. But when properly managed, the tension is creative and helpful — and it doesn’t have to be a battle, nor does it have to slow down testing or development. When those roles are working alone, testing suffers, but the different perspectives taken together make for stronger testing that finds important problems quickly. We can work together better if we understand and appreciate what we all contribute. We can cooperate without co-opting each other.
Course contents
What Will Happen in the Class
This class is taught Socratically, with exercises, discussions and illustrations of analysis, strategy, tooling, and testing within the RST methodology. Class discussions and debate address students’ questions and specific needs. We encourage you to question and challenge the material at any time. We all learn from the unique perspective that each student brings to the class. We invite you to bring real examples of testing problems and test documents to class. We are happy to show you how a rapid tester would work through them.
Main Topics Covered:
- The Agile / Rapid Testing Grid: four perspectives on performing and evaluating testing work
- Shallow testing — quick, efficient testing that has a chance of finding every easy bug
- Deep testing — testing that maximizes the chance of finding every elusive bug that matters
- Testing vs. checking: contrasting things that can’t be automated with things that can
- Demonstrations of creative ways to apply tools to testing
- Analysis of where testing time goes and why testing seems to take so long
- An exercise in test strategy, contrasting developer and tester approaches for working with an API and finding problems in it
- An exercise in analyzing and testing an existing product
- How tools can help in primary testing, deeper testing, and regression testing
- The secret life and hidden costs of automation in testing work
- Thinking critically about “ROI” — really cost, value, and risk — of various kinds of automation and tooling
Target audience and prerequisites
Who Should Attend
Whether you are a tester, developer, designer, or manager, this workshop is for you. Through the lenses of Rapid Software Testing, you’ll learn how and why developers think about testing in one way, while dedicated, serious testers think very differently about it. Then, through hands-on exercises, role plays, and discussion, you’ll learn how to get the best of both worlds.
- If you’re a developer working with testers, we will help you to discover new perspectives on how you can help testers and how testers can help you.
- If you are developer working without a dedicated tester on the team, we will help you to develop strategies for doing deeper testing quickly, inexpensively, and painlessly — and for getting the most out of other people to help you test.
- If you are a tester who does code, you are welcome and encouraged to bring your coding skills and tools to the class. We will help you see many ways of applying them to testing.
- If you are a tester who does not code, we will help you understand possibilities and challenges of creating tools and automation to help you test. Note that we won’t try to teach you to code in this class, but we will help you to learn to ask for what you need.
- If you are a quality coach or manager who is responsible for test strategy, we will help you create strategies that take full advantage of the skills on your team, and that avoid the common traps.
- If you are from an organization that is struggling in applying automation, we will help you understand your situation and form a plan to improve the situation.
- If you are a supporter of skilled, responsible testing, and you feel that you are under attack by technologists who think they can automate everything, we will help you defend your team and your work.
- No matter who you are, we’ll help you to learn ways of working collaboratively to identify misunderstandings, errors, problems, and bugs as early as possible — before they cause trouble down the line.
About the Authors
Michael Bolton is a consulting software tester and testing teacher who helps people to solve testing problems that they didn’t realize they could solve. In 2006, he became co-author (with James Bach) of Rapid Software Testing (RST), a methodology and mindset for testing software expertly and credibly in uncertain conditions and under extreme time pressure. Since then, he has flown over a million miles to teach RST in 35 countries on six continents.
Michael has over 30 years of experience testing, developing, managing, and writing about software. For over 20 years, he has led DevelopSense, a Toronto-based testing and development consultancy. Prior to that, he was with Quarterdeck Corporation for eight years, during which he managed the company’s flagship products and directed project and testing teams both in-house and around the world.
Contact Michael at michael@developsense.com, on Twitter @michaelbolton, or through his Web site, http://www.developsense.com.
The class is co-written with James Bach, a developer-turned-tester involved with testing and automation since 1987, and the creator of the Rapid Software Testing methodology. James was a co-founder of the Context-Driven School of software testing thought, which focuses on skills and problem-solving, rather than rote formalization of technical work. He is the author of Secrets of a Buccaneer-Scholar, and a co-author of Lessons Learned in Software Testing.
James works with project teams and individual engineers, coaching them in testing and testability advocacy, among other things. He has also been an expert witness on court cases that involve the need to test software products (such as in patent infringement or trade secret cases), or to analyze test processes.