What’s New and Noteworthy in Polarion 2016

I’m very pleased to announce the release of yet another new major version of Polarion… version 2016. It’s the first one since we became a Siemens company, and one thing I hope you will notice is… nothing has changed. Oh there are new features and enhancements of course. But our R&D still employs enterprise agile principles, enabling us to release frequently, faster, and with better customer satisfaction.

We will still have a “service release” (SR) each quarter that not only contains issue fixes and feature enhancements, but also includes complete new features if they are fully implemented, tested, and documented, and they do not significantly change the way people have been trained to use the last Polarion major version. All the new features released in the SRs roll up into our next major version, which when released, also includes new features and functionality.

So what I’ll show you in this post are the enhancements published since our last service release… all delivered just as we always have done, in the way you have come to rely on.

1. Merge Branches

In the Polarion 2016 release we redesigned the concept of comparing Documents. The new Compare view analyzes the “branched from” relationships. What does it mean?

Compare Branches

When you compare Documents, if a requirement A is branched into requirement B, you see the item as changed so you can fully understand the changes as if the two requirements were a single unique item.

Merge Work Item Changes

In reality, we had to redesign the Compare interface in order to provide you with a stronger tool to help you merge changes selectively from master to branch, or across branches. The feature scope exceeded everyone’s initial thoughts. It had to cover all the possible scenarios, from simple ones such as…

• You added an item to a master and you want to push a reference to a branch
  

…to more complex scenarios. For example:

• You have overwritten a Work Item in a branch (that is, you branched an individual item) and you want to merge the changes (attributes) back to the master item, and possibly replace the branched item with a reference to the updated master (to limit the number of different items as much as possible).

Flexibility
Different changes need to be merged differently, and sometimes there are even multiple possible ways a single change could be merged. For example, with Original to Overwritten item:

• Replace with a “live” reference (changes in the referenced item propagate automatically).


• Replace with a “frozen” reference (changes in the referenced item don’t propagate automatically, but can be propagated manually on demand).


• Merge certain attributes (i.e. data fields) only


• Unlink and insert the reference (keeping both items)

We wanted to make the Merge dialog really simple and let the project administrator configure how changes should be merged, given your process. For example, maybe you don’t want to allow frozen references, only live references. So the Replace with Frozen Reference action can be hidden. See: Administration > Document & Pages > Merge Actions.

2. Test Run Workflow and Signatures

Polarion 2016 delivers workflow automation to control and secure the lifecycle of testing, plus the option to require CFR 21 Part 11 compliant electronic signatures for workflow actions.

Define the Test Run Workflow – Not Just Statuses

Instead of just setting a Test Run’s status, you can now model the full workflow of your testing.

You can benefit from:

• Automating of status change condition checks. For example, a Test Run can be marked as “Passed with failures” only if all the issues related to failed test cases have been tagged as “reviewed”.


• Status change function triggers. For example a Task type Work item can be created when a Test Run is pushed from “draft” to “planned” status. The Task is linked with the Test Run, and this is where testers can fill in test records. Another example: an epic “Beta” Test Run can be created when an Epic type Work Item reaches the “implemented” status. When the Test Run is executed and passes, the Epic can be marked automatically as “verified”.

You can map your organization’s testing processes in the new Test Run Workflow configuration. You can set up a global default configuration, which can be customized in projects for each Test Run type.

Require E-Signature for Test Run Workflow Transitions

Each step in the process can optionally be set up to require an electronic signature before a Test Run can move to the next stage in the workflow. You can optionally require e-signature for any workflow Action.

Require E-Signature for Test Case Execution

For each Test Run type defined, it is possible to require an electronic signature when executing Test Cases in Test Runs of the type. For example, if you have a type, Manual Security Test, you can configure it to require a signature when executing Test Runs of that type:

If this configuration is enabled, then when Test Cases are executed online (in Polarion) or offline (via Excel round-trip), an electronic signature will be required before the results are logged.

3. Test Run Pages and Widgets

