The L4 Test Case

July 13, 2017

Part 2 of our Quality Assurance series.


We believe robust Quality Assurance (QA) is an integral part of creating truly innovative digital products and ensuring their market success. The following post is part 2 of our series on QA The L4 Way.

I am often asked: “How do I maintain test cases in Excel spreadsheets?” My answer is simple:

You don’t.

Pass or Fail?

 

Popular practices for QA testing, including using spreadsheets to maintain test cases, end up causing professionals to spend way too much time on maintenance than actual testing. Editing a test case is normal and necessary but should not occur frequently. Updating a test case suite repeatedly through a release process is taxing and time consuming. A schedule is already typically time sensitive and compressed at the end of the product development lifecycle: A better use of time for testers is to find and document bugs so we can release better products.

At L4, we have optimized our methodologies to free us from this pattern so we can spend more time testing our products and less time bogged down in test case management. Being efficient with our test cases early on allows us to be more focused on the most important part of our jobs: actual testing. Our optimized test cases can have a huge impact on our overall project outcomes. These methodologies have been very successful for us and we thought we’d share them with you:

Ensure test cases are properly categorized.

Test cases are categorized in three buckets: User Interface (UI), Functional, or Certification tests. Most pros are familiar with UI and Functional test cases — these are mainstays in the world of QA. UI testing, is a technique used to identify the presence of defects in a product by using Graphical User Interface (GUI). Functional testing is a process used in which software is tested to ensure that it conforms with all requirements and performs in the way that is expected. Atop of that we throw in Certification test cases. Each certifying body or manufacturer has its own set of guidelines or process required for a product to be “certified.”

Certification testing checks all mandated boxes; therefore, depending on the app or hardware we’re certifying, we stay on schedule. This ensures that our submissions will go through without any unexpected hiccups along the way. The end result reduces any potential “gotchas” so that we can keep our clients’ schedules on the rails and won’t be forced to re-submit multiple times for certification. Very frequently we’re able to certify a product on the first pass.

Write your test case for an experienced tester.

The number one goal here is a reduction in verbosity. In other words: keep it brief. We don’t advocate hand holding in our test processes and our test cases reflect this philosophy. We don’t want to overcomplicate our testing. If a client’s app changes we won’t have to alter multiple cases because of a single modification. Even a simple update like a background color change will impact an entire suite of test cases if written in too much detail. A non-verbose test case creates a useful template. Going forward, your team can use it across the product’s lifecycle, and possibly adopt it to other future projects.

Peer review your test cases.

At L4, all code is subject to peer code review for quality, consistency, and to ensure standards are followed. We want to make sure the code is right for the project, so why not extend this practice to QA test cases? At L4, we do. We ask for a second set of eyes on our written test cases to see if a different perspective will add value. We ensure the grammar and form are correct and understandable. Lastly, we want to guarantee the test case makes sense for the project and that the client’s end goals are being met. No gaps.

In my fifteen years of software testing, I recognize that writing test cases isn’t the most glamorous part of the job. But when test cases are properly categorized, succinct, and written with an eye on the final project goals, I am able to spend my time on the job aspects I enjoy the most: actually testing the product.

These are a few of my tips but I’d love to hear your suggestions and best practices around test cases. Leave me your questions or tips in the comments.

Read more: Part 1 of the QA Series: The L4 Bug

Derreck Dickson

Derreck Dickson is a Lead Software Test Engineer at L4 Digital. He has an extensive QA career that spans fifteen years and has tested everything from audio devices to smartphones to connected cars. In his free time, when he’s not serving as IT support for his parents, he enjoys playing basketball or a good RPG video game.

BLOG ARCHIVE
Cross-Compiled Development
Building Native Apps
Building Cross Platform Apps
  • August 2017
  • July 2017
  • June 2017
  • May 2017
  • April 2017
  • March 2017
  • February 2017
  • January 2017
  • Contact L4