Applied to automated record/playback regression testing, the Plague of Entropy describes the gradual deterioration of a test suite from a state of order to a state of disorder.
Energy that was once available to be used for actually testing the application becomes unavailable as it is used more and more to record scripts, to try to decipher whether or not a script's failure has any meaning or value, and to debug the full-blown software development project that is now your test suite.
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.
The 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.
Here 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
next 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"? If 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. As 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.
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.
The 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????
I think I know this one!
ReplyDeleteApplied to automated record/playback regression testing, the Plague of Entropy describes the gradual deterioration of a test suite from a state of order to a state of disorder.
Energy that was once available to be used for actually testing the application becomes unavailable as it is used more and more to record scripts, to try to decipher whether or not a script's failure has any meaning or value, and to debug the full-blown software development project that is now your test suite.
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????