Test case tests are contrary to exploratory tests. While we leave it up to you how you go about testing in exploratory tests, test case tests don't offer this freedom. In test case tests, we provide a number of test cases, each consisting of a set of three to thirty steps that needs to be gone through one by one. The setup also defines how many times and with which environments each test case can be executed.
Customers will set up test cases when they want to ensure that specific scenarios or processes can be gone through successfully. If problems occur, customers want to know which step caused the problem, if you could still continue until the end, and what environments are concerned. Many times, customers will let their main functionalities get checked, which are essential for the customer's product.
In order to claim a test case execution, make sure you quickly claim a test case right after the test starts. If a tester aborts an execution, it will become available to everybody again, so it's worth checking the test later again even if you cannot claim (any more) test cases.
You cannot claim a test case execution if you have already completed that test case, if you don't have one of the required environments, if all executions are currently being worked on by other testers, or if the test runtime is up.
Test case execution
At the beginning of a test case, a precondition might be displayed. You may only continue if you meet this condition.
Every step has a description telling you what to do on the page that you are currently on. For example, one step might ask you to “Add a product to the shopping cart”. Many times, it will also state an expected result.
Executing each step accurately is very important, so please make sure to read every step properly, upload the right attachments, and to provide appropriate answers to questions.
Step execution succeeds
If you were able to perform the action (and if you can observe the expected result), you check the step via the green button. Some steps will require you to upload an attachment proving that the current step was successful or that you are on the correct page, while others will ask you to answer a question, or not ask for any of the two.
Step execution fails
If you aren't able to do what the description asks you to do (or if you don't observe the expected result), click on the red button. When the execution of a step fails, we ask you to explain what happened instead and to provide evidence in form of at least one attachment. Your attachment proves the unexpected behavior.
If your bug report is not valid, it will be rejected, but it does not invalidate your test case execution. Like it is the case in exploratory tests, the team leader or customer might send an information request if something is unclear. Please respond as soon as possible but within 18 hours max.
By the way, your bugs in test case tests aren't duplicates.
What to do when you cannot proceed with the execution
If you found a bug in the previous step – you couldn't complete its demanded action – and you now struggle with the current step, you might have to terminate the execution at this point. Before doing that, make sure there is no workaround; you might be able to produce the necessary result for the previous step via a different path or function, and thus be able to continue with the execution. Try to finish the execution if possible.
If you could have continued the execution but terminated it early, the team leader will have to reject your test case execution. On the other hand, if you should have terminated the execution but instead continued and submitted a bug report for each following step, these superfluous reports will be rejected.
Keep in mind that the management and maintenance of test cases is pretty complex – sometimes steps aren’t perfectly described. Try your best to solve such problems or ask the team leader for clarification or help.
For every executed test case, you usually get a base payout and a payout for every completed step. Each bug you submit during one of your executions gives you a fixed bug payout extra.
The bug payout is lower than in exploratory tests due to the fact that you don't have to document a title, URL, and steps; it's simply less work for you.