Are we writing a wholesome test case?

What is a wholesome test case anyway?
There are many definitions and articles about a test cases available in books and sites.
But when it comes down to actually using a test case written by someone else, the wholesomeness of a test case really matters .

Can we certify a test case as complete, if, without any external guidance, the user is able to execute each step with a correct understanding of the purpose of the test?

We usually encounter some challenging test steps such as:
'Enter valid information in the required fields.'

• What is valid information after all? .. Do I, the user, have to assume/search for or randomly play with data in order to hit upon the valid information?
• What are the required fields? .... I know you are thinking, hey this is easy, the required fields will have a red asterisk besides them ..... well, not always, as I have now come to know!

'Verify that following information is fetched from XYZ and few of them displayed on screen'

• What is 'XYZ'? ... XYZ is the name of the host and it was assumed by the author that it would be a known thing.
• What is 'few information'? ...... all fields of the screen are listed, how is the tester to guess which information should be displayed after all?

Why do we write such steps?
Is it because we:

• have weak writing skills ?
• are crunched for time?
• think it unnecessary to write so much information in each test case?
• forget that the test case will be used by many others besides us, especially when we aren't associated with the project?
• are plain lazy?

Is it justified to put a newcomer through the trouble of interpreting the test cases for each new project that she works on? Isn't it a waste of productive time for her as well as the old hand who will have to guide her?

So is there a solution for this problem?

Of course there is, only if we are ready to accept the problem and are willing to invest in taking corrective and preventive measures.

A few points to keep in mind while writing the steps could be:

• use plain and simple language
• write the test for a newcomer, not for yourself
• be a liberal information provider

• mention the possible test data in the test itself

  provide links to more information such as requirements
  documents

  attach informative documents to the test suite

• ensure smooth flow of logic between steps
• word the expected behaviour in a precise manner
• get a non-team member to execute the test on the application,

be a mute observer

take notes

is she taking too long to comprehend the step

is she struggling to find the objects in the application

she cant proceed without asking questions to you

• if she isn't frowning by the end of the exercise then you can smile, else
  you know what to do :)

While writing this blog, many cases have been kept out deliberately, such as, writing tests for complex scenarios that span multiple screens or a test with more than 15 steps, etc. Such cases require some more intense introspection and we shall deal with them later.

Till then, lets be more careful and caring ........ at work!