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

4 thoughts on “Are there benefits of reading code without being able to write code?

  1. stevesmith2609

    Excellent post! As a long-term tester, I’m often frustrated that I struggle to write code, but can infer what I need from code written by someone else; it’s nice to have this (seemingly questionable at times) skill validated.

    Like

  2. Abe

    Agree about reading code could help a lot to focus the exploratory testing.. since as a tester that is not able to see the code.. he just will test what the requirements mentioned .. but many times the code affect another parts of the Application Under Test… another example it’s in retesting, a defect was fixed and the tester needs to re-test, checking the code helps you to see in the fix it’s just touching more parts.

    Great Post !
    Regards
    Abe

    Like

  3. I’m with Steve – I’m so bad at writing code, but being able to interpret the code has really helped me test.

    And guess what, I still maintain my testing integrity! I haven’t been brainwashed into the confirmatory army! (Maybe I’m Divergent…)

    I agree with reading the code when pairing – that has been the most natural time for me. If time permits, I’ll work my way through the code myself when investigating a bug.

    Have you got any more examples where your work has benefited from reading the code?

    Is there any more info around “pull requests are a Testers best friend”? I like to know what changes I’m pulling into test & pull requests help me with that. Is that how Alan uses them?

    Another great post Toby, thanks for sharing.

    Duncs

    Like

  4. Nice post Toby! I agree with what you are saying about learning to read code. I think thats an important skill that testers need. But do you think it would make sense to also learn how to write code to enhance your testing too? (if you know how to read it, then learning how to write it doesn’t seem like it would be too much of a jump).

    To give some context on how writing code might be helpful – if you can write code, then you can use that skill as part of your testing with building tools to aid your testing, or with being able to write throwaway scripts for generating data or for performing actions on the software to get you through the end to end flow to that new feature that you need to explore.

    Also it means that you’d be flexible for getting involved with code reviews (as you’d know if the code could be written better rather than only being aware of whether there are problems). And getting involved in code reviews also gives us that head start with our testing… Food for thought.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s