Untitled

A New Tool In My Tester's Tool Box - DbVisualizer

Recently, a member of my QA team introduced me to a new tool - DbVisualizer from Minq Software.

From the http://www.dbvis.com/products/dbvis/ website:

"DbVisualizer is a feature rich, intuitive and cross platform database tool for developers and DBA's providing a single powerful interface for a variety of databases. DbVisualizer supports simultaneous database connections, it lets you explore and manage database objects, execute SQL queries, visualize information and a lot more."

Currently, we are using the free version, and have found it very handy in our mixed SQL Server / Oracle environment.

For many more features, try DbVisualizer Personal.

Check them out!

See all the tools in my tool box at

http://www.sqablogs.com/jstrazzere/55/Tester%26%2339%3Bs+Tool+Box.html

Perhaps They Should Have Tested More - KDDI Corp.

Perhaps They Should Have Tested More - MBTA

MBTA glitch has riders feeling robbed

By Mac Daniel, Globe Columnist  |  July 30, 2006

A Good Patriots Omen

Went to Patriots Training Camp in Foxboro today - lots of fun.

During the evening session we had a brief rainstorm.  Afterwards this:

I consider this a good omen!

Thinking Like a Professional Tester

A recent incident at work got me thinking about characteristics that distinguish a casual tester from a professional.

Until recently, this company had no professional QAers.  Any testing had been done by Product Management folks, and by customers during User Acceptance Testing.  These people did the best they could, but they clearly had a lot on their plate - finding bugs wasn't their highest priority.

This time, one person was asked to go and delete a bunch of test accounts that had been added to a system.  She deleted most of them but reported that some couldn't be deleted.  She wasn't sure why, but they just "wouldn't delete".  She didn't seem concerned.

I asked her to put together a list of the accounts which could be deleted and those which could not.  When I saw the list, it appeared that all of those which couldn't be deleted had apostrophes in the name.  I gave her a few suggestions and asked her to investigate.

It turned out that accounts containing special characters in the name could not be deleted.  This bug had been there for quite a while.  People testing the system in the past had noticed the problem, but hadn't understood why it happened.  Even the customer had noticed the problem, but had just asked the developers to go into the database and delete the accounts.

To me, this points out a few differences between casual testers and professionals:

• The ability to recognize that a bug is occurring
• The desire to dig in and find out the characteristics of the bug
• The skill to generalize the problem
• The willingness to initiate a bug report

Perhaps They Should Have Tested More - Churchill Race Track

Computers caused Pick 3 glitch

Surface change created confusion

By Jennie Rees
jrees@courier-journal.com
The Courier-Journal

Tuesday's Pick 3 snafu involving the seventh race was caused by a United Tote software problem apparently triggered when a new rule came into play for the first time, Churchill general manager Jim Gates said yesterday.

Churchill received permission last fall to change Pick 3 rules, specifically addressing the problem for when a race comes off the turf after wagering on a multi-race bet has closed.

But the situation had never occurred before the jockeys, after the fifth race, requested the seventh and ninth races come off the grass following a mid-afternoon downpour. By then, betting had closed on the Pick 3 involving races five through seven.

Under the new rule, every horse in the leg involving the surface change is considered a winner. Complicating matters were a scratch after the sixth race of a horse running in the seventh race and a scratch of a horse in the post parade for the eighth race. Those scratches resulted in consolation payoffs in the Pick 3s ending with the eighth and ninth races.

Gates said United Tote had tested the system to accommodate the rules changes and hadn't had any problems.

"…When they inputted the surface change into the system, it wanted to refund all of the wagers, which was not supposed to happen," he said. "In order to get that fixed, they had to shut down that system to make that change. That was the reason for prices not being posted until that evening after the races were over."

The ninth race was not a problem because the surface change was announced before betting closed on the Pick 3 beginning with the seventh race, he said.

Many fans were angered by having to wait until yesterday to cash, because Churchill was closed Wednesday and Thursday. Gates said those who bet at tracks or simulcast outlets that were open Wednesday could cash that day.

Generic Software QA Engineer Job Descriptions and Levels

Many companies use descriptions like these when determining pay levels for QAers.

Software QA Engineer Job Descriptions

