Test writing Guidelines

In one of his latest blog entries, a friend of mine writing a blog regarding system engineering discussed the basic design questions When thinking of how to start writing a test plan you need to make sure that the said test plan provides answers to certain questions which are very similar. 1. What: what is the system supposed to so? - Functionality in general 2. How: what are the steps for the above mentioned ? Functionality in detail 3. How much: basic estimation of capacities / throughput. - load and system benchmarking 4. When: when do you want the solution? * we need to cover the first 3 questions if we are to write a full testing specification. When approaching the task of writing these tests we should not contemplate about the feasibility of the tests but rather create what I like to refer to as a "Tests wish list" only after covering all relevant aspects of the feature / component / system and reviewing this can we ask and answer the last forth question - In an idealistic world time is not a factor but in the real world we need to take into consideration the following: * delivery commitments in respect to dates or content - which may affect the order of the tests * simulation capability - on systems handling external inputs ... can we simulate this type of input / how much will it cost us? and so on. how ever the pure test plan should not include these aspects since making allowances in the test writing phase will lead to not testing the system.

Virtualization and its contribution to QA

There are many benefits to using virtual machines in testing. First, we need to bear in mind that applications change, and QA must test different applications in different conditions. for example testing different UI applications on different host types will potentially require a lot of resources which in these times of financial instability may pose a problem, since theoretically, it will require separate machines for each type of set-up, in the same manner when keeping a big version install the base you will need to maintain different machines running different versions of the SUT (System Under Test). In order to provide for this need one of the best cost-effective solutions would be running multiple virtual machines. This solution allows for running endless versions in parallel... this is effective for both QA and Support since one can simulate defects/ retest them knowing with full confidence that his system is identical to the one of the customer reporting the problem. further to this virtual machines can be used to allow easier/ simpler deployments or upgrades, since you can send the machines preconfigured in advance from the factory. As can be seen, there are many advantages to using virtual machines in QA.

Formal QA Education - do we need it

I recently attended a conference regarding a new release of the HP Quality centre product.

One of the guest speakers was a person involve with ITCB organization.

The ITCB organization is the Israeli branch of the international ISTQB the organization is involved with certifying QA testers. and in trying to set criteria

• which will mark the level of QA engineers.
• Create a common language used by all.
• Provide QA with tools and skills to perform their jobs more efficiently
  
• grant official and formal acceptance if the QA as a credible occupation

after we returned from the conference an argument arose between us in respect to the actual need for such an organization and what are the advantages and dis advantages of such a certification.

On the Pro's side we noted the main goal of a formal language and developing better personal testing capabilities which young testers tend to lack.

On the Con's we were concerned that this course / certification will become mandatory and therefore block acceptance of otherwise capable engineers for QA positions

My opinion is that the general idea is sound and will contribute to QA professionalism where ever implemented and may put an end to low opinion of QA personnel which I mentioned in one of my previous blog's .

How ever I think the certification should be a part of the training and not a a threshold factor preventing the acceptance of otherwise capable engineers.

I can testify from personal experience that most of my QA team where technically capable people which were mentored and bloomed into good QA engineers.

Further to this from the following diagram

We can see that Quality Assurance skill are only part of the makings of a good QA engineer.
To conclude I think this is the proper way to approach this rather than using the certification as a filtering tool

Version Releases - how do we make it comprehensible

One of the most obvious tasks the QA is responsible for is the version release at the end of the testing cycle.

First let me emphasis that I do not believe that the version release is solely under the QA's responsibility the release process is a lengthy process starting with the designer/ programmer and ending with the QA.

Next we must bare in mind what is the purpose of the release meeting?!?

I believe that this meeting is intended to provide a "Version Status Report" to all the relevant share holders, for example :
R&D Manager
Marketing / Sales
Project Managers
..

It is point less to expose the extensive list of people to a dry list of bugs and descriptions.

I believe it is up to the QA to make a clear presentation of the version status.

For example instead of presenting a table listing bugs , the first page in the presentation should be a "Grade" of sort to the version;

Version is GOOD , MEDIUM, BAD ... we can even colour code it for better presentation for example

