Milestones in Squash TM
What Is a Milestone?
In IT development, an application version contains evolutions and/or bug fixes. These (functional) evolutions come from (business) needs. They are described in the form of requirements. Ultimately, an application version is linked to a set of requirements. These requirements are themselves covered by a set of test cases and verified by a set of executions. The tests are executed within a tests campaign, which aim is to check said version.
Thus, this set of coherent objects (requirements, test cases, executions, campaign...) can be regrouped logically and tagged as being the coherent test repository corresponding to a given version of the application: test repository versioning.
Here, versioning is a simplified notion compared to code sources versioning: we are not talking about branch or merge management features. To avoid any confusion with this more specific term, Squash TM versioning is called "Milestones" rather than "Versions".
Therefore, a milestone is a label (ex: "1.11", "2013-2", "Project SEPA v4.1", etc.) given to the application's different objects that enables their regrouping under a common entity. Multiple milestones can be assigned to a single object. So a requirement that does not evolve between two versions of the application translates into a single requirement object assigned to two different milestones: that of version n-1 and that of version n.
Only users with an "Administrator" or "Project Lead" can create milestones from the Squash TM Administration workspace.
By default, milestones features are deactivated in Squash TM. To activate them, go to the Squash TM administration workspace.
To learn more about how to activate and administrate milestones in Squash TM, please visit this page: Manage Milestones.
A milestone is defined by a tag, a due date, and a status.
Usually, the tag contains the application version. The due date corresponds to the estimated acceptance end date, or the expected date for the production launch of the application. The milestone's status is defined by the user according to the acceptance cycle of the version:
- version not in the acceptance cycle yet: Planned
- version in the acceptance cycle: In progress
- version whose acceptance cycle is over: Finished
- version whose acceptance cycle is over and for which you wish to block all test repository changes: Locked
Milestone Life Cycle
A milestone's life cycle is made of four statuses: "Planned", "In progress", "Finished", "Locked".
Each of these statuses imply different rights:
- to link the milestone to a project or object;
- to create/delete/modify the objects linked to the milestones.
With a "Planned" milestone:
- You can link/unlink it to/from projects;
- You cannot link/unlink it to/from objects (The milestone does not appear in the pop-up to link a milestone to objects).
With a milestone "In progress" :
- You can link it/unlink it from projects;
- You can link/unlink it to/from objects (The milestone appears in the pop-up to link a milestone to objects);
- You can create/delete/modify the objects linked to the milestone.
A "Finished" milestone is identical to a milestone "In progress". The only difference is that a "Finished" milestone indicates that this version's acceptance is done.
With a "Locked" milestone:
- You cannot link it/unlink it from projects (The milestone does not appear in the pop-up to link a milestone to objects);
- You cannot link/unlink it to/from objects (The milestone does not appear in the pop-up to link a milestone to objects);
- You cannot delete/modify the objects linked to the milestone.
Hereunder is a summary table of the possible actions for each of these 4 statuses:
|Link/unlink a milestone to/from a project
|Link/unlink a milestone to/from a object
Every object linked to a "Locked" milestone cannot be deleted or modified. In the case of a campaign linked to a "Locked" milestone, all the elements it contains, such as its iterations, test suites, and executions cannot be deleted or modified.