<div dir="ltr">On Wed, Aug 14, 2013 at 9:00 AM, Louigi Verona <<a href="mailto:louigi.verona@gmail.com">louigi.verona@gmail.com</a>> wrote:<br>> This time talking of getting tired to file bug reports, get the podcast here:<br>
> <a href="http://www.louigiverona.ru/?page=projects&s=writings&t=linux&a=linux_podcast">http://www.louigiverona.ru/?page=projects&s=writings&t=linux&a=linux_podcast</a><br><br>You most certainly have a point: thanks for bringing this up for discussion.<br>
<br>I'll introduce a few concepts I feel are relevant to this discussion:<br>1. Developer time is best spent developing, not doing testing.<br>2. As a developer I know how that a lot of time goes into testing.<br>3. If testing is not done, the software suffers.<br>
4. The developer will test their uses for the software while writing it.<br><br>My background is writing Luppp, a live performance software. I've had it crash before getting on stage to do a performance, I now know the "users-perspective" of a crash: it simply is not acceptable.<br>
That said, I cannot possibly test every hardware control surface, every effect plugin etc with it. How can the testing be performed to a good standard?<br><br>One idea that comes to mind is a group of "testing-buddies". Basically, I'll spend 5 minutes doing bug-reports for you, if you do the same for me.<br>
Since each tester will try to accomplish different things (and on a different system etc), perhaps this could help?<br>A downside to this idea is that essentially developers test for each other: in the end of the day developer time is spent testing.<br>
<br>I'm open to suggestions, criticism etc :) -Harry</div>