Sunday 27 November 2011

Our Current Test Process


There have been several comments on past posts about the importance of testing changes to the system. This is done by the team currently, and is capture in reports. I thought I would simply provide some additional information for clarification.

Our process dictates that when we test a build we do the following:
  1. Run Acceptance Tests.
  2. Test all changes. This is done through using our bug tracking system. When a build happens, the bug is moved to a Verify state. The test team self organizes and each tester decides what to test and verifies the issues. Each change the developer does to the code is matched to either a bug in the bug tracker, or to a User Story or Task on our sprint board. This ensures we test all the changes.
  3. Run through all other test cases based on Coverage Level. In an earlier post I said Priority, but in truth it is Coverage Level. That level is determined at the beginning of the sprint on how much testing we require on a map. Remember, each functional area of the product has one map. We test the maps where the changes occurred to ensure that no other areas were broken by accident.
  4. Results are updated on our Dashboard.
  5. A summary is sent out to all those that are interested, which include a copy of our Dashboard, a list of new bugs found, and the list of verified changes.
I hope this post gives you some clarification on what we do when we receive a build to test. A future post should also write about our overall process during a given sprint.

No comments:

Post a Comment