Passing the Wrong Whitebox Tests

Posted on:

We’ve talked about the value of using whitebox testing in our Software testing series post on whitebox testing. What we haven’t explored is how to make sure we are creating the right tests. We have to validate our tests against the requirements. This post shows where the flaw is in the typical whitebox testing process, and how to fix it.

A reader emailed us with the comment, “It’s been my experience that developers can’t test their own code.” Their problem was that they were missing a link in the software development chain (missing a step in the process).

Software testing series: Pairwise testing

Posted on:

Very large and complex systems can be very difficult and expensive to test. Often, we inherit legacy systems with multiple man-years of development effort already in place, in the field and of unknown quality. With these systems, there are frequently huge gaps in the requirements documentation. Pairwise testing provides a way to test these large, existing systems. And on many projects, we’re called in because there is a quality problem.

The code freeze is killing the dinosaurs

Posted on:

The software development process for most companies has a flow – gather requirements, design, implement, test, release. There can be feedback loops, iterative cycles, spirals or waterfalls, but they all have these steps. When teams “freeze the code” and submit to test, they are creating their own mini-ice age and dooming themselves to extinction.

Measuring the Cost of Quality: Software Testing Series

Posted on:

Should we test our software? Should we test it more?

The answer to the first question is almost invariably yes. The answer to the second question is usually “I don’t know.”

We write a lot about the importance of testing. We have several other posts in our series on software testing. How do we know when we should do more automated testing?

Sample Use Case Examples

Posted on:

We talked about informal use cases a while ago in our use case series. Over a series of posts, we are demonstrating the process of defining a software product. The next step, and subject of this post, is the creation of informal use cases to support the defined goals for the software.