The lazy methodology, part II

As it turns out, there is a second part to the Lazy Methodology. As well as finding bugs as a result of programmer laziness, you can also find bugs as a result of tester laziness.
 
It’s pretty simple, way simpler than Part I. You just have to look through the list of current or older issues and think about whether they could apply to any other parts of the application. On the project I am working on now, this is a particularly good move because no one single person knows the entire application well so there is a high chance that if someone has raised a bug in one area, it may also exist in a related area.
 
So for example, if someone finds a spot where page numbers are not displaying correctly for search results, you have a good chance of finding the same bug on another page that displays multiple pages of search results. The tester that raised the bug may have not bothered to check the other areas, or didn’t know about them, or was just waiting to see if the developer fixed that bug in that single area before unleashing a shower of similar bugs upon them in a rather evil “you missed a spot” kind of way (in which case you can get to the bugs first and you’ll not only have found a bunch of bugs but you’ll have thwarted evil, which is always pretty satisfying).