Test smart: how to write test cases that catch annoying bugs
No one wants to release a buggy product that hasn’t been tested well. The credibility of your product and the reputation of your business might suffer a lot otherwise. Hence how to start testing from scratch? One of the fundamental things that enhance quality management is building appropriate test coverage on the system level.
The pizza thing
There is no universal recipe for efficient test coverage. It is the thing that varies among the projects and their unique testing needs. Yet experience shows the more various techniques you use in UI testing, the more test cases you find. If you explore more use cases, you’ll “scan” more potential weaknesses or confusing behaviours. Thus it is very likely that you’ll catch more bugs and discrepancies that affect user experience.
The test coverage is the system that helps you manage all the tests. Let’s imagine it as a pizza made of multiple ingredients.
Each tiny piece (like tomato, mushroom, onion, or olive) is the test scenario or test case. Each slice of pizza is a test set, or a group of test cases united by a relevant topic — a feature, for instance.
Testing efforts will be much easier if you divide your test coverage into slices — test sets. However, the first thing to learn is how to create its smallest elements — test cases or test scenarios.
Test case dilemma: to write or not to write
In very simple terms, a test scenario (test case) describes a sequence of steps that include conditions or variables, input and an expected result. The success of the test is determined by comparing expected and actual results according to a test scenario.
I’ve met some people from the QA field who believe there is no need to write test cases because it takes additional time that could be spent on actual testing. However, they either work with a Customer or Product Owner who does not care about written reports, or they are the only ones who test a product or both.
In agile environments, every single team member is encouraged to test the product as much as possible. Consequently, the whole team should own a shared repository of test cases. The test cases are not necessary to be collected in an endless spreadsheet that you are supposed to replicate for each test run. Nowadays, various test management tools are available to help you conveniently organize your test scenarios.
To my mind, each important piece of the system (test case) should be described and documented before a feature goes into testing. Ideally, test cases are written in collaboration with the whole team before the feature gets in the implementation.
It can be a time-consuming effort, yes. Yet this kind of preliminary analysis helps a lot in minimizing the potential risks long before your product gets to the end-users (who are perhaps a lot more confused when it comes to using your product than your Developers or Designers are). Moreover, documenting also helps visualise the test steps before the test scenario goes into automation.
Keep it clear and simple
Creating test cases is a doable task if you follow two basic principles: clarity and simplicity.
A well-written test scenario has a clear structure. I suggest following a known rule: Action— Data — Expected result.
Let me show you how it works in action. For instance, you are creating a scenario for login flow where the end-user is supposed to enter credentials in the required fields and click an appropriate button to be signed in.
The short description of the test case will look like this:
If a user enters valid data in the “Email” and “Password” fields on the login page and clicks “Sign in” he (she) is redirected to the home page.
Here: the action is entering data in the fields and clicking the button; data refers to valid credentials (email, password); the expected result is redirection to the home page.
As we can see, the test case contains one step (user action that leads to the expected result):
Test step
Action:
Enter valid data in the “Email” and “Password” fields on the login page and click “Sign in”.
Data:
Valid credentials (email, password) are required.
Expected result:
The user should be redirected to the home page.
If you’re documenting a case that requires a sequence of actions, defining all of its steps is important. Anyhow, the test case should be written in straightforward language following the logic of the flow that the end-user will go through. So keep it as simple as possible.
One slippery thing to mention…
If the test case contains alternative options for the user's actions or sets of data that lead to various expected results, then you’re dealing with multiple test cases.
For instance: in the example above, the end-users might enter either valid or invalid credentials in both required fields. They could also enter correct data in one field and incorrect data in another field. To avoid having a headache after release, try to create and check test scenarios for each possible situation that might happen to the end user. Once you write test cases for multiple situations, you can unite them in a test set.
Test cases in action
As you document the test cases, now it is a lot easier to move to another stage — testing in action.
When executing a test case, a tester compares the expected result with the actual result following a scheme: Action — Expected result — Test result. If the result is positive, the test has passed. If it is negative — it has failed, and the bug report will follow ;)
Testing is not about random clicking around the product or ticking Passed/Failed in the test report template. If you start working as a tester, get ready to improvise and try to apply as many testing techniques as possible. Be aware that testing in an agile environment might be a jazzy thing and it requires content decisions and rapid actions. As its main point is to give timely feedback so that the Developers can fix the issues before they reach the real users, it is vital to create and maintain proper test coverage in advance. The more you test your product, the more polished it becomes.
