10 Tips on Finding Bugs in Your Code

How to find bugs? Maybe those nasty little creatures creeping their way thru your beautiful code? Bugs, they call them, see? They are mean, hideous, odious and vile. (yes, we launched the synonym dictionary for that one). They live to damage your code, to make you lose time and effort and money.

It is almost like playing hide and seek for money.

Your money. It is time to take out the bug spray and go bug hunting. We bring you 10 tips how to discover bugs in your app in a more effective and structured way.

How to find bugs? Navigation and links in your app

We start with one of the most annoying website bugs. From the perspective of the end-user that is.

Picture this - you found an e-commerce store that sells those “stop bugging me” t-shirts you always wanted. You navigate to a button with a mailto link and you’d like to ask whether they can come in pink. You click the button and realize that it wants to send an e-mail to test@test.com.

Your navigation needs to be 100% functional. Period. Whether we are talking about the menu, outgoing links, internal links or even anchor links, they all need to work. If not, why would you put it in the first place?

Luckily this is one of the most basic functionalities of test automation tools like BugBug. You can put together a set of tests in a relatively short period of time. Run them whenever you like and react if the tests actually find a bug.

Is there a bug in my form?

Forms are tricky. In many cases they are a crucial piece of code and a common place where bugs in the code occur. From the software development perspective a form not only needs to send input values elsewhere.

It also needs to be protected from sending unwanted content. And given the fact you can do that both from the front-end and the back-end point of view makes it a good place for a software bug to be.

There is a wide range of use cases for a form. You want to login - a form, send something to the database - a form, create a user - a form.

Forms are everywhere.

It is crucial to find the bugs that might be located not only at the functionality layer but also in error message handling or the styling. That means that your form might have many types of software bugs at the same time.

Debugging a form might be also handled with a test automation tool. One of the most crucial things you need to prepare beforehand is a dataset. Dummy data of all sorts and sizes will allow you to thoroughly check both the functionality and security of your forms.

C is for Cookie

When we were kids, cookies were all positive. Chocolate chip cookies for desert and the blue guy from Sesame Street. Now the first thing that comes to mind are all the pop-ups, forms, checkboxes and legitimate interests. Adulthood sucks big time!

From the business and software engineering perspectives cookie data and session data are rather important.

Important enough to plan a specific testing phase just for them. You need to detect whether the cookie is deleted after the designated time or after clearing cache.

Does the app stop the session when it needs to etc. This might not seem significant, but a buggy code might cause serious security risks for example if the logout process is handled incorrectly.

Find bugs in your HTML and CSS code

There are two entities in the Universe that go thru your HTML and CSS. First are developers, who laugh at the looks of your website's console. Others are search engine bots. The latter are rather significant since they detect incorrect code and can make your site difficult to find. We do not want that.

Although syntax errors in HTML and CSS rarely break the application, they may decrease the usability and accessibility. Make sure your code complies with accessibility standards (e.g., WCAG 2.0 or 2.1). Verify that all elements are keyboard-navigable and provide appropriate alt text for images.

Assess the performance impact of the HTML and CSS code on the web application's loading time. Optimize the code for faster rendering and minimize any unnecessary requests or redundant stylesheets.

Business workflow - test if your software actually works

Remember our article on test scenarios? Here is when it comes in handy. In order to find bugs in code you need to leave your software tester experience behind for a moment.

You have to become the user and just try to break the thing - meaning you have to consider negative scenarios as well. Good example is trying to buy "%" or "G" products in an e-shop.

Try to think of a simple thing the user would like to do, not something difficult to reproduce - purchase an item, download a file and draw a path which he or she would use.

Each step on the path would be a separate test case within the scenario. It is the most natural way to find bugs in software applications.  Those tests are easy to automate. While creating scenarios you end up with a bunch of cases that you might reuse in different ways in your tool.

Does it work the same on all browsers and devices?

