When you say »software test«, most people will immediately have a mental picture of automated unit tests, continuous integration, fancy mutation testing tools etc. But in reality a large portion of testing activities is still manual, i.e., someone clicking through the UI, entering values, hitting buttons and comparing on-screen results with an Excel sheet. Such tests are sometimes exploratory (i.e., the tester performs some random actions in the UI and reports any bugs he may or may not encounter on the way) and sometimes they are structured (i.e., someone writes a natural-language document with step-by-step instructions for the tester).

In our long-running research cooperation with TU München and our partner HEJF GbR, we have encountered large regression test suites (i.e., hundreds of test cases) in many different companies that were built this way. Usually some test management tool is used to store these test descriptions and monitor the execution progress. Such test

Read more...

While there are numerous excellent articles, blog posts and books about the correct handling of character encodings in software systems, many systems still get it wrong because their architects and developers never understood what this is all about. I suspect that is due to the fact that many systems work more or less correctly even if you don’t care about character encodings. Moreover, character encodings in general and Unicode in particular is a topic of overwhelming complexity (if you want to fully understand it). The combination of these two facts—it mostly works even if I don’t care and really understanding the thing is hard—allows laziness to set in; resulting in software systems that handle text correctly under the most trivial circumstances only. This blog post aims to remedy this by focusing on the single most important rule for developers while abstracting away everything that is not required to understand this rule.

Read more...