I’ll start this off by saying I’m using test cases in TestRail, and politely request that the discussion doesn’t derail into talking about me dropping test cases or automating them, as that’s not an option for me, thank you.
My company’s product is large and somewhat complex; the most I can give away is that our software helps energy suppliers maintain their customer base, their meter readings, and their billing/invoicing.
I’m writing test cases for the separate areas, but some features need other parts to be set up in a specific way in order to test them. For example, selecting an option on a form at the start of the setup process changes the way meter readings can be obtained, which then have their own set of parameters that can generate an estimate reading, which then can change text in a results table to show one thing, or another. There are lots of other instances also, this one is just the first I’ve come across while writing test cases.
My problem is that I don’t know where to put these test cases. As the system is so large, I’m having to create different test suites for different parts of it, which has the potential to become messy. I have sections to make sure each individual feature functions as the requirements state, but haven’t got to the part where they need to work together.
Hi Carly, I may be mistaken or misunderstood but it sounds like you may have a set of dependencies or variances.
Dependence on certain choices for a journey to be taken.
Or, Variance of journeys
You could potentially have a suite for either or both depending on which matches your situation.
You could have the test case list the prerequisites for the journey to begin.
Or indeed you could just add these types of test cases to your existing suites.
It may also be useful to use some technique to help you understand what you need to map like a decision matrix, systems map or similar. That could help visualise where they might best fit.
Not sure if any of those thoughts might help but I wish you luck.
Looking at your situation there are a lot of possibilities to test. According to me it is a challenge for you to maintain this huge set of test cases.
There are several ways to reduce the complexity:
A classifiction tree is a way to get an overview. E.g. there are two ways to calculate a bill: one for a private person and one for a business.
The next step is to determine whether all combinations of parameters are possible. E.g. Business contract Q cannot have supplier A and delivery option B. This is also part of classification tree.
It is still possible that too many options remain. In that case I would recommend to use pairwise testing. Every pair of parameters like suppliers and delivery options is tested.
If there are still too many cases, then product risk analysis can be used to pick the most important ones.
If you make test cases, then link them to the cases in the classification tree. There are tools for classification trees on the market.
In order to reduce the size of the test cases my suggestion is to use keyword driven testing.
E.g. CalculatePricateEnergyBill(200 kWh, [other relevant parameters]).
This test is focused on the calculation of a bill of a private person which used 200 kWh considering other relevant parameters.
The advantage is, that a step is written out once. Then all relevant parameters can be set in a fast way.
Assuming your main problem is the overwhelming number of possible combinations,
I would start to ask whether it is really feasible and necessary to test all of these combinations.
May be the focus on a hand-full realistic and exemplary customer-near configurations could
help address the most important configurations following an 80/20 approach.