Difference between revisions of "Test process"
(cross-linking) |
|||
| Line 1: | Line 1: | ||
{{Expand|text=Here is a page for kicking off the discussion of what Dreamwidth's QA test process should be.}} | {{Expand|text=Here is a page for kicking off the discussion of what Dreamwidth's QA test process should be.}} | ||
| + | |||
| + | For automated testing, see [[Dev Testing]]. | ||
Notes: | Notes: | ||
| − | First Stage of Testing: | + | |
| + | ==First Stage of Testing:== | ||
First step: | First step: | ||
| Line 15: | Line 18: | ||
Checklists to follow to document tests. | Checklists to follow to document tests. | ||
| − | Second Stage of Testing: | + | ==Second Stage of Testing:== |
First step: | First step: | ||
Latest revision as of 11:23, 7 November 2015
For automated testing, see Dev Testing.
Notes:
First Stage of Testing:
First step: Load test the individual virtual machines to ensure acceptable levels of load on DB writes and open sessions. All DB Writes should be tested with the accounts used by the DW code. I'm not much of a developer, but I'm sure there are bigger brains who can write a quick script to do this.
Second step: Test failover, and test data integrity at the time of failover. It would be good to prove that the cluster is sharing the load, rather than forcing everything onto one machine, and only distributing the power over when that hits capacity.
Third step: Load testing to see how many sessions we can open before we see a performance hit.
Checklists to follow to document tests.
Second Stage of Testing:
First step: Test DW with unmodified base code. Test for load and failover.
Second step: Introduce code changes one by one, and test for load and failover.
Third Stage: Introduce users in a controlled way. Schedule simultaneous imports and exports. Schedule imports and exports in failover mode
