How Invasive Program Settings Turned me into a Jack of all Trades

Erin Hinnen Erin Hinnen
May 08, 2014
Web Strategy

As a Quality Assurance Tester, it is nearly impossible to identify all circumstances that a client might encounter with a tested website or application. To know every combination of operating system and browser they might use is doable, but what about elements outside of our control such as third party software or custom computer settings? I sometimes find myself stuck with an issue that isn’t the fault of the code, but rather a result of a “perfect storm” environment due to pesky network or PC settings. While it may not always be the fault of the code, it is our responsibility to convince the client that the issue is either a non-issue or to provide a fix that will resolve the issue. I have experienced scenarios that fit both of these categories and each was handled in a unique way.

Scenario 1: Companywide Default Settings

We were creating a custom site that provided video player functionality within the site itself. When a user clicked on the “play” button of the video, a media player would pop up within the browser and play the video. I verified this across all browser and operating system combinations in the requirements, but when the client viewed the site, they reported that the video player was “consuming the whole screen”. I e-mailed back and forth with them for a while, baffled as I could not reproduce the video player being too large. We met on a conference call and they walked me through what they were seeing—sure enough, when they clicked the “play” button on the video, Windows Media Player would launch and display in full screen mode. We were able to identify a setting within Windows Media Player that was forcing the video to open within the program and the client agreed that the issue was due to companywide default computer settings and not the code of the website itself.

Scenario 2: Third Party Software

Here we were adding code to a site to allow media tracking for downloaded videos. I verified that when I clicked the link to download, I was asked if I wished to download and then the video would download to my default folder and that download would be tracked on the site. When the client reviewed the site, clicking on the link to download and confirming the download would then open a new tab within the same browser and play the video rather than downloading it. This caused the media to not be tracked. When I reviewed the issue with the client, I was able to identify QuickTime as the culprit. After searching around for some answers to my problem, it became clear that this was a common issue with QuickTime; as a web developer said in a thread I was reviewing, QuickTime essentially “hijacks” your file extensions. I downloaded QuickTime to my Windows 7 PC at home and was able to replicate the client’s issue, but I was unable to resolve the issue without completely uninstalling QuickTime. What do you do in a situation where the only apparent option is suggesting that a client uninstall their software? I came back to the development team with my findings and we were able to locate a custom piece of code that forced the browser to download the media rather than allowing QuickTime to open it, and after days of struggle, QuickTime was vanquished.

Sometimes a Quality Assurance tester encounters issues outside of their realm of control. Sometimes they can help the client troubleshoot this issue and sometimes they can assist the developer with research regarding the issue. It is in times like this that it is incredibly important that a QC resource have the knowledge and thought processes required to not only locate and identify code related issues, but also to troubleshoot simple PC configuration related issues. It is through issues like these that I have expanded my technical knowledge, and that is how invasive program settings turned me into a “jack of all trades”

comments powered by Disqus