Quality Engineering Basics: Debugging
Part 3 of Quality Engineering Basics. In this series, I’ll cover some basics of Quality Engineering and Software Testing. Today's topic is debugging.
Now that you’ve had some time to practice reporting bugs, let’s focus on debugging.
At a very high level, the debugging process is used to determine how or when a particular bug happens.
While often the responsibility of the assigned developer, quality engineers can help immensely here. Pinpointing the specific circumstances under which a bug occurs can save developers significant time and frustration.
I asked ChatGPT to help us today with an analogy on debugging:
Debugging is like being a detective in a mystery where the mystery is a glitch or problem in a software program. Imagine the software as a story that's supposed to flow smoothly from start to finish. But sometimes, there's an unexpected twist – something doesn't work right. It could be the software freezing, giving an error, or not doing what it's expected to do.
So, in this story, we’re the detectives, and it’s our job to discover clues and help solve the mystery of each bug we find.
When we encounter a bug, going beyond a simple bug report can prove invaluable for getting it fixed. What clues can we look for to find out why this bug happened? What details can help narrow down when it’s reproducible and when it’s not?
Returning to an example bug report from part 1 of this series, let’s look at how we could do some debugging to improve that bug report.
Example Bug Report
Title: WordPress Import via XML: Unable to edit a specific imported post
Description: After importing blog posts from a WordPress XML file, I am unable to properly edit one out of ten imported posts. I was able to reproduce this consistently with multiple attempts.
Additionally, I tried duplicating the post as a draft and ran into the same issues trying to edit. I was successfully able to edit all nine of the other imported posts.
Workaround: I copied the content from the original source into a new post and deleted the imported post.
Impact: As a new user, it’s frustrating to have the platform not work as expected. Additionally, if edits are necessary for the post to be live on Substack, not all users are going to discover or implement the workaround and may abandon the platform.
Environment:
Mac OS version 1234
Arc Browser version 567
XML file (attached) exported from WordPress.com using WP version 6.0
Account/Newsletter: QUALITY BOSS
Steps to Reproduce
Export WordPress.com posts using tools → export → posts, and save the XML file.
On Substack, go to Dashboard → Settings → Import.
Enter qualityboss.blog into the URL field.
Click [Get Started].
Select file to upload → select WP XML file from step 1. (Selection for “Update existing posts does not seem to matter)
Click [Import].
Confirm ownership by checking the box next to “Yes, this is my publication and I accept” and clicking [Next].
After the import is complete, attempt to edit the post “Getting Started as a Quality Engineer”.
Expected Results
I expect to be able to edit any part of the post, as usual.
Actual Results
In edit mode, for this post only, when pressing backspace, nothing happens. If I select or highlight some text, and type over it, the text is replaced with the newly typed text. However, it then reverts to the original text after a few seconds.
When trying to edit a link, the link controls (change | remove) do not appear.
Screenshots or Videos
Attached video showing the actual results.
Log Files or Error Messages
No logs or errors available. However, here I would attach the XML file unless there’s another place to add files.Since there was only one post that exhibited this strange behavior, that seems to indicate that there’s something about the post content or the XML file content/format.
Things to try:
Duplicate the post on the WordPress side, export again, and see if the new copy has the same issue.
If it doesn’t, compare the XML file contents for the original vs. the duplicated post and see if there are any differences.
If it does, we can experiment with editing this post while preserving the original (to continue to reproduce the bug1).
Variations of the original post (assuming we’re using the duplicated version):
Explore removing or replacing various components of the post:
Remove the image from the post.
Replace the image with a different image and/or the same image in another format or size.
Remove the final paragraph of the post.
If the issue continues to reproduce, continue removing elements (paragraphs, hyperlinks, bulleted lists) one by one until it doesn’t.
Import the post to another WordPress instance (or another CMS/platform that accepts WordPress imports) and then export and import again.
Recreate the post on another WordPress instance/site and then export and import again.
Try a different version of WordPress (if possible) to export the post.
Export the post using a different browser.
Import to Substack using a different browser.
Attempt editing the imported post with a different browser or operating system.
If possible, look at the logs on the Substack side for the import and/or during editing to see if there are any errors.
Use your browser’s dev tools to look at the console output when editing the post, and capture any errors.
Everything that’s discovered here can be added to the bug report and provides more clues to help the developer solve the mystery of this bug.
Conversation Starters:
What other things would you try to pinpoint why/when this bug happens?
Have you ever had an ah-ha moment when trying to track down a bug? What was that like?
Solving mysteries, one bug at a time,
Brie
When you have a tricky or hard-to-reproduce bug, it’s imperative not to change or modify the account/data/etc. related to reproducing the bug. If you do, you may lose any chance of figuring it out or determining if it’s fixed.