Testing Traffic Rules: What Would Test Analyst Do (Part II)
In this article, I will describe the last three steps from the test activities list. To have the full picture of what I’m talking about, please check Part I.
Testing Activities:
- Reading test basis and extracting requirements from it.
- Test analysis (deciding which technique will help to test traffic rules section to meet all the requirements).
- Test implementation.
- Test execution.
- Report.
As I mentioned in Part I, I took traffic rules (section 4 of Ukrainian traffic rules “Pedestrian’s duties and rights”) to demonstrate the test cases creation process by using different test design techniques to get a certain traffic rules paragraphs coverage.
When you decompose your test basis, you realize which paragraphs can be covered with what test design techniques. Let’s check, what are the results we’ve got.
3. Test Implementation
This is the step where we are creating test cases.
I decided to have two sets of test cases based on the parameters.
The first set contains all parameters combinations [who]-[where]-[when] and the expected result. As you might notice, test cases from 23 up to 26 have n/a as the expected result. It means there is no description in traffic rules that provides us with a set of parameters and their values. A good practice is to get to know the expected behavior from anyone who has knowledge on the project. Or remove these test cases if not applicable.
I simplified the second set a little bit to get fewer cases with the same coverage.
Here we need to check all combinations for [who]-[where]-[transport type] parameters. But, if we do so, we will get 60 cases (which is a lot). Let’s consider how we can reduce the test cases amount.
To do so, we can represent all four values from the parameter [who] as one equivalence class [pedestian]. When it comes to defining the priority of pedestrians over the [transport type], it doesn’t matter who specifically it would be. The expected result would be the same. After such manipulations, we get 15 test cases instead of 60. Pretty cool, huh?
Of course, I could reach 13 test cases by collapsing bike and motor vehicles into one test case when the expected result is the same (“pedestrian” has the priority to walk first). Those would be with lines 2 and 8, as well as 13 and 16 respectively. But, I decided to leave as it is. As I want to verify the expected result for all transport types.
Again, we have n/a in the expected result, as these parameters combinations were not described in traffic rules. Although, it might be the situation when special transport occupied a sidewalk. Who has priority then? I assume, special transport would have priority. Speaking about real projects we have to remember, we don’t rely on our assumptions. It is our job to clarify unclear moments to avoid uncertainties.
After that, you might want to set the priority for each test case to be able to estimate time for testing. Especially, when we have lack of time or resources. If so, we pass high and medium priority test cases and skip low priority test cases. Of course, we inform managers about all risks related to that. That is why we have acceptance criteria and such thing as MVP.
4. Test Execution
In our case with traffic rules, we would need to actually have all these different people and vehicles surrounded by a variety of city conditions with their roads, sidewalks, etc.
5. Report
At this point, we would create an actual results report. It can even contain a list of some enhancements for the future.
Result: 55 test cases instead of 120
Eventually, we got reasonable coverage of 55 test cases for certain paragraphs (section 4 of traffic rules). The rest of the requirements can be covered by State & Transition technique and Use Cases.
My goal was to show a tiny part of what is happening backstage in Test Analyst or Test Engineer work. Even when it comes to traffic rules. Walk safely!
Please share with me the most bizarre cases when you applied testing techniques. I’m sure you have some.
