Best Practices for Debugging Website Issues

Thousands of lines of code are written to create an application, and a small unnoticed error will return an invalid result. A bug in an application could also be due to an issue with the hardware or compiler. Nevertheless, bugs are always expected in codes. However, not correcting them in time can be problematic.

Debugging is the process of finding and fixing errors. Even a developer with years of experience is prone to making errors in the code.  It is extremely important because even the smallest glitch in the code can create issues with the user experience. And if this glitch is a major one, it could destroy the reputation of the company. But what could be the worst thing that could happen? The company could lose money on account of a bug in the system, and you know such issues could prove extremely costly. Therefore it is necessary to debug these errors before releasing them to production.

NASA, Bitcoin, Heathrow airport terminal 5, Pentium, and Knight Capital Group have lost millions due to many bugs. Even software behemoths like Facebook, Google, YouTube and Twitter have faced such issues, which have led to public uproar. Bugs found on websites can create a bad user experience resulting in lower conversions and engagement rates. This article suggests a list of best practices to reduce the number of errors in the website code.  

Common Cross Browser Issues

Since different browsers and their versions render. Differently, there could be some cross-browser compatibility issues that might crop up. These issues hinder a consistent user experience across different browsers and their versions. Cross-browser issues occur due to many reasons. It could be because of the following reasons:

• HTML CSS Validation
• Compatibility of layout
• Style sheet issues like CSS Reset
• DOCTYPE error
• Browser could be outdated
• Unreliable cross browser libraries or frameworks
• Functions that are specific to certain vendors only
• No testing done in real devices.

Errors like these create some distortion in the display of the HTML and CSS of the website when they are checked on various browsers. These are called cross-browser errors. Sometimes, even the most sophisticated pieces of code that are created after much brainstorming suffers from compatibility errors. Moreover, every browser has a different rendering. One small example in this regard would be that Google Chrome and Mozilla Firefox render in different ways. Chrome uses DirectWrite, which gives the page a compact display, while Firefox does not use it, so it appears stretched.  

To resolve these issues, you need to test your code. In fact, it would be more convenient if you could use debugging tools with your Github repository. Or, say, how wonderful would it be if you could also use a debugging tool with a project management or collaborative software like Slack. That would be so simplifying and time-saving. Debugging would also be a lot easier and better if data visualization is also used in debugging. You need to also test your HTML code in the browser. But how do you do that for different browsers and their versions?

Therefore, it is critical to address cross-browser issues rather than solely checking the code and limiting yourself to that only. You need to check the entire methodology with which you would be locating the bug, rectifying the issues, and eliminating the bug. Your QA or testing team will support you with that. But you need to use a pragmatic and multidimensional testing tool for that.    

Testing on real devices could be impractical and expensive unless a tester has access to a personal device lab that is constantly updated with the latest gadgets and browser versions. BrowserStack addresses this issue by providing quick and easy access to a real device cloud with 3000+ device browser combinations. Log in and select device-browser combinations to test the compatibility and responsiveness of your website.

Try BrowserStack for Free

Common Syntax Errors

Some syntactic errors are overlooked when trying to spot major logical errors. A lengthy code will have plenty of semicolons and brackets, which becomes an easy miss. All semicolons and brackets must be in place, and all the open brackets need to be closed. The codes must be checked for case sensitivity.  Syntactical errors tend to change the meaning of the codes completely. 

Some of the common syntax errors include:

• Casing

Normally, JavaScript programs use Camel Cases while naming the variables. Using Lower Case or Upper Case letters could mess up the syntax.

For example,

orderedList could be written by the writer as OrderedList or orderedlist. However, code is always case sensitive, and hence OrderedList and orderedlist would throw an error.

• Missing Parentheses

This is one of the common errors where coders miss putting in a closing bracket for a function or a list or an operation or an array. Basically, these are all the bracket errors.

For example,

