What are some different styles of writing test cases? [closed]

Question

For instance, i have to make test cases for a Login Page. I see that all testers have their own style of creating test cases.. they use different words and different sentences. what are some unique words which a testers can use to make test case look more formal. for instance:

1. Open the url "google.com" in your browser... one can write Navigate to google.com.

Please share some unique styles of designing cases.

Answer 1

Personally, I find the style of writing a test case is irrelevant as long as the essential information for it is there:

• Who will be performing the test - the level of detail I use will be different for a test that's being performed by an experienced tester than for one that I expect a novice tester to perform. I'll give more guidelines to a novice and use more shorthand for an experienced tester.
• What the test needs to do - again, the level of detail will vary.
• What the result should be. This is usually not something I describe in painstaking detail because my test cases tend to be more guidelines for exploration than step-by-step "click this button" type things.
• When the test should be performed - including any prerequisites for the specific test. The nature of software development means I'll often use a single sequence of actions to verify multiple things at once.
• Where in the application and in the test environment the test is being performed - including the need to use a hardware lab, the need to access the application via the Internet rather than from a locally hosted instance and so forth. I've tested in situations where all of these factors are involved.
• Why the test is being performed - this could be as simple as there being a requirement that the software does X, therefore I have to test that the software does X. It could also be a lot more complex and based around what I know of the application user base (is this feature only accessible to specific users who will always be trained, or is it open to the general public?)
• How the test needs to be performed - mostly this is implicit, but there are times when it's necessary to specify that the test needs to be done with keyboard entry or via touch-screen or... You get the idea.

All these factors go into what I write in a test case, which is usually in the form of stripped down notes.

Answer 2

If you're simply looking for examples and formalisations to choose from, I'll add mine... else Kate is kinda right and this needs a bit more direction question wise ;)

I like Kate's principles in her answer, I cover mostly the same stuff but in a specific format I find very comfortable for 'me', and applies a little more multi-purposing to the output.

I use STR (blog post coming in the near future). It means 'Steps to Reproduce' and is effectively just that. Everyone knows how to follow 'steps'. They're ingrained in instruction manuals and recipes for cooking from the moment we start doing things for ourselves.

My main reason for using this is that it's human readable. It's basic common sense lowest-common-denominator-style formatting that should be useful, understandable and clear for any level of Internal & External customer. It also stops you from using 'Technical Terms'... which frankly mean jack.

It breaks down like this.

STR via <tool/service/location>:

 1. Step > next step > next step
 2. more of the same

Filling this in, you get something like:

STR via Control Panel:

1. Load "url.com/suburl/deeper" > Click 'Login' > Fill in Login Details
2. ....

Now, In that one step there are some assumptions. Firstly, you've established pre-conditions like:

Browser: Firefox (beta track/28.3.456)
Product: Awesome Thing
OS: OSX Mavericks (10.x.x)

By doing this you set the person reading this on a certain track, and can instantly tell whether they meet the test conditions.

Secondly, there's a '>' between steps.

I use this to show that I'm expecting a result between these steps, for example if I load that url the expected result is I'm shown a page with a Login button. This means you can get away from using Step, Expected Result, Actual Result (as taught by the painfully outdated ISTQB Syllabus). Effectively, the '>' implies a potential failure state.

Thirdly, there are different quote depths. "Thing" means you can copy and paste directly, 'stuff' means there should be something you can see and interact with.

These subtler details are more useful for technical teams, while at the same time notifying a difference to the casual observer between key steps in the test case.

A fuller example so you can see how it all comes together:

Front-End URL: (all STR will be relative to this URL)
Back-End URL: (links to any dashboards/CMS tools/services)
Browsers Tested: Chrome (latest Auto-update Version)
OS's Tested: OSX Mavericks
Resolutions Tested: <link to standards doc goes here>

PREP WORK:

Please make sure you have the visuals to hand when 
testing this work, you will need to refer to them 
to confirm context, text, image placement etc

Login - Nav Options: <-- this is just an informative header, optional.

STR via Front-End

1. Load "http://genericthing.com/" > Confirm page fully loads
2. Click the empty avatar > Login > Fill in valid email and password ("password")
3. Click ‘Login’ > Confirm you see the Hub/Dashboard page - Yes = Continue
4. In turn, Click each of the top-nav tabs and confirm content is loaded
5. Click 'Hub' in the top-nav > Confirm that:
 5a. Graphs have tooltips
 5b. Lines match the data set
 5c. Layout matches visuals
6. Logout > Click 'Login' > Fill in the wrong password ("rubbish")
7. Confirm suitable error message is displayed > Yes = PASS

COMMENTS:

Repeat as necessary for additional browsers.

Other comments and observations that aren’t a failure,
but may add additional future work “This looked crap, 
this took me additional clicks that aren't necessary”

Russ - Uber QA Guy
<Contact number>
[email protected]

You may have noticed one or two other things in there.

1. I used things like 'Confirm x' - This is an embedded confirmation, saving time and additional test cases
2. It has clear calls to action - Yes = CONTINUE, YES = PASS, No = PASS, No = FAIL - This helps the user understand if they've hit a wall or not, and whether they should start considering something a bug
3. I used 5a,5b,5c - These are Varients. These are your use cases, again this is a method of reducing the number of test cases required, but still giving the same coverage.

I try to remain consistent with word usage: Confirm, Load, Click etc. This is more for maintaining good practice and standards than anything else. It also makes it easier when implementing automation off the back of it.

Finally, I find this more useful than using Gherkin. I 'know' it's a quick route to automation, but quick isn't necessarily correct. In the majority of cases where I've tried to get people to compare Ghekrin to STR, STR always wins out. I don't see the point in abstracted languages, especially in Gherkins case as people so often forget cucumber is even there to help and constantly right their own definitions and calls etc.

As I said above, STR is just comfortable. Not just for me but for other people reading it. When you export your test libraries for Client Facing test packs, you don't have to change anything, it's easy enough for anyone to follow, quick to read and understand the point and SHORT due to embedding the important things, and making core assumptions about when something should have failed.

Anyways, as an example of another way people do test cases, that's mine