Primary Responsibilities:

• Debugs software products through the use of systematic tests to develop, apply, and maintain quality standards for company products. 
• Develops, maintains, and executes software test plans.
• Analyzes and writes test standards and procedures.
• Maintains documentation of test results to assist in debugging and modification of software.
• Analyzes test results to ensure existing functionality and recommends corrective action.
• Consults with development engineers in resolution of problems.
• Provides feedback in preparation of technical appraisals of programming languages, systems, and computation software.
• Ensures quality computer integration into the overall functions of scientific computation, data acquisition, and processing.

QA Engineer Level 1

KNOWLEDGE:  Learns to use professional concepts.  Applies company policies and procedures to resolve routine issues.
JOB COMPLEXITY:  Works on problems of limited scope.  Follows standard practices and procedures in analyzing situations or data from which answers can be readily obtained.  Contact with others is primarily internal.
SUPERVISION:  Normally receives detailed instructions on all work.
EXPERIENCE:  Typically requires no previous professional experience.

QA Engineer Level 2

KNOWLEDGE:  Uses professional concepts; applies company policies and procedures to resolve a variety of issues.
JOB COMPLEXITY:  Works on problems of moderate scope where analysis of situations or data requires a review of a variety of factors.  Exercises judgment within defined procedures and practices to determine appropriate action.  Has internal and some external contacts.
SUPERVISION:  Normally receives general instructions on routine work, detailed instructions on new projects or assignments.
EXPERIENCE:  Typically requires a minimum of 2 years of related experience.  In some companies, the requirement will be less.

QA Engineer Level 3

KNOWLEDGE:  Uses skills as a seasoned, experienced professional with a full understanding of industry practices and company policies and procedures; resolves a wide range of issues in imaginative as well as practical ways.  This job is the full qualified, career-oriented, journey-level position.
JOB COMPLEXITY:  Works on problems of diverse scope where analysis of data requires evaluation of identifiable factors.  Demonstrates good judgment in selecting methods and techniques for obtaining solutions.  Interacts with senior internal and external personnel.
SUPERVISION:  Normally receives little instruction on day-to-day work, general instructions on new assignments.
EXPERIENCE:  Typically requires a minimum of 5 years of related experience.  In some companies, the requirement will be less.

QA Engineer Level 4

KNOWLEDGE:  Having wide-ranging experience, uses professional concepts and company objectives to resolve complex issues in creative and effective ways.  Some barriers to entry exist at this level (ie, dept/peer review).
JOB COMPLEXITY:  Works on complex issues where analysis of situations or data requires an in-depth evaluation of variable factors.  Exercises judgment in selecting methods, techniques, and evaluation criteria for obtaining results.  Internal and external contacts often pertain to company plans and objectives.
SUPERVISION:  Determines methods and procedures on new assignments, and may provide guidance to other personnel.
EXPERIENCE:  Typically requires a minimum of 8 years of related experience.  In some companies, the requirement will be less.  At this level, graduate coursework may be desirable.

 

QA Engineer Level 5

KNOWLEDGE:  Having broad knowledge or unique knowledge, uses skills to contribute to development of company objectives and principles and to achieve goals in creative and effective ways.  Barriers to entry such as technical committee review exist at this point.
JOB COMPLEXITY:  Works on significant and unique issues where analysis of situations or data requires an evaluation of intangibles.  Exercises independent judgment in methods, techniques and evaluation criteria for obtaining results.  Contacts pertain to significant matters often involving coordination among groups.
SUPERVISION:  Acts independently to determine methods and procedures on new or special assignments.  May supervise the activities of others.
EXPERIENCE:  Typically requires a minimum of 12+ years of related experience.  In some companies, the requirement will be less.  At this level, graduate coursework may be expected.

QA Engineer Level 6

KNOWLEDGE:  As an expert in the field, uses professional concepts in developing resolution to critical issues and broad design matters.  Significant barriers to entry (ie, top management review approval) exist at this level.
JOB COMPLEXITY:  Works on issues that impact design/selling success or address future concepts, products or technologies.  Often serves as a consultant to management and external spokesperson for the organization.
SUPERVISION:  Exercises wide latitude in determining objectives and approaches to critical assignments.
EXPERIENCE:  Typically requires a minimum of 15+ years of related experience.  In some companies, the requirement will be less.  At this level, a graduate degree may be expected.

