Purchases in tests
If a test instructs you not to complete any purchases/orders, this means, also no such attempt should be made. This also includes cases in which the final order form is sent with missing mandatory fields or in which an external payment provider is triggered afterwards (even if this provider allows cancelling the transaction).
If you find a bug where an app or website keeps loading “endlessly” without any error message or crash, we require extended documentation to prove the validity of the problem:
Show your internet speed at the beginning and end of your screencast, e.g. via https://fast.com/
Show that you didn't use a proxy or VPN at the end of your screencast.
Please note that the fact that an issue has been accepted in the past (either by the Team Leader or by the client) does not guarantee that the same issue will be accepted in all future tests. Of course, our aim is to evaluate all errors in a comparable way, but it cannot be completely ruled out that something has been overlooked in the past or that new information has been added in the meantime.
Some examples of situations where your bug will be rejected even if a similar bug was accepted in the past:
The Team Leader accepted a bug but he wasn't sure if it was a valid bug or not and the customer left a commentary explaining it was indeed intentional behaviour.
The customer accepted a bug and did not add the report to the Known Bugs list, but left a commentary explaining the requirements have changed.
The instructions of the cycle have changed (always read the instructions carefully).
You were bonused once in a dispute but the dispute manager asked you to not submit that particular bug anymore.
Anyone from the team (the Team Leader, the CSM or the customer) asked you to not submit more issues in the chat.
The overall Test IO rules have changed and the information of the new rules can be found in the Academy.