| || |
Depth of testing required
Hello, I have a working knowledge of the QA process from a low level as I was involved in gathering requirements but not in a QA role in a past role. In my current role, I am tasked with creating a test strategy for the client implementation of our software. My question is this, how does this test strategy differ (implmentation of a client to previously developed product) from the strategy used for the development of a new product. The implmentation will require client-specific configure (no new build though). In the process that I am proposing, there is question as to whether or not certain levels of testing are required. One last caveat, the 'standard' product that is being released in a major upgrade from our last release therefore we have yet to implement any clients on it yet.
Any guidance you can provide would be appreciated.
Re: Depth of testing required
Depends on what your company defines a Test Strategy as, you will find different models in use all over, it may be that my Strategy is not what your company or Customer requries.
To me what a Test Strategy should include are, high level descriptions of:
- supported environments
- tools to be used in testing, and some description on how they will be used
- defect collection and information on statuses, and perhaps some detail on how they are opened and closed
- entry and exit requirements for Testing
- Test Plans, and what will be generated, but high level the detail will be in the plans
- Test Phases, detailed on what they are, why they are included and in what order they fall
Personally though, I would talk to your QA staff, from my view you haven't really done any work in the Test realm; requirements gathering to me is not really Testing or QA. But this is just my opinion, you are coming in and being tasked with generating a document to tell the Customer, and the QA staff, how the work is going to be done when you have no experience in doing what you are writing about. If you must do this, get input from the people doing the work, not here, but where you are, and make sure you listen to those people as they are the ones familiar with the processes in place at your company and have familiarity with how the product was tested in the past. They may even have their own suggestions from improvement.
Nothing learns better than experience.
"So as I struggle with this issue I am confronted with the reality that noting is perfect."
Now wasting blog space at QAForums Blogs - The Lookout