Perhaps They Should Have Tested More - Manitoba Lotteries

Casino blames computer glitch for jackpot

WINNIPEG, Manitoba, July 4 (UPI) -- Two Canadian men are demanding a Winnipeg casino pay out the jackpot promised in error by a nickel slot machine.

The Manitoba Lotteries Corp. says the message that the men had won almost $210,000 ($190,000 U.S.) was a software error because the nickel machines usually do not have payouts above $3,000.

But attorney Josh Weinstein told the Canadian Broadcasting Corp. there was no sign on the machine giving a maximum payout. He says the men were promised 4 million nickels for successfully matching five numbers on the Keno machine.

"It's our position that it's not a mistake that my clients should be paying for, if it was a mistake," he said. "We don't have results of independent testing."

You Shouldn't Jump to Conclusions

Here is a sanitized version of an interesting email conversation.

Everyone involved worked for the same company, but for different product lines (Product A and Product B).

Product B was used to track bugs, and included a new snap facility for attaching screenshots to Issue Reports.  QAers involved with Product A used Product B internally.

A member of the Product A team concluded that Product B was buggy and shouldn't be used.  He even recommended using a competitor's product!  As you will read, he was a bit hasty in his conclusions.

From: [Product A Architect]
Sent: Tuesday, June 27, 2006 1:17 PM
To: [QA]
Cc: [Product B Developer]
Subject: Images in [Product B] are very large

Most of the new issue I am seeing require long waits to show images that should be quite small but are being delivered as 1000x1000 (approx) BMP files.

I suspect this is the new screen snap facility in [Product B].

PLEASE don’t use this facility as it is buggy, seems to product HUGE files and probably takes up large amounts of db space.  Perhaps I am wrong and this is simply a rendering technique in [Product B], but it does not look like it.  If this is not due to the Product B and you are just pasting huge image files PLEASE stop.

I would suggest you start using [Competitor’s Product] for screen shots.  It is fast, stable, cheap, allows time taken banners and very impressive in cabability.

[Product A Architect]
Development Manager / Software Architect

Hi [Product A Architect],

I understand your concern about image sizing and we are looking at this now.  Thank you for raising this issue.

Could you please clarify what particular are of the most of your concern when you wrote, “PLEASE don’t use this facility as it is buggy?”

Thanks,

[Product B Development Manager]

:o)

Wouldn’t you call the creation of full screen images in BMP format (the most inefficient format available) when snapping small sections of image resulting in download waits long enough to prevent common use a bug?

Until that very significant problem is addressed, I would FAR prefer that our QA staff (for [Product A] anyway) not use the facility at all rather than produce unusable and space consuming images.  A good screen capture facility is very inexpensive.

I have no specific complaints beyond that.

The snap screen facility can indeed produce BMP files, but produces JPG files by default. 

I haven’t seen that they are any larger than JPGs produced by other tools.  Nor have I seen where it “takes up large amounts of db space”.

If there are bugs, someone should write Issue Reports, rather than just telling people not to use it because “it is buggy”.

The new snap screen feature is part of [Product B], and is now a shipping product.

-joe

From: [Product A Architect]
Sent: Wednesday, June 28, 2006 1:27 PM
To: Strazzere, Joe; [Product B Development Manager]
Cc: [QA]; [Product A Development Manager]; [Product B Developer]l; [Product Manager]

Subject: RE: Images in [Product B] are very large

Perhaps this is just [An individual QAer’s] use of the tool?  There is quite certainly a problem somewhere even if you are unaware of it’s existence.  If I use a tool and find specific problems, I will forward the specifics to the folks who seem to be using it. 

[Product B] is not a tool I work on and I am not involved in the QA or development of it.  Like ANY other tool in use for development, if there is a problem in deployment, I will halt use of particular features of the product if it is causing problems.  I quite frankly don’t care in the least who supplied the tool: if it does not work, I will ask those using it to stop the process that does not work.  We will NOT continue to use it pending an issue resolution just because it is internal product.  This is about effective management of a development process for [Product A] and not about the development process of the tool in use.

