Which are some of the most interesting bugs that you as a "Tester" , have found in your career.

I want to collect different test ideas(through bugs) so that I can test better. Please share the main scenarios around your bug, if not the details.

  • 3
    This is not really a good question for the SE format. Question should lead to answers based on facts and not opinions. This question is maybe better asked on a forum like sqaforums.com/forums/forum.php – Niels van Reijmersdal Feb 8 '16 at 12:02
  • Back in the 1980's, this line would compile in C, and lock up every system I tested it on: fgetc,(f,&ch); You have to have superhuman eyesight to spot the extra comma in a stream of C code. – pojo-guy Jun 29 '17 at 11:47

This question would do better on a more traditional forum: here we're focused much more on questions that can have a definitive correct answer.

That said, possibly the most interesting one I've ever hit was a rather nasty compiler bug that didn't trigger until the application executable was large enough.

The symptoms were random errors in test automation where an element that was clearly visible on the screen was not found. Inspecting the element in the test automation tool would crash the application, the tool, or both.

Tracking the problem down required working with the test automation tool vendor, the IDE vendor, and one of the organization programmers. In order to determine what was happening we built a test build of the application which hid all the proprietary information and exhibited the same behavior when inspected in the automation tool. This was sent to both the tool vendor and the IDE vendor.

While that was happening, the developer and I worked to re-engineer the application build to separate the debug info from the application executable and re-engineer the automation to work with the separated debug info.

After several iterations of this, the tool vendor determined that the debug info was corrupted during the build process. Experimentation on our end determined that it took a very large single executable to do this: building the application as a smaller exe with a bunch of dependent dlls didn't cause the problem. Neither did separating the debug info into a separate dll.

Several iterations later, the IDE vendor determined that this was indeed a compiler bug. I don't know what happened after that because I changed employer. Presumably a fix was scheduled and released.

I posted the information as a question here (TestComplete working with a very large application loses the ability to access application internal properties) and later answered it with the information I had.

I'm posting this as my "most challenging and interesting bug" because it took collaboration across multiple companies to track it down. The random automation failures were caused by the corrupted debug info, which might cause say a component's on click event to map to the application's close event. Or to be completely unreadable. I had no way to know this because my only means of inspecting the debug info was through the automation tool with the application running.

The developer had no reason to consider a compiler bug as the cause of the problem: compiler bugs are vanishingly rare and generally fixed as quickly as possible. Getting different automation crashes against the same build with no change to automation code had both of us frustrated beyond belief.

It also forced massive refactoring of the test automation scripts to rely on debug info as little as possible (awkward, in a windows application with multiple third party components).

| improve this answer | |
  • "Compiler bugs are rare" - depends on the project. I work on an OS that's very tied to specific hardware, and very optimized for the hardware. So the compilers are frequently updated to take advantage of new hardware capabilities, and, well. They can be interesting to track down. – Kevin McKenzie Feb 8 '16 at 16:08
  • Good point! And yes, compiler bugs are definitely a challenge to track down. – Kate Paulk Feb 9 '16 at 12:04