Thursday, April 30, 2009

How do you improve Quality

There typically are 3 types of projects, when it comes to quality that I have seen.
  1. The focus is getting the code out the door and then you pick up the pieces.
  2. The focus is on getting quality code out the door until deadline nears then you revert to number 1.
  3. The focus is on getting quality code out the door and as deadline nears features may be dropped and the deadline may slip.
When the project starts everyone seems to be on board with the idea of #3 but typically I have seen it slip all the way to #1 quite quickly.

At my current employer we have an internal application that is used by 300+ end users.

We used to have:
  • ZERO people dedicated to QA. (4-5 Delphi Developers, 1 Mainframe Programmer, no analysts)
  • Testing was done by end users testing as they had time.
  • We had no automated or unit tests.
  • The build process was compile from your own machine and copy it the network, with any developer free to release any code they wanted. Which would sometimes step over the other developers uncommitted code.
  • We had two environment's
    • Development used by both developers and testing.
    • Production
  • Exceptions had no details or context to help track down problems.
  • We had a very small and painful bug tracking system.
  • We would commonly be related to #1 type model above.
Over the few years that I have been here we have made many changes.
We now have:
  • We now have three people dedicated to QA. ( 7 Delphi Developers, 1 Database PL/SQL developer, and 1 Analyst)
  • We have end users still testing with the time that they have. But we now have better management support to get additional time needed.
  • We have a few automated tests, and a few more unit tests, but we really could use many more.
  • Our build process runs every hour through Final Builder, alerting us with email when someone checks in bad code.
  • We now have 4 environment's
    • Development (Dedicated to Developers only)
    • TEST where users get first look
    • QA a final look before production usually with data refreshed from production
    • Production.
  • We now use the JCL Debug to help use find those Hard to Reproduce Errors.
  • We have a better bug tracking system, but still not nearly as nice as some of the home grown solutions I have used at past employers.
  • We are now some where between the #2 and #3 model's above.

Every release we ask what can we do better? We try to learn from our mistakes and implement solutions to prevent problems. We release a new version of our software nearly every month, so we are continually improving, and quality has improved in many ways in the past few years.

However, today I feel awful!

We put out a release on Friday morning last week. I don't think I have ever had a release go bad as this one has. Today we are still working on fixing major problems that were caused by the release.
  • Some of which would have been caught by better testing.
  • Some of which would have been caught by better management of the information coming in about problems. (i.e. it was reported but not acted on!) Since, I usually manage this information, it's the reason I feel awful.
  • Of course like all systems some of them would have taken an unreasonable amount of testing to find.


So I have been thinking, it's time to go back to and look at quality in new and different ways.

I have been making a list for a while that specific to our product on ways to improve quality. Several items on the list are general enough to share with others.

  • Build a health check system detects common/possible problems that can be run daily in each environment's, which is very database specific. We have scripts for all of these, but not an automated way to run them.
    • Tables without primary keys
    • Missing Synonyms
    • Invalid Synonyms
    • Tables without indexes
    • Missing Grants
    • Disabled Constraints in Oracle
    • Tables that have not been analyzed recently.
    • FK Constraints without index on child table (table level lock will be placed on the parent table if these are found)
    • Invalid Database Objects
    • Plus several that are specific to our schema, i.e. constraints that can't be described in meta data.
  • Error Messages (Exceptions)
    • Ability to Send error messages to a web service
    • Ability to capture a screen shot with the error message.
    • Ability to ask users what they are doing when the exception occurred.
    • Ability to attach reported errors to items in bug tracking system.
  • Code Review to help identify and build additional unit tests around the code.
  • Automated Performance Testing Benchmark system. (I think DUnit has something that will work for us)
  • Get current Delphi Unit tests into an daily build and smoke test instead of just being run by hand by developers.

Ok...

I have shared some of my ideas on how to improve quality, as well as some of the things we have done.

How have you improved Quality in the software you write?

I am open to any suggestions, this is just a small attempt to think out side of the box.

Since I just started this blog, I really hope that someone is reading this and has some good ideas they are willing to share.

No comments: