QA Types

There are several types of QA which common today in the industry.
Each type of QA obviously comes in order to answer a specific need.
It is important to identify what are needs and not expect wrong things of the wrong types of QA

Unit Tester - The unit tester in general is one of the first to perform QA on the product , this type of QA will usually be done with in the development team, prior to releasing any version, this is basically a preliminary verification that the component functions as expected to a controlled (simulated) set of inputs and produces the expected outputs (results).
========================================================================
Black box / Functionality testing - This type of testing does not require the tester to have any familiarity with the architecture/technology of the tested component, he generally performs a predefined set of actions (inputs) and expects an appropriate response (output) in turn. This is usually the kind of tester people associate with testing , some one going over a graphical interface, checking all the check boxes and different screens. obviously the skills required for such QA are not high, unfortunately some think this type reflect on all QA.
========================================================================
System/ E2E testing - This type of QA usually involves high level QA ... there may not be drill down to a specific functionality but in this type of QA you most certainly have to have a good familiarity with the system flow and its architecture, further to this you must be very well versed in the technology relevant to this product ;e.g., for a telephony system you will have to have telephony protocol familiarity.
========================================================================
White Box Testing - This type of QA depends on the QA's familiarity with the technology in question in order to be able to challenge the application/product, in some respect the type of person required for this type of QA is similar to the E2E tester, how ever this QA will perform drill down testing on the product.

Product Life Cycle

In order to better understand the role of the QA with in the entire process of product delivery we first need to understand the process as a whole.

In the beginning there was the Marketing Product Manager; this person in-fact is suppose to outline the product road map and list down the requirements of the product.
The product manager will usually base his requirement lists according to market trends and need which he was exposed to, thus laying out a road map for the product and its list of features, further input/ specifications may come from specific costumers which have shown an interest in the product it self.

Next comes the System Engineer - his role will be to translate the sometimes vague requests of the Product Manager into R&D / development tasks.
basically the system engineer will lay out the method in which the solution is to be designed... his role is to design a system which answers the current requirements but keeps in mind future needs scalability and much more .
you may read more about Sys. Engineering in the following blog :
http://design-to-last.com/

The System engineering role is vitals since development with out a plan equals in my mind to a chicken running around with out a head.

Once the System engineer has completed his role come in the developers and take the plans laid out by the System engineer and devise the actual code structure .

Once code structure and design has be done it is time to get down to the dirty part of writing the actual code.

It is a common misconception to think that the QA role will follow only at the end after the programmer has completed his work.

THIS IS WRONG!!!!

If we remember the tasks we listed in the previous segment we shall see that the QA is suppose to accompany the product throughout the life cycle from infancy to maturity.

Good QA will be made part even in the early stages so they are at least aware of the Product manager list of requirements so see that they actually match the requirements from the costumer.

then , it is up to the QA to make sure the above mentioned list correlates and is fully covered in the design layed out by the system engineer.

last but not least QA will then test the product delivered by the programmer and make sure it complies with the list of requirements listed above and further to this that it functions properly with out affecting the environment surrounding it, be it the machine running the product or other machines in the network.

Good QA will try to predict costumer requirements and methods of use for the product and then test that these are actually possible .

QA Tasks

As mentioned in the previous segment the QA has several tasks, let us write them down:

1. Make sure a project is completed based upon previously agreed specifications, standards and functionality requirements.
2. Make sure a project is completed with out defect and possible problems.
3. Monitors and try to improve the development process from the beginning.
4. Preventive orientation.
   

After listing those formidable tasks we can see that the QA role is a vital one in the process of supplying a product to a costumer.

In the following segments we will discuss in further details these tasks.

What is QA

I thought that since my blog will be dealing with QA and my view on its role , I'd better spend some time in defining "what is QA?" at least in my opinion.

Quality Assurance makes sure the project will be completed based on the previously agreed specifications, standards and functionality required without defects and possible problems. It monitors and tries to improve the development process from the beginning of the project to ensure this. It is oriented to "prevention". (http://www.asknumbers.com/QualityAssuranceandTesting.aspx)

Let us take a look at this "dictionary" definition for QA, and try to gather from it the tasks for the QA engineer, let us also try and understand what are the inputs needed by the QA engineer in order to be able accomplish his tasks