Things a Tester can learn from a Programmer

May 3, 2011 — agile, blog, testing

UPDATE: This blog was also published as an article in Testting Experience, read the article here.

I sent a presentation with the topic Things a Tester can learn from a Programmer to the organization of Agile Testing Days 2011 in Berlin. Unfortunately, they did not select my session. However, I still would like to share the things a tester can learn from a programmer with you.

There is often a healthy rivalry between testers and programmers. Programmers never read the specifications, never test their own software, it always works on their machines. Testers, always are nagging about details, act as if they are the customer, and bother programmers the whole day with their questions.

I used to be a programmer and I’m currently responsible for test management in a development organization. (No Mr. Programmer, this is not a degradation 😉 ) I discovered that it has some advantages as a tester when you were a programmer. I would like to share those advantages with you, maybe you recognize some of them or maybe it inspires you to think about some of the advantages and try to implement them in your organization.

Code Reviews

Most programmers do code reviews on their code. It is a very good practice and I think almost required when you do no pair programming. Goal is to improve the quality of the code and increase the knowledge a certain area.

As tester you should also implement reviews, review your test cases with programmers, customers and requirement engineers. Additionally, also automated test scripts should be reviewed.

When you organize code reviews, don’t focus only on what the code does. For example, one person is the scribe, one person looks if the code complies with the guide lines, one person looks if the code is understandably, etc. The normal approach used by formal inspections.

Programming

If there is one thing that programmers are good in, it is programming and organizing a software project. (Or at least most of the programmers). Depending on your background as tester, you have to admit that programmers have more knowledge about programming as you. Brett Pettichord wrote several papers on test automation.

Test Automation == programming!

Use the knowledge of your programmers when you start with test automation. Ask one or more programmers to become part of the team/project group who will start with the test automation. This has two advantages, first they become also committed to the project and secondly you are able to use their knowledge about software projects.

When you set up test automation you should for example think about:

1. Version Control, where do you store your test scripts?
2. Labeling, do you label your scripts when you release software?
3. Project structure, do you create some kind of framework?
4. Project structure, are you able to work with multiple testers in the same project?
5. Language, how do you handle other language? Do your script support multi languages?
6. When do you update your test automation tool, at the start of a new release, during a release, one day before the end day of the project?

If it looks good then it is good

This section contains (some) prejudices, I already apologize on forehand.

Programmers don’t care too much about the details. They focus on the main requirements and don’t spend too much time on all the exceptions. As a tester it your job to think about all the exceptions.

Some times (I know I’m walking thin ice) a testers focus too much on the details and exceptions. Most software should be good enough, most software doesn’t have to be perfect!

Gerald Weinberg description of quality is: “value of a product”, extended by James Bach and/or Michael Bolton to quality is: “value of a product to someone who matters”. With this description, it is possible to deliver a product that contains bugs in exceptional cases/some areas. If the user never uses those areas, he is not interested in spending too much time on testing those areas.

Be careful as tester to spend too much time on testing certain areas. Act as a programmer sometimes and don’t spend too much time on testing in all cases.

(Ok, start flaming me about all assumptions I made….)

Pair Programming

One of the good practices of Extreme Programming is Pair Programming. Pair Programming is code created by two people working together at a single computer. Pair Programming has many advantages, and believe me, it’s not inefficient.

As tester you could work in pair in two areas,

• Pair Testing, read this blog of me about pair testing;
• Pair Programming. create test automation scripts with two testers working at a single computer;

Test Dojo’s

I’m already applying my next section, be lazy… 😉 Everything about test dojo’s is already here.

Be lazy

A good habit of a good programmer is, laziness. He hates repetitive tasks and always tries to automate boring and/or repetitive tasks with macros, scripts or (custom made) tools.

I often see testers who do a lot of repetitive tasks, for example install a new version of the software every morning, scan log files for errors, create complex reports with standard reports, etc. Why not start up your machine at 6.00am and start automatically an AutoIT script to start the installation, create a tool to scan your logs automatically or create some SQL statement to export the data to Excel?

Be creative and ask support of your programmers to automate your boring daily routines.

Use Patterns

Every programmer know the Gang of Four and the book they wrote, Design Patterns.

A pattern is a formal way of documenting a solution to a design problem in a particular field of expertise. My definition of a pattern is: a predefined described solution for a problem that occurs often.

Programmers use design patterns very often, a pattern that is often used is a singleton.

Why not create test patterns for tests that you have to test frequently? It’s not about features you have to test every release. It is about problems that you frequently face, and that can be solved by the same approach every time. Read some information on this blog about software test patterns.

How to write good comments

As programmer I wrote and read a lot of comments in the code. Some example of comments (in pseudo code) you often see are:

//If a < 1 then calculate a new value for X
if a<1 then calculateX;

try
  CalculateNewDate;
except
  //If an exception occurs during calculating of new date we raise an exception
  raise E.Msg("Calculation new date has failed");
end;

Tell me, what is the value of this kind of comments? This is the so called how-we-do-it comments, adding no value. Every programmer can read the statements above, it has no value to describe the statement again in the comments.

A good programmer writes why-do-we-do-this comments. For example in the above code, he describes why a should be less than 1 and why he raises an exception.

As tester always try to write why-do-we-do-this comments, in your test scripts and in your automated test scripts. How you test, that is clear, describe why you are testing the software.

Conclusion

Let’s end this blog with a conclusion…

I know I used a lot of prejudices and assumed also a lot…. but try to ignore the prejudices and all assumptions and see if there is something you can learn from the programmers.

Did I miss anything, or did I exaggerate too much… please leave a comment for me.