Anyone who has used a recent version of Specmate might has already seen an amazing new feature. In the overview screen of any Cause-Effect-Graph is now an anoccurus little button titled “Generate Model”. Clicking this button will trigger a chain of systems, that is capable of using natural language processing to turn a sentence like
If the user has no login, and login is needed, or an error is detected, a warning window is shown and a signal is emitted.
directly into a CEG, without any additional work from the user:
In this article we will do a deep dive into this feature, have a look at the natural language processing (NLP) pipeline required to make such a system work, see different approaches to implement it, and figure out how to garner the power of natural language processing for our goals.
Test Smell Detection improves your manual test cases. The automatic detection of test smells helps making your test suite easy to understand and easy to maintain. In addition, the automatic detection also leads to consistent reproducible test results.
The best way to find test smells is our Qualicen Scout. Scout can detect test smells in textual test descriptions automatically. Configured once, it immediately shows where you can improve your test descriptions.
What kind of improvements you ask? Well, there is a wide variety of so called “Test Smells” Scout can automatically detect! Test smells are words, phrases, or language constructs that are not good for your test quality. For example, …
ambiguous phrases in your test descriptions (a threat to reproducible test results).
sentences/paragraphs that are difficult to comprehend (prevents that your colleagues ask: “eh, what?”)
You might have seen the pictures of green swans on our twitter feed from time to time. You have probably been wondering: What the heck is going on at Qualicen?How is this related to Requirements Engineering?
We observe that numerous cyber-physical systems are rapidly gaining functionality and thus development gets more and more complex. Innovations are made possible in many areas by a complex interaction of sensor systems and software. Consider the development of autonomous driving, in which a multitude of different system functions must interact safely with one another in order to make complex decisions with the highest quality in order to transport people safely. In order to master the complexity, the classical, document-centered approaches of system engineering are no longer sufficient and are increasingly being replaced by model-based systems engineering (MBSE) approaches.
The SPES modeling framework provides a comprehensive, tool- and modeling language-independent method for MBSE. It offers a whole range of concrete models, modeling techniques and activities. In this blog post, I will introduce you gently to SPES. I will explain the basic principles of SPES and give some pointers where to find more.
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→
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.
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.
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.
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.