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)