Timeline for Workflow shortcut to meet the release deadline

Current License: CC BY-SA 3.0

5 events

when toggle format	what		by	license	comment
Jun 11, 2011 at 7:04	comment	added	user631		@stuartf Yes, my bad. In that line I refer to gathering / creation as the very first steps towards the actual specs, which usually involve gathering input from clients / stakeholders, generating raw ideas, checking the competition etc, assuming that's what the OP had in mind (as what else could a marketing dept. actually do towards specs?). I think we need a lot of clarification on the question itself, its wildly open to speculation.
Jun 10, 2011 at 18:16	comment	added	stuartf		"QA specialist should not be involved in the actual gathering / creation of the requirements." At the end of the first sentence in your answer. Apart from that you make some great points such as not letting letting the process become a bottleneck.
Jun 10, 2011 at 16:47	comment	added	user631		@stuartf If this was a general discussion I'd agree with you, but the question is more along the lines "Should I take over specs creation?". And where do I suggest that a QA specialist should not get involved? Getting testing involved from the start is what requirements reviews are for, shaping requirements with your reviews does involve QA in the creation process. But completely taking over the creation process, that's not typically a good thing. Still, if the person is sufficiently talented, the wrong way may be the best way to go.
Jun 10, 2011 at 11:56	comment	added	stuartf		I strongly disagree with a QA specialist should not be involved in the creation of requirements. From experience, I have found that getting testing involved from the start of a project (requirements creation) has helped us catch bugs or potential bugs before any time has been wasted on writing code for a component that would be fundamentally flawed.
Jun 10, 2011 at 11:33	history	answered	user631	CC BY-SA 3.0