Most teams think about testing in terms of code coverage – what % of the lines of code are covered? What matters to our stakeholders is how well the software works. More precisely, how well does the software let the users work? We should be targeting our quality message in terms of use cases, because that matches their perspective and context.
Measuring the Cost of Quality: Software Testing Series
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?
Foundation Series: Unit Testing of Software
Testing software is more than just manually banging around (also called monkey testing) and trying to break different parts of the software application. Unit testing is testing a subset of the functionality of a piece of software. A unit test is different from a system test in that it provides information only about a particular subset of the software. In our previous Foundation series post on black box and white box testing, we used the inspections that come bundled with an oil change as examples of unit tests.
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.