I do understand the concerns and needs of the [Product B] team, but since this thread exists, they do know about the problem I sensed within the product.  If that perceived problem is resolved quickly or is based on a faulty understanding or the use of a separate tool by particular individuals, then we can resume use of that feature.   Until the problem is isolated, please refrain from using the snap screen facility for [Product A] bugs since at this time it appears to have some problems.

You are correct in your conclusion that some images attached to some Issues are overly-large.

You are incorrect in your conclusion that the snap screen facility is buggy.

[The individual QAer] was using MS-Paint, not snap screen.

-joe

QA Leader's Checklist

Since I tend to write a lot of lists, I've started a list of "things I need to learn, think about, ask about; people and groups I need to talk with". A few of these things are specific to my situation, but most apply to any QA Lead role...

You can find the QA Leaders' Checklist at the new home for

All Things Quality:

http://strazzere.blogspot.com/2010/04/qa-leaders-checklist.html

Puzzling Response to a Bug Report

One person on my team was testing a new Troubleshooting feature, which attempted to rank similar items together on a single page, based on their "relatedness".

The feature had no written requirements at all, and was only recently implemented and deemed "testable".

Some of the results produced by this feature were seemingly unpredictable.
So he wrote an issue report demonstrating what appeared to be totally inconsistent results.

The developer replied this way:

Rankings are not human understandable. Don't try.

Operates as designed. Not a bug.

 

Bear in mind that this was an Architect-level developer, not some Entry-level coder.

When there are no requirements, any solution will suffice.

Web Pages Can See Your Clipboard

Be careful what you have on your clipboard when you visit unfamiliar web sites.

This demonstrates that web pages can see your clipboard.

Copy some text to your clipboard, then refresh this page.

Win32 API IsTextUnicode() is not foolproof - a simple demonstration

