BrainsLink

Linking the left brain and the right brain

Poor Quality Software Is Never Done

defectiveDefects. Every software package has them. Some defects are minor and don’t interfere with the operation of the system. Others are ugly, causing business users to lose data. Some are repeatable and consistent. Others are hard to replicate and tough to track down.

Part of what makes defect repair so difficult is that we often don’t agree on the definition of ‘defect’. Even when we agree that a behavior or an appearance constitutes a defect, we often disagree on the severity. Should it be fixed immediately or entered into the backlog for future consideration?

Consider the following issues that might appear in any software system. Are they defects? If so, do they require immediate attention? What’s your opinion?

  • A button or link is in the top left corner but should have been in the top right corner.
  • A menu selection is colored red but should have been blue?
  • A display item is labelled “Press return” but should have said “Press enter”.
  • The software takes more than 5 seconds to return a result and doesn’t give any indication that it’s busy.
  • Large numbers are formatted without commas but should have had commas (e.g. 2,500).
  • A report is exported in CSV format but should have been XLS format.
  • The user experience is inconsistent reflecting implementation by multiple developers without UX guidelines.

What do you think? In my opinion, they are all defects requiring immediate attention. Why? A business user’s first impression of the software is critically important. Complex and inconsistent user experiences cause dissatisfaction and customer support calls. Unexpected behaviors cause confusion and complaints.

Defects really don’t belong in backlogs. Defects need to be identified during development while the software engineers are actively working on the code. That’s why quality testing needs to be an integral part of the development process not an appendage tacked on at the tail end of the project.

Get Better and Get Done

If your team is deploying software with known defects, you need to change your thinking. Software with defects that have been covered up or relegated to the backlog is not done. It’s a work in progress.

If you’re deploying software with unknown defects that are found by users, you need to change your process. Software with defects waiting to be discovered in the wild hasn’t been tested well, if at all. The testing effort hasn’t had the level of commitment it needs.

I look forward to new software features as much as anyone. I also expect them to be done.

photo credit: Idiolector via photopin cc

Updated: August 11, 2013 — 9:36 pm
© Damicon 2014 Frontier Theme