Workflow shortcut to meet the release deadline

Question

When you design a test scenario or even when you run your tests and you stumble to lack of specifications from your marketing Dept. should you bypass them and take the initiative of making your own specs, or should you delay the deployment till you get a definite answer?

Answer 1

You should talk to your marketing department and understand why they have no specification for that particular area and explain to them why it is important for specification to exist and that there cannot be any short-cutting in this area. You may find out that they lacked resources or were unsure about this area. Regardless of the reason you can help them out and you can both together write the specification for this.

I'm not a great believer in something being outside someone's job description, if there is something that needs done and you can help, then you should. A project will run smoother if you have this mentality. Just because you are in QA doesn't mean that you cant help out in roles outside your own.

If you choose not to write a specification and you are going to document the test cases for this area, then these tests will essentially be the specification. It's is worth getting the marketing guys involved here to make sure that what you are testing is correct and the behaviour you have assumed is correct . Do not create the test cases on your own, you don't own the product and cannot make these decision of how the product should behave.

Answer 2

We never start with clearly written, complete, unambiguous, mutually-consistent specifications, and sometimes we start with nothing but an untested product. You can't test without some kind of model of what the product should be. You should ask yourself how important it is for your model to match the model in the heads of the rest of the company, and your answer should drive how you proceed.

Personally, I read whatever is written down, if anything, and draw a diagram of the product's entities, relationships, inputs, outputs, and constraints, in as much detail as I think I need in order to test. As I draw the diagram, I run into things I don't know. I make a list of questions, and when the list is long enough, I ask people until I find the answers. The final result isn't a specification, but it is enough to drive a test plan.

Answer 3

Getting clarification on specifications should be the correct move in my opinion. Consider what will happen if you choose your own specs; you could spend a considerable amount of time going in a direction that may turn out to be entirely different than what the business had in mind.

Answer 4

The QA process does include requirements / specs review (feasibility review, standards review etc) but a QA specialist should not be involved in the actual gathering / creation of the requirements.

Having said that, it's also not a very good idea to assign the process to a marketing dept., marketing people should of course generate ideas but those ideas should then be transformed / translated to specs.

So, to answer your question: Initiative is good, but overstepping the boundaries of your job description is probably not. QA skills may be closer to what's required than marketing skills, but still not close enough.

That of course is a generic view, and it may not apply to your specific situation. The "best man / woman for the job" principle transcends department titles and if you strongly feel that you can better the process (and can prove it to the decision makers), then what you should do is involve yourself in the process in an official role.

Requirements / specs are too important to the creative process, and its crucial to not let them become a bottleneck.

Answer 5

This is so tricky - either one is a good solution depending on the situation.

• Picking the right one will make you a hero.
• Picking the wrong one could make you lose your job.

So then if you take the time to talk with the stakeholders and flesh out the specs, what happens? Do they say "Wow, you were very thoughtful and thorough! Let's answer these questions so we can move forward with the project!" Or, do they tell you "Wow, you're wasting more of our time with these trivial details? Can't you just go do your "computery stuff" and let us get back to work?"

I've seen it both ways (okay, not marketing, but does it matter who made the poor spec? :-) and I've been treated both ways.

I try to find a delicate balance of the two. For small changes, I don't waste their time. I use previous examples to make a best guess about what they really want. For bigger changes or contradictions in the spec, I PROPOSE a solution and send it to them for a stamp of approval. I also send them a list of the small changes I took the liberty of making. Hopefully they get back to me in time before it ships if they want it changed.

Also, before I start work on a project, I identify things that need to be clarified and send them to the analyst before doing any development. (I know you're doing test scenarios, not application development, but I feel the same rule applies.) Then I try to work around those grey-areas until I am forced to put it on hold or bite the bullet and make some changes.

< personalRant justification="I hate it when people do this to me">

Some developers I know play "gotchya games" with the analysts to cover their own backside. They'll send a request for clarification, but they'll hide some of the main points. Maybe they're broken up in sentences in the middle of a paragraph or something like that, or you put two requests in the same bullet point in the email. Please, please, please don't do this.

It's not always intentional, but the end result is the same: they miss the request for clarification on a particular issue, so you miss out on what they had to say, the product ships without the clarification (and is usually wrong) and it comes back to you. Then you say "Well, I sent it to the analyst and he didn't seem to be interested in it. Not my fault he didn't think it was a big deal."

It works in the short term to get the "blame-hogs" off your back when something goes wrong, but the long term effects are drastic: Poor relations between your team and the analysts (as if it isn't hard enough getting information!), the product's reputation with customers suffers (and you may even lose some customers if the issue that went live is bad enough) and if it happens too many times, management begins to notice a pattern about you, especially when it happens with multiple analysts.

< /personalRant>

tl;dr: make what decisions you can, and communicate the ones you can't. Keep them apprised on your situation, and listen to what they have to say. Try to keep relations between your team and the analyst/marketing/business team (or any team!) as good as you can; it makes it better for everyone at the firm!