The pages for new Test Runs, and those in Test Run Templates are now implemented in the LiveReport Page format. They were previously implemented as Classic Wiki pages. So there’s no need to master Classic Wiki syntax in order to be able to customize these pages.

Existing Test Run pages in the old Classic Wiki format will still work and look as before. If Test Run workflow is enabled, workflow control will be applied to these pages.

New test run widgets you can use anywhere

An added benefit to the new page format is a set of new Test Run-related Widgets. These are used in Test Run pages, and are available for you to use in your own test run reports or other Pages.

For example, you could quickly build a Page enabling testers to execute a Test Run without giving them access to the Test Run itself, its properties, template, etc.

Test Run Comments

A section for comments appears in the Properties of Test Run. The user can view, add, reply, and resolve comments. The UI is essentially the same as for comments to Work Items.

Test Run Attachments

A section for attachments also appears in the Properties of a Test Run. The user can view, add, remove, update and download attachments. The UI is essentially the same as for attachments to Work Items.

 4. PostgreSQL Database

We introduced the PostgreSQL database in new Polarion installations in version 2015 Service Releases in place of the previous H2. It has proven to provide better performance and stability in enterprise environments. With the 2016 release we will migrate customers’ existing systems to use PostgreSQL.

Automated Migration

Our goal is to migrate existing Polarion installations to PostgreSQL as seamlessly as possible. The update scripts for Polarion 2016 install and configure PostgreSQL to work with your existing installation and disable the existing H2. Before updating your system, we suggest you check the details for your operating system provided in the Configuration.txt file, which you’ll find in the root folder of the update distribution.

Database Compatibility Mode

Because PostgreSQL’s syntax is more strictly ANSI-compliant than H2, some existing user-defined queries formulated with H2’s syntax may not work after the migration to PostgreSQL. If, after the update, you find any SQL queries not working you can enable Database Compatibility mode via a new system property:
com.polarion.platform.sql.h2CompatibilityMode.

When enabled, Polarion attempts to adjust queries formulated with H2 syntax “on the fly” so that they work with PostgreSQL. This should take care of most incompatibilities. More information will be provided in the a new Help topic: Advanced Administration: Database Compatibility (H2, PostgreSQL). TIP: If you want to check this before you update to Polarion 2016, check Help on the ALM Test Drive server (after it’s updated to Polarion 2016), or download and install an evaluation copy of Polarion.

5. Other Improvements

Besides the above new features, there are some significant improvements you should know about.

 Unlimited Bulk Edit

You can now Bulk Edit any number of Work Items. (Bulk Edit enables you to modify many items all at once.)

What does “Restricted” mean?

• First, Polarion does not analyze all 100000 items. In regular Bulk Edit you see what properties all the items have in common. E.g. if all of them are “Must have” – you see the value “must have” in the Priority field to show that all of the items have the same value. In restricted Bulk Edit we do not show this information.


• Second, after “Save” the system executes a background job to update all those (possibly millions of) items. It does not wait for the operation to finish to give a control back to user.

Control additions or removals of multi-valued fields in Bulk Edit

Bulk Edit is also enhanced so you can easily add and remove values of multi-valued fields. Just use the +/- actions next to the values:

Configure behavior of the ENTER key in Document Editor

You can now control what happens when you press ENTER key when editing a LiveDoc Document:

• If you want to create new items when you press ENTER – useful if you are a business analyst writing lots of requirements that should be granular.


• If you want would rather have ENTER add a new line, which can be more important if you write e.g. detailed test descriptions with lots of paragraphs. Just expand this menu on the Document Editor toolbar…
  
  … and configure your preferred behavior. (We plan to add more options later.)

Concurrent License Groups

If you manage Polarion at big organization, you might benefit from the new way of assigning concurrent licenses.
In the License topic of global Administration you can now create “license groups”. For example, you might define groups for different departments, and configure that group A will be assigned 50 concurrent slots out of your total 70, and group B the remaining 20 slots.

 You need to specify two properties for every group: the group size, and the group users. The structure of the properties are as follows:

