On Wed, Aug 14, 2013 at 9:00 AM, Louigi Verona <louigi.verona@xxxxxxxxx> wrote:
> This time talking of getting tired to file bug reports, get the podcast here:
> http://www.louigiverona.ru/?page=projects&s=writings&t=linux&a=linux_podcast
You most certainly have a point: thanks for bringing this up for discussion.
I'll introduce a few concepts I feel are relevant to this discussion:
1. Developer time is best spent developing, not doing testing.
2. As a developer I know how that a lot of time goes into testing.
3. If testing is not done, the software suffers.
4. The developer will test their uses for the software while writing it.
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.
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?
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.
Since each tester will try to accomplish different things (and on a different system etc), perhaps this could help?
A downside to this idea is that essentially developers test for each other: in the end of the day developer time is spent testing.
I'm open to suggestions, criticism etc :) -Harry
> This time talking of getting tired to file bug reports, get the podcast here:
> http://www.louigiverona.ru/?page=projects&s=writings&t=linux&a=linux_podcast
You most certainly have a point: thanks for bringing this up for discussion.
I'll introduce a few concepts I feel are relevant to this discussion:
1. Developer time is best spent developing, not doing testing.
2. As a developer I know how that a lot of time goes into testing.
3. If testing is not done, the software suffers.
4. The developer will test their uses for the software while writing it.
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.
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?
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.
Since each tester will try to accomplish different things (and on a different system etc), perhaps this could help?
A downside to this idea is that essentially developers test for each other: in the end of the day developer time is spent testing.
I'm open to suggestions, criticism etc :) -Harry
_______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