From the Aftermarket Pipes blog (http://apipes.blogspot.com/2006/06/this-api-can-break.html)

Over at WinCustomize, someone thought they'd found an Easter Egg in the Windows Notepad application. If you:

1. Open Notepad
2. Type the text "this app can break" (without quotes)
3. Save the file
4. Re-open the file in Notepad

Notepad displays seemingly-random Chinese characters, or boxes if your default Notepad font doesn't support those characters.

It's not an Easter egg (even though it seems like a funny one), and as it turns out, Notepad writes the file correctly. It's only when Notepad reads the file back in that it seems to lose its mind.

But we can't even blame Notepad: it's a limitation of Windows itself, specifically the Windows function that Notepad uses to figure out if a text file is Unicode or not.

You see, text files containing Unicode (more correctly, UTF-16-encoded Unicode) are supposed to start with a "Byte-Order Mark" (BOM), which is a two-byte flag that tells a reader how the following UTF-16 data is encoded. Given that these two bytes are exceedingly unlikely to occur at the beginning of an ASCII text file, it's commonly used to tell whether a text file is encoded in UTF-16.

But plenty of applications don't bother writing this marker at the beginning of a UTF-16-encoded file. So what's an app like Notepad to do?

Windows helpfully provides a function called IsTextUnicode()--you pass it some data, and it tells you whether it's UTF-16-encoded or not.

Sorta.

It actually runs a couple of heuristics over the first 256 bytes of the data and provides its best guess. As it turns out, these tests aren't terribly reliable for very short ASCII strings that contain an even number of lower-case letters, like "this app can break", or more appropriately, "this api can break".

The documentation for IsTextUnicode says:

These tests are not foolproof. The statistical tests assume certain amounts of variation between low and high bytes in a string, and some ASCII strings can slip through. For example, if lpBuffer points to the ASCII string 0x41, 0x0A, 0x0D, 0x1D (A ^Z), the string passes the IS_TEXT_UNICODE_STATISTICS test, though failure would be preferable.

Indeed.

As a wise man once said, "In the face of ambiguity, refuse the temptation to guess."

Some Strings for Pasting

Often, I want to enter strings into input fields of particular lengths or contents.

I use handy strings like these to copy to the clipboard and paste into the fields:

10 Characters
1234567890

123456789+

1234567.89

12345.6789

$123456.78

$12,345.67

12,345,678

123,456.78

abcdefghi+

abcdefghiX

ABCDEFGHI+

ABCDEFGHIx

WWWWWWWWWZ

---------+

~!@#$%^&*X

100 Characters
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789+

1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890

123456789+123456789+123456789+123456789+123456789+123456789+123456789+123456789+123456789+123456789+

abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstu+

abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuZ

ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTU+

ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUz

WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWZ

---------------------------------------------------------------------------------------------------+

~!@#$%^&*()_+{}|:"<>?`-=[];',./~!@#$%^&*()_+{}|:"<>?`-=[];',./~!@#$%^&*()_+{}|:"<>?`-=[];',./~!@#$%X

All Alpha Characters

abcdefghijklmnopqrstuvwxyz

ABCDEFGHIJKLMNOPQRSTUVWXYZ

All Special Characters

~!@#$%^&*()_+{}|:"<>?`-=[];',./

Dennis Hopper Pitches a New Movie Concept

An oldie, but goodie!

PITCH MEETING
LOS ANGELES - 9:17 AM

[Dennis Hopper]
Now hear me out guy,
I'm talkin' Oscar here,
classic, classic Cinderella Stuff.

Ok?

A football team...
Somewhere in New England...
Forty-two years, no championship, man.
Bupkus!

New season...
Home opener...
Guess what happens?

SWAM-O! Their franchise quarterback is gone!

So they got a decision to make... huh?

Sure it's too soon...
but they bring in "The Kid"!
And with the thing, and a thing,
and a BOOM!  and a BOOM!
He's got 'em into the playoffs!

Divisional finals...
We got a blizzard! Bah-ha-ha!

The Kid... is driving his boys down the field (phtt)
for a final touchdown (phtt)...
When... (phtt)...
He fumbles!
He fumbles!

(tweet)

Ok. So dig this...

It's not a fumble, alright?
The refs cite some obscure rule,
so it's a fumble...
but it ain't no fumble!

Cut...
To New Orleans.
Why?
Because I love that city like a brother.
Super Bowl!

Tie score...
Timex running dry...

And the Kid, huh...
Marches his boys right into field goal range!

They kick!

...Will it?
...Won't it?

It does!
They win!
They win!
Ah ha ha ha!
They're champions of the freakin' world, man.

And it could really happen.

[Movie Executive]
Next.

[Dennis Hopper]
Ah come on, not the goons, man!
Come on!

I haven't even told you about the sequel!
The sequel, man!

Every year, man!
Every year!

http://www.youtube.com/watch?v=vciGQGTS9WM&search=new%20england%20patriots

Perhaps They Should Have Tested More - Cox Communications

Thursday, June 08, 2006

The Flood of 2006

Massachusetts has had a lot of rain during May and June, 2006, with a lot of property damage.  Some called the end of May, the "Flood of 2006" (http://www.boston.com/news/weather/flood/)

Here are a few pictures my friend Dan Bourret took in Lowell.

Magic 8-Ball Answers

When the answer "42" isn't appropriate, it's time to break out the Magic 8-Ball for answers to foolish questions:

Perhaps They Should Have Tested More - All Binary Searches???

Nearly all binary searches are broken?

Guess I had better add "Search a billion-element-array" to my Test Cases...

(From: http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html)

Extra, Extra - Read All About It: Nearly All Binary Searches and Mergesorts are Broken

6/02/2006 08:34:00 AM

Posted by Joshua Bloch, Software Engineer

I remember vividly Jon Bentley's first Algorithms lecture at CMU, where he asked all of us incoming Ph.D. students to write a binary search, and then dissected one of our implementations in front of the class. Of course it was broken, as were most of our implementations. This made a real impression on me, as did the treatment of this material in his wonderful Programming Pearls (Addison-Wesley, 1986; Second Edition, 2000). The key lesson was to carefully consider the invariants in your programs.

Fast forward to 2006. I was shocked to learn that the binary search program that Bentley proved correct and subsequently tested in Chapter 5 of Programming Pearls contains a bug. Once I tell you what the it is, you will understand why it escaped detection for two decades. Lest you think I'm picking on Bentley, let me tell you how I discovered the bug: The version of binary search that I wrote for the JDK contained the same bug. It was reported to Sun recently when it broke someone's program, after lying in wait for nine years or so.

So what's the bug? Here's a standard binary search, in Java. (It's one that I wrote for the java.util.Arrays):

1:     public static int binarySearch(int[] a, int key) {
2:         int low = 0;
3:         int high = a.length - 1;
4: 
5:         while (low <= high) {
6:             int mid = (low + high) / 2;
7:             int midVal = a[mid];
8:
9:             if (midVal < key)
10:                 low = mid + 1;
11:             else if (midVal > key)
12:                 high = mid - 1;
13:             else
14:                 return mid; // key found
15:         }
16:         return -(low + 1);  // key not found.
17:     }

The bug is in this line:

 6:             int mid =(low + high) / 2;

In Programming Pearls Bentley says that the analogous line "sets m to the average of l and u, truncated down to the nearest integer." On the face of it, this assertion might appear correct, but it fails for large values of the int variables low and high. Specifically, it fails if the sum of low and high is greater than the maximum positive int value (2³¹ - 1). The sum overflows to a negative value, and the value stays negative when divided by two. In C this causes an array index out of bounds with unpredictable results. In Java, it throws ArrayIndexOutOfBoundsException.

This bug can manifest itself for arrays whose length (in elements) is 2³⁰ or greater (roughly a billion elements). This was inconceivable back in the '80s, when Programming Pearls was written, but it is common these days at Google and other places. In Programming Pearls, Bentley says "While the first binary search was published in 1946, the first binary search that works correctly for all values of n did not appear until 1962." The truth is, very few correct versions have ever been published, at least in mainstream programming languages.

So what's the best way to fix the bug? Here's one way:

 6:             int mid = low + ((high - low) / 2);

Probably faster, and arguably as clear is:

 6:             int mid = (low + high) >>> 1;

In C and C++ (where you don't have the >>> operator), you can do this:

 6:             mid = ((unsigned) (low + high)) >> 1;

And now we know the binary search is bug-free, right? Well, we strongly suspect so, but we don't know. It is not sufficient merely to prove a program correct; you have to test it too. Moreover, to be really certain that a program is correct, you have to test it for all possible input values, but this is seldom feasible. With concurrent programs, it's even worse: You have to test for all internal states, which is, for all practical purposes, impossible.

The binary-search bug applies equally to mergesort, and to other divide-and-conquer algorithms. If you have any code that implements one of these algorithms, fix it now before it blows up. The general lesson that I take away from this bug is humility: It is hard to write even the smallest piece of code correctly, and our whole world runs on big, complex pieces of code.

We programmers need all the help we can get, and we should never assume otherwise. Careful design is great. Testing is great. Formal methods are great. Code reviews are great. Static analysis is great. But none of these things alone are sufficient to eliminate bugs: They will always be with us. A bug can exist for half a century despite our best efforts to exterminate it. We must program carefully, defensively, and remain ever vigilant.

Resources

• Programming Pearls - Highly recommended. Get a copy today!
• The Sun bug report describing this bug in the JDK
• A 2003 paper by Salvatore Ruggieri discussing a related problem - The problem is a bit more general but perhaps less interesting: the average of two numbers of arbitrary sign. The paper does not discuss performance, and its solution is not fast enough for use in the inner loop of a mergesort.

A Bug By Any Other Name

So what do we call Software Bugs?

Here are a few terms I've seen or heard:

• Abend
• Anomaly 
• Blemish
• Bug
• Complaint
• Defect
• Deficiency
• Deviation 
• Err 
• Erratum
• Erroneousness
• Error
• Failing
• Failure
• Fault
• Flaw
• Glitch
• Imperfection
• Inaccuracy 
• Inadequacy
• Incident
• Incorrectness
• Irregularity
• Issue
• Lapse
• Miscue
• Misplay
• Misstep
• Mistake
• Mixup 
• Noncompliance 
• Oops
• Problem
• Shortcoming 
• Slip
• Slipup
• Stumble
• Tripup 
• Typo
• Weakness
• Wrongdoing

Can you add to the list?