Quality Assurance, part 3

The QA project as funded is complete and a report of activities and analysis can be found here:

This work would not have been possible without the generosity of our funding partners: Georgia Public Library Service, BC Libraries Cooperative, South Carolina Library Evergreen Network, Bibliomation, and Central/Western Massachusetts Automated Resource Sharing.

There has already been interest in the development community for increasing our use of pgTAP for testing the database, and I’m hoping we can build on Equinox’s work for using integration tests with Evergreen as well.

However, as the report points out, QA is not a finite destination or a project to bring to completion, but rather it’s a journey — a process — that must be continuously embraced and championed.  Every new feature, every bug fix, every single change to the code requires a QA response and that requires constant resources.

We’ve found that it’s much easier to devote resources (both staff and money) to projects that provide a clear and definite deliverable such as a new feature. QA is a project that only seems to be recognized when something goes horribly wrong — and it doesn’t take much to tip over that house of cards, as we have seen in our recent past.

Equinox is soliciting ideas from the community about how best to tackle this problem. Equinox is willing to step into a (to be defined) role of QA champion, but we cannot do it without monetary support.

Some have suggested that we simply tack on a “QA tax” to our support fees, but the fact is many of the largest Evergreen users do not have a support contract with Equinox. It also makes our support costs higher than competitors, so it does not make good business sense.

Equinox will support whatever direction the community decides to take on this issue — however, a direction must be decided and action needs to be taken or we will certainly find ourselves in a bad situation again.