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

Exploratory Testing on an API? (Part 3)

In the last two posts, I’ve been answering the question Do you perform any exploratory testing on an API? How do you do it? Last time I described the process of learning about factors in the project environment that affect my strategy as I go about the testing of an API. This time, I’ll go deeper, learn more, and begin to interact with the product. That learning and interaction feeds … Read more

Exploratory Testing on an API? (Part 2)

Summary:  Loops of exploration, experimentation, studying, modeling, and learning are the essence of testing, not an add-on to it. The intersection of activity and models (such as the Heuristic Test Strategy Model) help us to perform testing while continuously developing, refining, and reviewing it. Testing is much more than writing a bunch of automated checks to confirm that the product can do something; it’s an ongoing investigation in which we … Read more

Exploratory Testing on an API? (Part 1)

In one forum or another recently, a tester, developer or DevOps person (I wasn’t sure which of these he/she was) asked: Do you perform any exploratory testing on APIs? How do you do it? Here’s an in-depth version of the reply I gave, with the benefit of links to deeper material. To begin: application programming interfaces (APIs) are means by which we can use software to send commands to a … Read more

Test Cases and Coverage

A tester recently asked about creating an in-house testing process, wanting to know how to start writing test cases so that testing effort could be estimated. My reply—which could just as easily apply to a developer or business analysts in a testing role—went something like this: Test cases are not testing!  While that’s true, just saying so probably won’t help you very much, so let me offer an alternative to thinking … Read more

Which Test Cases Should I Automate?

When someone asks “I have a big suite of manual tests; which tests (or worse, which test cases) should I automate?”, I often worry about several things. The first thing is that focusing on test cases is often a pretty lousy way to think about testing.  That’s because test cases are often cast in terms of following an explicit procedure in order to observe a specific result.  At best, this … Read more

Very Short Blog Posts (36): Positive, Negative, and Sympathetic Testing

In Rapid Software Testing, a “positive test” is one that honours every required and explicitly declared condition or factor for a desired outcome. A “negative test” is one that violates (or dishonours, disrespects, ignores, omits, undermines…) at least one required and explicitly declared condition. That said, we don’t talk very much about positive and negative testing. We do talk about “sympathetic testing“, a closely related idea named by Cem Kaner. … Read more

Rapid Software Testing in Toronto, June 4-6

I don’t usually give upcoming events an entire blog post. I usually post upcoming events in the panel on the right. However, this one’s special. I’m presenting a three-day Rapid Software Testing class, organized by TASSQ in Toronto, June 4-6, 2018. Rapid Software Testing is focused on doing the fastest, least expensive testing that still completely fulfills testing’s mission: evaluating the product by learning about it through exploration and experimentation. … Read more

How Long Will the Testing Take?

Today yet another tester asked “When a client asks ‘How long will the testing take for our development project?’, how should I reply?” The simplest answer I can offer is this: if you’re testing as part of a development project, testing will take exactly as long as development will take. That’s because effective, efficient testing is not separate from development; it is woven into development. When we develop a software … Read more

Very Short Blog Posts (35): Make Things Visible

I hear a lot from testers who discover problems late in development, and who get grief for bringing them up. On one level, the complaints are baseless, like holding an investigate journalist responsible for a corrupt government. On the other hand, there’s a way for testers to anticipate bad news and reduce the surprises. Try producing a product coverage outline and a risk list. A product coverage outline is an … Read more