• Group Size: concurrent[LICENSE]Group[NAME]Size=[NNN] where…
  
  
  
  • [LICENSE] is the product licensed (e.g. ALM, Requirements, etc.)
  
  
  • [Name] is a unique group name you specify (no spaces)
  
  
  • [NNN] is a number denoting the number of concurrent user license slots for the group named in [NAME].
  
  
  
  


• concurrent[LICENSE]Group[NAME]User[NNN]=[User ID] where…
  
  
  
  • [LICENSE] is the product licensed (e.g. ALM, Requirements, etc.)
  
  
  • [Name] is the group name you specified when defining the group size
  
  
  • [NNN] is the number of the slot for the user you are adding to the group (e.g. 1, 2, 3). NNN is simply a counter.
  
  
  • [User ID] is the Polarion user ID of the user you are assigning to this slot in the group.
  
  
  
  

 Example of a 3-user group for ALM concurrent license:

concurrentALMGroupEastOfficeSize=3 

concurrentALMGroupEastOfficeUser1=jonesd 

concurrentALMGroupEastOfficeUser2=gunterk 

concurrentALMGroupEastOfficeUser3=chanr

 Change to Time-based Plan Calculation

 We no longer strictly follow the “burn when done” principle for time-based calculation of Plans. By default, Polarion now also calculates the Remaining Estimate value of items that have Resolution set, but Remaining Estimate value is > 0. (This can apply to items awaiting verification, for example.) If you prefer the former “burn when done” behavior, you can switch back to it by setting a new system property: com.polarion.plans.calculateResolvedRemainingEstimate

Best practice is to clear Remaining Estimate when the terminal state of workflow is reached. If Time Spent and Remaining Estimate are not filled for items planned to a time-based Plan, it behaves like a custom field-based Plan, and the “burn when done” principle is followed using either Initial Estimate (if filled) or the default estimate as the Work To Do value.

Store any Query as Personal Default

You know how every time you access the Work Items table, there is a default query that displays all Work Items in the “Unresolved” state. Have you ever wished that you could define some other query and have it run instead, whenever you access that context? Well, now you can. There’s a new option in the Visual Query Builder, “Save As Default”.

New Classic Wiki Macros

Two new Classic Wiki macros were introduced to replace the existing {includeForm} and {includeTopic} macros:

• {include-macros} – includes macros from the specified page without rendering its content


• {include-page} – includes content from the specified page and allows use of Velocity variable in the page attribute

The old macros have issues that negatively impact performance. If you have pages using these now deprecated macros, you’ll want to update to use the new ones. Check Syntax Help for Classic Wiki for usage details.

Use Existing License Key to Update

 Current Polarion customers will be glad to know that it’s not necessary to obtain a new license key before updating to Polarion 2016. You can update from any 2015 release using your same License Key Code to activate your installation after installing the update.

You can activate online or offline. (See the bundled HOW_TO_INSTALL_THIS_UPDATE.txt file in the update distribution for more details.) If you update from any Polarion 2014 (or earlier) release, you do need to obtain a new license key. You can request it online.

Performance improvements worth a mention

• General speed-up due to use of PostgreSQL instead of H2.


• Speed-up in specific save scenarios with attachments, thanks to an update of the Tika library.


• Speed-up in Document-related scenarios because Document and Wiki content is now not rendered when it’s not displayed.

And a few more noteworthy items

• Microsoft Edge is now a supported browser.


• Updated versions of bundled third-party software (see the Installation Guide documents).


• Possibility to configure how many Test Runs can be selected in the Execute Test extension


• Native 64-bit Windows installer that bundles 64-bit Apache and Subversion

There is more

As with every release, our R&D team has fixed issues that have come up, as well as working at the never-ending quest to optimize performance while providing the power and usability you need to do what you do. But by now, I hope you have enough info to go on with. So let me finish this post with a couple of reminders:

• Polarion 2016 is free to current customers who have an up-to-date maintenance subscription. There is a single update distribution for all supported operating systems. Download it here.


• If you would like to try out Polarion 2016 before updating your production system, it’s easy: download the Polarion product of your choice, install it on any machine running a supported OS, and use the built-in 30-day evaluation license.