- This topic has 7 replies, 7 voices, and was last updated 7 years, 4 months ago by
.
-
Posts
-
A trait for a great tester is being able to tell a story – tell the story about the user scenario or tell a story about the bugs found. Like fishermen we tell grand stories about the catch – those that got away, and those that always escape us.
What do you remember as some first bugs that you had to deal with as a tester?
1,2+E11
Back in 1995 people accessed the Internet using a telephone line modem and some user credentials to log into the phone exchange in the other end of the call. Due to a merger and general capacity settings the credentials had to be changed from a four digit number to a 12 digit number starting with 12 then four zeroes then the old customer number then three zeroes. So from 4311 to 120004311000 – pretty simple. Royal mail delivered a load of letters days in advance with the new customer ID in. … exponential notation, so ALL 10.000 letters read the same id: 1,2+E11. Every single customer had to call in the get the new id, and thus get online again. I still remember it takes 1 minute 30 seconds to explain from the old id to the new.When I started as a trainee programmer in the 70s we had to test our own code. During my 2nd year (now a junior) I produced my first major change to production code – a new version of the weekly History program that archived data and deleted old records. It passed all my tests including a parallel run with the old code and was duly released.
The Monday after the first live run there was consternation. A large number of records had been removed from the online data. Once we had restored the data from back ups taken before the history run the investigation began. The missing records appeared to belong to 2 major customers, Smedley and Cadbury. (Later I discovered 2 smaller customers Ledbury Preserves and Nestles of Aylsbury – stored as Nestlay). The program loaded its archiving and deletion rules for different record types from a file. A new record type had gone live at the the same weekend. It had the rule ‘Delete if the 7th character of a certain string is Y. The missing records were processed after the new record type and stored the customer name in the string.
Once we’d established these facts it didn’t take long to identify the bug. The history program failed to clear down its rules tables between record types. This was in a section of code unaffected by my changes. When I reported the analyst who had first looked at the issue said ‘I noticed it affected those 2 custormers but I didn’t think it relevant’.
Lessons learnt.
1. Pre-existing bugs can surface just after a code change. Never assume the error is in the new code.
2. Always look at any patterns seen. Don’t assume they are chance because you haven’t yet got an explanation.
3. You will not be able persuade management of point 1. The incident kept appearing in reports and was always blamed on the code change.I love that story @Hilary !
So true that pre-existing bugs can appear after code changes! What a great lesson!
The main bugs I first had to deal with were around localisation. The first games I tested were either originally design with English or Japanese in mind. This meant that when it came to test the game for localisation errors in German, hardly any of the words fit. We also had issues around special characters not appearing as German has a few different ones to English.
And the following were almost always issues:
Calendar, dates, times, currency, and numbers are displayed differently from language to language.Over the years this has gotten better I think, as companies realise that different languages have different requirements. In my next job we had new levels or games designed with internationalization rules making text boxes a lot larger than the team would have done a year earlier to accommodate all the different languages.
It wasn’t until some years later that I came across issues with national differences. In th 90s (before the Euro) I was part of a team supporting systems running in the UK, Belgium and the Netherlands. The Dutch and Belgians were suprisingly tolerant of having their screens and reports in English but we had to create translation tables for certain technical terms and for external documents. We also had to provide a wider version of reports to accomodate values in Belgian Francs..
One bug that surfaced was when we discovered that one of the European systems had been set up by cloning the other. The home currency had been updated but not the exchange rate tables. I had to write a fix program to re-convert all values entered in foreign currencies to the home currency.
Date formats can cause problems even within a single country. Our users had packages using DMY and YMD. In 2001 one user accidently deleted all her factory’s current purchase orders by entering a YMD date as the cut-off date into a screen that expected DMY and read it as a future date. Once we’d retrieved the orders we put out a 2 part fix. The date format was now displayed on the screen and the program checked that the date was at least 2 months in the past.
I don’t remember the first bug I found, but I do remember the first one critical I missed and was talked about by head of our dev office. I worked on a team developing application for big smartphone vendor. The application we were developing was going to go “onboard”, pre-installed and released with the new smartphone. As the phone wasn’t released by the time, we had to work with beta versions of firmware.
During one testing round I had several app hungs. I knew that firmware was just beta, and attributed the hungs to its instability, as hungs happened on different screen every time. It turned out that we had real critical problem: hung happened after application switched graphics modes from OpenGL to GDI, but not instanly, it happened in a few seconds after switch. As every time after that few seconds I was on different screen, I failed to notice that mode switching was the cause.
Two lessons I learned from this:
1) If your application switches any modes, test the switch rigorously (this also applies to things like screen rotation).
2) If something happens more than 2 times, report it, even if you don’t have exact steps to reproduce, as a bug or as release notes. Never think that problem is just OS, and never think that if something bad happens, the other side you supply your product to may not notice issues.The first bug I found was a real bug! I was a teenager with a genuine Sony Walkman. The walkman at one point started making an unstable sound as only casssette players can make. (for the young people here: http://en.wikipedia.org/wiki/Compact_Cassette 😉
Of course I opened up the thing itself to see what was wrong. Turned out a dead ant was stuck in the cogwheels. Everytime one of the teeth would hit the part with the ant the sound would jump.So it was a real bug 😉 And I solved it myself by removing it.
Albert Witteveen has been working both as an operations manager and a professional tester for nearly two decades now. The combination of setting up complex server environments and professional testing almost automatically led to a specialisation in performance testing.
He wrote a practical guide to load and stress testing which is available at Amazon. This books discusses how to do performance testing, how to provide real value and how to assess the performance in an objective way. It describes how t
Though I remember my first bug, there is no story around it. I am sure other members will have more interesting stories to share. Would love to hear from them.
- You must be logged in to reply to this topic.