2

I am looking for a sane way to organize our test scenarios and test plans. We have a quite modular application, which is customized for each customer. What else, each customer has several mutations of the application.

For example, imagine a calculator, scientific calculator, programmable calculator and each of those in different languages or numerical systems.

Right now, we have a separate test plan and list of scenarios for each customer-product combination. But the maintenance is a pain, because each time a feature gets changed, that is present in more products, we have to update several files. However, even some of the core features of the product, which are completely same for 9 customers are behaving differently for another.

What I think, we are missing, is some central document, which would describe all features together and from which we would then generate the test execution plan.

But I am not sure how to structure such a document, how to describe the "common features" and "custom specials" so these are maintainable.

Is there anyone who has used something similar or solved similar problems?

  • " each time a feature gets changed, that is present in more products, we have to update several files." Do those files contain test plans? Or something else? – user246 Apr 4 '16 at 17:01
  • Yes, we have to update the specifications and plans for each customer that will be affected by the change. – ne2dmar Apr 21 '16 at 15:00
1

I would suggest you work with the developers to find out what are the core functions that all releases have in common, that becomes your initial Test Plan and also a potential source for your regression testing for the overall product.

While having a discussion with the developers ask them which are the areas with the most risk both for the core functionality and what areas for each customized version for each customer are higher risk, this becomes your second, more in-depth sets of test cases.

The second group of people I would work with are the people in your team that work with the customers and decide what should be customized for each one. Ask them what are the customizations that are critical for each customer, this supplements the second set of tests above. While discussing with this group ask them to provided you with what is being planned to improve the product so when they deliver those requests to the programmers they should deliver that to you and the team of testers as well. This will supplement the tests you have created and keeps them current.

You then should make an estimate for how long it takes to test each one of the 4 lists above. This will help you communicate when being asked to test the different applications how much time you will need, and if that is not possible what is can be tested (start from the top down) and what the risks are of not testing the applications in-depth.

As an alternative you can suggest a staggered release so that you test a limited number of customizations first, maybe for your more critical customers or fixes and then test additional customer implementations later as time allows.

  • Well, the problem isn't about communication or the time, it's how to handle a large number of similar test cases. I know what needs to be done, I am just lazy to make the same edits to each file. – ne2dmar Apr 21 '16 at 14:59
1

What about a wiki, or something like a wiki? I'm thinking specifically of the ability to include pages inside other pages, so you could make a change to one of the inner pages, and then have it reflected in all the containers. I believe you can do something similar with MS Word.

  • That seems like a good and viable idea. And any proper wiki have some sort of versioning as a bonus. For now we are trying to use Testlink, which also reuses the test scenarios across different test plans. – ne2dmar Aug 4 '16 at 13:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.