"It seems very pretty," she said..."but it's rather hard to understand!"

"It seems very pretty," she said..."but it's rather hard to understand!" - Alice, on "Jabberwocky"


Never fear to follow your hunch! If the thing you're testing doesn't behave as expected, you may be dealing with a usability bug or an undocumented process flow.


Often, documentation for a software artifact is outdated, inaccurate, incomprehensible, or absent. It is your responsibility as a tester to fully understand what your product does and how. Often, a product manager or business analyst will contribute to this understanding of flow, but just as often, development may be doing their best to reconcile muddy requirements against an existing and/or conflicting UI implementation.


Create your own documentation around flow. It can be as informal as a drawing on a whiteboard, or as sophisticated as a Visio diagram. Ensure that each step of your documented flow is represented by a test case. Use whatever resources are available - product, development, code, actual users - to demystify any section where the allowable inputs are unclear or undefined. Make sure your test cases cover the boundaries of these "mystery" steps.


The words "It shouldn't do that" coming from dev are your red flag to dig further. By no means should you "just ignore" that unexpected behavior. Do everything you can to dig in and reproduce. If you cannot reproduce, document! Chances are that a production user may hit a similar issue.


Uncovering of bugs not directly related to the enhancement under test are a happy side effect of always paying attention to those weird glitches. The temptation to ignore what isn't easy to understand is strong - especially if no one else wants anything to do with the matter! - but our customers count on us to advance ALL quality-related discrepancies as issues, whether funding or time exists to address "unrelated issues" immediately, or whether it must be deferred to a later effort.