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.

Comments

Otilia said…
I find the use of such a syntax useful, since you can see in a glimpse what and where to test.
March 27, 2012 at 4:37 PM
Shailesh Gohel said…
Hi, You are right about this repeated syntax.

But do you have any other alternative to eliminate those syntax ?
March 30, 2012 at 2:52 PM
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?
April 5, 2012 at 12:17 PM
Francis Balfe 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
June 9, 2012 at 9:42 PM
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
June 11, 2012 at 6:56 PM
Unknown 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
July 13, 2012 at 11:12 PM
Unknown said…
This comment has been removed by a blog administrator.
October 29, 2012 at 11:11 AM
Post a Comment

Popular posts from this blog

Exploratory testing, Session based testing, Scripted testing…concertedly

In my last assignment a mix of exploratory, session based and scripted testing helped won an award, appreciation by managers & stake holders at our organization. The quotes from our award certificate “ QA team has come up with some intelligent testing techniques to validate the product. The customer test team was not able to find even a single critical bug after delivery ” Though the award was a small one in terms of the award categories our organization have, it meant a lot to me and the team, because this was the first time the team used exploratory approach. The assignment was not pure exploratory or session based, in fact it was supposed to be scripted, but a mix of all three exploratory, session based and scripted testing helped us learn, enjoy, and meet our mission. The assignment started off with developing test cases. We wrote test cases based on the initial requirement document provided. We did come up with a large number of test cases, of which most were re-written, some ...
Read more

Regression Checks + Regression testing = Regression testing?!

One of the questions I find hard to answer when I use exploratory test techniques in my project is,”How do you run regression tests? How do you prioritise them? Do you automate them? Do you document regression test cases?” And then a bunch of questions follow. Let me define the context. I work closely with developers; we use either Scrum or Kanban - which ever best suits our project, product owner, business. We do not believe in individual metrics, blame games, stringent processes, and heavy documentation. All we care about is to deliver high quality software. This does not mean that there is no process, metrics or documentation. We have them all, but they are there to meet our needs and to help those who will come onboard to support/maintain the software. Regression Checks At the start of a story, testers pair up with developers to develop feature files using SpecFlow. Some call it Acceptance Test Driven Development and others Behaviour Driven Development [I am yet to figure out the d...
Read more

What do you do when you find a bug?

What do you do when you find a bug? Hold on do not answer it right now. Let me first set the context. You are part of an agile team. The developers sit opposite to you. You are testing a feature in a session. You are time bound and have the good habit of capturing notes when you test. When you now find a bug what do you do? Assuming that you have taken enough notes you go on to write a good bug description and may capture a screen shot, video of the bug and continue with your session. At the end of the session do you Open the defect tracking tool (wait for it to load), enter all the fields for a bug, upload necessary evidence and have the tool share the defects with your dev team? Or Open the defect tracking tool (wait for it to load), enter all fields for a bug, upload necessary evidence and then compose an email to the dev team with the bug id’s/descriptions? Or Walk to the developer share your notes; reproduce it if required, work together to identify the problem? I work in ...
Read more