“I must stop this whole thing! Why for fifty-three years I’ve put up with it now.
I must stop Testville testing… but how?”
The Grinch’s idea was to cause mayhem by letting the QA team down, forcing the project to overrun and compromising on software quality. The Grinch’s thoughts included the following:
- If there are defects in the live system, it could bring businesses to a halt.
- When a live application fails, a customer may be unable to process business transactions.
- The failing application will need to be corrected and re-tested.
- If the failure has caused data corruption then the extent of this must be analyzed.
- In the event of repeated failures, customers will lose confidence.
- If the deadline is missed, it will ruin any competitive advantage the business has and could also destroy customer relationships relying on the winter upgrade.
The Grinch, who was a specialist scriptwriter, knew that mayhem would result from his sabotage. All he would need to do, was to destroy all the script work that he had spent years creating. All it would take is one late night after working hours to create errors within the scripts and in some areas to delete entire chunks of code! Test automation that is reliant on a
tester to code it, means that only that tester can respond to any issues within the code. So with a plan to ruin the code and the Grinch not around to fix it, any test automation was futile – a cunning plan thought the Grinch.
With that evil thought, the deed was done quickly for the Grinch had stolen his own test scripting!
An extract from “A Tester’s Winter Tale, How the Grinch stole scripting.”
A little festive fun with a serious thread that will resonate with all those involved in project delivery and software testing.
Or click here to see what others have done to stop their testers turning into Grinches
With apologies to Dr.Seuss author of “How the Grinch stole Christmas”