In this first blog post of our series on Atlassian tools and 3rd-party plugins for Atlassian tools, we’ll have a close look on how to do test management in JIRA. You will get an insight in first thoughts and ideas when organizing tests and which main requirements are the bottom-line for test management in JIRA. After this we will show which types of test management plugins are available for JIRA. We will have a closer look on the specific functions of two representative examples and compare them with each other. And finally we will give you some hints on how to find the right plugin for your tests.
This second part of the two-part article continues to describe the successful introduction of a proven methodology for quality assurance on the development side according to the principle “Very Early testing” with ERiC (ELSTER Rich Client) by showing in detail how the VET method was introduced to the ERiC project, done by mgm technology partners with Alexander von Helmersen of the Bayerisches Landesamt für Steuern and their teams.
This two-part article describes the successful introduction of a proven methodology for quality assurance on the development side according to the principle “Very Early Testing” with ERiC (ELSTER Rich Client), a project done by mgm technology partners together with the Bavarian Tax Administration (Bayerisches Landesamt für Steuern) and their teams. Within the framework of ELSTER  all software producers are provided with the library ERiC by the German tax authorities and it is embedded in all commercial and governmental software to file tax reports. It validates, compresses and encrypts tax data for the communication with the tax authorities. More than 100 million tax reports are filed via ERiC every year. Due to tax legislation ERiC development must meet rigid requirements.
The article’s first part describes the very efficient QA method of “Very early Testing”. Its second part shows in detail the introduction of the method to the ERiC project.
One of the assets of mgm is dedicated quality for software, including especially portal technology for applications with high-safety and reliance demands. In the first blog within this series, “Using Domain Specific Languages to Implement Interactive Frontends“, we described an approach using a specification language (DSL) family on customer level to specify valid inputs and frontend computations for forms-based interactive or batch systems. Let us continue and focus on the quality benefits of this approach.
For many years we have dealt with the challenges that frontends with interactive forms pose w.r.t. validation, test data and quality. Describing the requirements in formal Domain Specific Languages (DSL) became the way of choice to create a specification that gives a twofold benefit: first, the customer understands it better, and secondly, the software engineers use the specification not only to implement more resilient software, but also to improve quality assurance. This new series will explain how we do it and why we think it’s the best approach.
This part explains some of the sophisticated software technology that is working behind the scenes in our rule-based test-data generator for form-centric applications. You will see that a simple enumeration of all possible ways to fill in a form is likely doomed to run longer than the age of the universe. Therefore more efficient techniques are needed to make the seemingly impossible possible.
On May 17th-19th, I took the opportunity to escape the daily “Java business as usual” on the GR8Conf conference in Copenhagen, Denmark. The three days were packed with the latest information on Groovy related technologies such as Grails, Griffon, Gradle, GPars, Spock etc.
The previous part discussed why a unit test for a class should be written by the developer of that class, and why a functional test should be created by an independent tester. This posting argues that functional tests should not be part of the build process of the product, but instead should be developed and executed separately. For this, I give guidelines for setting up an independent validation system.
This part addresses the question what makes test data valuable for functional tests. You will understand the important concept of extreme and special values, and how to obtain test data that is highly compressed and also attains a high test coverage. The article also explains our novel idea for constructing a generator for such high-quality test data.
Over the past few years I have noticed that the distinction between functional tests and unit tests has blurred in a lot of projects. I think that using the features of modern testing frameworks like JUnit and TestNG to push functional tests into unit tests is the wrong approach, because it shifts the focus of the test from the test perspective to the development perspective. In this blog post, I explain in detail how I have come to this conclusion.
A lot of our web applications contain a large number of forms with hundreds of fields and complex cross-field constraints. mgm’s quality assurance team uses rule bases and automatic form validation to verify the correctness of these apps. This blog series discusses the challenges in generating test data for this verification and explains our automated process for producing masses of test data by utilizing the rule bases.