We are proud to announce the new release of WordToTFS that has been sim-shipped with Visual Studio 2017. There are a lot of new features and also some bug fixes we’re going to explain in this blog post. Basically both versions have the same features, but WordToTFS 5.3 still works on the Visual Studio 2015 API while WordToTFS 6.0 is one step ahead using the Visual Studio 2017 API. Please find more details on this topic at the end of the post.
Test Specifications and Test Result Reports
Some major improvements are made in the area of test reports.
Test Result Report including Test Cases without results
With the existing functionality users can create separate test documents: Test Specifications and Test Result Reports. Due to regulatory requirements, we extended the test result reports so that not only test cases with results are exported into the document.
To explain this in detail, the following scenario is used. A very simple Test Plan contains some test suites and test cases. By creating a Test Specification with WordToTFS, the document might contain the structure shown in figure 1 – “Test Specification”. After some test cases have been executed, the Test Result Report contains those test cases, that have been executed. In the sample in figure 1, the Test Result Report would contain every test case from the Test Specification but not Test Case 3. However, there are scenarios with the requirement to also show Test Case 3 in the Test Result Report, even if it has never been run.
Figure 1: Test Specification and Test Result Report
Since we want to support both scenarios, a new attribute in the configuration can be used to control this behavior (see figure 2).
Figure 2: New attribute for Test Result Reports
Test Result Report includes Analysis information
It is possible to include a lot of information into the Test Result Report. Nevertheless, there is some data, that has not been that easy to export or it was even impossible. Such an area was the analysis information that can be used to document e.g. Failure Type and Resolution of a particular Test Run (see figure 3).
Figure 3: Change analysis information of a Test Run
The following excerpt of the WordToTFS configuration (see figure 4) shows what needs to be added to the WordToTFS-configuration. Especially the attribute “ResolveResolutionState”, which is yellow highlighted, is very important to get a meaningful resolution state instead of an internal id number.
Figure 4: WordToTFS Configuration for analysis information of Test Run
Whenever a user integrates OLE-objects in an HTML-backed field of a work item, some magic is done behind the scene (more information on the OLE support can be found in the user guide at pp. 34-35). In some cases users want to know whether a work item contains OLE objects. There are different reasons for this desire that reach from administrative tasks to review of those objects.
Now WordToTFS can detect those embedded OLE-objects and store that information into a separate work item field. Just set the new field attribute “OLEMarkerField” to the reference name of a work item field that should store these meta information. Of course this option does only make sense, if a field is configurered for OLE objects.
Nevertheless it is worth mentioning that there are two ways to use this functionality. If a user has only one field that can contain OLE objects, also only one additional field can be used to set the marker. Which marker value should be used, can be configured as well, by the attribute OLEMarkerValue, as shown in Figure 5.
Figure 5: Configuration of OLEMarkerField
The other option is to use only one additional field, even if there are many fields on the work item form, that can contain OLE-objects, e.g. Description and Analysis Result or Impact Analysis. In these cases, the optional attribute OLEMarkerValue must not be used. In this case, the field name is written into the separate field, there are OLE objects in more than one field, all the field names are mentioned in the new field.
The full description of this feature and how to configure this can be found in the user guide at pp. 36-37.
Minor improvements and Bugfixes
Handling of HTML content
In some edge cases the algorithm to handle HTML content was inefficient and sometimes even wrong. Therefore we updated the algorithm that manages the data transformation of those content between Word and TFS/VSTS. By doing this, we got rid of some scenarios where even lines of longer texts were not exported into Word.
Enabling return key to find by ID
Whenever a user wants to add work items to Word by using their TFS ID, she can type the desired ID(s) into the appropriate text box. We enabled to start search by using the return key in addition to clicking the “Find”-button (see figure 6).
Figure 6: Get Work Items by ID
Test Results Report pane was loading infinitely – sometimes
After the generation of a Test Report has been aborted, but the document has been reused, some corrupt information was stored in the Word document. This sometimes made the Test Result Reports pane loading infinitely. This has been solved so that the pane is loaded correctly, even if a report generation has been aborted before.
Shared Steps not printed in Test Spec by Query via Commandline interface
Whenever a user wants to print Shared Steps without having its test cases as context, an appropriate work item query needs to be defined and eventually these data can be exported to Word. Nevertheless, this did not work while using WordToTFS from the Commandline interface. This has been solved.
Extended the user guide
Since WordToTFS is a very customizable tool, it is important to have a good documentation available. For this reason we have added a couple of things into the user guide. This was driven by a lot of FAQs we had the last time.
How to get it and compatibility
Anyone who has installed WordToTFS v5.x already, does not need to do anything. The auto-update functionality is going to install the new version in the next couple of days. If you want to fasten that process, feel free to manually trigger the update mechanism using the Update button from the WordToTFS Ribbon (see figure 7).
Figure 7: Update-button
Since we are sim-shipping this release with Visual Studio 2017, we also stared the new major release 6. This version is completely backed by the Visual Studio 2017 API. If you start using WordToTFS right now, this is the version you should use from the beginning.
For all others: As with every major version change in the past, we had planned to end the 5.x-support with this release, too. But we did not make it to get any important feature into that release, we wanted to have. For that reason we have planned to deliver one more update on major version 5 in the next couple of weeks, which will be definitely the the last update for version 5. This means, whenever your border conditions, regulatory requirements or other restrictions allow you to move forward to the major version 6, do not hesitate to do that to ensure further updates. WordToTFS 6.0 uses the TFS 2017 API and can connect to the same TFS versions as Visual Studio 2017. WordToTFS 5.3 is still using the TFS 2015 API and can connect to all TFS versions supported by Visual Studio 2015.
A big THANK YOU
It was a tough challenge to get this release out by today. A good time to thank all contributors, namely the team and foremost our customers that are highly engaged in getting WordToTFS even more mature. Thanks for all your questions that made us rethinking some decisions, your valuable feedback that helped us prioritizing the backlog, your time for getting hands-on-experience with preview versions, and nevertheless your funding that makes it possible to improve your favorite Microsoft Office Word integration for TFS.