The 7th Plague and Beyond
Wednesday, September 02, 2009
By James Whittaker
Sorry I haven't followed up on this, let the excuse parade begin: A) My new book just came out and I have spent a lot of time corresponding with readers. B) I have taken on leadership of some new projects including the testing of Chrome and Chrome OS (yes you will hear more about these projects right here in the future). C) I've gotten just short of 100 emails suggesting the 7th plague and that takes time to sort through.
This is clearly one plague-ridden industry (and, no, I am not talking about my book!)
I've thrown out many of them that deal with a specific organization or person who just doesn't take testing seriously enough. Things like the Plague of Apathy (suggested exactly 17 times!) just doesn't fit. This isn't an industry plague, it's a personal/group plague. If you don't care about quality, please do us all a favor and get out of the software business. Go screw someone else's industry up, we have enough organic problems we have to deal with. I also didn't put down the Plague of the Deluded Developer (suggested by various names 22 times) because it dealt with developers that as a Googler I no longer have to deal with ... those who think they never write bugs. Our developers know better and if I find out exactly where they purchased that clue I will forward the link.
Here's some of the best. As many of them have multiple suggesters I have credited the persons who were either first or gave the most thoughtful analysis. Feel free, if you are one of these people, to give further details or clarifications in the comments of this post as I am sure these summaries do not do them justice.
The Plague of Metrics (Nicole Klein, Curtis Pettit plus 18 others): Metrics change behavior and once a tester knows how the measurement works, they test to make themselves look good or say what they want it to say ignoring other more important factors. The metric becomes the goal instead of measuring progress. The distaste for metrics in many of these emails was palpable!
The Plague of Semantics (Chris LeMesurier plus 3 others): We misuse and overuse terms and people like to assign their own meaning to certain terms. It means that designs and specs are often misunderstood or misinterpreted. This was also called the plague of assumptions by other contributors.
The Plague of Infinity (Jarod Salamond, Radislav Vasilev and 14 others): The testing problem is so huge it's overwhelming. We spend so much time trying to justify our coverage and explain what we are and are not testing that it takes away from our focus on testing. Every time we take a look at the testing problem we see new risks and new things that need our attention. It randomizes us and stalls our progress. This was also called the plague of endlessness and exhaustion.
The Plague of Miscommunication (Scott White and 2 others): The language of creation (development) and the language of destruction (testing) are different. Testers write a bug report and the devs don't understand it and cycles have to be spent explaining and reexplaining. A related plague is the lack of communication that causes testers to redo work and tread over the same paths as unit tests, integration tests and even the tests that other testers on the team are performing. This was also called the plague of language (meaning lack of a common one).
The Plague of Rigidness (Roussi Roussev, Steven Woody, Michele Smith and 5 others): Sticking to the plan/process/procedure no matter what. Test strategy cannot be bottled in such a manner yet process heavy teams often ignore creativity for the sake of process. We stick with the same stale testing ideas product after product, release after release. This was also called the plague of complacency. Roussi suggested a novel twist calling this the success plague where complacency is brought about through success of the product. How can we be wrong when our software was so successful in the market?
And I have my own 7th Plague that I'll save for the next post. Unless anyone would like to write it for me? It's called the Plague of Entropy. A free book to the person who nails it.
Plague of Entropy: As a tester, I consider all projects in the beginng the start of a game of of telephone. You stand in a line and wisper something in the ear of the person next to you. This is then repeated down the line. By the time it reaches the end, generally the message is completely different from what the first person said. Much like a development project. Project owner explains requirements. Developer interprets and gets to work. Project owner reviews, lists what they want different. Developer makes more changes. Final product gets to testing with original requirements. Tester wonders what the developers were thinking and fail the project. In our efforts to get our projects completed on time, as a team forget to update what we do and what changes we are making to the original requirements. So instead, the tester wastes time testing a project based on an incorrect requirements document. So instead of spending the time during the project, we wait until the end when it seems like we have bugs in our project to have the "Lets update the requirements" meeting.
ReplyDeleteThe Plague of Entropy: rare event cases which cannot be easily replicated. You make the same 5 clicks to get to the same point 22 times in a row and on the 23rd, everything goes haywire. The same process runs successfully 28 more times in a row immediately after that.
ReplyDeleteif you fail to continuously work to prevent the last eleven plagues of testing, entropy will gradually increase the chance of a system demise.
ReplyDeleteHere goes: the plague of entropy is the decay to disorder, the loss of discipline as the project goes on. Passing test cases because neighboring cases passed - etc
ReplyDeletenext plague, the plague of groove.
our minds tend to repeat patterns that are lead to success, so over time - as we find the most efficient way to use something, we fail to notice the groove we are in. We fail to stop at a point in the descision tree and take the road less traveled.
That is why a tester learning a new product tends to find more bugs than someone who knows it well
Would the Plague of Entropy be accredited to Andrew Hunt and David Thomas. "Don't live with broken windows"?
ReplyDeleteIf you have a work (or living) situation in which things are normally broken (ie bad design, failing tests etc) then it also becomes normal to leave your own code/tests in the same state. Yet by cleaning up your code you encourage others around you to do the same and instil a sense of pride in your work.
The plague of entropy.
ReplyDeleteAs far as I know, I don’t live in a world in which glass unbreaks, coffee heats up spontaneously, or software gets simpler by changing it. Software is complex, and each new feature, bug fix, and code change risks breaking it.
Entropy in software testing represents the chaos that is a software system. The second law of thermodynamics states that systems will increase in entropy until they reach equilibrium. To ship a good quality product, we need to reach equilibrium, and stop the natural increases in entropy. Software testers help the team reach equilibrium.
When software projects go wrong, the schedule slips, features creep in, and small changes keep breaking core scenarios and derailing testing.
The end-of-release bug triage process is an attempt to bring the software into equilibrium, by reducing and more heavily inspecting each change.
Agile development is an attempt to keep the system in a steady state of equilibrium, by making small changes and keeping the software ready to ship.
Having good automation makes it easier to make changes, since the automation system will help provide rapid feedback.
Software testers need to embrace the entropy of their systems, communicate the current state of the system, and help with the risk assessment prior to release.
Alan Myrvold
Here's my shoot. the plague of endlessness.
ReplyDeletehttp://docs.google.com/View?id=dcr6gcwr_36c8hzsvdt
Plague of Entropy - Not having clear requirements and everyone is okay with it. The system requirements are squishy and test needs to extract the information for testing using what they currently know about the system. To find out later (usually 2-3 weeks before release) that they haven't tested the 'right' stuff. Hence delaying the release and losing credibility with Management.
ReplyDeleteThe kicker is the next time Management agrees that test shouldn't be testing without clearly defined requirements, but next time comes and goes and the same thing happens. Isn't this the defination of Insanity????