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.
2009-01-21
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:
On the Con side:
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.
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.
2009-01-17
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.
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.
2009-01-08
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
In a similar manner there must be a way to report the bug's priority according to project requirements.
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
- Missing\wrong messages
- Not perfect functionality
- GUI friendliness
- GUI - Spelling errors
- Documentation errors
- Feature malfunction
- ‘Bad’ errors messages
- Fields validation
- Translation problems
- Missing Install Shied
- Missing documentation
- Wrong version
- System\Component Crash
- Data loss
- Missing Feature
- Security intrusion
- Performance failures
- Customer determination
- Stops Testing progress
In a similar manner there must be a way to report the bug's priority according to project requirements.
2009-01-07
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:
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:
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.
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.
Subscribe to:
Posts (Atom)
Posts
