Polarion 2016 SR1 – What's New and Noteworthy

One of the things I always enjoy about my role is getting to showcase the latest output of our stellar development team. In the new version just released, Polarion 2016 SR1, we have focused less on introducing new features and more on enhancement of existing features, especially in Test Management and LiveDocs. We also put a lot of efforts into things around performance and scalability – something we will continue to do. So with that in mind, let’s jump in and see what’s in this release.

Test Management

We enhanced the Test Runs feature, used for test planning, to enable them to span across projects.

Select Test Cases from other projects
A new Project Span field in the Properties of Test Run Templates and/or Test Runs enables Test Case selection from multiple projects. Depending on what you specify in this field, when selecting Test Cases the Navigation scope may switch from project to a different project, or to the Repository. The Test Run name in the sidebar is a link back to the Test Run in it’s containing project. There are currently some limitations, listed below, which we plan to improve in subsequent releases.

Execute Test Cases from other projects
Test Runs with Test Cases selected from different projects are executed normally. Test Records are logged for each Test Case in the respective project. Overall result (Passed, Failed, Blocked) is recorded in the Test Run as usual.

 

LIMITATIONS:

• Supports manual Test Case selection only. We plan to add support for other cross-project scenarios: query on create, and query on execute.


•  Supports only selection of the HEAD revision of Test Cases. We plan to add support for selecting a specific revisions.


•  The Test Run Template must be defined in the project containing the Test Run. We plan to add support for having Test Run Templates defined in other projects, so that an entire Test Run can be reused “as is” – not just Test Cases.

Test Run Titles

You now have the option to decide how to identify and title your Test Runs . You can assign IDs manually or automatically. Especially when using automated test run IDs it makes sense to assign human readable titles.  Test Run Title can be edited any time during a Test Run lifecycle in Test Run Properties.

Any time the Test Run is rendered (as a link, in table, etc.) we show the “Test Run ID – Test Run Title”.  The Test Run title is copied from the Test Run Template used to create the test run. We recommend that you fill in a title for all your Test Run Templates to give users the recommended default.

LiveDocs

Improvements and enhancements around LiveDocs fall into the general areas of usability, referenced Work Items, and merging of Work Items.

 Expansion of LiveDoc keyboard shortcuts

We have enhanced the set LiveDoc keyboard shortcuts quite a lot. And rather than making you switch to some reference in Help, we now provide built-in documentation right in the Editor. The pop-up reference dialog is sensitive to the operating system you are using, so whether you use Windows, Mac or Linux you’ll see appropriate shortcuts.

Insert Referenced Work Items of type defined in another project

You can now insert a Work Item reference to a Document even if the Work Item type does not exist in the current project, so you no longer need to create “phantom” Work Item types just to be able to put a reference into a Document. (Of course you cannot overwrite such references in the Document.)

Merging

In Polarion 2016 GA we released the capability to merge changes between different branches (or from branch to master and vice versa). In SR1 we have added some enhancements.

Action Conditions

You can now optionally configure merge actions to be conditional. Conditional actions will not be available unless some condition(s) are satisfied. The <conditions> element in the configuration can contain one or more <condition>elements and logical operator tags to define simple or complex conditions.

• Condition: target Document is (not) the Master of the source Document –  A merge action can be conditional, allowed only if the source/target IS or IS NOT a Master Document. For example, if you manage Work Items in a Master Document and require all of the Work Items to be contained in the Master Document, you may make the action to Insert Referenced Work Items conditional, allowed only if the target (of the action) is not a Master.


• Condition: query based:  A merge action can be conditional, allowed only if a specified query on source/target Work Items or Document is satisfied. For example, if you want to allow the merging of fields only from Work Items that are in Approved status:
  (<condition id=”com.polarion.sourceWorkItemQuery”>status:approved</condition>)

Pages and Reporting

By default in new installations, all Repository, space, an user home pages are of the recently introduced widget-based  LiveReport type. If these pages are unmodified in existing installations, they are converted to use this newer technology.

Repository, Project and Space Home Pages

There is now the possibility to switch existing repository, project, and space home pages to the newer, more user-friendly LiveReport format. Converted pages have the same default content. If any of these pages in the Classic Wiki page have been customized, the mark-up is preserved for you to reference as you re-implement the content using the various visually-configurable Widgets.

Users’ Personal “My Polarion” Page

You and all users can also switch your My Polarion pages to LiveReport format. Go to: My Polarion > Gear Icon (Operations)  > Switch to Live Report Page.

If your My Polarion page still has the original default content it will be switched automatically to LiveReport format upon update to 2016 SR1. If the page has been customized, it will remain as the Classic Wiki type with the possibility to switch it to LiveReport type. You’ll need to do some work to recreate your wiki-based content using the various Widgets. The wiki mark-up is preserved on the page for reference (for queries, etc.)

