preload

Change Blindness

Posted by Albert Gareev on Nov 04, 2010 | Categories: LinksNotes

With this post I continue my examples on Bounded Awareness in software testing.

But, again, first I ask you to read the following article: “Multi-tasking makes you stupid”.

If you didn’t, here’s the summary.

A growing body of scientific research shows one of the jugglers’ favorite time-saving techniques, multitasking, can actually make you less efficient and, well, stupider. Trying to do two or three things at once or in quick succession can take longer overall than doing them one at a time, and might leave you with reduced brainpower to perform each task.

Change Blindness in Software Testing

Change blindness, as described, is a “failure to notice changes in the information that is visually available”, but same articles states, that it is not limited to the visual perception only: “people are indeed less likely to perceive change if it occurs slowly over time rather then abruptly”.  With that, authors draw parallels to a wide-known “boiling frogs” metaphor.

With regards to software testing, I have observed a few situations, where Change Blindness phenomenon emerged.

Requirements Gone Wild

Maybe you’re familiar with this one: everything has been planned and the workload has been distributed. Then, during the project, some of the features are modified, some excluded, others thrown in; plus your team had to urgently investigate and test a production hotfix. But, to ignore these, the testing is expected to be moving as scheduled, same test plans are required to be executed, even if a half of test cases makes no sense anymore…

Known Bug, Known Bug, Known Bug,…

Sure, tester’s role is to find, investigate and report problems. The decision whether to fix or not is made by project authorities, and, as Michael Bolton says, testers should get out of the quality assurance business. Though I’ve seen how decisions on quality (well, assuming that fixing bugs helps improving it) have a significant impact on testers. In particular, if many issues are deferred as “a variation of the known bug”, and each part of application’s functionality is ill like that, it’s not only impact on motivation side. New bugs have increased chances to slip in being surrounded by other, known bugs.


Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported
This work by Albert Gareev is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported.