My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions.
Suggestion #31: Join an open source project you like as a tester. - Erick Brickarp
For anyone who takes the Bug Advocacy or Test Design BBST courses offered by AST, this process is part of the class, and we walk through the process of joining the OpenOffice project (that's the project that was chosen when the class materials were prepared, and hence why we still use it as an example).
There are lots of projects out there that are looking for testers. If you are willing to participate, and show that you are effective, you may find that you develop a rapport with that community, and you may be invited to participated in other projects. That involvement can certainly be put into a resume or a LinkedIn profile, or making a github repository visible and showing your contributions. If you are not a coder, don't fret, there are plenty of places where testing skills are needed and appreciated.
Workshop #31: Pick a Project and find out where you can make a contribution
First things first... I'm not going to give you a list of projects to consider.
Why?
I want to encourage those of you who want to go this route do so because you thought of a project you want to contribute to.
Think about an application or a tool that you find interesting, enjoy using, or that you depend on to do your work. If you are already an active user of an open source tool, you are much more likely to be effective as a tester or filling other roles. The reason? You already have an understanding and an connection to the tool. You have a vested interest in seeing it succeed or have development of new features or bug fixes happen.
Once you have identified a project that fits that criteria, see if they have a link on their site that says something like "Getting Involved". Usually, that will bring you to an information page that will tell you what the project needs. Very often, documentation needs to be written, the web site needs some TLC, unit tests for features need to be written, bugs need to be fixed, automated functional tests may be out of date.
Often, a place that needs a lot of love is in the bug tracker of a project. As I mentioned in a previous post, many bugs are poorly written. There may be a large number of issues that are languishing because there just isn't enough information to get to the bottom of what's going on. Here is where a software tester of any level can be tremendously helpful. By going through the database and exploring the bugs, testing around the issue as described, you may find plenty of ways to make the bug more reproducible, expand the scope (or limit it), better explain the steps to get to the issue, and make the case for what needs to be done ( remember the acronym RIMGEA).
Don't be afraid to download the source code and set up a developer environment. With this, and frequently pulling updates, you can become very familiar with the underlying code. This might inspire you to see if you can directly fix some of the issues, or writing unit or system tests to help improve test coverage. If the tests work, and you feel confident of your changes, submit them and have them be reviewed by other programmers on the project. Don't take it personally if your changes are not accepted the first time. Ask for feedback, heed the advice, keep experimenting and try again later on.
Bottom Line:
Every project is different, and every project will have a range of scope, users and footprint. Projects range from small utilities all the way up to full Operating System distributions. Regardless of what project you choose, make it a point to learn as much as you can. Skills learned in one project can greatly enhance opportunities you might come cross in the future, whether they be more open source projects or paid gigs at commercial companies (or a cross section of the two; some Open Source project actually hire and pay people :) ).
No comments:
Post a Comment