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?
My opinions do not reflect those of my employer.
Subscribe to posts
RSS
Popular Posts
-
After attempting to use Microsoft Test Manager 2010 for an iteration, we quickly decided not to use it. Here is why. About 3 years ago we f...
-
Data warehouse (DW) testing is a far cry from functional testing. As testers, we need to let the team know if the DW dimension, fact, and b...
-
I recently read about 15 resumes for tester positions on my team. None of them told us anything about how well the candidate can test. Here...
-
Want your bug reports to be clear? Don’t tell us about the bug in the repro steps. If your bug reports include Repro Steps and Results se...
-
When someone walks up to your desk and asks, “How’s the testing going?”, a good answer depends on remembering to tell that person the right ...
Blog Archive
Labels
- Teamwork (86)
- bugs (81)
- process (66)
- software testing career (49)
- automation (45)
- writing tests (38)
- Personal Excellence (37)
- Managing Testing (33)
- questions (31)
- language (29)
- testing metaphor (23)
- Tools (19)
- STPCon (10)
- heuristics (10)
- Test Cases (9)
- test blogs (9)
- CAST (8)
- Presentations (8)
- Test This (8)
- metrics (8)
- Rapid Software Testing (7)
- Silliness (7)
- Data Warehouse Testing (6)
- Kanban (6)
- STARwest (6)
- Testing Conferences (6)
- Agile (4)
- Bug Report Attributes (4)
- Don't Test It (4)
- Stareast (4)
- documentation (4)
- Failure Story (3)
- Lightning Talks (3)
- Testing Related Ideas (3)
- You're A Tester (3)
- Performance Testing (2)
- Podcast (2)
- ATDD (1)
- BDD (1)
- HATDD (1)
- Meetups (1)
Who am I?
- Eric Jacobson
- Atlanta, Georgia, United States
- My typical day: get up, maybe hit the gym, drop my kids off at daycare, listen to a podcast or public radio, do not drink coffee (I kicked it), test software or help others test it, break for lunch and a Euro-board game, try to improve the way we test, walk the dog and kids, enjoy a meal with Melissa, an IPA, and a movie/TV show, look forward to a weekend of hanging out with my daughter Josie, son Haakon, and perhaps a woodworking or woodturning project.
My other passion is woodturning.
Test blogs I try to read
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.
Matt Heusser posted this today, and it seems to articulate some of what you are saying.
"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.
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.
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.