Are there benefits of reading code without being able to write code?

Standard

At the August London Tester Gathering, Alan Parkinson of Hindsight Software [1], gave a great talk on how “Pull Requests can be a tester’s best friend”. During this talk Alan mentioned the benefits of testers “reading code”. This statement seemed to spark some disagreement among those attending. In my experience, I agree with Alan, as a tester I find reading code a valuable source of information to support my testing, after all discovering information is one of our main objectives:

“…your ultimate goal in exploring is to discover information of interest and value to your stakeholders(the people on your team and any others who have vested interest in the information you discover.)”
Elisabeth Hendrickson – Explore It!

The activity of reading code can itself be fruitful to a tester as you may find bugs in the code and unexpected behavior without even executing the code. In my experience the clear benefit of reading code is that it provides information that can be used to drive a conversation about the product and can feed into exploratory testing charters.

The obvious question when talking about reading code is “Why would anyone choose to ‘just’ read code and not write it”

At this point it probably helps for me to define what I mean by “read”. When I refer to reading code I’m not simply talking about reading the words on the page, out of any sort of context these would just be letters, numbers and symbols. When I talk about reading code I’m talking about the following:

Looking for patterns in the code – To begin to understand patterns within code you are probably going to need to understand some of the basic elements of computer programs. Things such as If statements, loops, lists, operators, different types of inputs/outputs(Strings, Integers, Booleans). This basic knowledge can be picked up quite quickly and it doesn’t mean you need to be able to write them. A good example would be if your product provides applications based upon age. For example, any applicants over 30 are successful and under unsuccessful. The code implemented could be:

If (age => 30)
{
applicationSuccess = true;
}
else (age <30)
{
applicationSuccess = false;
}

Based upon reading this code within the context I’ve provided, let me guess, you have some questions, you can see some errors, it’s intentional. In this very simple case you have “read” code within a context, you have used this information and now have some questions to go and explore.

Readability of the code – A big success factor of reading coding is for it to actually be readable in the first place.

“…clean code should read like well-written prose. Think back on a really good book that you’ve read. Remember how the words disappeared to be replaced by images! It was like watching a movie, wasn’t it? Better! You saw the characters, you heard the sounds, you experienced the pathos and the humor. Reading clean code will never be quite like reading Lord of the Rings. Still, the liter-ary metaphor is not a bad one. Like a good novel, clean code should clearly expose the ten-sions in the problem to be solved.”
Robert C. Martin(Uncle Bob) – A handbook for Agile Software Craftsmanship

Ensuring the readability of the code means that when another member of the team comes to pick up the code, maybe later on for a refactor, the code should be easier to read and understand. Good commenting throughout the code can aid the team but it should be noted, there’s nothing better than a conversation, but as teams evolve the original writer of the software may not always be around.

Reading the files that have changed? – Another element of reading code is reviewing what files have actually changed. A good commit discipline that ensures linking to a work item, such as a User Story[2] and a concise summary of the changes can also help when it comes to reading any changes. Looking at the files in the context of the commit can immediately throw up questions if files have changed that you were not expecting. I’ve seen some examples of developers accidentally committing incorrect files. Use a commit monitor tool that runs in the system tray and alerts you when any files are updated[3]. You can decide if you want to go and explore any of these files, read these changes and if required, take further action (e.g go and speak to someone)

Comparing the code changes – Finally, another good approach to reading code is to do comparisons. Most Source Code Management tools allow you to compare changes to files[4]. Based upon the context of the change, the differences can often reveal interesting information. If you keep changes small you should be able to review the changes easily. This can throw up some questions and also provide low level information about what has changed in the application. This can help drive your exploratory test charters.

At this point i should say that locking yourself away in a room to read a whole bunch of code is probably not going to be very interesting. Reading the code together, with the author, is likely to more engaging and beneficial. Pairing up, as discussed in my previous blog post, is probably the way to go.

There are countless benefits to reading before you can write. Don’t forget though, there are even more benefits from testing before there is even code to read.

[1] Hindsight Softwarehttp://hindsightsoftware.com/
[2] JIRA Pluginhttps://confluence.atlassian.com/display/JIRA/Integrating+JIRA+with+Subversion
[3] Commit Monitor Toolhttp://stefanstools.sourceforge.net/CommitMonitor.html
[4] SVN Diff Toolhttp://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.diff.html

Advertisements