A look back at the best from a year ago
Passing the Wrong Whitebox Tests
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: Black Box vs White Box Testing
Should I use black box testing or white box testing for my software?
You will hear three answers to this question – black, white, and gray. We recently published a foundation series post on black box and white box testing – which serves as a good background document. We also mention greybox (or gray box) testing as a layered approach to combining both disciplines.
Given those definitions, let’s look at the pros and cons of each style of testing.
Foundation Series: Black Box and White Box Software Testing
Blackbox tests and whitebox tests.
These terms get thrown about quite a bit. In a previous post, we referenced Marc Clifton’s advanced unit testing series. If you were already familiar with the domain, his article could immediately build on that background knowledge and extend it.
Software testing can be most simply described as “for a given set of inputs into a software application, evaluate a set of outputs.” Software testing is a cause-and-effect analysis.
Marc Clifton’s Advanced Unit Testing articles
In a previous post, we mentioned a link to the first in a series of articles by Marc Clifton at The Code Project, a .NET resource site. Here are the links to all 5 of the articles in Marc’s series.