[haiku] Re: How to be a good (useful) tester?

  • From: Matt Madia <mattmadia@xxxxxxxxx>
  • To: haiku@xxxxxxxxxxxxx
  • Date: Thu, 10 Sep 2009 22:25:51 -0400

On Thu, Sep 10, 2009 at 21:49, Dennis <fraggle.rok@xxxxxxxxx> wrote:

> 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
...
> tester.  So my question is how to be a good (useful) tester?

Welcome to the club!
There's actually many tasks and needs that non-developers can assist
with, but we'll focus on testing :)

> If I do encounter bugs/KDL... take screen shots and document conditions;
> try to re-produce the bug and document that.
>
Screenshots are pretty much standard... however, textfiles produced
from serial debugging would be better if you manage to set it up. This
can be a bit tricky as it requires each computer to have an actual
serial port. On top of that, at this time Haiku isn't capable of
connecting to another computer running Haiku for serial debugging.
There are some guides that explain the process using other OS's :
http://www.haikuware.com/wikis/doku.php?id=serial-debugging
//www.freelists.org/post/haiku-development/Howto-on-setting-up-serial-debugging

in either case, it's best to get the output of `bt` (backtrace).
if there's room on the screen, `info` would be useful as it clearly
indicates the revision of Haiku.

Aside from those commands, additional ones may be suggested on a case
by case basis.

> 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.
>
You can even do a search for active tickets in a particular component
  http://dev.haiku-os.org/query  and add the necessary filters.
Given that Haiku has between 1000~1500 active tickets,  browsing a
particular component will significantly narrow the field.

> 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?)

http://dev.haiku-os.org/wiki/AccountVerificationEmail

Adding comments is the only way to add information to tickets that you
did not create.

> Ex. CD Player:  I inserted a CD and got KDL;  after searching there is a
> ticket similar, but I have a different hardware
>
If you do end up creating a new ticket for a similar pre-existing
ticket, mention that it may be a duplicate of '#1234", or whatever the
actual ticket number is.

> If I encounter a "odd behaviour", how best to relay this observation?  A new
> ticket?

When creating new tickets for hardware related issues, the following
is good to attach as files or mention.
`listdev`
`open /var/log/syslog`
`listusb -v`  (assuming its a usb related issue)
`listimage | grep drivers/`
`ints` (from within Kernel Debugging Land -- KDL )

enter the kernel debugger by invoking Alt-SysReq-D.
Then the "ints" command will output information about handled and
unhandled interrupts .
You can get out of the kernel debugger back into a usable system by
typing "co" (for "continue").
Just be aware, if you're using a USB keyboard on OHCI, you wont be
able to type inside KDL.


> 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.
>
Basically, Trac is not end-user support.  there's IRC, forums, and
mailing lists for that.

> 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?
>
File the ticket as an enhancement and not as a bug.  Though in your
example, it could be either a bug or enhancement.

> 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.
>
Not needed.  At worst, the ticket will be closed-->invalid.
If you're really uncertain, drop someone a line on irc.freenode.net#haiku

> Should a tester be paired up with a specific Dev?  Would that help with the
> communication of bugs/improvements?
>
In general no.
Once a ticket is being worked on, one or more developers will most
likely leave feedback for you at the ticket.
Usually requesting specific information, trying a particular revision, etc.

--mmadia

Other related posts: