When evaluating contributions to open source projects, does testing the code on various real-world inputs, reducing a large number of complicated bugs to small test cases and filing good bug reports count as a significant contribution? I've done this for several open-source projects (specifically D compilers) where I wanted to help out but the codebase was too complicated to learn my way around in the amount of spare time I have. I'm interested in both the perspective of the main developers (those that write the code and fix the bugs) and from the perspective of employers (in case I want to put it on my resume at some point).
What you're doing is mightily helpful. There is nothing worse than getting a vague, ambiguous 'bug report' where the user is simply complaining, "It doesn't work!". If you're able to narrow the cases to reproduce a bug (and write a detailed report), you're saving a developer a great amount of time.
If you wanted to get into the nitty gritty of the code, try following the progress on the bug report. See what the developer addressed the problem and learn what code and why it was changed to solve the problem.
From an employer's perspective, I don't think anything trumps code committed to a project. That should be your goal.
It's hard to express how much a good tester is valued by developers. Sure, we will tease because uncovering our bugs isn't exactly ego-boosting, but our test team is among the few people I will drop everything to help.
From a hiring point of view, it shows you take ownership in the software you use and don't just consider things other people's problems. Also, a lot of people don't realize how much of a developer's job is communicating technical information in plain English. Really no downside here to including it on a resume.
If you're wanting to get into software development rather than testing, you should try fixing some bugs on your own at some point. Many open source projects maintain a list of starter bugs for just that purpose.