How do *you* write test cases?

Discussions
, ,
42

I see test / use cases as high level test ideas during the design and (test) development phase. I would recommend don’t be too detailed. I have seen too often that designs changes in the development phase so that you need to rework it.

Tests are mainly executed to reduce and/or identify business risks. Test automation (assert checks if tests are giving the expected response) are important to identify that behavior didn’t change.

Exploratory tests are quite important since you need your brains (knowledge) and eyes for that.
Manual tests doesn’t exist, since you also don’t have manual development steps,
Following a test scripts with steps is not testing, but it is checking.

Read the blogs from Michael Bolton / James Bach

43

I think test cases can be very useful. We didn’t do them as much in the past and that caused issues.

  • supports testing by showing what you have done and what is still open, easy handover
  • documentation of new features
  • documentation of testing (helps spot coverage issues and remember what was done)
  • repeatable tests for hotfixes in older versions
  • easier onboarding of new testers

We write our test cases while we are testing. They are not a script that is followed. Of course we start by planning roughly what we want to test, but then you might have additional ideas during testing. They are medium detailed, I would say. Mostly each step is a scenario. When the setup is more complex one scenario can be multiple steps. Basic knowledge is not written down. If you want to edit a user everyone knows that you need to open the client and log in first.

44

This one I’d be very wary of.

I’ve seen teams do this purely because they have not prepared properly or have time to spend with the new tester and have convinced themselves its a good way for someone new to learn the product. An other reason is they have manual scripted regression tests that are no fun at all that they can cast off to the new person.

In my experience test cases for the new person have been more harmful than good and can have a long term negative impact on the way that person will work and enjoy their role.

It may work in some cases but just wanted to flag to be very wary of this.

45

I tell you what - this got to be one of the most polarising topics in testing :smiley: .

I’ve mentioned in earlier post but this is something I’ve flip flopped a lot on and still do - I’ve been having internal battle with this topic very recently as well :smiley:

I see the test cases as an aid to learning. Something for me that is quite important as testers come and go and we need to have good artefacts for people to use and learn.

One of the apps I work on as an e-commerce type thing - so imagine a feature around Tax (item prices are “pre-tax” then tax is displayed on the basket screen/checkout screen).

An “automaton” type approach here is to have a test case, with specific results.

Steps: “Add items A, B, C to the basket. Proceed to basket”
“Expected Result: Tax value of X is displayed”

(In this example, items A, B, C have been set up specifically for this test)

So in this I’ve given the reader some examples of items to use. In this case it is confirming functionality is correct. I think have a supporting wiki/doc which might give a bit more info as to why the tax is X.

The question is what is more useful in the short term -

The example with the specific data, or just a statement “Check tax is displayed correctly”.

I hate this topic :smiley:

46

I was looking for practical examples here on the actual writing of test-cases, didn’t find it in this thread.

I, too, didn’t write test cases but went with models, mind-maps, XBTM, charters, testing notes, exploration and experimentation, risk-based testing, deep testing, etc…

Unfortunately, I got into a corner now.
I found myself without a job and for the past months I’ve only found roles where test-cases based on checking the written requirements are a must: European institutions, banks, financial institutions, insurance, aviation/airlines.
I have no choice but to apply to join those. I have refused a couple already but I’m running out of money to survive unemployed.
Now, in each of these:

  • there’s already a process established(Tmap+ISTQB or close to it),
  • a manager that keeps people in check, and who most probably is not a serious professional tester - most of the times someone who hasn’t even been a tester; Btw, I haven’t met yet in 7 years here someone aware even of CDT, RST, BBST;
  • thousands of test cases, with testers & automation engineers already following those rules;
  • the job’s expectation is to do this and only this.

In my initial years of testing and when trying to be a good employee/slave, I made attempts to write or follow test cases (about 10 years ago) I froze and ended up either:

  • trying to fake that I’m doing it;
  • or update/write only the title of a charter(which annoyed people);
  • or delete half of the cases(as I thought they were too obvious);
  • or re-write the steps with a dozen of variations(or if X, or if Y, or if Z …then expected is maybe A, or B, Or C, or anything weird might happen and look around…);
  • or get into arguments with people about them;

My goal now is to get a job and try to keep it for several months.
Does anyone have any suggestions on how to make it work? or actually, how to turn off my thinking process to write test cases? how to keep my motivation and sanity working 40 hours/week doing just this?

47

Oh, I sympathize. How I sympathize.

I recommend the passive-aggressive/malicious compliance approach here. You do precisely what the ISTQB etc. guidelines say. In painstaking, make your eyes bleed detail. If there’s a step that can go either X or Y, that’s two test cases. And so on.

Sadly, if you take this path you won’t get much actual testing done in that 40 hours/week because you’ll be so busy writing the test cases you’re asked to write. You can cheat somewhat with a good template (if you’re lucky, the job will have one).

For your sanity, take lots of micro-breaks. About once an hour or thereabouts, get up and spend around 5-10 minutes doing something else marginally work-related. Take a trip to the bathroom, check out the break room, read up on company policies and whatnot (or appear to - this kind of workplace is likely to have a LOT of printed documentation that you can appear to be reading while you let your mind go to more pleasant places).

In a more serious vein, it helps to remember that many of these places have regulatory requirements they have to follow, and they have to have evidence of having followed said requirements. They also often have a long history of doing things a certain way, and a great deal of inertia. Those who work in these environments often view it was “it’s working: why risk breaking it?” - and believe me, finance, insurance, airlines and the like are very risk-averse.

Of course, the more you bother your superiors asking how they handle the multiple variations that can come into play when navigating the software (questions like “Do you write a separate test case for someone who navigates the system entirely by keyboard shortcuts? What about navigating half by mouse and half by keyboard? Going back once? Twice? Three times?” Eventually someone will get your point, especially if you’re asking sincerely. After all, you’re still thinking about how to find the gaps in the software.

(If you can, using something that will record your testing/exploration sessions and using those to seed your test plans will save you a lot of pain - you’ll still have to write the wretched things in the approved format, but at least you’ll have a record of exactly what you did to get there - and yes, most of my test plans got written while I tested the software or afterwards. Thankfully I don’t work anywhere with such heavy regulatory requirements)