[haiku] How to be a good (useful) tester?
- From: Dennis <fraggle.rok@xxxxxxxxx>
- To: haiku@xxxxxxxxxxxxx
- Date: Thu, 10 Sep 2009 21:49:49 -0400
After following BeOS and now Haiku for several years, R1 approaches and to
say the least, I am inspired!
Some bad news is that even after dabbling on my own, I am facing the reality
that I am probably never going to be a good-enough of a C++ programmer to
help. The good news is that I can at least read C++, and my day-job is IT
(ERP, database, systems and a little bit of programming) and I am a pretty
good trouble-shooter & documentor, having worked with vendors to resolve
bugs in their software numerous time in the past. After reading over the
Getting Started etc... I think a role I can take and contribute is that of a
tester. So my question is how to be a good (useful) tester?
For example, I downloaded a Haiku alpha ISO image to install (I have a
Dell D610 laptop that BeOS ran just fine on; Haiku installs and seems to run
OK as well... very encouraging to me!) I could create a list of "normal"
things I do and walk through those "tests" to make sure all seems to be
well. How useful is that sort of testing to the team? Should I document
and share that?
If I do encounter bugs/KDL... take screen shots and document conditions;
try to re-produce the bug and document that.
Then what? I would think some searching on Trac for similar bugs; it is not
necessarily a straight match due to wording in how I might describe the
bug/crash vs how someone may have previously created a ticket. So I expect
to have to dig a little bit to see if there is a similar ticket already.
If I do find a match -- how do I annotate the ticket with my details? I
have created an account on Trac (rokkr2791) but don't see any edit buttons
when I'm logged in (I presume insufficient priviledges?)
Ex. CD Player: I inserted a CD and got KDL; after searching there is a
ticket similar, but I have a different hardware
If I encounter a "odd behaviour", how best to relay this observation? A new
ticket?
Ex. CD Player: I inserted a different CD, it started to play, but no
sound; I drag & drop an audio track onto MediaPlayer and it plays.
In a similar manner are there "conditions" that should be met before a
ticket is submitted (i.e. a new one). I would hate to be submitting tickets
and only to find out they shouldn't have been.
What if I have suggestions for GUI changes or improvements
Ex. CodyCam: FTP-related text boxes are mushed, could be made wider etc
Do I try to create a mock-up or drawing of the possible re-layouts or just
attempt to describe the proposed change?
At a minimum I could a Google Doc or wiki page of my own and make that
available to whomever -- as long as I can send in an email and someone else
can review my findings and determine how best to submit it either as a
suggestion or as a bug ticket.
Should a tester be paired up with a specific Dev? Would that help with the
communication of bugs/improvements?
Some insight from the Dev's would be great. Knowing how to describe a
problem to a Dev helps immensely in driving continuous improvement. My hope
is that perhaps this can turn into a wiki page or article that can be
helpful to all the other wanna-Be testers like me who can put in a few hours
a week help prove out their favorite OS and apps.
Thanks!
Dennis
Other related posts:
