Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Advice on Test Plans and Stress Testing 1

Status
Not open for further replies.

bobbarker

Programmer
Dec 20, 2001
83
GB
I would appreciate any suggestions of (free!) references or resource on creating formal test plans and planning stress testing in a multi-user environment.
Am developing a new project much larger than projects I had previously worked on.
My previous experiences have been on applications with maybe up to 5 end-users in one site.
My current project is for up to 25 users over 2 sites using a new database platform that I have little experience in.
My test plan will require consdierable input from my customer with regards to upgrading some of their current software, creating test data and participation in stress testing so I am keen to document my requirements from them in addition to formal documentation of agreed benchmarks.
Many thanks in advance.


 
The basis for your testing should be your requirements. Based on the testing-V as described by Weigers in his requirements book, requirements are refined chronologically in the following order:
User Requirements
Functional Requirements
Architecture
Detail Design
Each of these design steps has a corresponding testing phase, which occurs in reverse order from the design.
Detail Design has Unit Testing
Architecture involves Integration Testing
Functional REquirements have System Testing, or Verification
User Requirements have Acceptance Testing (or Validation)

Each of these testing phases should have its own testing environment, separate from each other. The objective of each testing environment is to control the scope of the requirements (now features) being tested. By limiting the variables being tested, it becomes easier to determine the location of an error and to repair. Hopefully, the error is not so severe that it becomes necessary to return to the design stage. However, if this becomes necessary, testing must return to the Unit Testing level, not at the testing phase where the error was detected, an often forgotten step which can introduce more problems.

Although Acceptance Testing requires the end users (as completion requires user signoff on their User REquirements document), strong Power Users and Subject Matter Experts should be available earlier in the testing process to create test cases, scenarios, and data.

Well, I'll stop here, before I get really going and decide to write an article for the trade pubs on this subject. Feel free to ask any specific questions and I'll be happy to give you the answer, my opinion, and/or a reference to check out as applicable.

==============

Sometimes the grass is greener on the other side because there is more manure there - original.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top