Does one require more start-up time than the other?

My department is gearing up for a spike in development this summer. We plan to use temporary, contractor developers and testers.

IMO, the contractor devs do not need to know nearly as much about our systems as the contractor testers do. The devs will be able to make their updates with limited business domain or system knowledge. However, the testers will need to go way beyond understanding single modules; they will need extensive business domain and system knowledge in order to determine what integration tests to write/execute.

Some on my team have a notion that testers can come in and be valuable by running simple tests, with limited knowledge. It scares me so much I would almost consider giving up my entire summer, moving into the office, and doing all the testing myself.

I’m also wondering if contractor testers should be paired with veteran devs and vice versa. If we have contractor testers working with contractor developers, as is the plan, it sure seems like a recipe for disaster.

Have any of you experienced something similar? What advice do you have for me?


  1. Ken said...

    I have noticed, in my own experience, that relying on contract testers can be difficult and more time consuming IF you need them to work on large-scale integration efforts. Whereas developers tend to come in and work only on a small piece of the effort, testers usually are required to test across functions, systems or business domains. If you can bring in testers to work on smaller parts of the project, thereby allowing your more seasoned in-house testers to focus on the cross-domain effort, this could work.
    Also, I wouldn't pair contractors with contractors. My experience is this tends to be a case of the blind leading the blind. Your idea of pairing veterans with contractors is probably the best solution.

  2. Marlena said...

    Matt Heusser posted this today, and it seems to articulate some of what you are saying.

  3. macbookpros said...

    "the contractor devs do not need to know nearly as much about our systems as the contractor testers do."

    No offense, but I think that was formed from a biased opinion of "my job is harder and hence (unconsciously) probably more important than yours mentality" But maybe I could be accused of the same bias as well.

    Look at what happened with the reporting team dev contractors. I rest my case.

  4. Troy said...

    I am a manager for a government testing contractor and I can tell you from experience that a good contractor can be very effective. Yes, domain knowledge is useful but I find good requirements to be the most useful. Having people with domain knowledge available to answer questions will be a huge help for any contractor.

  5. The Wandering Luddite said...

    I've dealt with this scenario a number of times in the past. One effective strategy can be to divide the test planning and test execution tasks. Those with the heavy business domain knowledge perform all of the test planning, at least if the personnel ratios work out. It doesn't require near as much domain knowledge to execute, and any knew domain knowledge created by the planning gets to stay in-house once the contractors are gone.

    I should also note that this strategy tends to be more effective in an agile-like environment where the testing iterations tend to be in small chunks. If the phases are more discrete, this becomes unworkable.

    I agree with Troy that good requirement definition trumps domain knowledge, but I have to invoke Sturgeon's Law here -- "ninety percent of anything is crud" [especially requirements]. Most experienced contractors are very good at sniffing this out, but these situations tend to leave unsatisfactory experiences for both parties.

Copyright 2006| Blogger Templates by GeckoandFly modified and converted to Blogger Beta by Blogcrowds.
No part of the content or the blog may be reproduced without prior written permission.