Understand your Test Ideas

I develop Software Quality Assurance’s Mate — test cases management tool that aims to dramatically simplify manual test cases design — and I always look at the way QA Engineers write their test cases.

For example, I found this:

But now I want to give you another life hack on how to write your test cases better. And it is about how to threat your test ideas.

And the first life hack is…

Maybe it’s not a test case, but a test suite?

For example, if you face an idea that looks like (real examples of test cases summaries, that QA Engineers write):

  • Check upload files of different types
  • Form the report
  • Redis responds with timeout
  • Validacion de campos vacios
  • Поиск по версии Windows

and so on… Try to think of it this way: maybe it is not a test case, but a test suite? Because in most cases it will be a test suite!

This approach will help you to:

  1. Simplify your test case, splitting it to several atomic verifications;
  2. Improve test coverage because you’ll be not satisfied with 1–2–3 test cases in test suite, you’ll force yourself to think more and use FURPS+ model to add more useful test scenarios;
  3. Add structure to test cases to build more simple and clear Knowledge Base of them;

Maybe it’s not a test case, but a user action?

User actions — is another type of “tests” QA Engineers threat as test cases. For example:

  • User logs in
  • User resets password

could be test suites. But test cases in them could be partly the same, i.e. duplicated:

  • User logs in
    * Login page is displayed
    * Enter email as login
    * Enter valid password
    * Click “Submit” button
  • User resets password
    * Login page is displayed
    * Click on “Forgot password” link
    * Enter email as login
    * Click “Submit” button

(bolded same test cases, same “methods” for auto tests, for example)

But we don’t want duplication! We want maximum reuse of test cases. That’s why think of such test cases as user actions!

This is a new type of items that is currently developed in SQA Mate. I’ve never seen this implemented anywhere else. But this type of grouping artifacts looks very promising!

Maybe it’s a test case, but has not clear title?

Test cases are often about some particular condition or situation. That’s why test case title must tell both about this condition and expected reaction of the system.

Compare:

  • Logging partially sent fax
  • Logging successfully sent fax
  • Logging successfully sent fax page

with more comprehensive sentences:

  • Fax engine writes INFO message to log about partially sent fax
  • Fax engine writes INFO message to log about successfully sent fax
  • Fax engine writes INFO message to log about successfully sent fax page

A bit more words, but now you don’t need to read test case body to understand, what’s happening and what’s the exact system’s reaction. That’s a good title for test case!


P.S.: If you found this article useful, please, don’t hesitate to give it some claps! Thank you!