[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Suggestion] GNUstep-test for quality control
Re: [Suggestion] GNUstep-test for quality control
Thu, 16 Oct 2003 10:26:02 +0200
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1
An important note: the Users of GNUstep are developers. GNUstep is a
development environment. That's the problem.
So to get more Developers to develop programs with GNUstep you have to
attracked them. One way to attracked new developers might be to provide
next to a great API a great testing environment.
This way you can tell a developer when he runs into problems if it is
his mistake (his app) or the GNUstep API. That might prevent them from
running away from GNUstep and just file a bug report instead.
And automated mail-bug-script would be ideal.
Hope this helps,
Stefan Urbanek wrote:
On 2003-10-15 22:58:38 +0200 Lars Sonchocky-Helldorf
On 15.10.2003 20:58:37 Stefan Urbanek wrote:
Simplier solution: What about lots of users as a 'testing framework and
controll'? Advantage of 'user based testing framework' is that it
tests continualy. That 'framework' should also contain users, that
'kind of users that gnustep does not need' in a gworskpace thread few
on this list. More users means more testers and it does not matter what
users. At this time and state, gnustep needs any kind of users. More
I think, that if at least half of the effort devoted to writing test
am not against them) is also devoted to make gnustep more attractive, it
also help to remove bugs and have a quality controll.
That's a circular dependency: less bugs mean more users, more users
mean less bugs. But the flipside is also true: lots of bugs mean less
users, less users mean lots of bugs :-(. Currently the situation tends
more to the latter...
Yes, and we need to get out of it.
The problem with a "unorganised user based testing" approach is that
it needs committed, disciplined users to work. That's something you
can't take for granted. My experience tells me instead that far most
users simply turn away if things don't work out of the box: You even
can be thankful if about one percent fire their mail client up and
send you just complaints, the users that are able to give you a
qualified bug report you can count with the fingers of both hands.
Another result introduced by the nature of your approach is that
you'll get many reports for easy bugs you already know, but virtually
nobody is willing to invest a lot of time to track down a bug which
a.) occurs irregulary or b.) involves a lot of work. In the end it is
like in any chaotic multi agent system: the path of least resistance
is chosen. The already long history of GNUstep is another proof for this.
True, users go away if it does not work. So what? We should at least
have the first-user-experience parts bug-free, to let them go in and
start play with the other stuff. Like a trap :-) You need a trap, hook
or attraction to get users. Is there any in GNUstep? "The great
framework desing with no alternative? Yes, but ... it does not work (as
expected), so what?" You get the point.
About the discipline and organisation: you need that and you do not.
Point is, that currently there is no need to fix bugs. Why? Because
noone wants them to be fixed, or there are just a few people that want
them to be fixed. So why waste an energy? More users means more
pressure, and perhaps a chance that there is someone who will likely
want to fix it. This is something about that famous "it works on my
machine, so why bother?". True, why to bother, if there are just one or
two users with this behaviour and noone else complains?
You make a mistake when you think that the "effort devoted to writing
test suites" is basically lost time and done just for respectability.
Let me tell you: it is different. Any amount of time invested in a
proper test pays off. For a long time I also was a opponent of unit
testing, I just saw no benefit from it, I resisted doing it and left
it to the other guys here at work. But one day I *had* to do it and it
came out to be much less complicated then I had feared. In fact I
realized that I was so reluctant towards it because it was unknown to
me. Today I have the habbit to test early and often. Unit-testing just
helps you to make rapid progress while coding. I can tell you that I
discovered lots of bugs, even 'thinkos' in my code doing testing
(often borderline cases where some special treatment for certain
values was needed) that would have gone undiscovered and would have
caused bugs hard to track down later on (if you build on a faulty
foundation you building will most likely be faulty to). I wouldn't
start a project (even a private) without unit testing today.
No, I haven't said that the effort devoted to writing test is lost time,
just that at least half of the time should be devoted to gaining more
users. This is not a commercial software for particular requestor where
you already have a customer, this is free software where "customers"
are not certain. And if you write a SW that is really perfect (according
to tests), why is it good for if it is for noone just those who
developed it? Then the SW will die. I'm saying that testing by users can
be complimentary to testing with a testing framework. GNUstep needs
both. Now a question is, what is easier to get at this time?
Btw., to paraphrase your last question ... Would you start a project
without users (even potential) today? Are there going to be any future
users with this state and attitude of GNUstep?
Moreover, there are functionalities that can be tested only by users, so
saying that users are not good for testing is not a way to go.
To sum it up:
- user testing is complimentary to unit testing
- more users will result in greather pressure/need of bug fixing
- to get more users, there should be a trap/hook/attraction - is there any?
- without users, project dies with its developers
Have a nice day,
- Re: [Suggestion] GNUstep-test for quality control (WAS: Re: deferreddeallocation), Lars Sonchocky-Helldorf, 2003/10/15
- Re: [Suggestion] GNUstep-test for quality control, Stefan Urbanek, 2003/10/16
- Re: [Suggestion] GNUstep-test for quality control,
Dennis Leeuw <=
- Re: [Suggestion] GNUstep-test for quality control, Pascal J . Bourguignon, 2003/10/16
- Re: [Suggestion] GNUstep-test for quality control, Alexander Malmberg, 2003/10/17
- Re: [Suggestion] GNUstep-test for quality control, Philippe C.D. Robert, 2003/10/18
- Re: [Suggestion] GNUstep-test for quality control, nicolas, 2003/10/18
- Re: [Suggestion] GNUstep-test for quality control, Fred Kiefer, 2003/10/18
- Re: [Suggestion] GNUstep-test for quality control, Philippe C . D . Robert, 2003/10/19