Learning to Read Code? Here’s my Short Primer!

I support the idea of testers learning to read code. It’s also a great opportunity to build rapport with developers. If you want to learn how to write programs, I support that also.
However, I think reading code will benefit you more when you know more about it. For example, when you read a mystery book, you look for certain type of characters (a detective), and certain types of activity (discovering a clue). Reading code is much the same. Here’s my primer.

Core Constructs
There are four basic code constructs supported by just about every language. These are important to understand because each has implications to your testing. The constructs are assignment, If statements, loops, and math. Programming is an act of combining these constructs to accomplish business goals.

Code Construct How to Identify It (in most languages)
Assignment Look for an equals sign (=) between words and numbers
dateOfBirth = 6/30/2001
If Statements Search for the word ‘if’
Loops Loops contain with the word ‘for’ or the word ‘while’
Math Most languages use common symbols to perform arithmetic. The exception is multiplication which is often represented by the asterisk (*).

In addition to the core constructs, code supports collecting and reporting of information (input/output), and storage of information.

Assignment sets the value of a variable. For example, when you enter a date into a program, the program probably assigns it to a variable (temporary storage – see below) so that it might act on it. This allows the program to verify the date is valid and other tests before it is used elsewhere.
Testing Implication: Information collected from a user by the program is always suspect. This includes data collected from a web page, an application form, a file, or a web service. A healthy dose of Domain testing is in order.

The If statement provides a program the ability to evaluate data, and to direct workflow. For example, you want to open a credit card account and the company has a business rule requiring applicants be at least 25 years old. If you provide your birthday as today, the program evaluates that date and rejects it.
Testing Implication: Business rules may have multiple outcomes. In the example above, there are at least three. Your testing may need to functionally evaluate the program for each outcome: (1)the applicant is 25 years old, and the applicant is (2)more than or (3)less than 25 years old. Additionally, the program’s workflow may be different for each outcome.

Loops allow the program perform the same code sequence many times. For example, when your music program displays a list of songs, the same code sequence executes to display each line but the data it uses, the song name, changes each time through the code sequence.
Testing Implication: The number of times a code sequence executes may depend on the data, it may execute a fixed number of times, it may change program behavior if there is an error, and in some cases it may never stop. Review programs for loops and evaluate what controls the execution of loop.

Programs perform basic math to trigonometry. For example, a spreadsheet performs many arithmetic functions.
Testing Implication: The arithmetic equations themselves should be evaluated in isolation. Once you have confidence it the equations, the inputs to those equations may require Domain analysis and testing.

We are probably most familiar with the input and output of programs. We enter data into a screen, and we see data displayed on a screen or printed report. Programs accept data from other programs, web services, files, or cameras. Conversely, programs deliver information as files or strings of characters.
Testing Implication: There are many forms of input and output and they vary based on source (input) and destination (output).
How to Recognize It: Theses are largely code sequences specific to the requirement of the program. This is a great opportunity to review the functionality with your developers, collaborate on the testability of inputs and outputs, and learn.

Programs store data in two forms: temporarily and permanently. Temporary storage (known as variables) allows the program to work with data to meet the business needs. Permanent storage provides for persistence of information over a long period of time (disk drives and databases are examples of permanent storage).
Testing Implication: Temporary storage may be an issue in embedded applications where memory is scarce. Permanent storage can improve program testability when used to create logs or journals of transactions.
How to Recognize It: Temporary storage is declared explicitly in many languages. The syntax includes a data type identifier and a variable name. Permanent storage usually requires code libraries to read and write information to a file or database – another opportunity to talk to your developer.

Now, go find some code and practice!  Leave some feedback on the examples you found!


One thought on “Learning to Read Code? Here’s my Short Primer!

  1. Pingback: Testing Bits – 6/29/14 – 7/5/14 | Testing Curator Blog

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