Ambiguous phrases in testing

Table of Contents

I see many people using at least one of these phrases …

  • test(s)
  • case(s)
  • test case(s)
  • scripted test(s)
  • scripted case(s)
  • scripted test case(s)
Showing multiple clouds which are connected logically so that every combination can be drawn from it.

… and referring to one of this (at least) 2 concepts:

  1. Code, as used in automation (aka checks) like
    • @Test
      checkSomething(){
        …
        Assert.That(x,y)
      }
  2. Manuals: instructions to describe what humans should execute
      • Step #ActionExpected ResultComment
        1.do somethingx should happennotes of deviations
           

… without giving more context which one they mean!

 

Here is a simplified example of typical discussions I observe:

  • A: "It is important to do <phrase> !"
  • B: "How? Code is not testing."
  • C: "How? Binding instructions are limiting the testers."

I'm sad about so much ambiguity, as it causes many misunderstandings and misguided discussions.

At the very last:

Would you kindly add always if you refer to code/automation or human executing instructions?
Pweeeaaase 🙏

No. Its not clear when you use one of the phrases when you do not give context.


There is even a 3rd option

I saw this 3rd option never in relation to "scripted", therefor it applies only the first 3 cases:

General note-taking/planing/design in testing. In the from of lists or mind-maps in a more exploratory approach.
This can be either standalone or second the other two. With limits it occurs in the comment section of manuals.

Sounds this like influences of Rapid Software Testing? Might be. I can not deny them.

What would you add? Contact me how you want to. I would like to read any opinion.

 

What others added:
  • Ben Fellows:
    • I had a developer today use "test case" to refer to the conditions needed to manifest a bug. I.e. the repro steps.
      "We haven't yet found the test case for this bug".
  • Richard Adams:
    • In my first role regression testing was about verifying bugs. Most of the time we were doing destructive testing and occasionally it was scripted. All manual. In my next role those terms had different meanings.

      Now if someone asks me if there’s any test scripts for testing X feature, I’d be digging out python files that I use to help my testing.

      Having moved team, I’ve found more differences in meanings. There’s a huge push for smoke tests running almost non stop but different understandings on what that means. One other that annoys me is “escapes”. I always understood that as bugs found in released software but my work use it to describe anything that has been pushed.