TestToTester

Test Case Syntax


When reviewing a test case document (now don't ask me if it was positive or negative or division or) I could not stop noticing just how many times the words ‘verify’, ‘check’,’ is displayed’, ‘should be displayed’ is used. A pattern repeats itself which I am tempted to call the “Test Case Syntax”

Syntax:

verify << copy acceptance criteria >> is displayed in <>

Or

verify << copy acceptance criteria >> should be displayed in << copy acceptance criteria >>

Or

check if << copy acceptance criteria >> is displayed in << copy acceptance criteria >>

Check with your test lead to choose one of the formats

Example:

//Test case to verify forename, surname, post code is displayed in accounts screen 
verify the fields forename, surname, post code is displayed in accounts screen

This is how intricate development of test cases is. I do not understand why some testers continue to do this and their test leads, managers want them to do this.

7 comments:

Otilia said...

I find the use of such a syntax useful, since you can see in a glimpse what and where to test.

Shailesh Gohel said...

Hi, You are right about this repeated syntax.

But do you have any other alternative to eliminate those syntax ?

Sharath Byregowda said...

@Shailesh,

"But do you have any other alternative to eliminate those syntax ?" - Just use the acceptance criteria as a checklist why duplicate it?

franyhi said...

We, as testers, spend so much time creating test cases by re-wording a Business Analyst's work. It's duplication of effort and a waste of time.

Why not collaboratively write the requirements (with business, BA, dev, test) as executable examples.

The development team can hook into these examples and build their code to meet the specification.

Test passes = specification met. Job done (for verifying the requirements).

That frees up the tester to use their noggins to exploratory test to find those niggley bugs.

Search for "Specification by Example", "Behaviour-Driven Development" or "Acceptance-Test-Driven Development"

http://en.wikipedia.org/wiki/Behavior_Driven_Development to get you started

Sharath Byregowda said...

@franyhi

That is exactly what I feel every team should be doing. Check my previous blog post.

It's strange how many organisations still stick to this traditional approach.

But I definetly see light at the end of the tunnel

Jagannath Sriramulu said...

Hi Sharath,

Its a Valid point. I had been reviewing test cases(Never Designed myself) and never noticed it.

It depeneds on the Project Environment. My Current client asks us to write test cases in a certain way and never accepts alternative and team can not participate in development discussions and the other side is always an Iron Curtain.

But in independent scenaraio, its a better practice not repeat itself all mundane words

Blue Light said...
This comment has been removed by a blog administrator.