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.
Tag ‘Web Forms’
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.
For the e-commerce business, it is very important to have a valid and correct address base. Sending packages to incorrect addresses causes significant losses, since packages are not delivered and sent back. In the case of the Kickz online shop, we faced exactly this problem. Thus, we thought about how to improve and force users to enter correct addresses. Learn how we used Google’s Geocoding service to solve this problem.
This posting discusses how we integrated an web application with XForms as one of the main view technologies into a Liferay portal. We were using the Orbeon 3.8 XForms engine, which was introduced in the previous part of this series, and Spring Portlet MVC. Since we were facing quite a few problems and issues regarding Orbeon and Liferay, I go to great length discribing our working solution.
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.
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.
In this second installment, we conclude our evaluation of XForms implementations and explain why we ultimately preferred the Orbeon engine. I walk you through a XForms sample to explain essential concepts. My team has spent quite a lot of time understanding the Orbeon architecture and I discuss our findings, including separate-deployment configuration and state handling.
mgm develops several large scale web applications containing hundreds of forms, e.g. the e-government portal ElsterOnline Portal. Design, implementation, test, and maintenance of these forms implies significant effort. We are currently evaluating different technologies – including XForms, Wicket and JSF (ICEfaces) – that could help us to reduce these efforts, to improve quality and set the framework for our next generation web forms-centric applications.