Programming languages – a learning journey from a test perspective

BASIC – 10 print “hello world”

My first introduction to programming was in the 1980’s, using BASIC which was a common feature on the hobbyist computers of the time. For most people, computers were common in science fiction but had no practical applications in the home or workplace other than playing games. This was the age of home video game systems such as the Atari 2600 and NES, and the dawn of home computing with several general purpose computers (with BASIC interpreters) were now available to the public, and myself and some of my school friends were lucky enough to have them.

Whilst the majority of home computer users would just play games, the hobbyist scene extended into programming them and while good games were typically written in machine code using assemblers (literally writing code to read and write bytes within the memory of the computer to move sprites around on screen), simplistic games and other applications could be written using the slightly more human readable (and understandable) BASIC language and these were printed in the computer magazines and books published at the time.

Through many hours of typing these BASIC programs into the machine and then modifying the them to change behaviour, I developed a good understanding of simple programming concepts (loops, variables, boolean algebra, subroutines, etc.)

Academia – Pascal, assembler, C

My next steps into the world of coding were in learning Pascal (a strongly typed procedural language intended to encourage good programming practices) using Turbo Pascal, as part of my studies for a BTEC diploma. We also used some 68000 assembly language whilst learning about microelectronics, although the applications for both were purely academic and I haven’t had cause to use either since.

In University, I was first introduced to C (along with the concept of networks) and one of our assignments was to implement a messaging system with a very simplistic stop and wait protocol. We used C in a number of assignments, although none of these were particularly sophisticated.

The workplace – shell scripting

Once in the world of IT (as a technical support analyst) I was thrown headfirst into the weird and wonderful world of UNIX systems, and encountered shell scripting which (as the name indicates) isn’t programming as such, but uses a lot of programming like constructs (variables, loops, subroutines, etc.) and is quite flexible and complex tasks can be automated using the shell command building blocks.

After moving to the testing team, I began to learn a little more about C/C++ as the products and services we tested required extra components which we had to hand compile on many different UNIX systems (for example Solaris, AIX, HP-UX, Tru64 and various flavours of Linux). We also began to build data creation tools to support testing using shell scripts and started to automate some of the manual tasks (I was doing DevOps before it was cool – in fact before it was a thing)

The home computers of the 90’s – Windows PC’s – did ship with QBasic (as part of MS-DOS), although this was a very dated by now and seldom used.

WWW and the dot-com boom

Around 1997 Java began to gain momentum and as we were using it our new products (both client and server side), I started to experiment with this groundbreaking new language although initially without any real goals in mind. I also dabbled with JavaScript, PERL and PHP although as I had no real application for these either, it was purely a learning exercise.

In the testing team, we began to experiment with Rational Visual Test (using a BASIC like language), although we were unable to successfully use it for any automated testing and continued to test all of our products manually, using shell script tooling to help automate manual tasks.

A few years later, once mobile phones began to ship with a J2ME runtime, I immersed myself into learning Java, along with a lot of concepts around network programming and eventually built a half decent RSS reader that ran on mobile phones as a personal project.

Active directory – WMI scripting with VBscript

As our software was now able to integrate with Microsoft Active Directory servers, some way to automate those was naturally required (If I have to do something more than twice, I write a script for it), and so I began to build a suite of small VBScript tools to set up servers in various configurations and create test accounts to support testing. This was a simple yet powerful way to administer Windows servers without all the tedious GUI steps.

Test automation tools – WinRunner, LoadRunner & QTP

The state of the art had thankfully moved on in the world of test automation, and once I’d got the funding to purchase a licence for WinRunner, I began to build out a regression suite for our product in the C like Test Script Language (TSL) that it used. It was only loosely based on C, and used no real advanced features of the man language but was quite capable and I was able to perform on-demand automated smoke tests of our product. This was maintained and improved over time, and then ultimately had to be rebuilt when the HP acquisition of Mercury resulted in WinRunner being replaced by Quick Test Pro (now since renamed and sold on). Luckily (or unluckily) – this used VBscript and I was able to re-implement the entire suite in the new tool fairly easily.

I also successfully implemented a load test capability of our products using LoadRunner, with a quite complex script performing a multi-way handshake and starting a Win32 helper application for each user instance on the load generators – this was also implemented using the C like TSL language.

Java and C++ hackery

The demands of functional testing necessitated the creation of more complex tooling than shell scripting could support, and so I ended up building (and extending) numerous tools to support test work, and thus growing my knowledge of Java mainly (and C to a lesser extent). One of the most memorable tools I built was an audio echo application in Java. We were implementing up and downstream audio support for remote desktop applications and the test app I created sent the microphone input stream to the speaker output stream – ran locally there was obviously no propagation delay and anything said was instantly played back, when remote you could test the audio stream reaching the remote application tier and then returning through the server to the client, with the audible delay as it was sent across the network.

Selenium (and Java)

Faced with a business decision that forced us to migrate from the HP toolset, I began to implement the testing framework in Java, using Selenium to drive the browser and an SSH library to interact with the hosting server (rather than drive terminals using OCR with WinRunner & QTP), and a handwritten bitmap comparison function that did a pixel-by pixel analysis of source and target images checking the RGBA values were within an allowable tolerance and the overall count of matching pixels met a specified target.

In a similar vein, I also implemented a full stack load testing tool using the Selenium HTML Unit Driver with a Grid to perform bulk login and launch testing and capture simple min, max and average transaction times as a stop-gap replacement for LoadRunner.

Since then I’ve also built and contributed to several other Java based toolsets, and it’s also become my go-to language for personal projects, including API and GUI test tools which are under infrequent development (although are very much functional and usable) – if you’re interested, take a look at Wisard and Jester.

Microcontrollers – C: you again?

A few years ago I started to experiment with Arduino microcontrollers, which was a refreshing change and a lot of fun driving LED’s and other components from C/C++ code, as well as extending a simple network example to build a rudimentary web server – largely useless but a very interesting project nonetheless that then fed into an as-yet unfinished hardware project to build an RGB LED lamp controlled over a WiFi network (although the code is finished, I haven’t built the circuits to drive the high power LED’s).

In Summary

This has been quite an enjoyable exercise to write and if you’ve read this far, hopefully informative. All of my recent public coding projects are hosted on GitHub here : https://github.com/ObjectiveTester, some more useful than others 😉

The key takeaways here are that you’re going to be exposed to a lot of languages throughout your career. There is no ‘right’ language to learn and whatever is in common usage now will change in the future.

You may find it quite enjoyable to experiement with personal projects and this will almost certainly help your professional development.

Tips for testers

Don’t just jump into learning test automation because you think you need to. Being able to do the equivalent of ‘hello world’ in an automation tool is the first of many steps. Instead, learn general programming concepts first, with the languages the development team are using in your organisation – you can ask for help from colleagues, and there’s a lot of value in building tools that support manual testing. Test tooling that can be widely maintained will have a longer lifespan than tools built using other languages, even if those languages are easier to learn initially.

Learn by doing

You’re not going to learn if it’s not enjoyable – if you’re still on chapter one of a book / the first hour of a video and are struggling to make sense of it all then it’s time to stop and change your approach. Personally, I can’t just ‘learn a language’ – I have to have a project in mind, and then build the project and learn as I go. There’s a lot of free resources online, and a lot of good quality paid for content – tutorials, videos and books. Ask around – your team members or online communities are a great place to start asking for recommendations and help.

Your comments?

If you’ve got a favourite language, or are learning one right now, please leave a comment 🙂