On Exploratory Testing and ‘Playing About’

A thought that occurred to me recently while following procedures for testing using the boundary value testing method is, “What would happen if I tried values for inputs of an incorrect type rather than whatever values the particular testing method called for?” While simple test procedures such as normal boundary value testing clearly leave much to be desired, more comprehensive testing methods such as robust equivalence class testing seem to cover most of the potential sources of input errors, right? I think not. It was often difficult to fight my intuition and desire to choose test values that did not necessarily line up with the testing procedures covered in boundary value or equivalence class testing procedures. This desire to choose what to test and how to test it based simply on experience and intuition is whats known in the software quality assurance field as exploratory testing, and it is an extremely powerful method of testing when used properly and appropriately.

In a Let’s Talk About Tests podcast titled “Players gonna play play play play play,” from September 21, 2017, Gem Hills talks about the benefits of getting familiar and gaining a better understanding of a program simply by “playing about,” with the program itself. Hills argues that sometimes simply using the program and applying knowledge from previous experiences with similar programs or with the development team itself can often provide a software tester with potentially revealing test cases that would be missed if the tester was relying solely on a testing framework. In her post, Hills references Richard Bradshaw, perhaps better known as the “Friendly Tester.” Specifically, Hills talks about attending one of Bradshaw’s talks at the BBC in August where he spoke about how “having a play” with a program can become far more impactful by simply recording the results and tests, effectively turning this play into exploratory testing.

One of the reasons that Hills cites for playing with a program with no real agenda is that, “[She] is not confident that [she’s] tested everything but [she’s] not sure what [she’s] missing.” I found this point especially telling. This is exactly how I felt when I was writing test cases for the boundary value testing assignment, as if I was sure that I was missing something, but unsure as to exactly what it was that I was missing. It would therefore seem to make sense to me that I should begin playing around in an attempt to discover what it is that I am missing. Perhaps it is simply that I am lacking the appropriate testing method, and performing some exploratory testing provides insight into an effective method. It is possible, however, that a bug exists in the program that cannot be found by applying any number of testing procedures. In these cases, exploratory testing, or “playing about,” is the only effective testing tool.

Why Repeatedly Repeating Code is Bad Programming Practice

After a discussion with a friend about the recent eclipse, the subject of the apocalyptic end of the world came up. I was reminded of Y2K, and decided that it may be worth some research, as I was too young at the time to really understand what was truly going on. As a student of computer science, perhaps it would provide me with some important examples of things not to do in my own coding. On a blog post written by Steve Rowe for Microsoft Developer, he shares what he learned from an instructor about the true cause of the Y2K scare, a lack of implementation of the DRY, or the Don’t Repeat Yourself principle. Y2K was caused not by mistakenly representing a four-digit year with too few digits, but by making this error over and over throughout and across multiple files. Unless absolutely necessary, code with identical or near-identical functionality should not be duplicated. Following the DRY principle makes maintaining and repairing code easier and simpler; it is important that those striving to become excellent programmers follow this principle.

While my mistakes are not going to cause the same devastation as the mistakes of the developers that caused the Y2K scare (yet), they have certainly caused me a great deal of frustration while programming for assignments or personal projects. On more than one occasion, I’ve found myself repeatedly trying to remedy a certain piece of code, only to find out later that the error was caused by similar code that was implemented elsewhere. It was this duplicated code that was actually responsible for the error, not the unused or irrelevant piece that I had been wasting time attempting to correct. My failure to follow (or even be aware of) the DRY principle, which I was unfamiliar with before looking over the syllabus for Software Construction, Design and Architecture has resulted in countless hours of wasted time and energy. Any programmer, no matter how good he or she may think they are, could always stand to improve. Not only will following the DRY principle allow your code to be more easily understood by others, it will make writing documentation and performing any maintenance much simpler. Steve Rowe makes an interesting comment before closing his post, stating that, if duplicating code is deemed necessary, “It might not be a bad idea to put a comment in the code to let future maintainers know that there’s similar code elsewhere that they should fix.” If we all attempt to better follow DRY and Rowe’s advice, maybe we can avoid future Y2K-esque scares.