MLevel

Writing Test Cases for Functional Testing

What is a Test Case?

In software testing, a test case is an ordered sequence of inputs with conditions and variables that determine whether a piece of an application is functioning properly.  In functional testing, test cases are used to test the application’s interface and determine how an application and the user interact.  You could think of test cases for functional testing as similar to unit tests for code.

Test cases usually include the following:

  • Title
  • Description
  • Sequence of steps to execute
  • Expected result
  • Actual result
  • Pass/Fail

 

What’s the Value?

Part of the value in test cases is the process of writing them.  The activity of thinking about and writing down test cases can bring some realizations to the table that help improve your product before testing even begins.  But test cases also help us ensure we’re not forgetting to test key, frequently used components.  They bring a sense of control to the testing process.  Today I’ll be discussing 5 tips on how to write better test cases.

1.  Imagine Yourself as the End-User

Before you begin writing your test cases, you need to identify what your testing approach will cover.  The most important stakeholder is the end user, as they are the ones who will be using the product.  Ask yourself: What features will they be using most frequently?  What is the start-to-end flow of a real use case?  By putting yourself in the shoes of the end-user, your test cases will provide better coverage, and lead to more successful testing.

2.  Organization and Thoroughness is Key

If a feature’s behavior is dependent on inputs, include those inputs in the test case. The same idea can be applied for screen designs.  If your test case requires reviewing a design asset, include the asset in the test case.  Don’t leave the tester to hunt for this pertinent information.  It’s also important to consider the order of test cases, as some cases are dependent on others.  Keeping your test cases organized and thorough ensures the testing process goes as efficiently as possible.  There are plenty of tools available to help you organize and manage test cases.  Our tool of choice is TestLodge, a simple yet elegant test case management solution.

3.  Revise Regularly

We live in a world of constant change.  Technology changes.  Features change.  Designs change.  Test cases are prone to change and require periodic revisions.  By keeping them updated in parallel with product requirements, they will continue to serve as a valuable asset through each release cycle.

4.  Ask Questions, Contribute Feedback and Make Suggestions

As you write your test cases, don’t be afraid to ask questions, challenge decisions, contribute feedback and make suggestions.  Testing is all about bringing quality to the product.  It’s often the tester who really uses the product for the first time.  The ability to analyze and solve problems is essential.

5.  Test Your Test Cases

The job isn’t done once you’ve written your last test case.  Check your work by doing a dry run from start to finish.  Review all test cases with the mind of the tester.  If a screen is supposed to look a certain way, did you include the screen in the test case?  If a test case requires logging in, have you included the login credentials?  Are the test steps you’ve written clearly understandable?   You’ll be surprised what you can find by dry-running your test cases.

 

Conclusion

Test cases can be a valuable asset to software development teams.  They are one of the many ingredients in building quality products.  By writing and consistently revisiting test cases, your testing team will be on the same page and be able to track and better organize your testing processes.

Share this post

Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on pinterest
Share on print
Share on email

2 thoughts on “Writing Test Cases for Functional Testing”

  1. Avatar

    Ok I like what you wrote. But back to reality. Nobody had time to test test cases. We barely have enough time to write them, and for what?, to get buried into regression tests? I primarily write automated test and won’t spend any time writing out a test because any tester I bring on, I expected to read my code (tests) and learn from that. My main comment to all of this is spending time on manual tests helps a tester think and lays out their thoughts and once functional testing is complete those test are cherry picked and absorbed into regression

    Any additional thoughts ?

  2. Avatar

    Thanks for your comments!

    “My main comment to all of this is spending time on manual tests helps a tester think and lays out their thoughts and once functional testing is complete those test are cherry picked and absorbed into regression.”

    I completely agree. I think there’s a fine line between investing too much time on test cases and not investing enough time. As for not having time to “test the test cases”, a quick read through can be enough to realize there are holes. I think test cases should be proofread just as any other piece of writing should be. That said, I’ve found that investing less time in writing the test cases, and more time in making sure the test case applies to future regression tests is a better use of my time.

    Thanks again!

Leave a Comment