Communication / Process Improvement / Requirements / Software development / Software requirements specification / Testing

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

Foundation series / Software development / Test Automation / Testing

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.

Design / Process Improvement / Software development / Test Automation / Testing

Software Testing Series: Organizing a Test Suite with Tags Part Three

Posted on:

This is the third in a three-part post about using tags as a means to organize an automated unit test suite.

Part 3 of this post can be read as a standalone article. If it were, it would be titled Design elements of an automated unit test framework using tags. If you’re only reading this post and not parts 1 and 2, pretend that this is the title.

Lists / Software development / Software requirements specification / Test Automation / Testing

Software Testing Series: Organizing a Test Suite with Tags Part Two

Posted on:

This is the second in a three-part post about using tags as a means to organize an automated test suite.

Part 2 of this post can be read as a standalone article. If it were, it would be titled Top five problems with test automation suites. If you’re only reading this post and not parts 1 and 3, pretend that this is the title.