That's a big one. Cross-browser and cross-device compatibility testing is something that is often ignored by less experienced teams or freelancers. In the era of responsive web design and "mobile first" approach it is easy enough to emulate mobile devices during the development process.

Also the most popular testing tools have this functionality. It is wise to use it, since recently clients tend not to understand the "it works for me" excuse many generations of developers used.

The best coverage can be obtained by emulating multiple combinations of environments. For example - web browser A and operating system A, web browser B and operating system A (specific brands ignored on purpose). And so on.

You have to make sure your application is compatible with the most popular environments. Not only with the one your development team has been using forever.

There can be some hardcore examples here as well. Many years ago, while doing one of the first commercial projects ever, I hardcoded a few width values inside a div. It looked smashing on my monitor. When I presented it to the client, it was 150% of his screen.

BaDumTss. So yes - every now and then you have to even consider monitors.

Security tests

Things are getting serious. As they always do with security. First of all, whatever user data you store and use, you must protect them like your dearest treasure. We have news flashing that websites have leaked user's passwords or credit card numbers on an almost weekly basis.

Don't be that person.

You have to encrypt your database records, and do some preventive measures that would limit the severity of a potential unauthorized access.

Security testing is not limited to the user data. Some of the parts of your app may be available for authorized users. The same might happen for downloadable files. You have to test such matters like if the session is automatically killed after some time of inactivity or whether an SSL certificate is in place.

Use all available resources

There is more into testing than just automation tools. Two of the biggest and most powerful resources are always there for you and they are free. We are talking about developer tools and logs.

The former are located in most of the current web browsers (try pushing F12 while reading this and let the magic unveil itself).

4 core functionalities are:

• Inspecting HTML, CSS elements and DOM structure
• Checking the browsers' console for errors, warnings or JS issues
• Analyzing network requests for delays, API failures etc.
• Utilize performance profiling tools to assess the application's speed, identify bottlenecks, and optimize resource usage

The latter provide insights into exceptions, crashes, or unexpected behaviors occurring during application execution. You should monitor the logs on a regular basis. If you are not a fan of browsing thousands and thousands of records, worry not - there are tools that will help you with that task.

Regression testing

Regression testing is checking whether implementing changes to your software did not result in breaking something that worked before. They check whether your application regressed as you introduced new features, updates or patches. Assuming that a functionality that was created and tested will remain good forever is a common mistake.

Sometimes it might be a costly one as well.

It is not that hard to execute regression testing. Especially with modern tools like BugBug. This type of testing is basically running the same tests on an iterative manner while adding some more after every new chunk of project's code is implemented.

It takes some effort to set it up, but it decreases with every iteration.

We, the people!

Your team has been working on this app for what seems to be ages. Everybody claims to know it by heart already. You, as the QA, can foresee the outcome of every test case before it is written. Still - the app crashes every now and then. You ran out of ideas on how to test or break it, because your experience with the app limits your imagination.

But there is the group of superheroes, who will always find a way - the users.

Beta testing or crowdtesting if you will, has been around for a while now. 99% of the apps in the world are created for a client. It does not need to be someone who will pay for it. But that client will have some needs and some requirements for the software.

They are the most reliable source of test cases there is.

Obviously a vast majority of them will follow the business scenarios as designed and will seldom find something not covered by tests. But there are these few. Every app has them - the seekers and the goofballs.

The first will not go to sleep calmly unless they click every... single.. link... or button.. in your application. Those thorough ones will specify and describe the most deeply hidden bugs.

They are a gem!

The second will cover bugs that you have never dreamt of testing. "Well I clicked here, disabled my microphone, a cat ran across my keyboard and I managed to buy minus three t-shirts". Sometimes it may be difficult to recreate such a test case, but do not underestimate the goofballs!

We hope you enjoyed our tips on how to find bugs in your code. Bug detection is elemental for your business. Every error in the software may cost you a lot of money, a lot of effort and a lot of image.

Luckily you have at least 10 places where you can look for those mean beasts.

Happy (automated) testing!