Polarion Tips & Tricks

About

Here you will find recommendations based on real-life experience of using Polarion in different projects.

We also recommend you to read articles:


Collections in Polarion - Article

Date: 19 April 2020.

Collection can be used to organize documents into groups ("packages" or "containers") and to allow people to work inside these "containers".

Collection is a containers for live documents with additional functionality:

  • Collection can be Closed
  • Collection can point to revisions of LiveDocs or to HEAD version
  • Collections can have custom fields
  • Collections have History


Traceability in Polarion - Educational Article

Date: 10 Jan 2020.

Traceability is the capability to trace something. In Polarion ALM tracebility is implemented by "links" between workitems..

Traceability helps to answer the following questions:

  • How is this item related to other items?
  • What is the type of relationship?
  • What is the impact of change in this item on the other items?
  • What is the impact of change in other item(s) on the this items?


Easy way to review Files-Diff in Polarion

Date: 14 Jan 2017.

PROBLEM: There are different text files, they shall be compared and difference shall be reviewed by the team.
For example you have Linux CONFIG files for Production and Test systems - the team shall decide and document each option of the Config file.

SOLUTION:

1. Compare two text files in WinMerge (or another program, Beyond Compare , etc)
Generate HTML report of differences.

Work Item News & Announcements in Polarion

2. Open HTML report in a web browser.
Copy the content (Ctrl+A, Ctrl+C)

Work Item News & Announcements in Polarion

3. Paste the content into Polarion work item (for example into rich-text field "Description")
Right-click on the last column. In menu select "Insert"->"Column to the Right". Name the new column "REVIEW-COMMENTS".

Now the team members can write their comments in this column. All changes will be logged in history of workitem, so you can see who changed what.

Work Item News & Announcements in Polarion


Managing News & Announcements

Date: 26 may 2016.

PROBLEM: The standard way to share Announcements with Team in Polarion is to use macro "{announcements}".

However this approach does not have flexibility: you can not group Announcements or assign them priority.

SOLUTION: The solution is to create new Work Item type "News & Announcements", whith default field "Priority" and custom enumeration field "Topic".
"Topic" shall reflect events in your Development process. For example: (a) New Software Release, (b) Update In Polarion, (c) Update In Build System, (d) Change of Compiler, (e) Meeting.

Work Item News & Announcements in Polarion

REFERENCES:

  • Showing announcements on Wiki Pages. High level scripting.
    {announcements}
  • Location of Announcements in SVN repository: .polarion/announcements/announcements.rss
  • Class Announcement in com.polarion.platform.announce.Announcement.
    Used for low level programming/scripting. Lists methods of the class, such as getContent() , getSender() , getSubject(), etc.


Managing Builds - concept of "Build Record"

Date: 25 April 2016.

PROBLEM: There is no default functinality in Polarion to keep information about Builds produced for Release.

Usually there is more than one Build made for a Release:
- "ReleaseCandidate1", "ReleaseCandidate2" - could be results of integration and additional bug fixes.
- "GoldenMaster" - could be the final build.

It is necessary to keep track of these builds and related information: name/version, description, location of binaries, versions of software/firmware components and of build system, related test results.

SOLUTION: new Work Item type "Build Record"

Work Item BuildRecord in Polarion

The Work Item can contain custom fields, which describe the "build":

  • name/version - symbolic version of the build (timestamp "201501221321", or versions and subversions "1.2.1".
  • description - describes what is included in this build and for which purpose it was built
  • location of binaries - path to binary file, which is the result of build.
  • other version - versions of software/firmware components and of build system. This information will allow to rebuild exactly the same binary. Can be useful for debugging.

Test Results - related to the build

When testing is done by QA, then they execute test cases using specific Build (binary file). Therefore it is important and very useful to connect Test Results via TestRuns to the Build. It allows to see exactly which Test Cases were executed for each build. For example, it can be that some test cases were executed for ReleaseCandidate1 and not for ReleaseCandidate2.


Managing Team Events - Team Calendar

Date: 2 March 2016.

PROBLEM: To use Events in Polarion user has to have licenso of type: ALM or PRO.

SOLUTION: We offer a solution based on new Work Item Type "News & Announcements", which allows to easily manage Personal and Team related events.

Polarion Work Items


Naming of Work Items and Custom fields

Date: 10 December 2015.

PROBLEM: Good Name is a key for undestanding inside the Team. It makes the interface and values self-explained, reduces need for additional training sessions.

SOLUTION: we have gathered over the time good examples of Names used for Polarion Work Items.

Polarion Work Items
Topic Proposed Alternative Names Description/Comments
"News & Announcements"
work item type
- News & Announcements
- Information
Some information which you would like to share in your Team.
"Annoucement Type"
custom field
Custom Field Names:
- Annoucement category
- Announcement Type

Custom Field Values:
- Holiday
- Job Opening
- Special Meeting
Some information which you would like to share in your Team.
"Build"
work item type
- Build
- Build Record
Binary created for a specific release. It has version number, list of components/versions used for the build (from Version Control System).
"Feature"
work item type
- Feature
A software feature, which shall be implemented in software product.
"User Story"
work item type
- User Story
- Epic
High level description by Stakeholder of use case how some functionality shall be used.


Naming of Links

Date: 10 December 2015.

PROBLEM: Good Name is a key for undestanding inside the Team. It makes the interface and values self-explained, reduces need for additional training sessions.

SOLUTION: we have gathered over the time good examples of Link Names used in Polarion.

Polarion Links

Please note, that in Polarion a Link belongs to the WorkItem where it starts. It means Link is part of the Work Item "Origin". If the Work Item "Origin" is deleted, then the link is also deleted. If the "Target" Work Item is deleted, then the link is still preserved as part of "origin" Work Item, but it points to not-existing WorkItem ID.

Topic Direct and Back Link Description/Comments
"test" -> tests
<- is tested by
"implement" -> implements
<- is implemented by
"verify" -> verifies
<- is verified by
"impact" -> impacts
<- impacted by
"depend" -> depends on
<- is depending on
"relate" -> relates
<- is related
"tracks" -> tracks
<- is tracked
"reveal" -> reveal
<- is revealed by
"review" -> reviews
<- is reviewed by
"migrate" -> migrate to
<- migrate from
Used to link Work Items migrated/moved/copied from one project to another.
"duplicated" -> duplicates
<- dublicated by
Used to indicate that one Work Item is a duplocate of anothe Work Item.
"parent" -> has parent
<- is parent of
Used to indicate hierarchical relationship between Work Items.
"covers" -> covers
<- covered by
Example:
Stakeholder Requirement => covered by => Test Case.
Example:
Test Case => covers => Stakeholder Requirement.
"traces" -> traces to
<- leads to
Example:
Software Requirement => traces to => Stakeholder Requirement.
Example:
Stakeholder Requirement => leads to => Software Requirement.
Example:
Problem Report => traces to => Anomaly/BugReport.
"detected" -> detected by
<- covers
Example:
Anomaly/BugReport => detected by => Test Case.
Example:
Test Case => covers => Anomaly.
"contains" -> contains
<- is part of
Example:
Regulatory Documentation => contains => Regulatory Requirement.
Example:
Regulatory Requirement => is part of => Regulatory Documentation.
"derive" -> derived from
<- derived by
"mitigate" -> mitigates
<- is mitigated by
"produce" -> produces
<- is produced by
"analyze" -> analyzes
<- is analyzed by
"refine" -> refines
<- is refined by


Copyright © 2015-2018 Garantis IT Solutions   |   Phone: +44 (0) 118 343 1584   |   E-mail: info@garantis.co.uk