BlogBack

Quality Assurance, part 2

Quality Assurance, part 2

We are entering our 4th week of the QA project and here is what we’ve done since the last report:

  • We’ve created the unit test for the Dewey sort bug in Koha, http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9770, and for the same bug in Evergreen, we created a pgTAP test against the database as part of https://bugs.launchpad.net/evergreen/+bug/1194246, along with many other examples of pgTAP unit tests. These changes merge in with previous pgTAP work done by Galen Charlton.
  • We ported some of Kevin Beswick’s work in OpenSRF for unit tests in C to Evergreen, and created some example C unit tests specific to Evergreen: https://bugs.launchpad.net/evergreen/+bug/1194643
  • We’ve also been reviewing GNU AutoTools, Buildbot, and Bill Erickson’s Evergreen Installer Scripts for Debian Squeeze and Wheezy, with an eye toward testing running systems, as opposed to build-time checks. The pgTAP tests, for example, require an actual database with the Evergreen schema to be useful, and we’ll need to use Evergreen’s stock test datasets for API and performance testing.
  • We’ve sent out a survey for wide dissemination to Evergreen users, staff and patrons alike, to gauge which functional areas of Evergreen appear to be most important to Evergreen users: http://markmail.org/thread/r5ruv5np75562ehq We’ll send out a separate survey in the coming weeks to gauge which functional areas of Evergreen appear to the be most painful or cumbersome to Evergreen end users. These are being done separately so that the data can be gathered as objectively as possible, and when we combine them later we can plot the functional areas on the two axes, pain versus importance. We might then, for example, deem the functional areas that are furthest from some relative origin on the plot in the quadrant of most importance and most pain as the ones that should get the most attention. This is useful information in general, but for the purpose of the QA project, we may tackle one or two of these highlighted functional areas as a case study in how to use QA in conjunction with fixing the problems.
  • We’ve identified existing developer documentation to serve as best examples for core languages/domains within Evergreen: https://docs.google.com/document/d/1ekAX8h8YzNAsr0Pvssuj7Tu_WrQ_kqjNesKfu8bOLU8/pub These examples need to be worked into some sort of primer/styleguide for EG development and/or debated/reviewed by other developers.
  • Finally, I’ve been microblogging some of this at http://phasefx.tumblr.com/

Next steps:

  • Iron out the automatic installation of Evergreen for the purpose of testing, and actually fire off tests that depend on this such as the pgTAP examples.
  • Construct more tests in this vein, for API testing, etc.
  • Send out the second survey for EG pain points.