How we investigated whether our Qualicen Scout is a useful tool for companies in the domains of software and systems engineering.
Why we wanted to answer this question
As science showed, the quality of the requirements documentation influences the subsequent activities of the software engineering process. Detecting errors late in a software engineering process leads to very expensive changes of parts of every pre-executed activity. Accordingly, we at Qualicen help our customers to assure the quality of requirements specifications before they are used in other activities.
Continue reading Detect more Quality Defects in your Requirements
This article is a sequel to our blog post Structured Test-Design With Specmate – Part 1: Requirements-Based Testing published by my colleague Maximilian. So far, Maximilian introduced you to our tool Specmate – a tool that helps you to automate your test-design. He explained how to model requirements using cause-effect-models and how to automatically generate test specifications based on them.
However, Maximilian told you only half the story (I’m sure you were already guessing that based on the Part 1 in the title. 😉 ): Not all requirements are like the ones in his examples. Many requirements are of a different nature and can’t be specified easily using cause-effect models.
In this post, I’ll demonstrate the second way of modeling requirements in Specmate: Business processes. Furthermore, I show how to generate automatically end-to-end tests based on these business processes.
Continue reading How to automate Test-Design with Specmate – Part 2: End-to-End Testing of Business Processes
Falls Ihr/Sie nächste Woche in München seid, kann man fast gar nicht über die REConf 2018 laufen ohne uns zu begegnen:
Keynote: “Vom Design Thinking zum Requirements Engineering: Vom Warum und Wieso zum Was und Wie”
Prof. Dr. h.c. Manfred Broy wird am Dienstag um 9 Uhr die Eröffnungs-Keynote zum Thema Design Thinking und RE halten:
Requirements Engineering ist vielleicht der wichtigste Teil der Software-Evolution. Falls es uns nicht gelingt, die Funktionalität, die der Endnutzer benötigt, korrekt zu spezifizieren, und falls es uns nicht gelingt, die geforderte Qualität korrekt zu identifizieren, besteht die Gefahr, dass ein System entwickelt wird, das nur teilweise oder vielleicht sogar völlig nutzlos ist.
Im Prinzip gibt es zwei wichtige Schritte im Prozess des Requirements Engineerings. Die größte Herausforderung ist, die benötigte Funktionalität zu finden. Das ist eine schwierige Aufgabe und Techniken wie Design Thinking können hier helfen. Design Thinking ist ganz darauf ausgerichtet, Lösungen für Probleme zu finden und diese durch die Konstruktion eines Prototyps konkret zu machen. Dies ist ein kreativer Prozess, um Ideen zu entwickeln, wie die richtige Funktionalität eines Softwaresystems ausschauen könnte. Jedoch, wenn ein Prototyp vorliegt, ist man noch weit entfernt davon, einen guten Satz von Anforderungen zu besitzen.
Deshalb ist es notwendig, eine Brücke zu finden von den Resultaten des Design Thinking-Prozesses zum Requirements Engineering, um alle Details einer Anforderungsspezifikation auszuarbeiten. Dieser Prozess ist beeinflusst von dem gewählten Entwicklungsmodell, wie etwa agiles oder konventionelles dokumentationsorientiertes Vorgehen. Design Thinking und Requirements Engineering ergänzen sich perfekt, um die kreative Identifikation der Funktionalität und der detaillierten Beschreibung der Funktionen, aber auch der Qualität von softwareintensiven Systemen sicher zu stellen.
Continue reading Hear us speak at REConf 2018
In this blog post I am going to introduce Specmate, the result of a research project I have been involved into. It is an open-source tool to automate test-design, among others. This is the first post of a series in which I am going to show you some of the ideas behind Specmate.
What is test-design and why does it matter?
Test-Design is the activity to come up with the right test-cases for a piece of functionality. But what are the right test-cases? There are many criteria, depending on your focus. For me, there are two main points:
- First, they should test the right content. That means, they relate to the requirements for this functionality and cover every aspect that the requirements talk about. They should hence be able to find faults: deviations of the implementation with respect to the specification.
- Second, they should be feasible. That means, it should be possible to execute the test-cases without wasting resources.
Continue reading Structured Test-Design with Specmate – Part 1: Requirements-based Testing
There are many reasons to do automated testing on the GUI level. Automated tests are fast, repeatable, and (hopefully) provide reliable test results. On the long run, they might be even cheaper than manual testing (the only alternative for GUI testing). Done the right way, you can even integrate them in your build system giving you the final verdict that each build is as you expect it to be.
One Can’t Go Wrong With Test Automation, Right?
All that sounds very promising. However, it’s quite easy to waste all these beautiful advantages of test automation by having a test suite of poor quality:
- If your automated test suite is fragile and breaks every second time it is executed, testing becomes annoying quickly. And what is the benefit of a test suite that is unreliable? Would you trust the outcome of such a test suite?
- If your test cases are labor intensive to change, you will slow your development pace. Put in different way: The only way to keep your test suite updated with the same speed as you develop new/changed features is to spend more effort in changing your test suite. And soon, you will ask yourself “Why am I spending so much effort in test automation? What has my automated test suite ever done for me?”
Example of a fragile test suite: Absolute URLs will make your test suite fail as soon as you deploy your application on a different server.
Continue reading Quality Plug-In for Ranorex
When we look at requirements documents that are new to us, we often need some help on terms and abbreviations. Creating a glossary to explain these imporant domain terms and abbreviations is a fine idea. It helps new team members to get going, improves the readability of a requirements specification and helps to avoid misunderstandings. The main problem with glossaries is that we create them once and update them only rarely. In consequence, the majority of glossaries are not particulary useful. In this article, Qualicen consultant Maximilian Junker shows how you can get more out of your glossary and keep it always up-to-date.
Continue reading How to Awake Your Glossary From Zombie Mode
As most of you know, we moved to the GATE in Garching (a university town, 20 minutes out of Munich) recently. So in oder to celebrate our new offices, I wanted to share a few pictures from these days with you.
We moved here in December. Engineers as we are, we loved all the assembling! And not too many things broke, actually 😉
First desks assembled
It’s getting there!
We have the greatest lamps.
Continue reading Moving in at GATE Garching (with Pictures!)
If you haven’t heard from us at Qualicen in while it, it is because we are fortunately(!) very busy right now. Lot’s of cool projects all over Germany and even up in Sweden. Contact us, if you would like to hear more about these projects or get in contact at one of the following venues.
Continue reading Updates from Qualicen
Several roles are concerned with requirements quality. Of course, there is the requirements author, writing the requirements. But there is also the reviewer, who proof-reads and validates the requirements. And finally, there is the QA-Engineer, responsible for the overall quality of all artifacts created during the engineering process. Each of these roles needs a different view on requirements and different tools in order to do their work efficiently and achieve a high requirements quality. In this article I am going to show you how the Qualicen products specifically support authors, reviewers and QA-engineers in their work to keep requirements quality high.
Continue reading Three Perspectives on Requirements Quality: Authors, Reviewers, QA-Engineers
I’ve worked quite some time on understanding and detecting quality defects in requirements documents and requirements quality in general. All the time, I was very dissatisfied with the current state in both research and practice on this topic. I think, the problem behind this is that there is no guidance: In times of rapid change and delivery, where every project looks different, we still have no good rule of what a good requirements document is.
A few years ago, we came up with such a rule, and tried it in various applications. And – so far – it seems to work! We’ve collected this experience and are now ready to tell you about it, because we really believe this should change how you view requirements engineering, and this should change what you consider good requirements documents.
Continue reading Requirements quality is quality-in-use