You probably think this is just another post about how important it is to test everything before it goes to production. Nope.
Testers are too often expected to test things they don’t have a chance in hell at testing. Testing for the sake of process or perception, provides little to no value and degrades the whole trade of testing.
Sometimes when people ask,
“What are the testers going to do to test it?”, I respond,
“Nothing…we’ll just rubber-stamp it.”
Devs usually laugh because they know the bug risk is ridiculously low or the tester does not have the skills to test anything beyond what the dev already tested. However, other testers, managers, or BAs react with horror.
“Rubber-stamp it? Blasphemy! You’re the tester. EVERYTHING must be tested by you before going to production!”
The term “rubber-stamping” invokes negative reactions because it brings up the mental image of the desk clerk stamping document after document without paying any attention to what is on them…like the tester marking “Verified” on the bug or feature they didn’t really do anything to test. But that’s why I like the term! I’m trying to be honest about what value the tester added…none.
Here are some examples where the rubber-stamper-tester is justified:
- The tester has inadequate skills to perform the tests but has interviewed someone else on the team (usually the devloper) who did test.
- The test is not feasible to recreate in a non-prod environment (e.g., a complex multi-user scenario, custom PC environments, unknown repro steps)
- The patch can only be verified in debug mode, using complex timing and coordination requiring breakpoints and other unrealistic tricks. Even devs may skip testing if regression tests pass.
- If critical functionality is broken in prod, we may decide to release a fix without testing it. Speed becomes paramount in this scenario. We are smart...it is possible that we are smart enough to see a logic error, make the fix, take a deep breath and release to prod without the overhead of testing. After all, it can’t get any worse in prod, right?
Should at least glance at the changeset of the files merged into the branch, and hit View Differences of the changed source file to see what was modified between the previous version.
Even if you don't understand anything after awhile of doing it you'll be able to pickup on stuff that could possibly break.
I guess I'm sort of projecting onto you guys what I would do in that situation -- but then again I'm a dev so that may not be reasonable.