Slashdot Mirror
Test, Test and Test Again
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."
I am in 100^ agrement hear. Far to often developer dont test and check they're code before they release it This resultsi n a poor edn-user experience. Tey wrok two fast always trying to git on to to the next thing.
Test test tst!!$
one tester for each developer?? bah, I have around 300 users^Wtesters.....
The best test environment is production. - Me
chrome://browser/content/browser.xul
Besides, there are books on testing. What's the point of this little spurt of typing?
The article is very good, but I disagree with the part of "one tester per developer". I don't believe there is a formula to use, since each system is/can be a different case. I don't have a good theoretical background about the subject, but for me it always seemed a good idea to divide the system in specific parts like 'login routine', 'add foo routine', 'database connection' (...), and then test them.
Too amateur?
Er Galvão Abbott - IT Consultant and Developer
I think the trick here is for the developers to write lots of automated unit tests. This catches the vast majority of obvious bugs, and lets testers become more like "power users" or something. That is to say, rather than the testers writing bugs like "I did xyz and it crashed" they can write bugs like "it'd be great if this screen had a 'quick user lookup' field". The testers then begin to think of ways to improve and streamline the application, the end users get a better experience, and the developers have more fun because they're actually adding features rather than constantly fixing easy bugs.
Andy Glover 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.
The Army reading list
When he started out stating that all physics grads are stupid. If I wanted stupid name calling, I'd go eavesdrop on next doors kids.
**TODO** Steal someone elses sig.
From my experience, open source software may be released early and often, but it sure isn't tested thoroughly. Sometimes it seems to me that it's not tested at all, when extremely blatant bugs appear in releases. (One of the recent ones I found is a Import dialog in Inkscape that doesn't alphabetize correctly. This isn't 1985, open source developers, alphabetization of a list of files is a solved problem!)
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.
Comment of the year
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 have to pay when they do expensive system testing.
Antti S. Brax - Old school - http://www.iki.fi/asb/
When asked to comment on whether this methodology would be adopted at Microsoft, Steve Ballmer responded "developers developers developers testers testers testers!"
.evom ton seod gis eht
Heck, I even run internal tools that I write for internal company developer use past other programmers as a sanity check (after using them myself extensively) to make sure that things are actually working before I make the tools available to the general developer public.
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 used to be end users or who are still end users). In any case, the folks testing should probably not be familiar with the code internals. It's too easy to unconsciously behave in certain ways (and avoid certain types of behaviors) if you know precisely what is expected by the program logic.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
Don't forget The Career Programmer which discusses testers at length.
Have you read my journal today?
I've been a professional software developer for over ten years. Based on my experience, I can say with certainty that there are three main sources of bugs.
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 the trickiest to fix without breaking something else without realizing it.
3. Lazy developers who neglect to thoroughly self-test their own work before calling it finished. This causes the most bugs in gener, but fortunately most of them are easy and quick to fix as they are mere oversights.
Moderator hint: a comment is neither "Flamebait" nor "Troll" if it is true.
The first few paragraphs were so poorly written and full of unfounded opinions (even the EDITOR had to step in three times to comment on it!) that I couldn't even get to the potentially interesting parts... since I knew I wouldn't be able to trust anything else after that point.
Without development, there won't be much testing. Likewise, without testing, there won't be much development. Farewell, reputation.
-- Chaos, panic, pandemonium... My job here is done!