DevelopsenseLogo

“Did anyone test this?”

That’s a question that people often ask in exasperation when some piece of technology fails to fulfill its purpose, or has some obvious problem. It’s not a question that people on the outside can answer for sure. After all, something can be tested and a problem can be reported, but management might decide that there are bigger fish to fry and that, despite the problem, the product is good enough. … Read more

You Can’t Inspect Quality Into a Product

Over the last 35 years in the software business, I’ve heard the expression “You can’t test quality into a product.” To support that statement, I’ve seen this quote — or a part of it — repeated from time to time: Inspection does not improve the quality, nor guarantee quality. Inspection is too late. The quality, good or bad, is already in the product. As Harold F. Dodge said, “You can … Read more

Checking is Inside Testing

Read more here: Testing and Checking Refined – by James Bach, Michael Bolton [https://www.satisfice.com/blog/archives/856] On Testing and Checking Refined – by Michael Bolton [https://developsense.com/blog/2013/03/testing-and-checking-redefined] Testing, Checking, and Changing the Language – by Michael Bolton [https://developsense.com/blog/2009/09/testing-checking-and-changing-language] Professor Harry Collins was mentioned in this video. Please see this link regarding him: https://profiles.cardiff.ac.uk/staff/collinshm Watch more at the Rapid Software Testing YouTube Channel

Podcast: Beyond Checkboxes: Rethinking Software Testing

Join David Carty of Applause, and Michael Bolton, as they discusses the importance of comprehensive testing, the importance of open communication between teams and the effect of AI on software development. https://www.applause.com/resources/podcasts/ep-28-rethinking-software-testinghttps://www.applause.com/resources/podcasts/ep-28-rethinking-software-testing

Four Frames for Testing, Part 7: Critical Distance

There’s a popular trope in the software development world these days that suggests that everybody on the team is responsible for testing. With that idea in mind, some people take an extreme position: since everyone tests, no one needs dedicated testers any more. Developers can do all the testing; or business analysts can do all the testing; or the customers can do all the testing. Then there’s another notion (which, … Read more

Four Frames for Testing, Part 6: Development and Testing Are Fractal

The previous post in this series provided a detailed description of testing framed in terms of Intention, Discipline, Testability, and Realization: It might be tempting to unroll these frames by starting in the top right, and rearranging them in a nice, tidy, linear sequence: Although it’s not the way people usually talk about it, you could think of this as a kind of end-to-end testing. Most of the time, so … Read more

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 with testing 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 … 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

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

In the previous installment, we looked at what the business wants: a product of high value, and one for which costs of development and will be low. This time we’ll look from a slightly different angle: how does the business get what it wants? There is a kind of universal development cycle. No matter what your development model might be, it probably looks something like this: Since it’s a cycle, … Read more

Four Frames for Testing, Part 2: Four Kinds of Risk

In the first installment of this series, I introduced two key things that the business wants from development: a product of high value and low cost. In order for the business to get a high-value product, we must envision success so we can set about building it. And yet… there’s risk. It’s easy to assume that we’ve built a high-value product, and that cost to the business is low and … Read more