Thread

Skip Navigation LinksForums > SpiraTest Forums > SpiraTest Best Practices > Best Practices for Testin...

Best Practices for Testing Multiple Releases Using SpiraTest RSS Feed

Monday, March 12, 2012
  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
Tags:
(To Reply to this thread you first need to Sign-In)
3 Replies
Adam SAdam S
re: Adam S on Monday, March 12, 2012
Saturday, June 30, 2012
Please let us know if you have any feedback or alternative suggestions.
(To Reply to this thread you first need to Sign-In)
Grant BellGrant Bell
re: Adam S on Saturday, June 30, 2012
Wednesday, July 3, 2013
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?
(To Reply to this thread you first need to Sign-In)
Robert C MehlerRobert C Mehler
re: Adam S on Monday, March 12, 2012
Monday, February 24, 2014
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.
(To Reply to this thread you first need to Sign-In)
Tagged
Statistics
  • Started: 3/12/2012
  • Last Reply: 2/24/2014
  • Replies: 3
  • Views: 6343
Powered by KronoDesk v1.1.0.15 | © Copyright Inflectra Corporation 2011-2016 | Licensed to Inflectra Corporation.