Email Subscription Form

Saturday, April 18, 2020

Debugging for Testers

Wikipedia defines debugging as "the process of finding and resolving defects or problems within a computer program that prevent correct operation of computer software or a system".  Often we think of debugging as something that only developers need to do, but this isn't the case.  Here are two reasons why:  first, investigating the cause of a bug when we find it can help the developer fix it faster. Second, since we write automation code ourselves, and since we want to write code that is of high quality just as developers do, we ought to know how to debug our code.  




Let's take a look at three different strategies we can employ when debugging code.

Console output:
Code that is executing in a browser or on a device generally outputs some information to the console.  You can easily see this by opening up Developer Tools in Chrome or the Web Console in Firefox.  When something goes wrong in your application, you can look for error messages in the console.  Helpful error messages like "The file 'address.js' was not found" can tell you exactly what's going wrong.  

Often an error in an application will produce a stack trace.  A stack trace is simply a series of error statements that go in order from the most recent file that was called all the way back to the first file that was called.  Here's a very simple example: let's say that you have a Node application that displays cat photos.  Your main app.js page calls a function called getCats which will load the user's cat photos.  But something goes wrong with getCats, and the application crashes.  Your stack trace might look something like this:

        Error: cannot find photos
        at getCats.js 10:57
        at app.js 15:16
        at internal/main/run_main_module.js:17:47


  • The first line of the stack trace is the error- the main cause of what went wrong.  
  • The next line shows the last thing that happened before the app crashed: the code was executing in getCats.js, and when it got to line 10, column 57, it couldn't find the photos.  
  • The third line shows which file called getCats.js: it was app.js, and it called getCats at line 15, column 16.  
  • The final line shows what file was called to run app.js in the first place: an internal Node file that called app.js at line 17, column 47. 

Stack traces are often longer, harder to read, and more complicated than this example, but the more you practice looking at them, the better you will get at finding the most important information.

Logging:
Much of what you see in the console output can be called logging, but there are often specific log entries set up in an application's code that record everything that happens in the application.  I'm fortunate to work with great developers who are adept at creating clear log statements that make it easy to figure out what happened when things go wrong.

Log statements often come with different levels of importance, such as Error, Warning, Info, and Debug.  An application can sometimes be set to only log certain levels of statement.  For example, a Production version of an application might be set to only log Errors and Warnings.  When you're investigating a bug, it may be possible to increase the verbosity of the logs so you can see the Info and Debug statements as well.

You can also make your own log statements, simply by writing code that will output information to the console.  I do this when I'm checking to make sure that my automation code is working like I'm expecting it to.  For example, if I had a do-while statement like this:

do {
     counter++
}
while (counter < 10)

I might add a logging statement that tells me the value of counter as my program progresses:

do {
     console.log ("The value of counter right now is: " + counter)
     counter++
}
while (counter < 10)

The great thing about creating your own log statements is that you can set them up in a way that makes the most sense to you.

Breakpoints:
A breakpoint is a place that you set in the code that will cause the program to pause.  Software often executes very quickly and it can be hard to figure out what's happening as you're flying through the lines of code.  When you set a breakpoint, you can take a look at exactly what all your variable values are at that point in the program.  You can also step through the code slowly to see what happens at each line.

Debuggers are generally available in any language you can write code in.  Here are some examples:


I hope this post helps you get started with both debugging your code, and investigating someone else's bugs!


2 comments:

  1. Thanks for the article. Really appreciate the time and effort that went into composing this article. Looking forward to reading more from you.
    softwaretesting
    softwaretestingcompaniesinhyderabad
    manualtesting
    automationtesting

    ReplyDelete
  2. Hey Guys !

    USA Fresh & Verified SSN Leads with DL Number AVAILABLE with 99.9% connectivity
    All Leads have genuine & valid information

    **HEADERS IN LEADS**
    First Name | Last Name | SSN | Dob | DL Number | Address | City | State | Zip | Phone Number | Account Number | Bank Name | Employee Details | IP Address

    *Price for SSN lead $2
    *You can ask for sample before any deal
    *If anyone buy in bulk, we can negotiate
    *Sampling is just for serious buyers

    ==>ACTIVE, FRESH CC & CVV FULLZ AVAILABLE<==
    ->$5 PER EACH

    ->Hope for the long term deal
    ->Interested buyers will be welcome

    **Contact 24/7**
    Whatsapp > +923172721122
    Email > leads.sellers1212@gmail.com
    Telegram > @leadsupplier
    ICQ > 752822040

    ReplyDelete

New Blog Location!

I've moved!  I've really enjoyed using Blogger for my blog, but it didn't integrate with my website in the way I wanted.  So I&#...