GOOD will be marked in GREEN
Medium will be marked in ORANGE
Bad will be marked in RED

Those grade can be discussed and agreed upon in advance where each grade will be related to a certain amount of bugs, e.g.;

GOOD = 0 "Show Stoppers", X "High", Y "Medium", Z "Low"
MEDIUM = ...
BAD = ...

management will first get a certain idea as to the version quality.
and then if they wish to get more details they can drill down and see
...

Before going any further I'd like to discuss the platform on which we present the release ...

While I may be breaking some sort of TABOO I do not think word / any other form of document is the way to go.

I think web interfaces will serve us better providing better clarity and flexibility.

The Whole idea revolves around the concept of trying to avoid data overflow.

I believe we should not expose all the data flat out since it will confuse the higher levels of management.

I propose using hierarchical rather then flat description.

This is easily achieved using web pages.

The main page will contain a table with a list of the released Base Lines along side their grades.

Each BL will be a link allowing to view what is the BL content and what are the elements making up the grade (number of bugs, coverage rate)

Each number of bugs will be a link to a table listing what are the bugs exactly .

Last but not least each BL should have a version delta page listing what new features were added between the last released BL and the new one.

For Complex Systems a Components Table should be available detailing the different component versions and if needed installation instructions pages.


To be Continued...

Testing Plans - Optimal vs. Real life

Up Until now I have discussed what we should strive for in the QA.

How ever one must bare in mind that there is a difference between an extensive testing plan and its actual implementation.

One of the best signs for a QA maturity is the ability to prioritize and plan a head taking into consideration the feasibility of an actual test plan.

In the normal flow the QA engineer will map out the entire test plan covering all the little bits and pieces needed to be tested.

The QA team leader will then take the raw plan and organize it according to time table limitations.

This re-organization can be consisted solely from re shuffling the tests order to allow a better , more effective release picture in a shorter time.

How ever in some case a little more joggling may be called for when the time frame needed for a full test cycle exceeds delivery commitments.

When faced with the second option we as QA will need to perform some risk assessment in order to consider which parts of the tests can be dropped.

The risk assessment process is a very critical phase since it calls for an ability to see the whole system ... a wrong assessment will lead directly to system problems on the costumer system.

The risk assessment can and should involve others except the QA team leader.

In any case the tests which were dropped and the risks taken should be voiced clearly in order to inform all of the interested parties to the compromises made in the test plan.

Support and Deployment - What is the best way

There are several methods to implementing a deployment, I would like to mention but two which basically display the two far ends.

The All-In-One (my name for it) or the Specialists (my name for it).

The All-In-One approach basically means that the manufacturer handles all parts of the Installation/ Deployment/ Support through one person.

The merits for this method are that the costumer interacts with one person which is responsible for providing all of the answers to all of the different questions.

This type of approach is feasible with certain limitations:

1. The person handling this role has the required capabilities and in-depth understanding of the system
2. System complexity allows a "one man show".

How ever if these limitations are not met then basically what we get is embarrassment in front of the costumer since problems are bound to arise and when the "One Man Show" is unable to provide answers in time/at all this reflects badly on the provider.

The Second method usually works for high complexity systems, in which the manufacturer assigns a team to a project where each of the team members is responsible for a segment of the system and is capable to provide in-depth insight to his part of the system. This may also contribute to a certain amount of respect from the costumer since he receives exact answers to each questions with great detail.

There are obviously down sides to this type of costumer approach since it:

1. requires greater resource allocation
2. costumer may get a feeling of being directed from one person to the other according to the question which he brings up. - this can be handled by assigning a strong PM to the costumer.

Basically both method have advantages and disadvantages it is only a matter of deciding which is better for the system the manufacturer is providing.

If we choose the all-in-one method for a complex system we risk having the one man become both an embarrassment to the company and a "nuisance" to R&D since he is unable to handle requests/ queries from the costumer.

If we choose the specialist approach for a simple system we are wasting resources and reducing profitability un-necessary.

Therfore Choosing wisely is critical.

Bug Status List