If it seems to you that we have been moving away from Polarion’s original Wiki pages (now called “Classic Wiki”) – you’re right, we have. Wiki is quite an old technology by now, with a steep learning curve often requiring coding skills. So will your Classic Wiki content will stop working later on? No. In the future when we will ship Polarion with only LiveReport technology, we will still provide Classic Wiki support as an add-on for backward compatibility.

Performance and Scalability

Not for the “geek” crowd only. We see these issues as directly related to usability and user experience, something Polarion products have long been noted for. I think our team achieved some nice results this release.

Reduced Footprint of PostgreSQL Database

We optimized the way URIs are persisted in the PostgreSQL database resulting in significantly lower disk space consumption. The reduction depends on the structure of the data in the repository. The DB size of our production server dropped from 148 GB to 53 GB – that’s 64% smaller.

Faster LiveDoc Save

We optimized the permissions evaluation that detects if only comments were added, resulting in better performance of Document save.”

Smoother Document Editor Experience

The team optimized various frequent scenarios in the Document Editor to provide an improve experience when editing big Documents:

• typing


• deleting by Del and Backspace keys


• scrolling


• continuous numbering of lists

Faster Reindex and DB History Creator Job

• Smaller DB disk space footprint and optimized storage of URIs mentioned above had the added result of a faster reindex procedure.


• Faster data indexing phase due to optimized collection of linked Revisions, resulting in great performance boost for repositories that do not use linked Revisions.


• Greatly improved performance of the fields recalculation phase of reindex due to detailed analysis of the affected Work Items set.

Polarion’s production server reindex time dropped from 5.7 hours to 2.4 hours – 58% faster. Also run duration of the DB History Creator job dropped from 27.1 to 12.3 hours (55% faster) on virtualized 4 core node in our cluster.

Faster data pre-loading

Performance of data pre-loading was significantly improved for environment with many projects. Our tests show drop from 1320 to 216 seconds (84% faster) in environment with 381 project

Faster import of test results from xUnit

Improved performance of import of new test results in case the Test Cases for the automated tests are already created. Reference test with 5000 tests shows improvement from 4,4 minutes to 50 seconds – 80% improvement. (Applicable for Polarion ALM and Polarion QA.)

Miscellaneous Improvements

• Faster initial import of LiveDoc from Excel sheet – Reference test with import of 3500 requirements to LiveDoc runs 60% faster, dropping from 6,9 to 2,8 minutes.


• Faster collection of features for restriction editor in variant management – Performance of opening features list for pvSCL restrictions was optimized. Our test data show that list of 600+ features opens within one second.Polarion VARIANTS


• Detailed logging for performance profiling and analysis – Transaction logs have been enhanced with information about time spent in particular sub-operations that can take significant amount of time, e.g. in SVN, DB, Lucene, permissions evaluation, etc. This will help our support and R&D teams to troubleshoot and analyze potential customer performance problems more effectively.


• Reduced size of Polarion log files – Content of Polarion log files was reviewed and cleaned up from entries that are logged frequently and do not provide much information. As a result, the size of Polarion log files was significantly decreased.

Other Enhancements

Internet Explorer 11 Native Support

Previous versions of Polarion have supported IE 11 in so-called IE 10 Compatibility mode. This cause issues for some users, and these are now fixed:

• Pasting of Image Attachments from Clipboard – You can now paste the images through the operating system clipboard, i.e. copy image data in a 3rd party program to the clipboard and paste it to a Document or Work Item rich-text field.


• Faster Editing of Big Documents – our on work on the Documents Editor, IE 11 native mode itself has a positive impact on the overall user experience when editing Documents (loading, cursor movements, etc. )

UI and General Usability

• Reset the query conditions when switching queries or context – Polarion by default remembers the last query condition used, when switching contexts or Work Item types. Users can control the behavior and override the system default:


• Improved UI for the Visually Impaired –  Some people with visual impairment had difficulty differentiating content changes because the only differentiator was red or green color. Users can now enable a “High Contrast” mode that provides a different visualization of such changes.
  


• Modification of diagrams regardless of their storage – Diagrams displayed in Work Item descriptions can be edited in both Document and Work Item view, no matter to which object is the diagram is actually attached. (Polarion ALM, Polarion REQUIREMENTS)

Known Issue

The popular but unverified Work Item Save Hook extension will throw exceptions when running on Polarion 2016 SR1, as a result of improvements in logging mechanism. There is a simple workaround – just set in the following property in the polarion.properties system configuration file:

com.polarion.platform.loggingServiceInterceptor.enabled=false

I hope you will find that the Polarion 2016 SR1 release delivers some benefits for you. On behalf of our entire team, we appreciate you choosing Polarion as your lifecycle management solution.