How to unleash community testers?

MeeGo is a large system dedicated to a vast number of users and to make it successful we need to please all of those end-users.

The more feedback we get from the manual testers the more fine tuning can be done. The open source community model, therefore, fits perfectly here - as long as it is easy and encouraging for community members to join the testing efforts and contribute to the final MeeGo quality.

We have reviewed the current set up and found that it can be improved in the following areas:

1. The testing environment should be easier to set up for new testers. Registering a new account should be all that is required;
2. Results should be available in real-time to other testers;
3. History of bugs should be available when re-testing the same functionality;
4. It should not be necessary to learn git and to install extra desktop tools to perform manual true testing, encouraging just about anybody to join the testers community;
5. Test-cases and results should be available to all community members. Access to TestLink where all ‘easy’ test-cases are stored should not be limited;
6. Currently there are only a few test-cases (no more than 100) which are run on each build. There should be many more;
7. Testing tools should be integrated with feature management and error management. It is done manually so far and prone to mistakes;
8. Test-cases should have unique names (IDs) to avoid ambiguity. Duplicated names make tracking history and results harder.

So what can we do about it?

Centralized test management systems are considered impediments in the Agile world. Ideally, all test-cases should be automated, executed on each build and maintained in VCS along with the source code. This is a brilliant idea, but what about reality? How can we make sure that all features requested by a customer are implemented? Can we really avoid a centralized test management system? Most probably not.

In many cases, it is easier and cheaper to create and maintain manual test-cases describing features and use-cases. These can be applied to a variety of implementations and user interfaces. Hence having a tool that can show the following:

• planned/approved features
• test coverage for features
• pass/run rate for test-cases
• errors connected to test-cases
• and finally, a full path between feature and impeding errors

would be a neat improvement to the current process.

This session will present how to simplify the MeeGo testing process by adopting one of the open source projects so anyone can start using it without any previous experience or preparation. This brings more testers to the project, makes their time more effective, the results faster and the collaboration better.

Qualitio is available to everyone willing to join the MeeGo testing community.