| || |
should QA be a part of requirement ?
Should QA be a part of requirement gathering? If yes, what should be the role ?
Re: should QA be a part of requirement ?
Yes....to verify that all the requirements are testable, list out things that should be tested, may need to estimate the project and it allows you to know what the customer really does.
For instance if a non-testable requirement is that the system needs to go fast, how fast is fast? Is it faster than there previous system or do they have a set SLA?
With the previous requirement you know that you need to do performance testing, most likely functional testing needs to be done, etc. If they do international business then you know that you need to research their markets for localization testing.
Its also good to be involved in the requirements gathering phase because not all the information is in the documentation and you may not know the customer tendencys which could cause an inaccurate estimate.
The other reason is that you can learn about the customer's business processes by being involved in the requirements gathering phase. This will help you in testing because you will understand how they will be using the system, their terminology and their expectations. A big part of how someone interprets a quality piece of work is based on the expectations of that piece.
I hope that helps! [img]images/icons/smile.gif[/img]