CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

Jeremy D. Miller -- The Shade Tree Developer

Under the hood and working with .Net, TDD, Software Design, and Agile Stuff

Testers are pigs

For the sake of this post, let's just assume that testers and developers are just one big happy family with the shared goal of shipping working software.  On rereading this post it's definitely preachy, but I've been burned in the past by not being inclusive of the testers and my current client definitely suffers a bit from a too developer-centric viewpoint.

Testers are pigs in the "people who have a direct stake in the project's success" manner. Sometimes we fall into a trap of thinking that productivity and schedule constraints are strictly related to developer time, but the testers are just as important.  I've got a case at work where 2-3 days of developer time probably translates into a couple weeks of testing.  Asking me alone when we can deploy isn't that useful because the testing is the bottleneck.  The tester's time is paramount.  For that reason, we need to get the testers (the tester in reality) every chance to be forearmed with prior knowledge of the work being done.  Planning has to include the question "how long do you think you need to test this?"  Is it really fair to dump a feature on the testers that they've never heard of and say "test this by the end of day tomorrow?"  Do you like it when somebody drops a complex architecture with a design pattern you've never seen on your desk and says code this by next week? 

Do unto testers as you'd have done unto you.

Remember to involve the testers anytime you're launching a new project, scheduling a production rollout, changing requirements, or really doing anything that alters the course of the project.  A lot of the time we implicitly assume that the testing time is linearly dependent upon the development time, but that's not always true.  The testers really need to have a say in the project scheduling, both to ensure that they have adequate time to do their job, and also just to know what it is that they're going to be expected to test.  In an ideal Agile team the testers are fully involved with each user story in near lock step wth the developers, so it's easier to keep the testers into the normal flow of a project.  Ignore the testers in your planning, and you pay for it later.



Comments

Jeremy D. Miller said:

@KG2V,

Exactly why we should love our testers when we do have them.  My experiences aren't that far off yours.

# September 18, 2007 8:48 PM

Abhishek said:

Including testers right from the conception stage has both its pros and cons. I would prefer the testers come in only after the development of the feature starts. That keeps them isolated from HOW the developers are thinking about the feature. It is important that testers give every feature the thought they want to give as testers rather than them thinking like developers. Otherwise so many bugs crawl under the blanket and can't ever be seen till the client complains. Of course I agree that the testing MUST be put in the schedule. But so far I don't know if testing time can be estimated accurately.

# September 19, 2007 12:59 AM

From the software development trenches said:

A bit earlier than normal, but it is time for another weekly roundup of news that focuses on .NET, agile

# September 20, 2007 9:22 AM

Patrick Debois said:

Maybe it's time for some self reflection?

Operational people can say the same of the developers. Once in the trenches, you become commited. Programmers only are committed during the project phase.

# September 22, 2007 4:18 PM

JEDI » Blog Archive » links for 2007-09-23 said:

Pingback from  JEDI  » Blog Archive   » links for 2007-09-23

# September 23, 2007 6:19 AM

The Disco Blog » Blog Archive » The weekly bag– September 21 said:

Pingback from  The Disco Blog  » Blog Archive   » The weekly bag– September 21

# September 24, 2007 1:03 PM

J.D. Meridth said:

Jeremy Miller posted about Testers being pigs . I have learned through my current position that he is

# September 26, 2007 9:33 PM

59 23 * * 0 flush » רשת חדשה, עולם ישן - ולהיפך? said:

Pingback from  59 23 * * 0 flush » רשת חדשה, עולם ישן - ולהיפך?

# November 27, 2007 4:05 AM

Leave a Comment

(required)  
(optional)
(required)  

Enter the numbers above:
Add

About Jeremy D. Miller

Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy previously worked as a systems architect building mission critical supply chain software for a Fortune 100 company and learned agile development practices as a .Net consultant at ThoughtWorks, one of the pioneers of agile development. Jeremy is the author of the open source StructureMap (http://structuremap.sourceforge.net) tool for Dependency Injection with .Net and the forthcoming StoryTeller (http://storyteller.tigris.org) tool for supercharged FIT testing in .Net. Jeremy's thoughts on just about everything software related can be found on his weblog "The Shade Tree Developer" at http://codebetter.com/blogs/jeremy.miller, part of the popular CodeBetter site. Jeremy is a Microsoft MVP for C#. Check out Devlicio.us!

Our Sponsors

This Blog

Syndication

News

All opinions expressed here constitute my (Jeremy D. Miller's) personal opinion, and do not necessarily represent the opinion of any other organization or person, including (but not limited to) my fellow employees, my employer, its clients or their agents.

About Me

"Best Of" Compendium

StructureMap (Dependency Injection for .Net)

StoryTeller (Supercharged Fit)

Build your own Cab

TestDriven

MVP