Announcing the KDE Quality Team Project 389
Quique writes "The KDE Community is pleased to announce the launch of the Quality Team Project, a community of contributors who will serve as a gateway between developers and users in the KDE Project, and as a new way for people to begin contributing. KDE is a very attractive project, offering high quality software and is freely available. There is a lot of people who feel the urge to give something back, but stop in the middle of the way, frustrated by the steep learning curve. The aim of the project is to reduce these barriers by welcoming these potential contributors, and by offering documentation, support, and even guidance if requested. The objective is to support the new contributors, (programmers, documenters, testers, artists...). Have you ever wished to help KDE in some way, but never knew how? Keep reading!"
This is EXACTLY what open source needs! (Score:5, Insightful)
Allow me to use Slashdot as an example. Wednesday nights = push development into production. Anyone on the slashteam want to tell me what regression testing tools and system testers they use? Sure, usually (not always) there isn't a crash-and-burn build, but occasionally there is annoyances and such that are just 'thrown into' the build that people didn't know was coming and other things.
Granted, this is Robs code, let him do what he wants with it, but with a 'QA' step it just makes for a better product.
Re:This is EXACTLY what open source needs! (Score:5, Insightful)
Not to mention, produce a better product for the rest of us.
Build it, and they won't come.. (Score:5, Insightful)
Sounds like KDE is looking for folks to come along and do all the thankless, boring shit. Spellchecking help files, testing obscure check boxes, applying different themes. Of course, all the cool design work and programming, and artistry, etc, will be done by the core team - who will, of course, accept all the credit.
Noone wants to do the monkey work. I don't want to test constantly, read bug reports, track down insignificant bugs in code thats unused 99.9% of the time. I only do so because it's my job.
Which is a shame for open source in general, because it's that QA step, all the thankless hours of gruntwork, that make the final product what it is.
This is what Open Source needs (Score:5, Insightful)
I think this is exactly what open source needs. It's one thing for programmers, sysadmins and advanced users to contribute to open source projects, but there's often no easy way for the average user to help out.
With ideas like KDE Quality Team, the developers get to hear from the users and integrate features that they would like to see, as well as providing a means by which the average user can contribute. That's why Wikipedia works so well - it is possible for anybody to contribute. It's great to see the "anybody can contribute" idea extend to open source where up till now it's really only the advanced users who can contribute easily.
Re:i hope these guys will integrate with kde-redha (Score:5, Insightful)
Got to give KDE credit.. (Score:5, Insightful)
What about USABILITY? (Score:3, Insightful)
Re:Someone read ESR's rant (Score:5, Insightful)
As an open source author and member of a quality assurance team, experience tells me that the greatest effort will go into programming. QA teams generally have enough work to do just fixing bugs, writing documentation and testing releases ("important stuff"), that not enough time is left for making the user interface uniform or even intuitive. In this case, though they are asking users for direct input on the topic. That's a good sign.
Re:On the heels of ESR (Score:3, Insightful)
The sad part about all this is that ESR will test only Gnome but will bash ALL open source environments, just as he tested only one distribution but bashed ALL Linux, also those distributions which have seamless CUPS configuration.
I certainly don't agree with much Eugenia sais, but at least she doesn't bash A for mistakes B made.
Re:Build it, and they won't come.. (Score:5, Insightful)
Actually it seems someone do want: otherwise how could many open source projects like Apache, Samba, linux (!!!) become what they are?
Re:Build it, and they won't come.. (Score:4, Insightful)
Re:This is what Open Source needs (Score:5, Insightful)
There's a reason for that: average users can find bugs, but cannot report them without having a programmer or an advanced user looking over their shoulder. An average user doesn't think through things logically enough to be able to isolate problems or to come up with the steps needed to consistently reproduced a bug.
You might say, "But the average user doesn't need to know those things! He just needs to report the bug and the programmers will research it and fix it." That's nonsense. A bug report from an average user (if he files one at all) is likely to be along the lines of "A program crashed when I clicked on a menu item." And when you ask for more details, he has forgotten which menu item he clicked on, he has forgotten the error message, he doesn't even know which version he was running. At best you might figure out which OS he uses, but that's it.
QA testing can be done by average users only if they are closely monitored by programmers or advanced users. There needs to be an advanced, knowledgable user present to watch the novice use the program and see how he uses the software. The KDE Quality Team might get some work done--for example, average users could easily locate and point out misspellings or other errors in the help files or dialog box messages--but don't think for a moment that KDE is tapping a great heretofore unused resource. The quality of the feedback generated by the KDE Quality Team will likely be low.
What we really need is to have local LUGs sponsor QA seminars. Get all the local geeks to bring a friend who has never used KDE. Sit them all down in front of a brand new installation of the latest KDE and ask them to perform simple tasks similar to what they would do at home using Windows. (Burn a CD, search the web, etc.) Watch them closely and take notes every time they find a bug or unexpected behavior. Compile that information and submit the necessary bug reports. Now that information will be truly useful.
Disclaimer: I could be wrong about everything. It's not likely, but it's happened before.
Re:This is EXACTLY what open source needs! (Score:5, Insightful)
more importantly is the new developer relations.
lots of big oss projects suffer from poor developer doco, wildly-divergent coding standards and a lack of anything vaguely looking like project management. have you ever tried to bust into the mozilla code? it's easier to become a mason!
in the proprietary world of software, new hires get weeks of training to explain the ins and outs of the source tree, the preferred tools, the internal standards &c. this is done not just to get said hires up to speed and productive as quickly as possible but also to ensure that their contributions don't damage the conceptual integrity of the project.
smart move kde.
Re:Build it, and they won't come.. (Score:2, Insightful)
Well, they _are_ asking for volunteers. I'm sure somebody is better than nobody.
Re:Build it, and they won't come.. (Score:5, Insightful)
Or OS/X. They took an OSS platform and layed a slick, highly integrated and very stylish UI on top of it. In about a quarter of the time that various linux desktop projects have been around. What's the difference?
Legions of grunts whos daily bread relied on toeing the company line, testing what they were told to test, documenting what they were told to document.
I wish this project all success, but I'm skeptical. Contributing programming or artistic skills for free makes sense. After all, programmers like programming, artists like drawing.
But noone likes doing gruntwork. Noone really dances on their way to work at McDonalds. We'll see in the end.
An aunt of mine was as veterinarian, she ran a small animal hospital. She'd have two or three high school girls apply to volunteer there each week, girls are goofy at the idea of hugging puppies.
They wouldn't show up again after the first time they had to do the actual work, say, clean up after a Great Dane with a case of diarreah.
Re:This is EXACTLY what open source needs! (Score:3, Insightful)
Kind of an obvious statement don't you think? Every major OSS project that I know of does what they can with regards to QA and Testing. They all do alphas/betas and encourage users to test their products and report bugs.
Saying that QA/Testing is what OSS needs is a bit of naive statment, unless of course your talking about what KDE in particular is doing. But the way I read it is you were just trying to make some blanket statement about OSS software in general.
Re:Bout Time (Score:1, Insightful)
It sounds like the other two posters don't realise that absolutely anybody can put a comment on an existing bug report.
Re:Quality Team? (Score:4, Insightful)
KDE 2005 == Mac OS 7 (Score:1, Insightful)
Re:On the heels of ESR (Score:3, Insightful)
Re:This is what Open Source needs (Score:3, Insightful)
The point of the project is not only to bring in this heretofore unused resource, and then train it, so that you get a growing number of people with little or no technical background becoming competent with things like Bugzilla, CVS, translation tools, promotion work, etc. These people can then act as a gateway between the developers and the users, to try to improve the quality of communication between these two groups.
Your idea of LUG-based QAs is a great one, but it's not something the KDE Project can enforce, whereas the Quality Teams project is viable and will hopefully make a big difference.
I'm thinking more of... (Score:2, Insightful)
Re:Found on GNOMEDESKTOP (Score:2, Insightful)
As long as you show *all* facts, Ali. Your years trolling lists, forums and even bugzilla don't speak very well for you, and justify your reputation much more than any reaction from gnome developers.
You cause your own problems, you're not a victim, even if you want to look as a martyr.
Re:Well, maybe not exactly... (Score:5, Insightful)
It has been my experience as well that people often confuse "testing for defects" with "quality assurance." The former is doing something to figure out if what you made (note the past tense) is ready for release. The latter is a process or set of processes that assures (or attempts to) that the output of your development cycle has quality. Testing is really only a phase of the entire quality assurance process.
Re:KDE 2005 == Mac OS 7 (Score:3, Insightful)
But to everyone else, seriously, compare a screenshot of KDE with open apps to a screenshot of OS X with open apps. It's like night and day. We gotta work on an attractive and intuitive interface.
Re:Build it, and they won't come.. (Score:3, Insightful)
I used Windows for a long time, but then switched to Linux (Mandrake with KDE). I had no major problems whatsoever regarding usability - everything worked more or less like in Windows, but there were more nice things you could tweak and adjust. That's why I love KDE.
Now, for the first time, I admit, I had to use a Mac, with OS/X. I had a hard time. Everything was different - hell, there wasn't even a freaking right mouse button!
I didn't have to spend much time with it, and maybe, if you grow up with a Mac, it's great, but for someone used to Windows or KDE, it's a nightmare.
Don't mod me Flamebait, I am dead serious.
What's missing (Score:4, Insightful)
1) Requirements and specifications. Also known as what you need before you start coding. Otherwise known as the official arbiter of whether the program is doing what it is supposed to be doing.
This is thankless gruntwork, but it is very valuable. Some KDE apps already have some, but all need them. Take an email client for example. Go grab all the RFC's relevant to POP3, IMAP, etc, and distill them down into a set of requirements stating what the program is supposed to do. Open Source is informal enough that we could get away with combining requirements and specifications into one document.
2) Test procedures. Now take that requirements document and write a comprehensive test procedure. Include regression testing. Now anyone can take this procedure and simply execute it to find out if the program follows its requirements. If a step fails, log a detailed bug that states which requirement is not met.
Not only would these two things aid the the developer in creating and improving the application, they would also improve the quality of bug reports. Instead of bug reports saying "it doesn't do what I think it should do", you get bug reports saying "it does x but the requirements say do y." If the applications still doesn't do what you want it to do, examine the requirements yourself, and if they aren't complete, propose a new one.
Requirements are your road map, and test procedures are the person in the passenger seat reading it to make sure you take the correct exit to Albuquerque.
Re:Sounds Good (Score:2, Insightful)
Re:Well, maybe not exactly... (Score:5, Insightful)
I should point out that most of those topics are rather equivalent to just one:
It's worse than that for FOSS, because the available total man-hours must be scaled by the funness of the task. Programming is more fun than debugging, which is itself more fun than reviewing requirement documents or measuring escaped defects. In paid work, testers are cheaper to hire than coders; but on a volunteer basis, testers can be harder to attract because the job is less emotionally rewarding.
But, always remember that in many Open Source efforts, the users are the testers. That's a valid viewpoint if something is free; Microsoft is excoriated when they periodically lure customers into paying to become testers, but the practice is more defensible when no money changes hands.
If you want solid, defect-finding, QA people who can improve your product, you'll be asked questions like these.
And yet, corporations that have an affirmative answer to everything you listed have still proven themselves fully capable of producing code that's absolute garbage. The public at large might not be aware of this, as the truely bad code dies before making it out the door. Someone who works in the industry will see veracity in the quote "Most software projects fail [ibm.com]".
Additionally, the themes of Superprogrammer vs The Horde" [indiana.edu] are relevant to understanding why. Having seen a few SEI CMM 5 shops in action, it's clear that to fill the man-hours for all the redudant tasks requires hiring a grade of developer that's frankly sub-par. Programming is the one field where a true 20x productivity differential between two professionals is unremarkable. It seems that the prominent Open Source projects have gotten more attention from generous SuperProgrammers than a typical commercial developement is able to attract.
Re:Gnome is NOT a KDE alternative (Score:1, Insightful)
It's just like all the "BSD is dead" retards who post in every BSD-related thread.
Frankly, I don't give a shit about the reasons why either of them are better. Just give me one that works.
Re:Build it, and they won't come.. (Score:3, Insightful)
Give me a break. I could give you an entire list.
From your post, it seems you are a KDE fan and that is good, but don't bash others just because they don't choose to use that system. I don't use it because it so slooooooow and has an extremely cramped interface. Way too many buttons going on.
Mods, this is a reposted troll (Score:2, Insightful)
I'm sure we could all come up with the same kind of list for KDE. Both projects have endless usability issues.
Re:GNOME has had a quality team for years. (Score:3, Insightful)
Re:Well, maybe not exactly... (Score:5, Insightful)
FOSS tend to be small groups, with small projects. And there is no insane pressure from management to let releases escape to early.
It would be nice to have some dedicated testers around to do smoke tests and general usablity tests. In general FOSS projects rely on the users to want to run the bleeding edge code and test that. But in my experience a group of good testers is the best bang for the buck beyond starting with great programmers.
To the specific points:
>What is the development process? Is it documented?
The development process is pretty typical. Check out any successful project on SourceForge. No need for QA audit role. There's no management around to muck things up, the engineers are in charge.
> What types of estimation procedures do you do?
Irrelevant. It gets done when it gets done. If you pay for the development one can do better... you can audit those circumstances, but in general, don't need QA audit role here.
> What is the SCM process? Is it documented?
CVS or subversion and bugzilla or some such is typically the tool. Much of the SCM process probably depends on the distribution that actually packages the code. Might be Debian's release process. Anyway this is pretty well defined too...
> What is the review/inspection process for all artifacts?
There are usually a few "stars" writing all the code. They can tell crap from not. And if it's crap it probably doesn't work, so no one is going to use it. So you find out one way or another. Reviews of code might help but in general it doesn't matter. If it works well, and the people maintaining it can read it, we're OK. The project will die its natural death otherwise (just like proprietary software... actually its death is usually prolonged too far...).
> Are there software requirements? Are they inspected/reviewed?
What gets implemented is what the creator needs and sounds cool or seems OK and is contributed. Unless someone is paying, in which case this might be useful. But in general, no role for QA here.
> Are there development plans/design docs? Are they inspected/reviewed?
Informal probably. Small team, might trade mockups of screens or working prototype code around. Back of the napkin kind of stuff. Probably works OK for most projects. Wouldn't fly a plane that way though
> Are there code reviews?
Hahah. And you and I both know they don't really matter anyway unless you're dealing with poor programming ability, in which case you're screwed anyway... what are you going to do, fire the volunteer programmer from his own project?
Code reviews don't find bugs. You might be able to get more conformity to the coding guidelines if any that way. But in general, many projects enforce their guidelines by having few people allowed to check in. And good programmers go with the flow as far as code formatting anyway.
> What are your defect escape rates?
Escape rates? Must be some QA auditor speak. Does that mean bugs V&V didn't find before release? Anyway, Not interesting... If the stuff doesn't work people won't use it. It will die a natural death.
> What is your plan for alpha/beta testing?
Release early, release often but maintain a good stable release if you're changing things rapidly. Don't need QA to tell us engineers how to do that.
> What is your release schedule?
Irrelevant. It's done when it's done unless someone's paying.