moveIT

When Manual Tests “Smell” – Hidden Problems and Patterns

Abstract

Have you ever heard of ‘code smells’? This term expresses the situation in which a certain code characteric might indicate a much deeper problem. Things may seem okay at first sight and everything might appear to work fine, but if you dive in more deeply, it starts to smell more and more and code may even be rotten with low maintainability and bad performance as possible results, just to name a few.

Developers are encouraged to use design patterns to create better code. Whenever they fail to apply these patterns, their code becomes smelly. Some of these failures have common characteristics and are grouped into the concept of ‘anti-patterns’. By using these anti-patterns as a checklist on your code, possible issues can be detected and corrected. Since test automation can be considered as a form of development, there also exist ‘test smells’ and anti-patterns for automated test cases.

Having spent a lot of time on reading about these anti-patterns, I started wondering whether there also exists something like ‘manual test smells’: manual test cases that seem to be okay at first sight, but are actually hiding a deeper problem. What are the pitfalls that we might overlook? Testers apply test design techniques to derive their test cases from the requirements, but once we write down our test cases in natural language, do we testers also apply anti-patterns? And if we do, what are then good test design patterns for writing manual test cases?

In this presentation I want to share with you my story on the anti-patterns that I’ve discovered and the design patterns I would like to propose to avoid making certain mistakes when writing manual test cases.