Get started Bring yourself up to speed with our introductory content.

The more technical tester series, part four: Learn how to code

Software testers are under increasing pressure to become more technical. Expert Matthew Heusser is back with another 'more technical tester' article on learning to code.

This is the fourth in a series of stories about becoming a more technical tester. Previous articles covered servers...

and the network; capturing and testing the text that comes across the network; and HTML, CSS and JavaScript -- the programming languages of browsers.

Testers that can create servers on demand, test below the GUI layer and debug the GUI layer will be incredibly powerful. All of these are technical skills, yet they tend to get lost amid the clamor for automation.

For this fourth installment of the series for becoming a technical tester, it's time to talk about code.
Most articles focusing on "learn how to code" are skin deep, or worse, show one very specific tool -- how to create a browser and drive it to a popular website. This tutorial will go a bit deeper, showing you how to build a few common automation tools for testers, along with where to go for more.

The concepts in this tutorial to learn how to code apply in most programming languages, and programming in the same language as the programmers on your team will make it easier to get support.

So follow along with the exercises, type them in and then redo them in the language of your production programmers, especially if it is C# or Java.

Exercise 1: Get Ruby installed

Ruby is free, open source, popular, has a great deal of support and is truly object-oriented. Being object-oriented means logical bits of functionality can easily be captured in reusable bits that are easy to change.

Most Linux and Mac systems come with a version of Ruby installed. To find out if your system has Ruby, type ruby -v in the command line to see the version. You should see something like this:

ruby 2.2.1p85 (2015-02-26 revision 49769) [x86_64-darwin16]

As a programming language, Ruby is stable enough and backward-compatible enough that your version doesn't matter that much.

If you see Ruby installed, skip to the next exercise.

If not, go to ruby-lang.org and download a new, but stable, build of Ruby for your operating system. Then, run ruby -v to verify that it has installed.

Exercise 2: Hello World

Create a text file called math.rb that contains the following code:

print "Type a number to multiply ";
varOne = gets
print "Type another number to multiply ";
varTwo = gets
puts ""
print "First number times the second equals ";
puts ( varOne.to_i() * varTwo.to_i()).to_s();

Now, type in Ruby hello.rb in the command line. Notice that print does not add a new line separator, and puts does.

Also, look at the print statement -- the text takes in the two variables, converts them to an integer with to_i(), multiplies them and converts them back into a string for a print. This means multiplying 7.5 times 4 gets you 28, when it should be 30.

The application also has no bounds checking; it will convert the plain text of one to zero. And the software adds no commas for a thousands-separator -- a typical problem that testers are good at finding.

Exercise 3: Parse a text file

First, download the file access_log.txt; it is a dump of an Apache log file. Go ahead and read the file. Notice the lines that say GET /twiki/bin/etc -- etc is the name of a command. We want to get live data and look at the frequency with which these commands are called, so we can focus our testing on those pages or make performance testing focus on the right percentage of pages.

The core logic for this is simple: You must create a data structure called a hash. The hash works a bit like a post office number -- storing an index, which is text, and results. We loop through the file, going to the location indicated in the name of the command (attach, view, statistics, edit and so on) and increment the count at that number. When we are done, we sort the hash and print out the results.

Here's the code:

commands = Hash.new;
#Open and read the file
IO.foreach("access_log.txt") { |line|
   if match = line.match(/\/twiki\/bin\/([\w]+)\//)
     capturedval = match.captures[0];
     if (commands.key?(capturedval))
         commands[capturedval]=commands[capturedval]+1
     else
         commands[capturedval]=1
     end
   end
}
commands.each do |key, count|
      print "#{key} contains "
      puts count.to_s() + " elements"
end

The program begins with IO.foreach(), which opens up the file and loops through each line, inserting it into the line variable. The match command isolates the specific command that is called, either creating an entry for it in the commands hash or adding it to the existing entry. Finally, the program loops through commands and shows how often each appears. The view command appears 378 times, while statistics occurs just once. Imagine how this sort of information could focus a test effort.

Before we move on, there is one more thing about the code that applies to technical testers.

Notice the first line with .match has a lot of slashes and characters. It is a complex regular expression, matching /twiki/bin and the next word that follows. Regular expressions allow the programmer to grab lines of text that are interesting and manipulate them. Play around with regular expressions or experiment with different lines and matches in real time.

Exercise 4: CURL and driving a browser

In the second article in this technical tester series, we covered CURL, a method for pulling down webpages from the command line. Here's a different idea: Create a .CSV file with three fields -- the name of the test, the URL and a filename showing what the text should contain.

Call a CURL command to get the text and paste it into a text file. Then, loop through the first file, calling the URL and performing the comparison. (You could just call a system CURL, call CURL from the command line or convert to Ruby syntax.)

If the output does not match the text, send the output to STDERR using STDERR.puts. Also, increment the number_of_errors and number_of_checks. Finally, output the number of errors, the total number of checks and, if you have it, the total length of the test.

For a sample webpage, consider your company's homepage, google.com or, perhaps, one of the open APIs mentioned in article two.

As a final exercise, use the Selenium web driver to drive a browser to www.amazon.com, then search for a book, click on it, add it to your cart, click on the cart and see if the dollar total matches the cost of that book. Use Ruby's selenium-webdriver gem; here's a quick start guide.

Exercise 5: GitHub

GitHub is a public repository of code and projects. Programmers use GitHub to create a portfolio that demonstrates the code they have created.

Testers are less likely to use GitHub, as they don't usually code -- but if you complete exercises 1-4, you will have some code to show. Get started with GitHub and place the code from exercises 2-4 in it.

Congratulations, you have a small, but nontrivial, body of open source code to share. You have a public portfolio of work!

Beyond

These exercises are just the tip of the iceberg for programming, comprising perhaps a third of a semester of an introduction to computer programming course. A typical computer science degree will consist of four programming courses, plus half a dozen more courses in hardware, chip design, graphic design, operating systems and electives.

An easy next step toward becoming a more technical tester is to learn how to code, using the Selenium documentation as a guide. Sadly, that is also a good way to create a big ball of mud that is hard to maintain and debug.

As an alternative, consider the harder, but better, step of working through a programming curricula.

Two resources I would suggest are the free, web-based books Learn Ruby the Hard Way by Zed A. Shaw and Sandi Metz's Practical Object-Oriented Design in Ruby. Metz's book includes a test framework tutorial that may cover the cost of the book by itself.

Next Steps

Here's how to learn Ruby if you already know Java

Why Selenium is so important for software testers

It's time to lean in to your software career

This was last published in February 2017

PRO+

Content

Find more PRO+ content and other member only offers, here.

Essential Guide

Get ahead of the game: How to be a more technical tester

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

What have you done in your spare time to become a more technical tester?
Cancel

-ADS BY GOOGLE

SearchMicroservices

TheServerSide.com

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

Close