"When Can Test Start?"

A few quick thoughts on a subject I've seen at least 10 times in my career:

"Okay, when are you done enough for me to test this thing?"

Let's parse that a bit, because the ensuing arguments are one of definition

• "Okay," Acknowledging that stuff is just great or else I wouldn't be talking.
• "when" I'm going to ask you for a date. 
• "are you done" Done as is: Things won't change between the time I hit submit on the bug and I go to the bug review meeting and look like an imbecile.
• "enough" I'm not a total douche.  I'd like to test this, not make you look like a fool by filing 15,000 bugs.
• "for me" Hi, I'm a professional software tester.  Yes, we do exist.
• "to test" I was born to test and break things.  I can make your code cry.  You need me.
• "this thing?" At the end of the day, your work of art is a piece of business value and I'll not insult both of us by implying otherwise.

The above is the way a real QA professional sees that question.  I think.  Because, I'm not a QA professional, and God HELP YOU if I were.  I maintain my decade-plus assertion that great testers are born, not made.

So, what's the problem?  

Scenario

• You'd like to release your Thing on Date X.
• You'd like to make money or save time or whatever.
• You want some reasonable assurance that it works.
• The QA team says they need Date X - days to test things.
• That milestone is either imminent or sadly in the rearview mirror.

To wit: You're an engineer and you're staring at either a Project Manager or a QA professional and they ask you that question:  "Okay, when are you done enough for me to test this thing?"

This is like an opening move in chess, I'd argue, and there are several (well-studied) responses

Your Responses

1.  Deflect.  That is, attack the premise that you're ever "done" with software.  Said differently, imply there are plenty of testable features:  "There's plenty of stuff to test.  Why haven't you started already?"   I've been there.   I've done this.  It doesn't work.  If your shop cares about milestones, this is a one-way ticket to escalation.  For one thing, you've established a Dev > Test primacy that excites the Lizard Brain in all of us, particularly test managers.  Particularly if they have an axe to grind.
2. Lie.   "Sure, we'll be done by ______." While given with the best intentions, any sort of answer that fits that pattern given on the spot is a lie.  Take a breath and understand that.  You might have a 50/50 shot of hitting a date given on the spot, and if you miss again, there goes your credibility.  
3. Stall.  In effort to avoid 1 & 2, a natural is, "I'll get back to you."  This is perfectly acceptable in many circumstances, including here, but realize:  If someone uttered that original question, their Spidey Sense that you're going to be horribly late with crappy deliverables they have to somehow pull out of the fire goes off.  Better: "I'll get back to you this afternoon." 
4. Work the problem.  Assuming everyone is trying, all sides want to meet the goals.  The Testers really want to test, because they've lived through working 70 hour weeks trying to test stuff that delivered late.  They're sensitive to that not happening again.  So, call a meeting to look at the situation from both test and development perspectives and see what's testable and when the late stuff will be available.

Variations

1)  Deflection by fit-throwing: roll your eyes.  Swear appropriately.  Go off by yourself in a huff.   Your hapless manager/team lead will try to rope you back in and they'll forget all about the test kerfuffle.  You're acting like a 2-year-old.   Please be better than that.

2) Lie by legalism: "I don't believe our schedule committed to exactly ______ by ."  This will send everyone back to their various documentation and buy you time.  It's a damned dirty trick, and everyone sees through it.  You'll probably win the battle--no one maintains that kind of documentation, unless there's a government contract involved--but again your credibility is toast.

3) Work the problem....until they quit.   This is inviting them into a meeting.  Then another meeting.  Then a meeting you have to reschedule.  Eventually, they give up.  Again, past a certain point, people know you're all smoke and mirrors.   You don't want that on your reputation.

4) Fire all your testers.   "We can automate everything, and we don't need them.  We need developers, and the budgets are tight."  You're rationalizing.  Call me in exactly 18 months when all your customers find the issues you didn't add to the automation suite, but a good tester would've found in 1 day.

5) Put the testers on the development team.  Bah, just fire them.  Admit you want them to STFU so you can keep hitting dates, and doing this removes any sort of counterbalance to the "ship it" mentality of a development manager.

* * *

I've lived through some theme and variation on all the above.  The RIGHT answer is: Work the problem, bombard your test group with progress and status before you get close to a milestone so there's zero surprises.   

That's right, if someone even asks the question in the middle of your project, take it as a sign your development process has failed, and act accordingly.