Test Cases — are Knowledge Base for your product or service
How many manual test cases do you have? Several hundreds or thousands?
I work in a company where we have more than 100.000 (yes, a hundred of thousands) manual test cases. And this amount still continues to grow.
This may look something unreal: how can we execute all these test cases? And maybe the most surprising answer is: we don’t!
We don’t execute them all for every release. But we keep them and manage and restructure and reorganize them because… they are a Knowledge Base about the product, about the features expected behavior, about tested conditions, etc., etc.
Some of them may be needed in a year when something got broken in production, for example. Was that tested? How exactly? What conditions have been covered? And so on…
Where to get the answers on these questions?
Code can tell how it is expected to work, but it’s not true unless the code being executed (read: being tested).
Specifications also can’t tell you, because they are often obsolete and not so clear and they are about expectations, not about real execution.
And only test cases made and executed by QA Engineers can tell us the answers. QA Engineers touched the app the last before the app has been delivered to production. And they touched it with test cases: in this condition the app behaves this way, in another condition that way, etc. (see 4 types of test cases titles that QA Engineers write).
Sometimes some component may require redesign or features extension already being in production for several years! Business grows, system architecture changes, people who made them come and go — this happens! And that’s why, you need that test cases for regression testing, for knowledge.
Another important understanding about test cases: you don’t need all your test cases being automated (see When to automate and Manual test cases vs. Auto test cases: who wins?) — because everything has it’s cost and very often manual test cases beat automatic test cases in terms of costs!
That’s why there’s should be no worry about an amount of manual test cases. There’s should be worry about test coverage (how to improve test coverage see: FURPS+) and awareness in automation purposes and costs.
Long story short. When you write test cases (both manual and auto), think of them not as something that tries to break your system. No! Write test cases as something that completes your knowledge about your product or service. Write description of your app behavior… but in terms of test cases: when something happens, then the app does that, when another happens, then the app does that, etc. Kinda “cement”, describe, cover functionality with tests!
And how to do it better?
First: choose proper Test Cases Management Tool.
Second: write test cases titles clear and complete.
This helps A LOT!
Thank you!
P.S.: If you liked an article and found it useful, please, don’t hesitate to give it some claps — just to let more people to know about it!
Thank you!
