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?

  • 1
    Your question is wildly open to speculation. Can you give us a little bit more detail on what the actual process is in your organization and what exactly is expected from QA and from marketing? You are asking whether it's ok to take over some steps of the process, but don't tell us what steps those are. Is it complete lack of specifications? Why, in your opinion, does the process fail?
    – user631
    Jun 11, 2011 at 7:08
  • Complete lack of specs due to work flow short cuts.
    – Theo
    Jun 14, 2011 at 13:33

5 Answers 5


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.

  • 3
    +1 as this reflects the nature of Software Quality Assurance being everyone's job. Additionally, the principle of open communication and collaboration within a project is key even if there are clearly written specs. Sometimes even a clearly written spec leaves out key details that only a collaborative effort can discover. Jun 10, 2011 at 13:14
  • 1
    We use a Q&A section on our functional specs on our team wiki to help spec out gray areas. As the whole team gathers information, they update the Q&A section of the wiki so we have the information in one place. Jun 10, 2011 at 18:15

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.


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.


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.

  • 3
    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.
    – stuartf
    Jun 10, 2011 at 11:56
  • @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.
    – user631
    Jun 10, 2011 at 16:47
  • 1
    "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.
    – stuartf
    Jun 10, 2011 at 18:16
  • @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.
    – user631
    Jun 11, 2011 at 7:04

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!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.