DevelopsenseLogo

Context

Four Frames for Testing, Part 5: Intention, Discipline, Testability, Realization

In the last post, I introduced four frames for testing, each of which might present a set of ideas for covering a product at various points through its development. On the way to a complete package, system, or service, people produce many different ideas and artifacts, each of which can be tested. Moreover, people with different interests, temperaments, and roles in the development process perceive testing in different ways. Although … Read more

Four Frames for Testing, Part 4: What the Business Wants from Testing

Last time, we looked at what the business wants from development. What does the business want from that part of development we call testing? Sometimes people say that what the business wants from testing is confidence — reassurance that everything is okay. This is understandable — confidence is a good feeling for designers, developers, managers, and the rest of the business. Confidence and reassurance are not the business’s goal, though; … Read more

Exploratory Testing on an API? (Part 4)

As promised, (at last!) here are some follow-up notes on previous installments in the series that starts here. Let’s revisit the original question: Do you perform any exploratory testing on APIs? How do you do it? To review: there’s a problem with the question. Asking about “exploratory testing” is a little like asking about “vegetarian cauliflower”, “carbon-based human beings”, or “metallic copper”. Testing is fundamentally exploratory. Testing is an attempt … Read more

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 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

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