Business,  Digitalisierung,  en,  Software & scripting

Automatic release-note and test guide creation in TFS

Due to the need to increase the product quality and to reduce manual efforts i adapted the methodology of agile software development.

Initial Situation

  • We needed to avoid that stuff was going to be implemented without reflecting the value.
  • We had to ensure that every developer, tester, trainer, sales man etc. was able to understand, why the software development made each change, and what is it good for.
  • The colleages had days of effort to note down, redact, reformat and publish online-manuals, traing documentation etc for each version.

Our goals

  • Establish a process in which an idea or recommendation is only implemented when it has a value which is worth its effort.
  • Ensure that everybody can easily comprehend the intensions and goals of every single change.
  • Reduce the manual effort for documentation and publishing the changes in the software.

The way i went

Before our developers got directly their tasks from everybody in the company who had an idea.

So at first i had to establish a working instance (product management) which ensures, that every recommendation is checked before done.

Then i developed a process based on the old MSF for Agile Template (yes, it was 2012) to adapt the very easy to understand way of creating user stories:

        As a <role>, 
        I want <goal/desire>
        so that <benefit>

original Connextra 2001 style

Then i added a field for „acceptance-criteria“ which was not yet available at the old MSF agile template, to ensure that before starting software development, the colleages of the product management team had to reflect, what to test the implementation against. For the transition from „new“ to „active“ this field became mandatory.

I added a field called „release-notes„, where we could note down, what we wanted to tell our customers on delivery of the feature. So… Which benefits this brings, what it means regarding their working process, where it could be reached etc.

Afterwards the colleages were easily able to countercheck whether user-story, acceptance-criteria and release-notes fit together. If only one of those three attributes contradicts one of the others this user story had to be reworked before it could be pushed to the developers.

The result is, that now the recommendations and ideas we start developing are reasonable and already well documented.

The last step for reducing the manual publishing effort was to use the SSRS coming with the TFS-SQL to generate an report which contains everything that is needed for publishing a document containing the changes in the delivered version and a small WORD-macro to

  • extract the content from all the tables,
  • remove the crappy MS-format assignements
  • replace them by real stylesheets
  • generate an table of contents (TOC) with proper Links to the topics based on the assigned styles
  • and save it as PDF which can be delivered with the version.

Finally we added some parameters to the report.

This allows everybody in the company to easily generate release notes for every combination of base-version to update-version. We can now even deliver the information what changed between two specific versions, per customer!
And we can easily check what changed underneath a specific area-path (eg. at the accounting-module or for external interfaces) for reworking our trainings etc.