Our product is a web based SaaS application. Internet Explorer has a setting to Display a notification for every script error that QA has turned on (for manual and automated testing). This causes some script errors (mostly javascript) to be displayed that would not be seen with the default browser settings.

Our team is in disagreement as to whether this is a good idea.

What are the possible pitfalls to turning this setting off? One member said that there is a risk that we will allow a number of errors into our code that might not work with some future browser. Then, instead of having a few errors here and there to correct, we will have a large backlog. Is this a legitimate fear?

Can anyone provide examples where ignoring minor JS errors causes larger problems down the road? Can anyone provide counter examples (that ignoring them has caused no issues)? I realize that you can't prove a negative, but a product that has adopted this policy with no problems through several browser version upgrades carries weight in our decision.

Edited to add: There are no user reported bugs for that specify they have used this setting. It is not a default setting, so most end users will not change it. But we are tasked with testing the code, so we turn it on to find all the bugs that we can. There is disagreement within the team as to whether this is a good practice. One side says we should find all the bugs we can and deploy the cleanest code that we can. The other side says that this is a minor issue and we should focus on larger issues (an opinion I can agree with). But the question is whether this policy of ignoring apparently minor errors will later cause larger problems, particularly with accelerated releases of browser versions.

  • I recommend not basing your decision on the opinions of whoever happens to show up and answer your question. Have you tried looking through your bug database for customer-reported bugs caused by Javascript errors that only show up when the IE setting is turned on? – user246 Dec 18 '13 at 20:39
  • @user246 Yes, we have. There are no reported bugs for this setting. It is not a default setting, so most end users will not change it. But we are tasked with testing the code, so we turn it on to find all bugs. – John Oglesby Dec 18 '13 at 20:49
  • Correction: we turn the setting on to find more bugs. We know we won't find them all. – John Oglesby Dec 18 '13 at 20:55
  • 1
    Is it only QA who has it turned on? For something that gives such quick low-effort feedback, it seems a little strange if the programmers aren't using it. Just thinking this might be another option - I'm assuming that your devs do a quick happy path run-through after coding, if they turned on notifications for this then they'd be able to evaluate the seriousness (or not) of the error. (FWIW, I work on a web-based SaaS app, and if I spot JS errors, I point them out to the dev and we discuss the implications. It's going to vary on a case by case basis.) – testerab Dec 19 '13 at 13:27
  • @testerab Yes, it is currently only QA that has the setting turned on. And I believe your comment about a happy path run through has a lot of validity. – John Oglesby Dec 19 '13 at 19:33

A simple JavaScript error might be a reason of a huge bug. I am always having “Show JavaScript errors” turned on my browser.

Let’s consider the following situation: During saving a Web Form, some JavaScript exception had occurred while populating data from the UI input fields into internal JavaScript object, for instance, JSON object.
In this case, some of the values of the JSON object might be empty or undefined
The JSON object came on the webserver and was successfully saved into the database. Some fields with undefined values were converted to database NULLs. Some important data was not saved and the empty strings were saved instead.

After a month, a manager started a monthly report on the system. As result, the report had incorrect data or was interrupted because of broken data.

The management asks the vendors or developers of the system: “Why doesn’t it work?”

The developers/vendors shrug their shoulders:
“It’s because of incorrect data. We don’t know how it had come there”

In my experience, I’ve seen several times when wrong (incomplete) data was saved into database because of JavaScript exception. It wasn’t created any troubles for the product, because the developers fix such issues immediately.

  • Thanks Dmytro, this is exactly the type of example I was looking for. – John Oglesby Dec 20 '13 at 13:30

One of the main things a tester has to do is decide where to focus their limited testing time for the most benefit. If you feel that testing the browser with this mode turned on is an effective use of your time, then go for it, raise the bugs and be prepared to fight for them in the but triage.

From the information that you have posted, this sound like classic "bug hunting", and trying to find as many bugs as possible, regardless of their impact. It feels like this time could be better spent testing or investing that time elsewhere, for example, non IE browsers.


I believe turning OFF to scripting errors or browser notifications could be better idea. Turning them off won't hurt the operation of any program.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.