DMDirc

Hi everyone,

As a newcomer to the DMDirc project, I’d thought I’d introduce myself. I’m Chris ‘laser’ Northwood, and just before the releases of the 0.5 release candidates, I was asked by the other developers on DMDirc to become the QA Lead.

My approach will hopefully become fully implemented for the 0.6 release, and we’ll hopefully see this by having fewer bugfix releases (particularly, less release candidates), as I did not have enough time to implement this for the 0.5 release.

My experience in testing is mainly in functional testing (I’m currently working as a Test Engineer for Sophos, a computer security company), so I’m going to be mainly concerning myself with functional testing, leaving the current unit testing approach to be worked on by the other developers.

The biggest problem I’ve found since joining the DMDirc team is a lack of documentation, which is essential to ensure a good set of test coverage. Greboid has so far developed a pretty good functional specification for the UI, which I can work from, however there are a few other changes I’m hoping to make to ensure the focus on QA. First off is a “Requirements Dashboard”, matching new, changed and existing functionality to a specific requirement, allowing us to check dev status and test case coverage for a specific requirement (see, this mockup dashboard).

Each requirement should have a test case to verify the functionality before testing can begin to ensure a good testing strategy to increase quality of the DMDirc releases.

We currently use a handful of different tools (specifically, Google Code Issue Tracker and Litmus) for QA, which although are good on their own, do not necessarily integrate together well, which is where my dashboard idea is hoping to pull them all together.

I’m also hoping to change the release strategy of DMDirc. Currently, testing is continuous on feature incomplete nightly builds, and release candidates are generated as soon as DMDirc is feature complete. Some of my changes are mainly semantic, but should hopefully clarify the process.

• Nightly builds are still generated, but these are mainly for quick testing and developers rather than the more extensive general testing.
• Once all features for that milestone are implemented (i.e., the dev status on the dashboard is all green), and all defects raised against the last release of DMDirc fixed, a Feature Complete build is released with which the DMDirc QA team can run test cases. Additionally, any defects raised against the last release of DMDirc are verified at this point.
• Any raised bugs are then fixed by the dev team until all test cases have been executed, and raised defects fixed, when the developers release second build to the DMDirc testers, who verify the defects raised against the previous build.
• When the testers are satisfied that there are no unverified raised defects, and nothing caught in testing, a release candidate is published, which will allow DMDirc to be tested in user environments.
• If any issues are raised by the release candidate, a new one is released until these are resolved.
• When a release candidate has been released and no issues identified with it, the release candiate becomes a released final build, and developers can move on to developing new features for the next milestone.

I’ve created a workflow to hopefully show how I intend this to work:

This is not too dissimilar to the current process, just slightly formalised.

Hopefully I’ll be able to implement this with no real trouble, which means that come 0.6, you’ll be able to see the benefits in a more bugfree release.

Chris Northwood, QA Lead