Divide Test Cases across multiple Testers

Question

I am writing test cases whereby the basic steps are similar to this:

1. Create a record in system A
2. Check if corresponding record is created in system B
3. Check if corresponding record is created in system C

Steps 2 and 3 are the success criteria of the test case - if either of them fail the test case as a whole is failed. None of the testers at my disposal have access to all 3 systems. At most one tester has access to 2 of them. I know that in an ideal world each tester would have access to all required systems, in my case "the powers that be" have decided this is not possible for now.

My question relates to ways to make this collaboration work using testing software. I can think of two ways to organise a test case:

1. Write one Test Case that includes all steps. The testers must then pass the Test Case around and work on the individual parts they are able to.
2. Create individual Test Cases for each of the above mentioned steps, whereby a) the Test Case for step 1 does not have any testable outcome of its own, and is simply there for the purpose of data creation b) the Test Cases representing steps 2 and 3 each reference the corresponding Test Case of step 1.

What would you do?

Answer 1

What would you do?

I'd most likely hand in my notice working in such an environment.

Is there any reason why this has to be overengineered? Not in my opinion.

I'd simply create one test case and trust my coworkers. They should be able to communicate when it's needed.

Of course getting access to all three systems is a priority (it is really necessary in fact) but I can understand some people make artificial problems in this area.

Answer 2

What about the three of you sit down and... work together? You can simply plug one computer in a screen and you all test it together.

(No sarcasm, seriously)

Two of the tags you posted are "HP-ALM" and "Jira". It can be a guess, but I feel that you may be limiting you way of working because of how these tools are setup.

From the Agile Manifesto:

(We value) Individuals and interactions over processes and tools

The best architectures, requirements, and designs emerge from self-organizing teams.

Any tool is meant to be used to enhance human capabilities, not to limit them. If a tool is not helping, don't use the tool - find another way of doing it (self-organization).

And testing not about marking scripts as passed or failed. Even less about who did what. Testing is about telling stories. Find the best ways to communicate these stories to the people that matter.

Answer 3

So I have been using a test management tool (Kualitee) that allows me to somewhat managed the same with the help of test scenarios and test cases group into one.

For example, I choose a module to test and create three different test scenarios to be executed by three different testers, I group the corresponding test cases according to scenarios and then assigned the testing cycle to different testers. Now each execution is recorded exclusively to the test cycle I assigned with associated defects.

However, I do see the need to differentiate test cases based on steps instead of creating one full-blown test case. This would help validate steps quite early and with shorter testing cycles.

Answer 4

To ensure better tracking of testing coverage and from an integration testing point of view, software testing solutions will adopt the 2nd approach if a single engineer does not have access to all the 03 required systems.

The individual test-cases created for this scenario, will be responsibly executed by each user at the integration point while testing the whole product. Below 03 use-cases can be added:

• Verify that the system-A user can create a record successfully
• Verify that the UserA's record gets automatically created in system-B and system-B's user can successfully see it
• Verify that the UserA's record gets automatically created in system-C and system-C's user can successfully see it

This approach also provides better clarity if record visibility fails for any of the system-B or system-C user.