This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
Some nuggets about testing in VersionOne
Hopefully I will be able to provide a bit of insight into using VersionOne to plan some of your QA and testing activities. My background is in QA (engineer, lead, manager) and Agile culture (ScrumMaster, project manager).
VersionOne is an agile project management tool with Acceptance and Regression Testing features/functionality; as such, it allows an organization to track the testing activities that contribute directly to the progress of a project, such as workitem completion. These features provide particularly for the planning and tracking of the work itself in the context of the project (the ‘what’) rather than in the context of the product being developed (the ‘how’).
In terms of agile practices, Acceptance Testing validates that a feature meets the customer’s expectations; in many cases, it is the customer (whether a ‘real’ customer, a Business Analyst, or Product Owner) who defines the acceptance criteria, giving the QA members of the team the guidelines of what to expect in the feature to validate that this has been implemented satisfactorily.
A common practice of testing in agile is for QA members to pair up with developers working on the same story from the beginning. The test cases for the acceptance test are agreed upon, and testing begins as soon as code is being produced (where it makes sense to start the validation process, certainly). Many teams choose not to log defects against the new code, but rather, as the QA engineer and the developer have paired up, collaborate on bringing these bugs to the fore and address them on the spot, writing new unit tests and pushing out new code through their Continuous Integration system. The acceptance tests tied to the story may provide as much detail into specifics of the feature (when VersionOne is used as the only tool to track the testing efforts), or may be used simply in binary form – for a pass/fail status.
Some common questions about testing using VersionOne:
I know I can write Acceptance Tests for each story. Where do I write integration test plans? Sanity test plans? Performance test plans?
If these types of testing/test plans contribute to the immediate acceptance of the story, certainly additional tests can be created for the story. These additional tests may also be used simply as binary markers – pass/fail – for the story; many teams that choose to use this workflow are mostly using third-party test management tools, many of which integrate with VersionOne.
Is there a way to distinguish between tests written by a PO or a QA team member?
A suggestion would be to use a custom field, where you would add a list type value for each originator. For instructions on how to do this, in VersionOne go to Help > Contents > Administration > Custom Fields. Once you create this field, you can add it to a pertinent grid, such as the Backlog, or use it to filter your stories in any list.
I have assigned Regression Tests to a Test Suite; how do I add them to a Test Set?
Test Sets are instances of all the Regression Tests in a Test Suite. Once you have added Regression Tests to a Test Suite, you have the ability to create these Test Sets. In the graphic below, notice that there is a button to Generate a Test Set – this creates the instance of all the tests in the suite, and can be scheduled to a Release or Sprint:
When I create a Regression Test, is there a way to add it to a Theme or Feature Group?
Regression Tests are essentially templates for Acceptance Tests; every time that a Regression Test is added to a Test Suite or Test Set, it creates an instance of that Acceptance Test, with the parent Backlog Item being the Test Set. Acceptance Tests are related to a parent Backlog Item as well, whether it is a Story or Defect. Tests in VersionOne are not related to Themes – the parent Backlog Items are. A Test Set, as a parent Backlog Item for Regression Tests, would be the asset to which you can associate a Theme.
More to come :-).