There are two distinct roles in many software projects that are involved with testing: developers and testers. Should they take the same approach to testing, or are there some principles that apply to only one of the roles? What should they do to coordinate their work? Danny Faught went through an exercise to compare and contrast and found that the questions he couldn't answer were as interesting as the questions he could answers.
Tied into the idea of roles are the different levels of testing. In this article, I focus on the top and bottom levels-unit tests, which help us overcome the fear of change, and system tests, which help us overcome the fear of release.
First, let's explore some common ground.
Developers and testers want to do a good job.
This is important. Though it seems obvious when you read it, it's easy to lose sight of this idea when you're getting frustrated working with someone who's on the other side of the fence. For example, I frequently get frustrated when developers don't write automated unit tests. However, many developers want to do better unit testing but can't convince their manager to let them spend the time necessary to do it, even with the prospect of greatly reducing the debugging effort later in the project.
Testing in isolation makes it easier to isolate bugs.
When you have unit tests that test code in extreme isolation, it's easy to figure out the cause when the tests fail, and it's relatively easy to thoroughly test the paths through the code. If we test at the subsystem level when we can, rather than exercising the entire system, we get the same benefit. But it's also important to make sure that all the parts play well together.
Both kinds of tests require maintenance.
Tests at all levels need to be maintained when the system under test or the platform you're testing on changes. And at all levels, you can apply techniques to reduce the burden of maintenance.
What's the Difference?
All testing shares many common principles. But we can find a few differences if we dig for them.
Unit testing is best done by a developer who knows the product code.
Even if the developer isn't an experienced tester, it's usually better for someone who is intimately familiar with the product code to write the unit tests. For system testing, projects often benefit from having a test design specialist make the decisions. So the unit tester is often a development specialist with limited knowledge of test design, and the system tester is often a testing specialist with limited design and coding skills.
A unit test suite may need to run 100 times a day.
But a system test suite may be run only a few times a day, week, or month. The speed of the unit tests can be more critical than the system tests.
You might have more unit test code than product code.
Depending on how thorough and concise your unit tests are, you may have as much or more code in your unit tests than in the product you're testing. This doesn't tend to be the case for automated system-level tests. Though, scripted manual tests, when you have to have them, can easily exceed the length of the requirements and design documents.
Some items are harder to put either in the "same" or "different" categories.
What level do we do boundary testing?
Boundary tests can be done at the unit level, where it's easier to stimulate many different kinds of inputs. And boundary errors (like using