Aims of a test case name
It’s important to choose good names for test cases for various reasons:
When you or other testers on the team are looking through the test case Browser, it should be easy to find out which test case is the one you need – and if there are a few test cases that are similar, then it should be clear which one is the right one for the task at hand.
When you use the search dialog or filter field, knowing how your test cases are named will help you to find the right test case. Otherwise, you may end up thinking that there is no test case for the current workflow and introduce redundancies by creating a new one.
When reading through a larger test case, or through a test result report, it should be easy to follow the flow and steps of the test without having written it yourself. The easier test result reports are to understand; the less time you will spend analyzing test failures when they occur.
Test case names are internal to the project:
Unless you have written your own extensions that make use of test case names, the test case names remain completely internal to the project. There is no need to write names in camel case, or to use_underscores. You can use plain text and include white spaces to make them easy to read.
Example: SA Resident that qualifies for a reduced rate accepts the declaration and can navigate to the next step
Basic naming guidelines:
The easiest rule of thumb for test case naming is to describe what the test case does – no more and no less. Bear in mind that although you do want to be able to identify what the cest case does, you don’t want names that don’t fit on the screen anymore If you’re using categories to structure the cest case crowser (which you should), then your cest case names don’t need to be exhaustively descriptive. They just need to give you enough detail for the contexts they’ll be used in.
Choosing a name:
The first and most likely thing the name will contain is either the action or the aim of the cest case, for example:
“Open New Project Dialog”
“Select any entry from a context menu on any tree node”
“Fill in mandatory fields in new customer dialog”
If the cest case acts on one particular component, then it’s a good idea to mention this in the name as well:
“Select any entry from the languages list”
“Close search dialog with OK button”
“Close search dialog by pressing escape”
And if you have a cest case that works with very specific (i.e. hard-coded) data, then mention that too:
- “Login as the administrator”
Being specific about meaning:
Often, it is worth being very specific test cases name.
If you have a test case that checks whether a checkbox is activated, and, if it isn’t activates it (using a retry Event Handler), then you could consider calling the Test Case:
- “Make sure that checkbox is activated”.
Using “make sure” instead of “check whether” is an important semantic difference: regardless of the state of the checkbox in advance, this Test Case will result in the checkbox being activated.
Standard test cases:
Another useful naming convention is to preface any low-level (usually single-action) modules you create with the word “standard”. This is most usually the case if you take one of the unbound modules installed with the tool and reuse it in your own test case so that you can hard-code data that will probably never change for your project, for example:
Names can change:
Even once you’ve named something, that doesn’t have to mean that the name is set in stone. If the name is causing confusion, then change it. And most importantly, if a relevant aspect of the test case itself changes, then make sure you change the name too!