Using Google services (Wave, Docs) in daily QA process

There are many organizational difficulties facing small to medium Software Quality Assurance (QA) teams. Because of this, we welcome any help to simplify this work and make assignment, communication and reporting more reliable. Tools are not the silver bullet, yet with a responsible team the right tools can make a lot of difference. Read on to see how we started using Google’s toolkit (namely, Google Wave and Google Docs) in our daily QA and general development practices, as described by Dmitriy Boltovskiy, our QA team lead.

What are these difficulties, you might ask. Organizing a QA process requires:

• a lot of preparation, as we work on the test-cases during or right after the design and specification phase,
• intensive back and forth communication, both between the QA engineers as they coordinate testing assignments, especially on interdependent tasks, and communication with the development team on the implementation detail, especially when issues are found,
• and there’s reacting to feedback that is sometimes delayed, since the development team may already be working on other tasks, and may not respond to an issue immediately, — thus making a face to face meeting not always possible,
• plus lots of reporting and the management keeping a close eye on those reports — to determine when a task is ready to be shipped, or when adjustments to priorities or assignments may be in order.

All of this boils down to efficient communication between several team members, so let me show you an example how we solve some of these issues.

A real-life QA scenario

Let’s assume that we plan a new version 3.3.0.0 of our software product. There are two tasks planned for delivery in this release:

• Task #1001 New report screen in Forecasting Area.
• Task #1002 Implement widgets in Home Page.

To initiate the process, I create a new Google Wave: “Version 3.3.0.0”, as you can see on the screen below (apologies for having to compress some of the screenshots to get all the data in):

In order to facilitate interaction, I add 2 people to this wave — Vadim (a QA Engineer) and Alexander (the developer assigned to this task). They can edit this wave and view any changes which were done to it by other people.

Then I create the following directory structure in Google Docs, to contain both the specifications and the test-cases for the planned tasks:

I upload the following documents into Google Docs:

• Specifications for Task #1 and Task #2 to the “Tasks” folder.
• Test Cases templates (these are still empty, for the QA guys to populate) to the “Test Cases” folder.

You can see the specifications here:

And the test-case templates are here:

These documents are shared with the specific people involved in the development and testing process, so that they can view and edit them as necessary:

When this is all done, I update the “Version 3.3.0.0” wave to add links to the corresponding documents, now the wave serves as the main control panel for accessing the needed data and asking questions or providing feedback and status updates:

The actual assignment of the test cases to QA team members can be as easy as leaving a comment, or one could edit the task list and write the person name near the task they are assigned to:

And get confirmations from each of the guys:

When test cases are complete I can review and approve them straight from Google Wave, and then I can delete the unnecessary comments or data from the wave. The ready test cases may look like this:

When version 3.3.0.0 is implemented and ready to be tested, Alexander from the development team updates the wave, and may also let know the location of the latest source or installation files to test:

This is when we, the QA team, may start the actual testing process:

As testing progresses, which we can also discuss in the wave (though we are more likely to discuss progress in person), I can quickly check every test case and see the overall results:

If every single test case has PASSed status, I can report that version 3.3.0.0 is successfully tested, the tasks are completed, and the wave may now be archived:

As you can see, this approach is practical and simple. If the team consists of many members, one may need more ways to filter and display data from the reports, yet for smaller teams this solution works well. Please let us know in the comments if you use something similar, or perhaps you can suggest an alternative approach.

Just remember: no tool or process will ever replace common sense and responsibility.