Test’er’ Driven Design
I’d like to thank one of our senior developers for inspiring this post. Dave Vines recently sent out an excellent, thought provoking email on how we should be moving towards a tester driven development model. I’ve slightly reworded his email:
“One thought that I’ve recently had was that perhaps we need “Tester Driven Development” rather than “Test Driven Development”. Let me try to explain.
We are currently very much a “Developer Driven Development” organization:
We gather new requirements and (typically) farm them out to the development community to investigate
Once a work item is identified, it is typically a developer that
- Writes the Design document
- Calls the meeting to develop the use cases
- Identifies the interesting scenarios
- Gathers the development resource to write the code
- Decides which iteration in which the code will be written
- Hopes that test will have the resource to test all the use cases and “interesting edge cases” that have been identified and for which code has been written (or not written)
In effect the developer owns the work item
In a “Tester Driven Development” organisation I would see us:
Gathering new requirements and (typically) farm them out to the test community to investigate
Once a work item is identified, it is typically a tester that:
- Writes the design document
- Calls the meeting to develop the use cases
- Identifies the interesting scenarios
- Gathers the test resource to test those scenarios and use cases
- Decides which iteration in which the code will be tested
- Indicates to development what use cases and code will be needed and when
In effect the tester owns the work item
This would be a massive culture shift for a department, but one that makes it clear that the desired deliverable is actually requirements that have been tested, not requirements that have been coded and may have been tested if test had enough resource. “
I think this is a great proposal, but it triggered me into thinking about why it should be such a massive cultural shift. I think it starts with the different perceptions of the test and development roles. There is clearly a perceived hierarchy. I’ve had people on planes laugh at me when I tell them I’m a tester. (don’t worry, they’re recovering quite well now). Strictly the developer and tester roles are a collection of sub roles ranging from the architect to the implementer. However, a developer is normally associated with the higher of these sub roles, whilst the tester is associated with the lower sub roles. I tried to put this into a diagram.
I believe if we are really going to crack TDD properly then we need to redefine the development and test roles and create a third role that I’ll call for now the Business analyst. Someone who understands the business needs (the requirements and the use cases) and the solution being developed.
This would give us a set of roles like this:
The Business Analysts would be people with architectural, design and use case development skills from both the old development and test roles.
Could this be an easier way of making the massive cultural shift?
Tags: design, ownership, requirements
February 15th, 2008 at 18:04
Up until the “Read the rest of this entry »” break, I was itching to reply with how the department I work in does things…
…but you either know already, or have come up with a pretty similar option. We actually have Business Analysts who, as you suggest, cover the use cases. It does seem much more sensible to have a strong input from a business perspective, rather than leaving developers to try and guess what should be done.
Another approach that’s crossed my mind is Documentation Driven Development but that’s probably for another post
February 17th, 2008 at 10:36
This is an interesting idea, Jon. I think it makes a lot of sense, in general, to be led by use cases, and from the perspective of the user and what they want to achieve. I’m not sure Business Analyst is the correct term, as you don’t necessarily need to understand a company’s business to (say) write a word processor for them to use. You do need to understand the user though.
I think the tricky thing with this sort of change, is how you restructure the teams you already have. How do you shift developers to be more test focused, and testers to understand more aspects of development? Also, importantly, how do you retain an appropriate level of test independence? (i.e. not knowing the implementation details when you test)
February 19th, 2008 at 21:33
I can’t quite work out how this differs from the status quo. Would the tester and developer be working for the business analyst?
The main problem I see is that developers are responsible for delivering the code, but not the quality of it (not really). Testers are responsible for the quality of the code, but no power to actually improve it. Power != Responsibility on either side.
One thing I try to do is couple the power and responsibility for something as tightly as possible. If you have power over something, you get the pain too.
Now, if test own the line items and employed the developers … that would be interesting.
February 20th, 2008 at 08:30
Thanks for the comments guys.
I agree with Arthur about the Business analyst role, it’s not quite what I’d intended. It does remind me of my first programming job, early ’80s coding in COBOL for a manufacturing firm, (8 VDUs for 12 programmers, coding sheets and ties). Anyway, we had systems analyst who owned all the systems, they gathered the requirements, did the design and passed the specs to the proggies who wrote the code and effectively did the unit testing (although we didn’t call it that then). It was then the Systems analyst’s responsibility to test the system before handing it to the user. So even back in those days we had a crude notion of this structure. Note that we had no role called ‘tester’. Granted, verifying batch reports was a lot easier than the stuff we do today.
I think this also ties in with your suggestion John, power and responsibility are key to this.
February 21st, 2008 at 14:00
I read John’s post and wondered if his comment, “Testers are responsible for the quality of the code….” was his belief, a management view, or accepted wisdom.
As someone relatively new to current software test and development practice, but with a lot of experience in several other roles (including hardware/firmware testing), it seems to me that testers can never hold the main responsibility for the quality of the product they are testing, although instrumental in improving it. If anyone remembers Product Assurance, it used to be said that you can’t test quality into a product.
By identifying any weaknesses or errors in design and/or implementation, testers are part of an iterative process of improving quality. And, of course, the quality of the test cases is a fundamental part of this.
At the end of the day, I believe that product quality is a team result.
February 23rd, 2008 at 01:04
Steve, on rereading my comment I have to wonder myself. Alas, I can’t think of better answer than breaking-the-product which puts them in the same popularity league as auditors (process testers if you will) and hackers (the naughty kind).
I agree that, ideally, product quality should be a team result. However, I’m not sure large teams (say 50-100 people) can feel the kind of ‘team spirit’ necessary to achieve this.
May 9th, 2008 at 12:00
[...] more and more recently as its something we need to get right. I’ve already touched on tester driven design in an earlier post. Now I’d like to look at three basic concepts that may help us move on. [...]