One quick story:
I was adding a new feature that needed an API client created by another developer. The API required three inputs: ID, country code, and phone number. I followed this specification, made a test, and all seemed good. But when I updated my code later before deploying. I found out the other developer had changed the order of the inputs from the client method that I was using. My test caught the mistake before it went to production.
This real story shows one scenario that specification-based test. And how it could save you from creating a new bug in your system.
What is Specification-based testing?
Specification-based testing is a black box technique where the developer has to write the tests by following the specification that the code was built. The idea is to use the specification to create test scenarios that will match the defined business rules.
Why Specification-based testing important?
This technique is important because it helps you to check the proper behavior of the code if the code is following the specification that it was built on. It helps you to identify some misunderstandings to clear out. Also, it helps you to understand the behavior of code that you didn’t write in an exploratory way.
Five Steps to Implement Effective Specification-Based Testing
1 - Understand the requirements: Understand the business rules that led to the development of the code. Consider the inputs, what they are, how they fit with the business rules, what are the objectives of each one, and what it represents. Do the same thing with the result.
2 - Explore the program: Test a variety of inputs, and see what results from it. This step is good for understanding code that you didn’t write (if you wrote it, this step is optional). It will look like that you are doing a reverse engineering of the software.
3 - Explore inputs, outputs, and partitions: check the parameter types, and how many there are, explore each of them individually (null values, negative values, higher values, lower values, things that could break stuff), then explore them together, check how the inputs affect the results.
4 - Analyze boundaries: check the boundaries of your code, and test passing values that are on the edge of your validations, which is a common place to have bugs in it. Example: if you have a password validator that checks if the password has 8 or more characters, do a test with exactly 8 characters, maybe in a hurry you misplaced a ≥ to a > introducing a bug in your code.
5 - Devise test cases: After these steps, you'll understand the code. You can then create tests based on these results. Some may be redundant and testing all scenarios may not be beneficial. Choose the most relevant ones for your application. Domain knowledge can help identify unlikely scenarios.
Want to know more about this topic?
In the following days, I’ll dive into each of those steps in more detail, follow me, and do not miss my next blog posts of this series when it comes out.
Top comments (0)