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
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>
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
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
You may have noticed one or two other things in there.
- I used things like 'Confirm x' - This is an embedded confirmation, saving time and additional test cases
- 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
- 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