Once in a while you get a bug report, usually from someone new in QA who may not fully understand the product yet, that makes you raise an eyebrow.
I'll start off with one which my team (both dev & QA) still laugh about years after it happened.
The product I was working on had a toolbar with a set of buttons which toggled certain aspects of the app's state. I got a bug report which stated that "when you push button [x], it gets stuck. you have to push it again to get it unstuck."
I can't read the field where I type in the password. When I type in this field, it only displays circles.
I swear this was from a professional QA tester, not from a user.
I had a bug report that a button was "turning blue".
Turned out that the tester was reporting the normal behaviour of windows buttons, the very subtle blue highlight of a button with focus.
This wasn't from QA, but it was while I was in the support team.
We once got a report from a customer that the 20GB HDD they had in their system wasn't big enough, and they wanted to order a "bigger d#ck" (I'll let you fill in the blanks).
I'm actually surprised that the email got past our spam filters. Not surprisingly, it did the rounds quite a bit at work.
This is my absolute favorite bug report and response, with the attribution from the 'vmsnet.misc' newsgroup, long ago. DEC was Digital Equipment Corporation, for you youngsters and VMS one of the better operating systems of the time.
The author of this was "Stanley Rabinowitz", famous in the DEC world as the author of the SMG$ library, the WHAT utility and many other parts of VMS. The copyright of this is therefore probably his, but he has now left DEC.
Posted-date: 14-OCT-1983 @ 03:08:00 Subject: My SPR answer (for your review)
SPR NUMBER: 11-60903
ANSWER CATEGORY: UE MAINTENANCE HOURS: 1 DUPLICATE PROBLEM: N DUPLICATE SPR NUMBER(S):
OPERATING SYSTEM: VAX/VMS
O.S. VERSION: V3.2 PRODUCT: VAX/VMS PRODUCT VERSION: V3.2 COMPONENT: Run-Time Library SUB-COMPONENT:
LIB$ routinesDATE ANSWERED:
13-Oct-1983MAINTAINER: Stanley Rabinowitz
ATTACHMENT: N
PUBLICATION INSTRUCTIONS: N
SPR PROBLEM ABSTRACT: User claims year 2000 should not be a leap year.
TITLE: - PUBLICATIONS: - ADDITIONAL O.S. VERSIONS: ADDITIONAL PRODUCT VERSIONS: COMPONENT SEQUENCE NUMBER: SUPERSEDES:
TYPE OF ARTICLE:ANSWER CATEGORIESCG=1=CORRECTION GIVEN
RS=5=RESTRICTION
SG=9=SUGGESTION FN=2=FIXED IN NEXT RELEASE CS=6=CUSTOMER SUPPORTED
IQ=10=INQUIRY DE=3=DOCUMENTATION ERROR NR=7=NON-REPRODUCIBLE
HW=11=HARDWARE UE=4=USER ERROR
II=8=INSUFFICIENT INFORMATIONTYPE OF ARTICLEF=OPTIONAL FEATURE PATCH N=NOTE M=MANDATORY PATCH
R=RESTRICTIONFOR MAINTENANCE USE D I G I T A L SPR ANSWER FORMSPR NO. 11-60903
SYSTEM VERSION PRODUCT VERSION COMPONENT SOFTWARE: VAX/VMSV3.2 VAX/VMS V3.2 Run-Time Library
PROBLEM:
The LIB$DAY Run-Time Library service "incorrectly" assumes the year 2000 is a leap year.
RESPONSE:
Thank you for your forward-looking SPR.
Various system services, such as SYS$ASCTIM assume that the year 2000 will be a leap year. Although one can never be sure of what will happen at some future time, there is strong historical precedent for presuming that the present Gregorian calendar will still be in affect by the year 2000. Since we also hope that VMS will still be around by then, we have chosen to adhere to these precedents.
The purpose of a calendar is to reckon time in advance, to show how many days have to elapse until a certain event takes place in the future, such as the harvest or the release of VMS V6. The earliest calendars, naturally, were crude and tended to be based upon the seasons or the lunar cycle.
The calendar of the Assyrians, for example, was based upon the phases of the moon. They knew that a lunation (the time from one full moon to the next) was 29 1/2 days long, so their lunar year had a duration of 354 days. This fell short of the solar year by about 11 days. The exact time for the solar year is approximately 365 days, 5 hours, 48 minutes, and 46 seconds. After 3 years, such a lunar calendar would be off by a whole month, so the Assyrians added an extra month from time to time to keep their calendar in synchronization with the seasons.
The best approximation that was possible in antiquity was a 19-year period, with 7 of these 19 years having 13 months (leap months). This scheme was adopted as the basis for the religious calendar used by the Jews. The Arabs also used this calendar until Mohammed forbade shifting from 12 months to 13 months.
When Rome emerged as a world power, the difficulties of making a calendar were well known, but the Romans complicated their lives because of their superstition that even numbers were unlucky. Hence their months were 29 or 31 days long, with the exception of February, which had 28 days. Every second year, the Roman calendar included an extra month called Mercedonius of 22 or 23 days to keep up with the solar year.
Even this algorithm was very poor, so that in 45 BC, Caesar, advised by the astronomer Sosigenes, ordered a sweeping reform. By imperial decree, one year was made 445 days long to bring the calendar back in step with the seasons. The new calendar, similar to the one we now use was called the Julian calendar (named after Julius Caesar). It's months were 30 or 31 days in length and every fourth year was made a leap year (having 366 days). Caesar also decreed that the year would start with the first of January, not the vernal equinox in late March.
Caesar's year was 11 1/2 minutes short of the calculations recommended by Sosigenes and eventually the date of the vernal equinox began to drift. Roger Bacon became alarmed and sent a note to Pope Clement IV, who apparently was not impressed. Pope Sixtus IV later became convinced that another reform was needed and called the German astronomer, Regiomontanus, to Rome to advise him. Unfortunately, Regiomontanus died of the plague shortly thereafter and the plans died as well.
In 1545, the Council of Trent authorized Pope Gregory XIII to reform the calendar once more. Most of the mathematical work was done by Father Christopher Clavius, S.J. The immediate correction that was adopted was that Thursday, October 4, 1582 was to be the last day of the Julian calendar. The next day was Friday, with the date of October 15. For long range accuracy, a formula suggested by the Vatican librarian Aloysius Giglio was adopted. It said that every fourth year is a leap year except for century years that are not divisible by 400. Thus 1700, 1800 and 1900 would not be leap years, but 2000 would be a leap year since 2000 is divisible by 400. This rule eliminates 3 leap years every 4 centuries, making the calendar sufficiently correct for most ordinary purposes. This calendar is known as the Gregorian calendar and is the one that we now use today. It is interesting to note that in 1582, all the Protestant princes ignored the papal decree and so many countries continued to use the Julian calendar until either 1698 or 1752. In Russia, it needed the revolution to introduce the Gregorian calendar in 1918.
This explains why VMS chooses to treat the year 2000 as a leap year.
Despite the great accuracy of the Gregorian calendar, it still falls behind very slightly every few years. If you are very concerned about this problem, we suggest that you tune in short wave radio station WWV, which broadcasts official time signals for use in the United States. About once every 3 years, they declare a leap second at which time you should be careful to adjust your system clock. If you have trouble picking up their signals, we suggest you purchase an atomic clock (not manufactured by Digital and not a VAX option at this time).
END OF SPR RESPONSE
A bug was opened because we did correctly validate a currency field (against the ISO list). They opened it because the Use Case said : Currency [alpha-num], so they were expecting "2" as a valid currency.
I'm still questioning myself about that one.
"Page design/colors do not match comp."
Wouldn't be so odd if they weren't comparing the page to the wireframes.
The QA person called me with a bug in a coworker's code (the programmer-coworker was sick that day). She complained that some of the fields in the web-based login screen were a light yellow (name, etc.) and others weren't. It was easy to explain - I had just explained it to the programmer before he got sick the day before - it was the Google Toolbar's Autofill trying to be helpful.
Screen blacked out after user wasn't doing anything with their computer for 5 minutes. User paid someone to reinstall Windows for them. In future maybe I'd better disable power management options on all PCs that I work on for others.
"Hover turrets appear to be floating in midair."
Why yes. Yes they are.
Dealt with this yesterday:
Issue report X: "The FileSize column is still visible after Grouping is enabled. FileSize column should be hidden."
(Issue was fixed)
Issue report Y, came in immediately after the fix was deployed: "The FileSize column disappears when Grouping is enabled."
I received a defect stating only this:
"It is wrong"
I had to push back to find out exactly what it was.