By Markus Gartner
Do you know the joke about how to become an expert in C++ in 21 days? You learn the basics in days 1-21, and continue to the advanced topics in days 22-3648. Then you learn enough about physics and biology to build a time machine, and an age-reversion potion. Then you travel back to day 21, and replace your older self with your younger self. Some testers find it’s similar if they want to learn programming.
A while ago I read a traditional book on testing. One thing stood out for me. The authors mentioned that testers can benefit from having some knowledge about programming. I certainly agree to that statement. Having run a couple of BBST classes, though, I often find that testers from a non-technical background may find that advice difficult.
Psychologically if you are a tester, and you don’t want to learn something about programming, no article, training class, or coaching will help you. That said, don’t feel forced to learn programming. You don’t have to. Just be aware that there might be some bugs that you won’t find without some knowledge about programming. If your testing team can compensate for that, that might not be a problem.
Also be aware that you need to be open regardless of your past. You won’t learn much when your thoughts constantly have to deal with how difficult this is, and that you failed in the past to learn something about this. If you can let go of those feelings about the content, the learning will stick more.
Some people are even oblivious that they are programming. Have you ever played with Excel in order to derive some information for you? Maybe you put in some formula in the cells in your spreadsheet. That was programming. I remember that I once wanted to write a tiny application in VB script for Word that could help me write training plans for my swimming classes more easily. That was fun in the beginning – and a drag in the end because I was oblivious that I was programming. Eventually I abandoned that pet project.
Finally, you should be clear on why you want to learn programming. It might be in order to find more bugs that you currently miss now. Or you might want to learn programming so that you can automate some of your tedious tasks. Or you might want to learn more about programming because you want to be able to talk to your programmers on the same level. Be aware that these reasons may lead to different approaches.
Before we dive in, one final piece of caution. I studied computer science, and as a side-effect learned some programming back in university. That said, I might or might not be the right person to tell you things about programming.
Your first language
When learning something new, I found timely feedback crucial. As a swimming trainer I was told that kids keep the experience of their movements in mind for 30-45 seconds. That means that I as a trainer need to correct a wrong movement within that timeframe. It’s the same when learning programming languages.
That said, for your first programming language, you should pick one that provides you quick feedback. Nowadays scripting languages are wide-spread. These most often come with an interpreter. In an interpreter you can type in programming fragments, and execute these statements directly, and get instant feedback. That enables quick learning for you, especially if you are completely new to programming.
During my university time I spent much time on the IRC. Back then, I used an IRC client for chatting called mIRC. It came with a scripting language, mIRC script. While hanging out on countless channels chatting, I also started to improve my IRC client, so that some things were easier to solve. Thereby I learned a lot about programming, how to build maintainable functions, and other concepts. For example I created simple commands for quick access while chatting. In order to post the song I was currently listening to, I just had to type ‘/mp3’, I had created a dialog to play sounds to the current channel, and so on. Oftentimes I had lots of intrinsic motivation for these pet projects. That is important to keep in mind when taking your first steps in a programming language. If you can find tiny projects on your own, you will find more progress learning the language.
Among the set of scripting languages available, I recommend languages like Python, or Ruby. These come with a large set of standard libraries that make your life easy. Although in the beginning it might feel overwhelming, over time you will become familiar with those libraries, and can solve increasingly complex problems. I remember having read an article about how to create your own answering equipment at home. That project involved Python programming. I extended the existing source to write call logs to a database, and created a tiny php application to read contents from the database, so that I could check call logs at home when I was somewhere else. At some point I included abilities to listen to the call messages through the browser. That was fun.
In general there are two strategies that you can use in order to get familiar with a particular programming language. You can either dive in the language references or tutorials, and work through them. I usually found that I learn more when I start with an existing code base, and try to extend it. At that point my learning will be more targeted towards solving a particular problem. I will still need to dive into the language reference, but will have fun solving an easy problem.
With the interpreter in the back, I have a playground to try out statements, and test them before putting them in the production code. That eases my learning curve, and I can progress more quickly. If you can find a pet project like answering equipment, you will learn more quickly. Oh, one piece of advice while taking your first steps in a programming language: don’t stop learning when you get frustrated because you can’t solve a particular problem. That usually meant for me that I was on the edge to find out how it works. Sometimes I was working until 3am in the morning, becoming more and more frustrated. After a night of sleep, I had found the clue that I needed in order to solve that problem. It’s still the same today.
One final concern: how deep should you dive into the programming language? Learning a programming language can quickly become an endless journey. Don’t dive too deeply into it. For a first grasp of programming it will be enough to understand basic concepts like functions, variables, constants, and the basic data types. On the data types, you should familiarize yourself with strings, arrays, and maps, as well as various forms of numbers, and how to translate either into another. These concepts are included in almost any programming language, and you can be productive with these on simple projects quickly. Also learn the basic functions for those data types. For arrays, you can put stuff into it, get its length, and extend it. With these functions you should have a solid go. You should be able to automate some of your repetitive tasks easily with this knowledge, and become even more productive at work.
Low-level computer organization
If you are working on a highly technical product, then you probably expand some of your knowledge by learning more about the foundations of computers. These days many programmers are not familiar with the underlying foundations in computers. For example, most have never dealt with limitations of floating point arithmetic, assembler languages, and pointer arithmetic. While these topics scare some non-technical testers, they can be hugely valuable in order to build an understanding computer programs – and can split the respected testers from the not so respected ones.
Elisabeth Hendrickson told me a story about a tester she once met. The tester tested a web application. She used the mouse, and moved the scroll-bar up and down. Hendrickson asked her, what she was doing there. She said, she was testing the application’s scroll-bar – oblivious about the fact that any bug she could find with that would be a bug in the browser, not the web application. Can you imagine how a programmer would react upon a tester reporting a bug in an application that clearly was more part of the browser in use rather than the code that programmer wrote?
If you would like to avoid exposing your ignorance to your programmers, you should dive deeper into topics related to lower-level concepts. Do you remember the Y2k-bug? A few years back the whole IT industry poured enormous efforts into changing the underlying date representation from two digit years to four digit years. The fear was that computer system could not distinguish between 1900 and 2000 once the near century had started. Skip forward a few years, and it seems that these problems have been long forgotten. At times, I joke about the problems that the Y10k bug will bring in the future. Can you imagine how many people will be familiar with the underlying computer organization then?
If you dive deeper into the internal data structures in a computer, and lower-level programming, you will find many opportunities to find bugs. For example, the computer uses a fixed amount of binary digits to store numbers internally. This causes some problems when translating from binary numbers to more human readable decimal numbers. One example for that is the internal date representation found in many Unix systems. Dates are represented as seconds since the 1st of January 1970. Unix systems store this value in a signed 32-bit integer. Signed 32-bit integer values range from −2,147,483,648 to 2,147,483,647. This allows the Unix time to also represent dates before 1970. Unfortunately since limited precision numbers in computer can overflow, this also means that there will be a date and time, when the Unix date will overflow from the largest possible number to the lowest possible number. In the current implementations of the Unix date system with 32-bit signed integers, this will happen somewhere around 2038. That’s quite a bit earlier than the Y10k bug. If you realize that many of the Internet servers are running Unix systems, the Year 2038 problem might even become relevant for the system you are currently working on.
Consider the Network Time Protocol (NTP). That is used in order to set the right date and time. A timestamp is fetched from a server on the internet, and a local NTP program adjusts the time of your computer on regular basis. This system is widespread among Apple, Windows, and Linux systems. These systems experience similar problems as the Unix Year 2038 problem, resulting in an overflow to occur in the Year 2036. Are you sure your system will not be affected by that?
The basis for all these problems lies in the internal representations of numbers in computer systems, and the problems that occur when converting binary numbers into decimal ones. A few years back I worked with a large telecom application. There were two larger subsystems that exchanged data between each other. With some knowledge about binary to decimal number conversion, and floating point representation, I was able to find a bug that could occur on a particular date, resulting in miscalculation of fractional digits. That bug could have led to customers paying too much of their money to a telecom provider in the range of a couple bucks. Summed over 10 million subscribers, there could have been a serious problem.
Low-level data types are not enough, though. When it comes to programming, you should know assembly language as the building block for today’s programming languages, and where more structural programming language like object-oriented programming differentiate. Why does this matter? Consider some of the test design practices that you might use on a daily basis. Did you know that most of them were discovered when bugs were introduced in more procedural programming languages, or assembly languages? So, how do you know they still are relevant when dealing with object-oriented programming like it’s widespread nowadays?
When dealing with compiled languages, the compiler translates higher-level programming constructs into lower-level programming constructs. Classes become blocks of code in low-level assembly language. Nowadays these compilers rarely create surprises in the underlying machine code. So, how are problems created in our programs? When you know the limitations of low-level assembly language, and how more modern programs might be translated into the machine language, you also become more familiar with the limitations of your test design techniques. You do not have to thoroughly understand these concepts, nor have to be able to program in assembly language. But to become more effective as a tester, you should know about the underlying principles.
Unfortunately covering such a topic as assembly language and binary numbers is too much for this article. Back then I read some very good books that covered the basics of computers. These started with “Write Great Code Volume 1 – Understanding the Machine” and “Write Great Code Volume 2 – Thinking Low-Level, Writing High-Level” from Randall Hyde [Hyde2004, Hyde2005]. Some of the underlying basics about how your computer is organized is covered in “Computer Organization and Design – The Hardware/Software Interface” by Patterson and Hennesy [PH2013]. These books helped me connect back with the underlying organization of the computer. Of course, nowadays there are also resources like wikipedia, and online reading material that might help you get a deeper understanding on low-level computer organization. Also early textbooks serve a huge foundation on the fundamentals of programming.
If you have dealt with some programming languages, and became more and more familiar with the underlying concepts, you might have started with some automation of your tests. Since test automation is software development, you probably need to dive deeper.
I remember a test automation experience where we as a group of testers felt a large bit of pain. The automated tests were unreliable, slow, and needed lots of analysis after they ran. Eventually we figured out that it was the design of the test automation was causing us most of the pain. Back then, I started to dive into programming constructs like design patterns, refactoring, and unit tests. These helped me largely to re-write the whole test suite to a degree that was still in use three years later. The understanding of software design helped me to construct simple components that could be reused in several occasions, and see where code duplication previously had caused us a lot of pain.
In order to apply design patterns in your automation code, you should make yourself familiar with the concepts of object-oriented classes, interfaces, and functions. Design patterns will teach you how to tailor your classes so that you can reuse commonly used code more easily. For example, I remember that we applied the Strategy pattern quite often. With that pattern, you have several strategies how you can accomplish a particular task in your working code. These strategies can then be plugged into your test automation code on demand, and be unit tested in separation of the whole application. You start to build an automation code base that allows you to plug-in different behavior thereby leading to easier reuse of concepts.
One piece of caution: learning how to apply design patterns constructively takes some time. Also, you need to teach your colleagues on these patterns, since they provide some sort of indirection and abstraction that people working with the code need to get used to. In the long run, getting more familiar with these patterns though will serve you well if you can create a shared understanding of the underlying structure.
No matter what, only applying design patterns is not enough. Over time code bases tempt to rot. They need constant care. This care comes with refactoring. Refactoring means you need to restructure your code without changing the outside behavior of the code. With refactoring you can transform an existing code base from one structure to another one. Thereby you can change your code from one design pattern to another.
There are many books and resources out there on design patterns and refactoring. You can almost pick any one, and get started quite quickly. However, also consider working together with a programmer on these. A programmer can coach and teach you about his thinking process while transforming the code base from one pattern to another one. You will also benefit greatly from his experience in applying these patterns to production code.
Starting programming can become a never-ending road. It also appears to be a long road. Be sure to get started with the first step, and don’t get overwhelmed by all the stuff out there that you could learn. Focus on a single piece. Focus on the stuff that brings you the most fun. Thereby you will learn more quickly.
It seems in order to get familiar with programming, you should look for a couple of things. Start with finding a pet project that solves a practical problem for you. It must not have anything to do with your work as a tester in the end. But it should solve something, and you should have fun solving that problem. That in combination will help you take the first few steps.
Also make sure to solve a tiny problem for your own, and refuse to sell that solution to someone else. Your first programs will be tailored for you, and only for you. If you try to install the same solution for someone else, you will quickly find out that there are many things these folks do differently. That might cause you pain, since you eventually need to rewrite your whole solution to incorporate safety checks, and avoid problems that you wouldn’t have run into on your own.
These tips should get you started. With some basic understanding of programming, you will figure out not only where bugs might lurk. If you start programming yourself, for example on your pet projects, you will find out how you think differently as a programmer. With that in mind, you realize how bugs slip into a program. Also you will find more empathy with your programmer colleagues. That way you will find different ways to connect to your colleagues, and convince them more easily to fix a particular bug in the program. Sounds like a win-win situation for both of you.
As Morpheus said in the Matrix movie: “I can only show you the door. You are the one that has to walk through it.” I showed you some doors. Decide through which you may want to walk.
[Hyde2004] Hyde, Randall; Write Great Code Volume 1: Understanding the Machine; 2004; No Starch Press
[Hype2005] Hyde, Randall; Write Great Code Volume 2: Thinking Low-Level, Writing High-Level; 2005; No Starch Press
[PH2013] Patterson, David A., Hennesy, John L.; Computer Organization and Design: The Hardware/Software Interface, 5th edition; 2013; Morgan Kaufmann Publishers In
Your Blog Here
AST Grant Program
Want to invite a speaker to your local user group? Interested in running a peer workshop? Want some promotional support or reimbursement for the cost of drinks and appetizers? We can help.
I’m Michael Corum, from Knoxville, Tennessee in the US. I grew up here in Knoxville, and have lived here most of my life, except for a short time in Cincinnati, Ohio and two years in the US Army, where I served as a medic stationed in various parts of Texas. I got into software testing […]
We have another volunteer opportunity to ask our membership for help with. Previously, we’ve asked for help with the AST3 to help manage our technology, and we are always looking for help with teaching BBST Courses. Both of these opportunities are still open for your contributions. This particular request is hoping to locate 2+ people who […]
One of the first signs that this year’s AST board was going to work well together was unanimous agreement that we would not try to do everything ourselves, and that there is more to do than 7 people with families and jobs can handle. We agreed to ask our membership for help, and at the same time, […]
- September 2016 (22)
- August 2016 (40)
- July 2016 (48)
- June 2016 (51)
- May 2016 (39)
- April 2016 (69)
- March 2016 (61)
- February 2016 (54)
- January 2016 (66)
- December 2015 (63)
- November 2015 (86)
- October 2015 (50)
- September 2015 (31)
- August 2015 (81)
- July 2015 (63)
- June 2015 (36)
- May 2015 (45)
- April 2015 (30)
- March 2015 (34)
- February 2015 (29)
- January 2015 (36)
- December 2014 (51)
- November 2014 (31)
- October 2014 (20)
- September 2014 (21)
- August 2014 (25)
- July 2014 (33)
- June 2014 (34)
- May 2014 (34)
- April 2014 (31)
- March 2014 (53)
- February 2014 (55)
- January 2014 (63)
- December 2013 (36)
- November 2013 (34)
- October 2013 (73)
- September 2013 (61)
- August 2013 (97)
- July 2013 (80)
- June 2013 (57)
- May 2013 (48)
- April 2013 (60)
- March 2013 (61)
- February 2013 (76)
- January 2013 (87)
- December 2012 (47)
- November 2012 (43)
- October 2012 (50)
- September 2012 (41)
- August 2012 (38)
- July 2012 (50)
- June 2012 (28)
- May 2012 (52)
- April 2012 (55)
- March 2012 (87)
- February 2012 (48)
- January 2012 (76)
- December 2011 (66)
- November 2011 (81)
- October 2011 (132)
- September 2011 (34)
- August 2011 (60)
- July 2011 (64)
- June 2011 (64)
- May 2011 (54)
- April 2011 (57)
- March 2011 (33)
- February 2011 (33)
- January 2011 (58)
- December 2010 (66)
- November 2010 (56)
- October 2010 (36)
- September 2010 (21)
- August 2010 (19)
- July 2010 (12)
- June 2010 (21)
- May 2010 (24)
- April 2010 (3)
- March 2010 (15)
- February 2010 (9)
- January 2010 (12)
- December 2009 (21)
- November 2009 (30)
- October 2009 (9)
- September 2009 (17)
- August 2009 (9)
- July 2009 (4)
- June 2009 (8)
- May 2009 (7)
- April 2009 (17)
- March 2009 (7)
- February 2009 (3)
- January 2009 (4)
- December 2008 (4)
- November 2008 (2)
- October 2008 (2)
- September 2008 (2)
- August 2008 (2)
- July 2008 (6)
- May 2008 (1)
- We are interested in your story. Submit now for #CASTx17 in Sydney https://t.co/rwBinhXa8O 06:01:29 AM September 25, 2016 ReplyRetweetFavorite
- Yes, #CASTx17 in Sydney is happening. Submit your proposal today https://t.co/rwBinhXa8O 06:02:03 AM September 20, 2016 ReplyRetweetFavorite
- Don't miss the unique opportunity to speak at #CASTx17 in Sydney. Submit your proposal now https://t.co/rwBinhXa8O 06:02:03 AM September 15, 2016 ReplyRetweetFavorite
- @aJimHolmes @charrett we offer a flat rate that should cover both. 07:37:09 PM September 14, 2016 in reply to aJimHolmes ReplyRetweetFavorite
- @charrett @aJimHolmes That is correct. 07:25:43 PM September 14, 2016 in reply to charrett ReplyRetweetFavorite
- It's going to happen in February 2017. Submit your paper now for #CASTx17 in Sydney https://t.co/rwBinhXa8O 06:01:44 AM September 10, 2016 ReplyRetweetFavorite
- @karlosmid Hey Karlo, thanks for pointing that out. Can you try again? The website should be available now (at least on my machine :) 10:35:01 AM September 06, 2016 in reply to karlosmid ReplyRetweetFavorite
- There is still time to submit your proposal for #CASTx17 in Sydney https://t.co/rwBinhXa8O 06:01:51 AM September 05, 2016 ReplyRetweetFavorite
Looking for something?
Use the form below to search the site:
Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!