# How to teach test automation engineers to use a debugger

Context: It seems a lot of test engineers do not know how to use a debugger. This is based on the fact that we get a lot of null-pointer exception questions that can easily be solved if you know how and when to use step-by-step debugging.

I am looking for a canonical answer how to debug, targeted at testers. One that can be used as comment in other answers for people to try.

Question: How do we teach beginning test engineers debugger skills, so that they can analyse most common errors. Do you give such training? If yes, how? Answers should try to include:

• Why is having skills to use a debugger important?
• What should a (test) developer minimal know about using debugger?
• General training materials, not language specific (maybe link to good articles, or books)
• Simple example situation which is good for training purposes (for people with basic test automation knowledge)

Excellent question.

Debugging is a basic skill programmers should have. Many testers lack programming skills because companies throw people with no or only little programming experience into test automation and expect them to learn such skills themselves.

Debugging is then one of many programming skills they lack. For instance, the problem with NullPointerExceptions can be easily resolved if they knew how to read stacktraces.

The way I learned such skills was by pairing with senior developers and watching them as they read stacktraces and debug bugs I found in their code.

The way I taught such skills was by pairing with less senior tester and showing him how to read stacktraces and debug their tests.

I don't think such approach is specific to testers. There's no magic about testers. Just treat them as other engineers and use same approaches for training you would use for regular developers.

Unless you're not asking for ways to train them but rather for incentives...

• I like pairing as an answer, but what if you have no experienced developers sitting near you? Most people who are stuck are trying to learn automation from scratch on their own in their free time. – Niels van Reijmersdal Jul 10 '19 at 10:51
• @NielsvanReijmersdal Then do what other developers who work alone do: write a simple program and run it in a debug mode as suggested here: stackoverflow.com/questions/3974230/how-to-learn-debugging. But first a tester must realize s/he is a developer. Makes sense? – dzieciou Jul 10 '19 at 10:54
• Great point. Testers are developers, and developers need to know how to debug. I am looking for a canonical answer how to debug. This is a good start. – Niels van Reijmersdal Jul 10 '19 at 11:05

Debugging in terms of Lay man's(i.e. manual tester) language is to find the root cause of any issue/bug by following the steps or by observing the screenshot, GIF or video provided. So, in the similar manner various things are involved in debugging for which one can follow these points:

1. If your Automation framework has an ability to generate screenshot, then we can easily go to that part in the application then check the browser's developer tool and check for the html element or browser's console.
a. For Chrome : Press Ctrl + Shift + i
b. For Firefox: Press F12

2. In continuation with above point one needs a skill and "patience" to read the back-end console log or the editor your team was using for programming/scripting purpose. Now a days the editors are smart enough to take you to the exact location of code where it breaks.

3. Debugging through editors is also a good option. Editors like Visual Studio, Eclipse has good debuggers to trace code Line by line. <= This will probably the answer to situation mentioned in your Question.

4. Also, If you found any error exception in your code during script execution then just Google it and do some research around it. It give some knowledge about the exception and found many ways to solve the problem. But, personally I will not suggest to do this just because in most of the cases(if not searched with correct keywords) it will let you to the different direction.

## Show the benefits

I think the problem is frequently the incentive (I mean personal one not compensation) is not clear. When you make the incentive(s) clear the case makes itself, and the motivation is now there for anyone to take advantage of (but it's always a two way street). This is similar to trying to get good commit messages. Put someone in the place of a person trying to debug a bug introduced by 'some recent commit... and you'll often fix the problem of 'good commit messages' better than any other exhortations. People want to see and understand why and not just follow rules (which they will do poorly in many cases).

Here's the (real world) example I use with testing a UI:

I'm trying to test an elements locator. I can either spend hours repeating:

• make a code change
• run the program (tests in this case)
• see the failure
• guess a fix
• save the change
• run the program
• See the failure
• Try a fix
• etc.

When running tests in a UI and there is much to get through for the simulated user to reach that point the above process can technically be called:

nuts

Now compare this to putting a breakpoint in. For example with ruby-rspec you can use binding.pry and have the code 'stop' at the point where the screen is at a certain point in the process. Then, in the debugger you can try out like 20 different css locator finds in 1 minutes Something that might have taken an hour previously.

When you show a benefit this dramatic, if the person seeing it doesn't think that is totally awesome then you have a bigger issue.

@NielsvanReijmersdal!! As per the comment you have mentioned two questions:

Q1. How to get started with debugging with editors?

Ans: First of all it depends which programming language you are using let say for JAVA mostly Eclipse and IntelliJ IDE is preferred, For C# i.e. Microsoft related programming language it is Visual Studio and for Javascript we can debug its code with chrome browser's developer tool. So, Below I am providing few documentations for how to do debugging with different editors: