Test, Test and Test Again 41
snikkersnak writes "Richard Collins has written a piece about developers and testers; the article is arguing that in closed development these two roles have to be chained together one-on-one in order to reproduce the 'release early and often' effect of open source development."
ABsolutly (Score:5, Funny)
Test test tst!!$
Re: (Score:2)
one-to-one (Score:3, Funny)
Re: (Score:3, Funny)
And there's what's wrong with OSS in a nutshell.
No, the GP was referring to portion of code the GP developed for Vista.
Wrong. (Score:1)
Re: (Score:3, Insightful)
One tester per developer? (Score:2, Interesting)
Too amateur?
Re:One tester per developer? (Score:4, Informative)
Parts testing is just step 0 of the testing process.
Re: (Score:3, Interesting)
At one time, I had a tester assigned to me half time. That was when I was given someone else's code to fix. That was the worst code I've seen outside of a classroom. The writer, for some bizarre reason, had been promoted to project manager in spite of the fact that he had only been a software developer for a couple of years or so. Prior to that, h
Re: (Score:1)
Automated unit tests (Score:5, Interesting)
Andy Glover [thediscoblog.com] has a good blog on testing and QA in general. He uses FitNesse and TestNG and various other Java testing tools so he's pretty up on all the latest junx.
Re: (Score:1)
It's OK, our QA group tends to as well.
Re: (Score:2, Interesting)
Uh...
If you think that the work of testers can be replaced by unit tests, you either have really stupid testers or really stupid developers. Or both.
Unit tests don't fix bugs. A unit test tests a unit (hence the name), so if 'xyz' is a complex setup, it's likely your unit test won't have caught it. If a developer thought it could happen, he would have fixed it to begin with. Testers are there to find bugs that d
Re: (Score:2, Insightful)
When a tester spots a bug, a unit test might be written to document the behaviour, that the developer didn't think of, thereby reducing regressions.
In additional to 'bugs', testing is useful in checking whether an application performs a task as dictated by a specification, i.e. missed functionality. Unit testing won't catch bugs in code that hasn't been written in the first place!
As for the 'design work' matter
I stopped reading... (Score:2)
Re: (Score:1, Insightful)
First of all, I don't believe that is what he said! Quite the opposite, he seems to imply that physics grads are smarter (in at least one area) than compsci majors! And I think that is right on! Physics grads are trained in mathematics, physics and, more generally, how to solve a host of complicated problems. Compsci grads are taught programming languages and algorithm construction and not a helluva lot of problem solving.
I personally prefer programmers who are e
Re: (Score:3, Interesting)
As for the CS/Physics thing, I find physics grads (me, BTW) have a big weakness when it comes to 'correctness', and being able to simplify algorithms. If they can fix those weaknesses, they become better than ordinary CS grads. The same for CS grads not being able to break out of problems, if they can broaden their narrow focus on 'code elegance', they to can do great thi
Uh, from my experience... (Score:4, Insightful)
Of course, I also don't think "release early and often" is a good philosophy. If you release early, by definition you're releasing something that isn't yet ready for the public, and when the public uses it they're going to be disappointed and a lot less likely to try your next version.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
Ahh, the old case-sensitive sort. I've never quite understood the point of doing it that way really, even given case-sensitive filenames. It is the "normal" X behaviour, though KDE does offer the option of insensitive sorting.
Re: (Score:2)
Or look at it from a usability standpoint... what is easier to remember? Whether a filename starts with S, or whether a filename starts with a capital or lowercase? Not only is S easier to remember, but it also narrowed the selection down tremendously.
The
Re: (Score:2)
It's the right way to sort for the kinds of people who were Unix users twenty years ago: programmers, scientists, and engineers. You're right that it's one of those things that will have to be "fixed" before Linux is "ready for the desktop." But it wasn't wrong in the first place -- it was (and still is, in most cases) right for the people who use it. The only reason to change it is
Re: (Score:2)
1) I'd wager it was done that way CPU-saving or code-saving measure because it's easier to write a case-sensitive sort function than a case-insensitive one.
2) I'd wager that the reason "the type of people who use Unix" prefer it that way is only because they are used to it from using Unix.
3) I'd wager that if you polled just "the type of people who use Unix" that they would prefer an actual alphabetical sort. Since that's what, for instance, the index of every book they read, the card catalog a
Re: (Score:2)
Preferring it that way is a simple matter of being used to adhering to case-sensitive naming conventions. Programming in most languages will teach you that, as will sharing large amounts of data and files with colleagues. (When using mathematical notation, also, it is often helpful to use capitalization consistently.) On my system, for my work, if I know the type and app
Closed source does not work like open source (Score:2)
I have to call bullshit on that argument.
First of all the word "early" in the good old "release early, release often" mantra really means releasing untested software.
Secondly, pardon my own misleading subject line, the division is not about libre vs. proprietary (open source vs. proprietary). It is between gratis vs. non-gratis software. When people use software they expect to get what they pay for so when the users do not pay in cash they pay in testing time. This time is what non-gratis developers
Re: (Score:3, Informative)
On FreeBSD, for example, these three branches are called -CURRENT, -STABLE, and -RELEASE. Typically, only active developers run the -CURRENT branch, but a lot of people run -STABLE. People runn
Ballmerism (Score:1)
*Everything* should be tested! (Score:2)
Multiple testers are better than one, since different users often have different approaches, and I think testers are optimally obtained from a pool of actual end users (or in our case, quite often, from a pool of business analysts who either
Moo (Score:2, Interesting)
Thorough self-testing (Score:2, Informative)
In order, they are:
1. Lack of sensible high-level design and architecture. This causes the bugs that require massive amounts of churn or ugly hacks on top of hacks to fix.
2. Source code that was written without regard for human maintainability/understandability/readability. This causes the bugs that take the longest time to investigate and which are th
Re: (Score:2)
So poorly written! (Score:2)
Should testing drive development or ... (Score:1)