DevelopsenseLogo

Agile Software Development and Rapid Software Testing

Michael Bolton: Agile Software Development and Rapid Software Testing

Over the last several years, a set of ideas and activities have been dumped into a big bucket called “Agile Software Development”. Agile development has hit mainstream recognition. Yet there is often uncertainty and turmoil around what “Agile development” means, in theory and in practice, and the confusion affects Agile projects and the people in them. There have been some discussion points, such as Mike Cohn’s Agile Testing Pyramid and Marick, Crisipin and Gregory’s Agile Testing Quadrants, and many people have found them helpful. Yet James Bach and Michael Bolton, authors of Rapid Software Testing, still hear testers expressing a good deal of pain over the role of the tester and the structures of testing activity in Agile projects.

Rapid Software Testing (RST) is a skill set and a mindset focused on doing the fastest, least expensive testing that still completely fulfills the mission. From RST’s perspective, testing is testing and Agile is context. Whether you adopt RST, working in Agile contexts, or neither, or both, Michael Bolton will provide observations and advice on how to adapt your testing to fit mission context you’re in.
Bio

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. He is the co-author (with senior author James Bach) of Rapid Software Testing, a methodology and mindset for testing software expertly and credibly in uncertain conditions and under extreme time pressure. Michael has 25 years of experience testing, developing, managing, and writing about software. For almost 20 years, he has led DevelopSense, a Toronto-based testing and development consultancy.

Presented by esterzy.pl

Four (and More) Questions for Testers to Ask

Testers investigate problems and risk. Other people manage the project, design the product, and write the code. As testers, we participate in that process, but in a special way and from a special perspective: it’s our primary job to anticipate, seek, and discover problems in products. It’s probably a good idea to clear up some possible ambiguity here. When I’m talking about a product, I’m talking about anything that some … Read more

(At Least) Four Things for Testers To Do in Planning Meetings

There’s much talk these days of DevOps, and Agile development, and “shift left”. Apparently, in these process models, it’s a revelation that testers can do more than test a built product, and that testers can and should be involved at every step of development. In Rapid Software Testing, that’s not exactly news. From the beginning, we’ve rejected the idea that the product has to be complete, or has to pass … Read more

On a Role

This article was originally published in the February 2015 edition of Testing Trapeze, an excellent online testing magazine produced by our testing friends in New Zealand. There are small edits here from the version I submitted. Once upon a time, before I was a tester, I worked in theatre. Throughout my career, I took on many roles—but maybe not in the way you’d immediately expect. In my early days, I … Read more

A New Agile Testing Ecosystem

A New Agile Testing Ecosystem – EuroSTAR – Michael Bolton

Over the last several years, a set of ideas and activities have been dumped into a steamer trunk called Agile software development. Agile development has hit mainstream recognition, even though there is often uncertainty and turmoil around what “Agile development” means, in theory and in practice—and that uncertainty and turmoil affects Agile projects and the people in them.

Read more

Acceptance Tests: Let’s Change the Title, Too

Gojko Adzic recently wrote a blog post called Let’s Change the Tune on some of our approaches in agile development. In changing the tune, some of the current words won’t fit so well, so he proposes (for example), “Specifying Collaboratively instead of test first or writing acceptance tests”. I have one more: I think we should change the label “acceptance tests”. “Acceptance tests” are given a central role in agile … Read more