since one of the focal point in the QA is testing and its by product - the bug , I thought I should spend some time detailing the bug status list - the list below is one which I think is most efficient , mind you in my organization we do not use it in exactly the same manner :(

Open - The Initial state of the Bug when the QA has reported it for the first time.

Non Reproducible - This state is marked in order to let the programmer know that this bug has been observed but can not be re- produced.

Fixed - Once the Programmer has identified the source of the problem fixed it and released a version to the QA, the Bug status will be changed by the programmer to this state - pending QA re-test confirmation.

Re-Open - Once QA has received the Fixed version it will re-test, if the bug re occurs QA will then mark the bug as re-opened

Closed - Once the bug has been retested and the fix is confirmed then the QA will update the bug status to Closed.

• Next two status options are not with in the general bug life cycle for obvious reasons.
  

Duplicate - when the same bug has been reported twice ( by two QA engineers or when one problem report arrives from a costumer and another from the QA) the bug will be reported as duplicate and the fix will be marked only on one of the duplicate bugs.

Behaviour - Not a Bug - This status marks this certain "malfunction" is by design - basically indicating that QA may have miss understood the design and suggested solution according to the MRD/SRD ... (http://qa-regarding-qa.blogspot.com/2009/01/qa-methodology.html)

QA and Support - what is the connection

In the general scheme of things as I see it there are two avenues between the manufacturer and the costumer.

The First is from the manufacturer to the costumer , in which a product is manufactured then tested and at the end released for the costumers use.

The Second is from the costumer to the manufacturer, in which the costumer will report a problem to the manufacturer and hopefully be presented with a solution by the support team.

obviously the two avenues must mix, the question is where and how often.

In the following caption I'd like to present what I think is the proper manner for interaction.

When a problem arises from the field (costumer) the first task is information gathering, if this is performed well then we are one step closer to resolving the problem.
In one of my previous entries I mentioned this when I noted you have to know what questions to ask and what to look for.

One of the most popular support method involves different TIER levels.

Each level is suppose to perform a sort of analysis and attempt to resolve the problem... only upon reaching a deadlock will the problem ticket be passed on to the next TIER level.

Each TIER has different capabilities and is intended to handle different sort of problems;

TIER I - will usually handle small operative problems : electrical and other communication problem should be ruled out, if the problem has not been resolved by this level it shall be passed to the next level.

TIER II - this level will usually handle all configuration malfunctions in order to rule out problematic setup and system definitions. Once this option has been ruled out the next support level has to be involved

TIER III - in this level actual debugging of the problem must be done ... for this the support engineer will need the system configuration files and proper relevant logs ... all of these can be collected in advance by the previous TIER level in order to save time and face with the costumer.
Once configuration has been determined and an exact suspect scenario has been chosen the support engineer needs to attempt to reproduce the defect for the benefit of the R&D team which will need to handle the problem.

reproduction is critical because it will allow us to verify the fix once it has been implemented ... but in order to be able to do so the details mentioned above are a must!!

The next phase in the support cycle will be the TIER IV.

TIER IV - this support level is with in the R&D and its role is to co-ordinate the fix and its release.

Once the Fix has been completed by the R&D team it is up to the QA to retest according to the scenario detected by the TIER III engineer.

In some cases QA may also handle the original reproduction instead of the TIER III engineer but in order to do this effectively and successfully they must have all the relevant information prior to the reproduction attempt.

To summarize:
A support group MUST have an organized data/ information collection and distribution method!

Since with out it time is wasted in each support level from the beginning which in turn causes great over head for the fix.

Integration - is it QA or not

During the past couple of weeks I've been involved knee deep in integrating between two of our system components.
On a personal note I do find it very interesting, since integration in it self does not follow all the strict QA methodology.
This in turn started me thinking as to whether or not we can consider Integration as part of QA.

On the Pro side:

• System is being tested for functionality against pre-defined input scenarios.
• Problems are reported to developers for fixes

On the Con side:

• There are no regression testing.
• there is no definition for test cycles/ version release cycles
• There won't necessary be official releases but rather temporary patches.

My final conclusion is that I do believe Integration can be classified as a "Testing Cycle" of some sort.

My only concern in this respect is the following.
a given fact is that early integration basically translates to non working product.
a separate time table must be allocated, and at least two weeks should be added to the regular time allocated for testing since this is roughly the amount of time required for the integration to yield a working product.

Only upon meeting these conditions will we be able to complete a real system testing and thus include in our test reports a Integration Cycle.

QA - The Human factor

When discussing QA we can not neglect talking about the people who will perform the task.

In my experience there are several types of people who do QA work, the types are affected by the attitude of the companies towards QA and their view in respect to its importance.

Here in Israel there are 4 types of Testers:

The Temp - This type of tester is usually in between, he will usually be a person fresh out of military and on his way to the the big trip/ university.

He is looking for a way to earn some money for the above purposes and can not be depended on in regards to long term plans



On His Way to Development - a close friend of the tester mentioned above , this one is usually already spent a couple of years studying and plans to start working in the R&D, he is basically looking for a foot hold in a company in hopes that it will open the door to a development position.



Can't find any thing Else - this type of tester has been forced into trying to find work in QA since he can't seem to be able to find work else where, the only reason he got hired as QA is that some one has very low standard for QA and very poor opinion as to their role in the development process. *



Serious QA - This is the type of person you would like to see handling your testing process.
This type of QA Engineer will usually have some formal technical education , he is here to do QA work and will focus in being efficient and productive, he will invest the time in researching QA methodolgy



* The Question the Pops to the mind is obvious why would any one hire for QA work any other then the forth type of tester.
The reason as always is complex, but the root cause is similar to the chicken and egg question, which came first.

basically what happens is this , due to lack of available type 4 testers mangers are forced to look at the other types ,this in turn harms the professional opinion in regards to QA engineers , which in turn causes HR in companies to lower the salary bar for QA which ... are you ready for this causes less people to be interested in careers in QA.

And here we go again.

Just for an example :
a few years back some one approached my QA Manager in regards to a vacant position in one of our teams, when my manager inquired in regards to relevant experience the developer which made the inquiry raised a brow saying "what do you mean he knows nothing... what are QA suppose to know"
The problem is that it is not just one person but the entire industry is plauged with this misconception

Managers and HR do not contribute by setting low standards and low wadges , another example, in our QA group which is in charge of testing a very telecom related system most of the QA do not hold any degree and those who do have had no relevant telecom education.

Bug Severity Guide Lines

The Bug severity will display what is the impact on the SUT according to the QA tester.

In order to avoid miss understandings and inconsistencies it is best that a table of sort be presented and agreed upon between all QA testers and vs. the Development group.

please review such a table below:

Low

• GUI ‘cosmetics’
• General minor issues

Medium

• Missing\wrong messages
• Not perfect functionality
• GUI friendliness
• GUI - Spelling errors
• Documentation errors

High

• Feature malfunction
• ‘Bad’ errors messages
• Fields validation
• Translation problems
• Missing Install Shied
• Missing documentation
• Wrong version

Show Stopper

• System\Component Crash
• Data loss
• Missing Feature
• Security intrusion
• Performance failures
• Customer determination

QA Stopper

• Stops Testing progress

One can argue about the table above the only thing critical is to have such a table, and that all the relevant parties agree on it.

In a similar manner there must be a way to report the bug's priority according to project requirements.

QA Methodology

Once we have dispatched with most of the preliminaries it is finally time to get to the bottom of QA - Methodology which is directly linked to documentation.

The document trace usually follows along side the product life cycle which I described in a previous blog entry (product life cycle).

Once the Product manager has decided what are the main features for the product/ version he will then release a document describing these requirements called a MRD (Marketing Requirements Document).
Following this document System engineering will usually output an SRD/PRD (System/ Product Requirement Document) - this document will detail what of the requirements is to be implemented and what are the priorities.
the QA in turn will then review this document and start preparation for the testing.

First QA will generate a STP (System Test Plan) this will describe:

• what is to be tested
• testing set-up
  
• testing requirements (resources)
  
• General time table which should correlate with R&D releases

The STP is usually prepared by the QA manager/ Team leader
Once the general STP has been released and approved it is time to get down to the details of the testing. the STD (System/ Software Test Document)
The STD will usually be prepared by the QA assigned to preform the tests.

When the tester has finished writing the document then a DR (Design Review) will be held in order to approve the STD.
we must make sure the following attend the DR:

• Product Manager
• System Engineer
• Developer / Developer team leader
• QA tester
• QA team leader
• Project Manager - to provide costumer related info if necessary.
  

Once the version is released to QA and testing has begun, upon completion or at predefined time frame the QA tester will issue a STR (System Test Report).
The STR will detail what tests were actually done and from those tests which passed and which failed , for the tests that failed we will include a short description of the fault and list the relevant bug report.

At the end of the test cycles have completed a Release meeting will be called, in it QA will present the last segment of documentation the RN (Release Notes) these will include a list of the bugs fixed in the version and a list of the bugs still open at current according to bug severity's criteria.

It is vital to understand QA is not releasing the version but rather giving a status report as to its quality, the decision whether to release or not is at the hands of the R&D manager and the Operational Manager according to external constraints.

Testing Phases / Parts What are their meanings

First let me start of by saying the QA is a very methodical occupation, there is a time for every little step, with that being said we can now discuss the different stages in the version testing cycles:

Functionality - this phase involves checking the a new added functionality has indeed been added for starters and further more we would test and make sure that it is functioning as expected according to system requirements.

Regression - in this phase the tester will continue on to test that old / previous system capabilities have not been affected by the change code done for the new features.

Bug Fixes - this phase is not part of every version cycle tests since it depends whether any bugs were fixed, basically QA is expected to go over the version Release Notes and verify that all the bugs marked by the programmer as fixed in this version have indeed been fixed. e.g. QA will have to simulate the conditions which brought on the defeact in the privious version and very that the defect does not occur in the new version.

Performance - every product has certain dimensioning requirements, regarding the amount of input it can handle, in this phase the QA will verify that the system can indeed handle the high marker for system input as specified in the System requirements by the product manager.

Stability - in the same manner where a certain maximum input load is defined for a specific system then a certain steady state should also be decided upon between product manager and system engineer.
according to this steady state stability tests are run checking system functionality over an extended period of time to see no system error occurs during the said time, stability tests can run from hours to days or weeks

Attacks - in different SUT's (Systems Under Test) this test phase may be called in different names, in general this test phase will include abnormal use of the system to check for ability to receive abuse by hostile/ untrained operator.

Sanity - this phase is one of the critical phases. basically it is a collection of several test cases from all of the above phases (almost) which is meant to give a quick picture of system state after receiving a bug fix /patch.
Again this will not test the entire system but rather a brief run through the system in order to reflect system state to relevant parties

Cyclic Testing vs. Itertive Testing

Iterative testing -

Simply means testing that is repeated, or iterated, multiple times. Iterative usability testing matters because the ultimate goal of all usability work is to improve usability.

Iterative testing is usually helpful in early development steps and can be considered as part of the integration process.

Cyclic Tests -

This is the type of testing we usually associate with classical testing in Cyclic testing the work is more methodical.

The content of a released version is usually divided into several parts.

We would usually try to test new version features in the earlier cycles later moving on to regression.

We should incorporate bug fixes cycles during this cycles provided we receive bug fixes during the test phases.

We will discuss the different parts in more details in future blogs.

Bug / Problem reporting the right and the wrong way to do it

There is an entire Methodology behind bug/ problem reporting.
There are many tools used for bug tracking and reporting.

all of these do not matter, we need to keep in mind the purpose and the goal for which we report a bug, if we do this then all will be well.
According to the Bugzilla site :(https://developer.mozilla.org/en/Bug_writing_guidelines)
The guidelines to problem reporting are detailed below:

• Be precise
• Be clear - explain it so others can reproduce the bug
• One bug per report
• No bug is too trivial to report - small bugs may hide big bugs
• Clearly separate fact from speculation
• Reproduce your bug using a latest version of the software, to see whether it has already been fixed.
• When system configuration is relevant specify it.
• When log files are available provide them.

Following these guidelines will ensure the programmer understands you and has all the information to solve the problem... it obviously does not guarantee bug fix times

Trouble Shooting Guide lines

During the earlier days of my career I found my self constantly being called on Costumer site for trouble shooting reasons .

I would usually discover when arriving there that the so called complex problem is easily solved by a simple and short analysis session.

I tried to lay out some guidelines for others to follow in order to enable them to do the same.

What it basically comes down to is asking the right set of questions in the right order.

the questions which guided me were:

1. locate the first step/ component to indicate a problem
2. what is the cpu/ mem utilization?
3. which application is consuming the most resources?
4. open the log files
   
5. look for the most recent error message
   
6. what does it say
   
7. what does it mean
   

When answering these last two questions you can generally solve most problems.
At one time I traveled to one of our costumer sites in the east.
Problem report was system was malfunctioning and missing several input responses.
When arriving on site I noticed that the gate component was running at high CPU utilization (~90% steady state)
when reviewing the logs I noticed a configuration error.
Once I handled this I noticed that the CPU did not drop.
I reviewed the logs again and noticed that the same error message is being printed at a very high rate ( which was causing the high CPU utilization).
I turned to the programmer and requested to reduce the debug level for the specific message (since it was pointing to an not mapped input type and not a system problem)
Once this was accomplished all other problems were gone.
Problem Solved.

If the field Engineer /Support follows this rules he can generally get to the bottom of the problems or at least point R&D in the right direction

This in my opinion is the true meaning of On site Field Engineering, other wise it would mean that the Field Engineer is expected only to perform the "Next, Next, Next, ..." installation type.... Is this what Field Engineers are for ?!?

I Don't think so.

QA On Costumer Site - rules and guide lines

There are very specific criteria to determine when QA is needed on site , as I see it only if these criteria are met then there is a point to assigning QA to the costumer site.

1. Costumer has specific system inputs which can not be simulated in a lab.
2. Specific problems can not be simulated in the lab .
   
3. Tests did not complete prior to deployment, and costumer is willing to provide a testing environment.
   

In general as you can see I think there are very few occasions justifying QA on site , how ever since on many occasions system know how is lacking and QA is forced to travel to site . When On site the following rules should be met...

1. QA has traveled on site for a specific purpose it does not include costumer instructions/ politics on site installations etc...
2. when reporting from site QA should maintain the same guidelines directing him when reporting a bug from the lab.
1. be clear and to the point
   
2. describe a specific and exact scenario
3. provide all possible available debug information
4. describe system configuration with all necessary detail

Once these rules and guidelines are followed we are certain to make the most of the QA visit on site.

When this need actually arises

QA and IT - to install or not to install - that is the question

When dealing with QA yo must remember that there are extensive IT requirements, this is of course product dependent , but for true QA to exist, several things must occur which relate to IT.
First and foremost Product Manager/ System manager must define :

• on which Platform the Product must run.
• What are the minimal system requirements for the product.

once the above has been determined it is extremely vital that the QA performs tests for all of the System configuration defined;

And here comes the tricky part who is in charge of the installation and maintenance of these environments.
In the organization in which I am part of w do not have a separate IT group. this creates havoc in my opinion for the following reason.

1. Not all QA are predefined to have IT capabilities and thus a lot of time is wasted due to insufficient skills.
2. Since no proper IT exists there are no predefined sets of instructions as to how and what exactly to set up with in the Platform itself
3. QA time is "wasted" on OS setups.
4. Since QA are not exactly qualified for this they find it difficult to issue clear instructions to system Field Engineers on how to set up costumer systems, thus creating in consistency of OS types and configuration ... which basically will lead to unexplained problems from specific costumer with out any clear reason.
5. No one can handle new hardware certification/ old hardware End-Of-Life replacement.
   

In my opinion it is vital to have a strong IT group in every company , and not just for the sake of handling the tedious tasks of system setup but in order to set up guidelines so that we create a consistency between all of the systems installed among the different costumers

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 .