Into NLP 3 ~ Numerous Language Pieces – Tokenization
Previously we started our journey into the world of Natural Language Processing by learning the basics of Regular Expressions (RegEx) and fuzzy matching. While RegEx is certainly a powerful tool, it has its problems. As I wrote, Regular Expressions have a
Into NLP 2 – Fuzzy String Matching and the Edit Distance
NearLy Perfect In my last article I started with a dive into the wonderfull world of Regular Expressions. We’ve seen how RegEx are really useful for search tasks. However… They are not perfect and today we will look at one particular
Conditionals: Why you should avoid these two letters for better test case execution
At Qualicen, it's often my job to check other people's system test cases and tell the team what I think about these tests. So what do I look for? Well, in principle it is simple: After tests are written down, they are "only" executed and maintained. So this is where tests can be bad and I try to spot things that make execution and maintenance harder. For the maintenance, the largest problem here are clones, which we covered in our last blog post. For the test execution, the main problem that you want to avoid is that different testers test different things. This is called ambiguity and comes in many tastes. In this blog post, I want to explain what is structural ambiguity and why it is bad, and this way help you to create better test cases.
(Scroll to the summary, if you don't care about the details) ;)
Ambiguous test flow
The problem for test execution that I want to discuss here, is an ambiguous test flow. This means, that for a single test case, there are multiple paths that a tester can follow when she executes the test. Let’s look at an example.
[caption id="attachment_145" align="alignleft" width="810"]
A simple, straight-forward natural language system test case.[/caption]