Most Memorable Defect

My first and most memorable defect!

As test engineers, we fondly remember the defects that we found in our careers – the first one, the most memorable one, the nastiest one, and so on. Well, in my case, there have been several nasty ones, and they are countless – core dumps and such. But I fondly remember the first one and that happens to be the most memorable defect too. This also happened to be my first Software Testing project that I worked in.

I was working on a C compiler as part of the development team, maintaining some modules that need to be rewritten for new requirements. A team member was working on a new casting requirement for a new data type, and another one was working on optimization of target code generated out of the DAG.

As these two people didn’t have a bandwidth to test their modules with an ‘out-of-the-box’ thinking, and since they were focusing on their own individual modules and no one was looking at the product from an integration perspective, I was asked to do some ‘sanity’ checks to make sure that the modules worked fine with each other when integrated.

So, I sat thinking about what would comprehensively test these two modules together. On one side, I got to test the new data type, and on the other side, I need to make sure that the output assembly is fine. I figured that the only way to do that would be to execute each and every data type along with the new data type and make sure that the code is generated fine. I also had an intuitive feeling that bringing in all these data types together in multiple possible ways would give rise to situations where there could be defects.

Instead of going through each and every data type, I decided to write one test that would exercise all data types. Not complicated at all, just a straightforward exercising of all data types. Something like this:

NewD N; /* the new data type */
double d;

N = (NewD)(char)(unsigned char)(int)(unsigned int)(float) d ;

I was expecting that proper code would be generated with all the castings taken care of, and the variable ‘N’ would get a final assignment. But….

The optimization module that took care of removing redundant or unnecessary code had a problem and removed a portion of the code that was necessary, and the resultant assembly looked like a box with a huge hole in the middle with the relevant code missing!

That was funny and interesting, and had everyone shaking their heads. They spent a couple of days redesigning a portion of the optimization module. That turned out to the most memorable defect not just to myself but also to other team members! And yes, every change (howsoever minor) warranted an automation suite that would run for around 3 days.

What interesting/funny bugs have you encountered in your career? Feel free to share in the comments!

If you would like chat with me on my Software Testing experiences, give me a buzz!

Leave a Comment

Your email address will not be published. Required fields are marked *