Some teams rerun every test every sprint, this is time consuming and isn’t worth the effort. Having a clear understanding what tests to execute during regression testing raises the return of investment of this testing effort and gives more time to specify and execute test cases for the functionality implemented during the current sprint.
So, collecting a good regression set is important. There area lot of approaches how to get this regressions set, most of them are based on risk classifications and business value (see TIP 07. Getting Testing Done in the Sprint – Risk and Business driven Tests).
From “A good regression test is invaluable.”
The principle is that from each test case a collection of additional data is determined into the test cases for the regression test are ‘classified’. Using these classifications all cross sections along the subsets of test cases can form the total test that are selected.
Automation of this regression set is almost a must (see next TIP 03. Getting Testing Done in the Sprint – Test Automation).
Microsoft Test Manager has an interesting capability to control the amount of regression testing that need to be done during the sprint. the data diagnostic adapter “Test Impact”, it give information about test cases which are impacted by code changes
and see page 63 of the training guide http://www.slideshare.net/clemensreijnen/mtlm-visual-studio-2010-alm-workshop
How to create a regression set in Microsoft Test Manager.
Guidance for Creating Test Plans and Test Suites and read this http://blogs.msdn.com/b/anutthara/archive/2010/09/22/guidance-for-creating-test-plans-and-test-suites.aspx and this Management, preserving and organization of manual test cases within VSTS 2010.
One thing to keep in mind: In MTM2010 the copying of test cases between test plans copies the reference by default and not the test case. So, a test case can be referenced in multiple test plans and suites, changing a test step will change it on all locations.
Creating regression sets for developer tests and functional system tests are mostly more easy. Unit tests are small and run fast, so no problem to run them all. Unit Integration tests are a bit more challenging, you need to balance a bit more what to run when, but both developer tests and functional system tests, aren’t often the biggest bottlenecks in getting testing done in the sprint. When they are, try to do the same approach as mentioned above… balance what to run when.
01. Getting Testing Done in the Sprint - The Team and Activities
03. Getting Testing Done in the Sprint – Test Automation
04. Getting Testing Done in the Sprint – Undone Backlog Item
05. Getting Testing Done in the Sprint – No Double, Triple Testing
06. Getting Testing Done in the Sprint – PBI Implementation Sequence
07. Getting Testing Done in the Sprint – Risk and Business driven Tests
08. Getting Testing Done in the Sprint – Write Logical Acceptance Tests
09. Getting Testing Done in the Sprint – Test Tasks on the Board
10. Getting Testing Done in the Sprint – Done
11. Getting Testing Done in the Sprint - The Customer Test Team
12. Getting Testing Done in the Sprint – The Test Branch