Skip Navigation LinksHome Page > Forums > SpiraTest Forums > SpiraTest Best Practices > Best Practices for Testin...

Best Practices for Testing Multiple Releases Using SpiraTest

Monday, March 12, 2012
Avatar
  1. Create an entry in SpiraTest for release v1.0
  2. Write test cases, and assign to release v1.0
  3. Create test sets, ensuring they are assigned to release v1.0, and give them to the testers
  4. Perform testing
  5. When testing passed, deploy software
  6. Create an entry in SpiraTest for release v2.0
  7. Select test cases from v1.0 that should be carried forward to v2.0 and assign them to release v2.0
  8. Deactivate (not delete) the release v1.0 entry
  9. Optional GÇô perform smoke test
  10. Write new test cases to exercise v2.0 functionality, and assign to release v2.0
  11. Augment existing test sets, or create additional test sets, ensuring they are all assigned to release v2.0, and give them to the testers
  12. Perform testing
  13. When testing passed, deploy software

14. Repeat steps 6-12 for future releases, incrementing the release version number each time
(To Reply to this thread you first need to Sign-In )
3 Replies
Saturday, June 30, 2012
Avatar
re: inflectra.david Monday, March 12, 2012
Please let us know if you have any feedback or alternative suggestions.
Wednesday, July 3, 2013
Avatar
re: inflectra.david Saturday, June 30, 2012
Adam will this provide MI reports covering test set coverage for all releases?

E.G Total of 20 test cases applied to 10 Test Sets - Some of the test cases are applied to multiple test sets (e.g login test case)
       Test Sets 1-8 executed in Release 1 and has 2 Failures requiring a fix in Release 2
       2 Test Sets re-executed in Release 2 with 2 new test sets covering additional functionality

Is there a report which will provide Release 1 and Release 2 coverage at test set level?

One of the problems we have is obtaining MI at test set level where full coverage could be performed over multiple releases within a fully integrated environment built up of systems of systems. Our current proposed release structure would be to have:
Parent release = Cycle 1
          Child release = System
                   Iteration = Version number of that system - Any additional versions would require a new iteration but may fall under the same Test Cycle

Test Sets would be assigned to the Parent release to report on the full test cycle, how would i get MI at this level as i can only produce it at Child Release level?
Monday, February 24, 2014
Avatar
re: inflectra.david Monday, March 12, 2012
If I group test cases into a test set for my initial release and want to repeat these tests in a second release why can I not just assign the test set to the new release?  I've done this but my second release shows "no tests" assigned.  This would be significantly easier than having to assign every individual test case to the new release.
Statistics
  • Started: Monday, March 12, 2012
  • Last Reply: Monday, February 24, 2014
  • Replies: 3
  • Views: 8372
Tel: 1-866-572-5878 | Help Desk | Legal Notices | Privacy Policy
Powered by KronoDesk v3.0.1 help desk software | © Copyright 2006-2019 | Licensed to Inflectra Corporation.