Many times when I go to a client and tell him that his QA team needs to start at the beginning of the project's development process I see a wondering look at his eyes.

A good QA process needs to start as early as possible in the development process, the type of testing that is being done at that early stage called "Static Testing".

"Static Testing" is basically documentation testing and code testing but without using the software, for example "Code Reviews".

When the software is used for testing it is called "Dynamic Testing".

In this post I will focus on the "Static Testing" of the requirements only.

Why should we test the requirements?

Research shows that over 80% of the bugs are introduced before a single line of code is written.

If we think of that it make sense, how can a developer write a good application if the requirements are faulted? How can a tester test the application if he doesn't know what exactly to test? How the user can finally get what he needs if the developers don't know what exactly to develop?

So we can see that the base for the product's quality starts with good requirements.

I don't say that this is the only parameter for good quality, but it is the most influencing parameter and that people don't know.

Now we have a new question coming:
Why the QA team should test the requirements?

The QA team member has a very unique view, the QA team member can see that the requirement is testable, he can see if the requirement is well defined and he can put himself in the user's shoes by that he can spot usability problems before a single line of code is written.

Important: I don't say that the QA team members are the only people that will test the requirements but they must be in the list of people that tests the requirements.

We can see that the QA team member needs to have a wide knowledge in many fields, one of them is requirements and documentation.

Have Fun!!!