Skip to main content
Test Case Testing

What are test cases and how do their tests work?

Markus avatar
Written by Markus
Updated over 9 months ago

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 need 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.


Test procedure

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 24 hours max.

In case the bug you've encountered while executing a test case step has not been submitted by any other tester before, we ask you to submit a new bug report and describe the behaviour observed by you in more detail. If you're creating a new test case bug, please make sure to follow our regular bug report requirements on the platform. As soon as you click 'Failed' in your test case execution form, you will be offered to either submit a new bug report or to choose the bug submitted by another tester:

If you cannot find your bug in the list, please choose 'Submit a new bug'. However, if you can find the bug you've encountered in the list of already submitted bug reports, please create a reproduction instead of a new bug report. You can find more information about test case bug reproductions in the respective Academy article - Test Case Bug Reproductions.

Linking a Known bug

If the Test Case test contains a Known Bugs list, and you experience the same bug as in the Known Bugs list in your Test Case execution, you will have the possibility to link that Known Bug. To link a Known bug, after you select in Step execution "Failed", you will need to open the menu and select the Known bug.

You can identify the Known bug by its icon (badge) as you can see in the screenshot above.
After you select the Known bug, Bug Details will be shown to you, and at the end you will see a "Link Known Bug" section where you will need to upload a screencast. When you upload it, you will need to press the "Link known bug" button in order to link it and proceed future.

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.


Payout

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.

Did this answer your question?