Developers Can’t Test For Toffee!
by Kelly Waters
In the more traditional world of managing software development projects, it is widely acknowledged that developers can’t test for toffee!Yet agile development methods increasingly seem to require or imply that all people in the project team should test, including developers.
So, first of all, why is it that developers can’t test? Are we to believe that these highly intelligent individuals somehow don’t have what it takes to test? Of course not.
The trouble is simply this: Good developers build their code to handle every scenario they can think of. If they’re really good developers, they write automated unit tests to test everything they’ve built. And if they’re really good developers, they even do this up-front so everything is designed and built to pass first time.
But still it’s not enough.
For developers only build (and therefore test) everything they can think of. And testers, partly due to their nature and partly due to the fact they’re not buried in the detail of implementing the code, are able to think up scenarios that the developer didn’t think of. And that’s the problem.
So what do we do in agile development, where everyone is expected to test?
My answer is this:
Wherever possible, do include at least one dedicated tester within the Agile Development team. If the tester is not able to test everything personally because there are more developers than the tester can handle, have the tester take a special QA role, including the following activities:
- Identify the test strategy and test scenarios
- Ensure the appropriate test environments are in place and controlled
- Write the test cases/scripts – ideally up-front but on a just-in-time basis per feature
- Review the developers’ automated unit tests, to avoid re-testing the same things later and to QA the scope of the tests
- Execute some of the most important test scripts personally, particularly where there is higher complexity or risk, less clarity or where more attention to detail is required
- Coordinate the test efforts of others (including developers), so one person knows what scripts have been executed, what areas have been tested, their status at any time, and the issues logged against them
- Manage the bug log to ensure issues are logged clearly and prioritised consistently
- Liaise with customers and/or business users to organise acceptance testing and advise on approach
- Ensure that each developer's code is also tested by someone else, even if it's another developer
In my experience, there is real business value in having tester expertise for this quality management / quality assurance role, even in a situation where there aren’t enough testers to go round. In an Agile Development environment, the emphasis of a tester’s role is more on QA than it is on testing per se.
See also:
Why Agile Testers should be in at the start
10 Key Principles of Agile Development
6 April 2007 13:01
private Toffee toffee;
. . .
@Before
public void setUp() {
Toffee toffee = new Toffee();
}
. . .
@Test
public void testForToffee() {
assertNotNull(toffee);
}
On a more serious note, your post got me to thinking about specialized roles on IT projects and how agile methods and lean organizations are changing those roles. In the end I didn't reply specifically to your comments, but instead a more general article emerged. It's a rather different way of looking at the question than you present in your post, and I'm curious to know what you think of it.
26 August 2009 22:38
But we also need a UI tester. Different role. For example, people cannot do two things at once consciously. Therefor, programs should not demand it of them. In order to walk and chew gum, at least one of those activities must be so well learned that you need not think about it. An experienced driver can talk to a passenger while driving, but this is not true for a novice driver.
This argues that modes should be avoided since they require the user to keep the mode in mind while attending to something else. Humans often fail at such tasks.
It is not enough that the program performs the required computation correctly and efficiently. It must also not break the user's train of thought. This implies that ease of learning is not just an advantage, but rather a necessity if the user is to maintain her attention on the content and not be distracted by the mechanism.
We do not go to the movie theatre to watch the projector but to see the movie content. Anything which demands the viewer to attend to the projector detracts materially from the experience.
If you use a modal dialog box, it is guaranteed to break the user's train of thought. DO NOT DO THAT.
If you have a SAVE button that is required to avoid losing your work, then you demand that the user keep this in mind. If she fails to click that button, the program will then destroy the work of a minute, or hour. This is unacceptably cruel.
These requirements, for any program to be excellent, are not easy to satisfy without careful attention by the developer, yet they seem only to be discussed in Jef Raskin's book, "The Humane Interface". You can find the author's summary of the principles and rules in two pages at Nitpicker.pbwiki.com if excellence is a matter of concern. When such interface excellence is achieved, the result is an addictive tool that does not frustrate users.