QA/QC involved in requirements or after requirements / design is complete

Question

As a QA lead or QC/tester, in your company/projects, were you involved in the discussions during requirement phase itself or only during or after design/development phase?

Answer 1

Preventing bugs is always preferable to catching them. Use the 1/10/100 rule. The cost of catching a bug in production can be an order of magnitude more expensive than catching it in test, which can be an order of magnitude more expensive than catching it before it's been written. QA should strive to be involved earlier in the development cycle in order to help guide the developers to writing relatively bug-free code rather than waiting to catch bugs (and suffering under the constraints of buggy specs.)

Answer 2

The earlier, the better. In addition to what J Doe says, that the earlier you catch defects, the better, being involved with the design and implementation can lead to more testable code.

For example, there might be areas of error recovery code that would be difficult to enter in a normal environment, so the code could be restructured, or an additional runtime switch provided, to make it easier to test that code. Similarly, you can make sure that appropriate types of logging are included that could make verifying certain tests easier. If you're doing function/white box testing, you can advocate for having modules be as simple as possible, to facilitate test coverage and regression tests. If you're doing black box testing, you shouldn't be paying too much attention to the design, aside from advocating for more testable code, but you can be an advocate for the end user, in terms of installation, configuration, and documentation.

Answer 3

I have been involved both before and after the requirement phase, more recently with Agile organizations where requirements are constantly collected.
From these experiences I have learned that being involved before requirements is beneficial because:

• You get a chance to give input on testing requirements
• You get to both learn and provide input on the business domain
• You become part of the development team earlier and hear all the conversations
• You get to hear high level requirements and thus learn the company's quality metrics
• You can get folks to think about happy, sad, additional and optional workflow requirements
• You can provide input on designs that you know will be troublesome and bug-prone early on
• You get a chance to get ask about devices & browsers and get a sense of what testing will cost

Answer 4

As QA I have worked in 10 different projects and clients. Client throughout the world. I observed below points with respect to the above question asked by @kankara.

• It depends upon when does client involves QA into the project. It would be requirement phase or would not.
• It also involves how much knowledge the client possesses on Quality Assurance and Engineering of the product, importance of quality awareness.
• If you are involved in requirements phase you could find if there are any requirement misses and it would be a huge cost saver as fixing bugs related to requirements would be higher in later stages when it comes to waterfall model.
• If QA is involved after design or development face he might not understand there is not possibility of finding defects early in STLC lifecycle.

Please refer to below pyramid for more details.