Driving Test cases when only system requirements are present

[Tassawer]

How can you drive test cases if you are only presented/ supplied with technical information in case of system requirements and you haven’t seen the system yourself.

You are supposed to write test cases with steps.

[Roman]

I argue not to do it in details until I really interacted with the system.

Context-driven school has good arguments for that, and my personal experience in testing proved them right

• Technical information or requirements may change. That changes cause changes in test cases (TCs) / steps. It takes a lot of time and effort to change written document(s). One would spend less time going for detailed description after one saw the system and learned about it works, not before one learned that.
• There could be misunderstandings. You knowledge of system can be poor: it might not work like you imagine now. If you write something out of your imagination and it doesn’t match the real system work, you have to rewrite it or throw it away. Again, risk of time losses.
• Written test cases don’t find issues. Testing finds issues.

My approach (I successfully argued it with my test manager, team lead etc).

• Because of above-mentioned points I don’t write detailed test cases in advance
• I compose a lightweight checklist(s) which I use in my testing (also make notes).
• After I interacted with system and learned it to some good degree, I’m ready to write detailed description and now it is going to match actual system behavior with approved changes
• Working with system I develop a mini-lingo to write about it (one more thing I may not know in advance is how to call what).
• My fellow testers do not need my detailed test cases here and now. Fellow testers can see what I’m going to test / testing with simple plan or checklist. They know the product well enough to understand what I’m going to do and what I’m not going to do. If they don’t, developer(s) can fill them in, just as they filled me in.
• Developers do not need my detailed test cases here and now. They need to know ASAP what issues are in what they developed. Even if I can develop most perfect test cases in advance, but discovered critical issue hard to fix last day before delivery, it is bad-bad-bad. I better discover issues first and make documentation later.
• Managers do not need my detailed test cases here and now. They need to know ASAP if there are any issues, how critical are the issues, etc.
• Customers do not need my detailed test cases here and now. They need tested application, and testing first I do better for the project. If they need test cases as well, they need it with tested app delivery, not in advance.

So, for the sake of the team and the project success you better test first and write detailed steps later.

In case you cannot avoid writing in advance, you may try to go for more generic steps, like “update app binary on server” instead of “open configuration page / click Update button next to binary app file name / choose new binary file in file dialog / click Update “.  In any case it is better to learn / test system first and write detailed steps later.

For the writing itself, you can use design drawings / mockups / specification , whatever helps your mind to visualize your journey. Still, you better be most general without really seeing it.

 

Helpful materials:

CAST 2014 Keynote – Test Cases are Not Testing: Toward a Performance Culture

No Test Cases Required: Test Session Chartering

Quality Jam 2017: Michael Bolton “A Ridiculously Rapid Introduction to Rapid Software Testing”

 

 

[Author]

Posts