console.log('PI: ' Math.PI;

This code will return an error because of missing parentheses.

You need to type:

console.log('PI: ' Math.PI);

Parentheses errors could also be caused by missing concatenation operators. 

• Missing curly braces

These are used while writing program blocks in the code. Have a look at the example below to understand better.

For example,

const charge = function () {
if (sunny) {
useSolarCells();
} else {
promptBikeRide();
};

Correct code with the parentheses would be:

const charge = function () {
if (sunny) {
useSolarCells();
} else {
promptBikeRide();
}
};

• Spelling errors

While typing, spelling errors are quite common. No elaboration on this. Even minor mistakes can create a code to malfunction. 

• Wrong placement of semicolons

Let us use the above example only for this.

For example,

const charge = function () {
if (sunny) {
useSolarCells();
} else {
promptBikeRide();
};
}

Correct code with the semicolon in the right place would be:

const charge = function () {
if (sunny) {
useSolarCells();
} else {
promptBikeRide();
}
};

Best Practices for Debugging Website Issues

1. Black boxing

Black boxing code is a concept of hiding functions or methods while debugging. These predefined functions/methods are made error free by their developer. Black boxing functions reduce the effort in debugging the code.

Hence, black boxing these functions/methods would help focus on the newly written codes. The exact process can be applied when existing codes are used as they were tested for some other application. Blackbox previously tested scripts long/short to continue saving time and energy.

2. Commenting out

A convenient method in debugging is ‘commenting out.’ This involves converting some functional codes into comments that will not be executed. Codes can be commented out in the suspected part of a website. This way, the commented part of the code is not executed. You can comment out the part in the code that causes the bug and then rectify it. Each line can be placed back into the code one at a time until to identify the bug.

To comment on a block of code add /* at the beginning and */ at the end of the code that you want to comment out. This given format of comments is seen in C++ code and JavaScript Multiline code. Different formats are followed for comments in different languages.

Some examples are added below for Python and Java:

• Python

There are 3 types of comments in Python.

Single-Line Comments: They are created by using the hashtag ‘#’symbol. Syntax:

# Our first Python code

Multi-Line Comments: They are created by hashtag and string literals also. Each line is considered a single-line comment. Syntax: 1

# Python code practice for

# debugging website issues

Syntax: 2

″ ″ ″ Python code practice for
Debugging website issues ″ ″ ″

Python Docstring: They are written by string literals with triple quotes, after Python functions, modules, and classes. Syntax:

def add (a, b) :
″ ″ ″ Add the values of a and b ″ ″ ″
return a+b

•  Java 

Java has 3 types of comments

Single-Line comments: It uses a double slash. Syntax:

// Add your comments here

Multi-Line comments: Syntax:

/* Start your comment here
.........
........
End your comment here */

Documentation comments: Start with /** and end with */ and every single line between them begins with a *. Syntax:

/** Start
*.................
*................
*..............
End */

3. Stress Testing in Production

Stress Testing involves verification testing of the stability and reliability of a software app. For example, it would help to check what would happen when there is a sudden surge in traffic. You gather the system data and analyze the system defining the stress test goals. You create the automation script, execute it, analyze the stress test results, identify the bottlenecks and then tweak and optimize to rectify the script.

Stress testing is discovering what could happen in the worst-case scenario. While running codes, confirming if the application is not overloaded and can handle the traffic is essential. 

How to perform stress testing?

1. First, make a strong test strategy. Find out the right scenarios, resources, network speed and collect the data from software for this purpose.
2. Select a stress testing tool. JMeter is the best tool for stress testing. It’s purely based on Java language.
3. Then we need an automation test script to run on it to perform the testing and store the results.
4. Finally analyze the result and check the parameters like – stress, speed, performance, and consistency.

• Stress: Capability of handling extreme conditions, system distortion point, time taken by the system to find a recovery resolution.
• Speed: Average load times, avg. response times, count the connected user per second, etc.
• Performance: Memory, disk space and CPU usage.
• Consistency: Page failure per second, transaction passed/failed, error rate, etc

4. Using Breakpoints

Web designs need to adapt to all platforms. A responsive web design breakpoint is where the design and content will adapt a certain way to render the best possible user experience. It is crucial to place breakpoints in the proper places across the website to improve debugging. 

A designer/developer can define breakpoints as pixel values. For developers, a common breakpoint would be a media query, and for designers, the point at which the viewer’s perception of the website’s content or design is altered. Below is the list of common screen sizes a responsive website needs to adapt to.

Common screen sizes:

Mobile: 360 x 640

Mobile: 375 x 667

Mobile: 360 x 720

iPhone: 375 x 812

Pixel 2: 411 x 731

Tablet: 768 x 1024

Laptop: 1366 x 768

High-res laptop or desktop: 1920 x 1080

Now there could be times when an app like Facebook, Twitter or YouTube could face issues with breakpoints when being tested on various devices. That is when you require responsive testing. 

If breakpoints and responsiveness are not checked, then it could create some issues. Like, if the breakpoint is absent or at the wrong place, then the code would pause abnormally. Likewise, if a webpage is not responsive, then various elements and containers of the page will not be displayed properly on different devices.   

Let’s consider amazon.in a website in this case. When we browse this site through a mobile phone, we find the product search option appearing below the ‘amazon.in’ logo. But when we open the site on a laptop/desktop, the same thing will appear in a different layout. For the desktop site, the product search option is aligned with the same line as the ‘amazon’ logo. This is a real use case of responsive web design. Thus you need to perform responsive web design testing. 

It’s a kind of usability testing that you must perform to check how easily the end-users can handle those different layouts or whether there is any issue that occurs for different layouts of  the same website. It may be some issue with visibility, appearances, navigation, and other things.

From this point we can say, the main goal of using breakpoints and responsiveness is to show the content in the best possible way so that it is readable and visible on different sizes of laptop/desktop/mobile/tab screens.

5. Using Print statements

Using a print statement to debug code may be the easiest method. When the software is running, all programming languages provide one or more commands that can be used to print values to the console. Once the bug location has been identified, a print statement can be added to print out the variables containing the bug’s values to determine why the bug is occurring.

It is an excellent method for getting started because it doesn’t require additional tools or an IDE. While debugging in Chrome browsers provide additional features to print out variables in a nested manner. While printing the object, one can locate and view all its attributes in an easy-to-read manner.

It is impossible to create error-free codes and successfully test them on all devices. These few practices will ease a developer’s work and minimize website issues. Testing a small batch of codes at the beginning will minimize the errors over the long run. This article could be handy while developing a website/application to improve and enhance the work.

6. Reporting and bug tracking

A capable bug tracking system will help you find the bugs, analyze how they affect the execution, and prepare reports. These reports contain several indicators to locate the bug, track their actions, and how they affect performance. These reports are then prepared in CSV or PDF format and sent to the QA or the testing team. You can even analyze these reports with the help of various filters. These reports can also be scheduled for sending to the testing team. BrowserStack testing tools provide insightful test insights and analytics. 

7. Using DevTools

Chrome, and Safari DevTool are popular for website debugging. It solves the problem by associated monitoring techniques and an error console and supports website programming like CSS, HTML, and JavaScript. Then produce an instant result. For example,

Debug for JavaScripts: Run the console.log() command from JavaScript on the Dev Tool console. It gives an on-time report of invalid scripts and the exact location of the bug. Otherwise, it shows a set of instructions as a result of successful test execution.

Conclusion

It is important to have proactive debugging for a high-quality user experience. The above-mentioned best practices are a great way to ensure effective debugging that you should perform to fix issues with a website. 

They enhance the performance of the websites and protect them from unwanted crashes and defects. Thus they help companies and business organizations to leverage production and earn high reputations among end-users by providing consistent services.

Although, debugging website issues is a complex process. Following the best practices helps to save time and effort. It also helps in the optimum functioning of the website. But it is recommended to test on real devices to ensure all the real user conditions are taken into account while testing. This ensures better accuracy of test results and improves debugging. 

BrowserStack’s real device cloud provides access to 3000+ real devices and browsers where you can test your website on both the latest and legacy devices and browsers. BrowserStack Live helps you debug websites in real-time using Chrome and Safari DevTools for the best performance.

Try Debugging Websites on Real Devices