There are many interesting project experiences involving testing. It is sometimes strange to see encounters that are déjà vu. This particular project is always repeating the same set of testing incidents with the same type of toxic testers. Like the previous project, nothing are willingly shared during the requirements workshop. The real project started in the testing phase where the user is known to test repeatedly the unknown datasets. For reference, we are running Waterfall Agile approach.
Testing is not Sharing
The test cases and scope should have been known but these people are well known information gatekeeper. In addition, you may encounter inexperienced noobs who cannot gather the right requirements or collaborate closely to break through the gatekeeper. It is always easy to feedback why have all these issues not be tested beforehand. Indeed, this would have been a useful comment if the information gatekeeper is willing to share the test scenarios.
Signs of Battling Testing
You will find these common tell tale signs of toxic tester when the user start to test on exception scenarios that are only known to the information gatekeeper. Do not be surprised or discouraged by the massive issues flagged. A typical development team will be battled by these type of toxic testers. The typical testing feedback will always be brief discouraging and laced with acidic comments. The key to handle toxic tester is to hold your ground and focus on fixing the critical issues.
Toxic testers will always be around in many projects. You are expected to see this type of testers when you have very brief workshop and limited information. You will also need to gear up with an Agile team to agile the high influx of reported issues.
Danny Kwok 