Testing in Open Source Projects

Question

This is a bit of a general question. I'm trying to practice my testing skills and perhaps get some better experience with manual testing mature applications. In particular, I'm interested in desktop applications. One good place to do this is with open source projects, particularly those in need of dedicated/semi-dedicated testers. While I know every open source project has its own culture around it, with differing levels of maturity, are there any general tips for OSS testing?

Answer 1

As an end User you test, there is no specific rules to follow. Generally understand what are their requirements and set a work plan what different testing methods you could do with the application. Make sure you are aware of these techniques. You could go with their release notes, what changes they have made in the current version. Then you could test from functional to performance based on your skill and ability.

Answer 2

walking in your shoes, first things I'd check in an OSS project are:

1. whether they use issue tracker. If a project ignores issue tracking it's highly unlikely to be useful to practice testing skills

2. whether their issue tracker is active. If all they typically get is two-three bugs/year, then active tester participation would likely teach one how to handle culture shock instead of testing practice

3. whether they actively fix the issues. If the best they can do is to fix 5-10 bugs in a year then it's basically impossible to practice one of the most important tester skills - verification of fixes

4. what checkpoints do they use to communicate the progress of issue resolution. If you see bugs tracked like - discovered in revision 1234, - fixed in rev 5678, - verified in rev 91011 - think twice if it's worth participation. Or better yet, get some of their known and fixed bugs and try to repeat the discovery and verification. Check how long it takes you to get the right revision checked out, built and installed. If it takes you several hours just to do that, consider your chances to practice testing as pretty low

Answer 3

Widely-used open-source software (e.g. Apache and Firefox) may be thoroughly and methodically tested because of the size of its user base and because employers may be willing to pay testers to test it. However, most open source projects rely on volunteers who tend to test only the aspects of the project that they care about. (One can argue about whether this is a good thing; perhaps features that are the most frequently used will be most likely to be tested. On the other hand, features that are hard to test may not be tested because no volunteer feels like testing them.)

Most open source projects do not have a test plan. In an environment with a lot of turnover, it is good for things to be written down so that there is some continuity among practices. If you contribute a well-written test plan -- even if only for certain aspects of the software -- you will provide the project a valuable service. You will also have a writing example your resume can refer to.

Answer 4

If your the first one to offer testing on the product then get in contact with the owner, with a list of tests you see could be developed. They will have other ideas and you will work out a strategy between you.

Have a look at a few test suites you could employ to help out, we use TestLink, its good for running tests but the UI ... is open source ... if you wanted to test it and complain about how impossible it is to use, specifcally loging in and out to different roles in order for someone in a small team to wear more than 1 hat ... that would be awesome.

Otherwise have a look at http://www.kjross.com.au/, from there you may find something useful in their blogs, we work with them and they are pretty active in the testing space.