Optimal way to write Test Cases for the same functionality

Question

I'm trying to change my approach to testing and use more documented, thought out formula. I'm trying to write test cases, was reading some theory, but I'm still meeting some obstacles.

For example - let's take the game, in which I can do the same thing for different objects, for example move something and replacing things around the map. Code responsible for said movement is the same for every object, but they are different from each other, in one way or another.

What I have troubles with, is the optimal approach in writing and documenting test cases for situation like that. Of course ideally I would like to check if every object behaves how it should, when moving it around, but if I had hundreds of objects, should I write down test case for every single one of this objects? It seems really time consuming and almost counter productive, but I still would like to somehow document everything I check.

What is your experience in that?

Answer 1

For my experience, the best way for it to be less time consuming is to automate it but since you tagged it as manual-testing, the only advice I can give is try grouping it.

For example if you have hundreds of objects, and when you move this object you need to check how they behave. Im pretty sure, there are lots of objects that when it move, it will have the same pattern or behavior(as you said that they have the same code but only differs in one way or another). So with this, you can tone down your test cases. Even though the object is not the same, as long the behavior is, the you can make it as one test case. This is how should I approach it, if I am in your situation.

Answer 2

An "optimal way" will depend on your purpose (actually, the value of any practice depends on the context).

A test case, like a Product Coverage Outline, an executable specification, or a checklist, is a document target at a particular person. So your question needs to be complemented by who will read the test cases (and with what purpose).

Assuming that you are targeting at someone with a good knowledge of the application's context, you can describe the common behavior at one part and what differs each type in another place, for instance with a mind-map or a bullet-list:

• Object behaviors

  • Common
    • Bla bla
    • bla bla
  • Specific behavior
    • Type A
      • Bla bla
    • Type B
      • Bla bla
      • Bla bla

Answer 3

Abstract sub test cases like functions and call by hyperlinked names.

As in programming, we define abstractions as functions , similarly in manual testing we can abstract common functional behavior as sub test cases and develop domain specific keywords(sub test cases) and call by hyperlinks.

Once we have identified an functional flow pattern and named it , we can call it whereever required as sub test cases with individual object names as parameters.

This simplifies the test flow by providing hyper links to these sub test cases definition.

Answer 4

If the steps are the same, there should not be a separate test case for every object. The different objects, in this case, are the parameters for one specific test case. Each time you execute this test, you need to document which object has been used and what the actual result was.

Where do you document your test cases? Do you use some kind of a management tool or just in Excel?

If it's in Excel, you probably should be able to create some kind of a parameter variable , but I'm not sure how to properly implement it. If you're using a test management tool of some kind, look for the Step parameters option in test cases. We use PractiTest and actually use their Step parameters functionality a lot, that makes test cases reusable in many occurences, including those that are similar to yours.