- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Like Nazgûl and Hobbits.
Admin
The trouble is, there are a lot of QA people who feel their only job is to fill their quota of bugs reported.
Never mind that the bug is silly. Never mind that they provide no way to reproduce. Never mind that the bug doesn't actually exist.
Three (real but simplified/censored) examples:
Bug 1: "The parser accepts both lowercase and uppercase commands. The [competing product] rejects lowercase. Please reject lowercase commands."
Bug 2: "When I run [well defined testcase] in my environment it crashes"
Bug 3: "When all of the servers are down, the testcases fail."
Sadly, we did fix bug 1. We never figured out bug 2; we never could figure out what "my environment" was. Not for want of asking; it clearly did crash, just never in front of anyone but the tester. Bug 3 eventually lead to the firing of the sysadmin staff; I don't care what you think of me, but I refuse to try to make my software run properly on a machine that is powered down.
And QA should at least be able to run the debugging step of "is your computer plugged in?".
Admin
Take the app I'm working on for example. When our QA person comes up with test plans that rely on changeable data in our DEV environment, why should I get push back when I point out that the data will be different in the TEST environment and those tests probably won't pass? (Ie. I do a search for "xyz" and get 45 results back in DEV. Not gonna happen in TEST, so don't rely on the number 45. "Why?" "Because the data in TEST is not the same as the data in DEV." "Why?" "Because...ah forget it, your test looks great." )
Admin
And an awfully high-strung one, it seems. Try decaf.
Captcha: persto. "Persto! My self-aware regex-based script wroks!"
Admin
I have worked with QA people who find trivial issues like this that were never defined in the requirements, but they log them as bugs because it violates their own personal preferences of how they believe the application should work.
Just this week in our planning meeting for our upcoming release, the product manager has added a task to have the application retain the form values after postback. I smiled and shook my head. They asked what I was smiling about. I told them, "The application was working exactly that way initially, but QA-person [since retired] demanded that the form be cleared on postback. I protested and lost. Should be an easy fix."
Admin
Want another?
Defect: Product name "Compoundword" should be "Compound word".
Really? This is an established product, and no one has ever mentioned that we are changing the name... are you sure? If the requirements change, why didn't they tell us? Fine, whatever
The next day-
Defect: Product name "Compound word" should be "Compound Word".
Admin
[quote user="RichP"]Shouldn't the plural of "mongoose" be "mongeese"?[/quote
And a baby mongoose would then be a "mongosling?"
Admin
Close the bug report as "invalid bug submission: missing requirement ID"
Admin
Either way though, once the conversation moves to "this is a bug"/"No it isn't", the bad blood starts to develop. Bottom line: QA is there to test that software meets requirements. When QA tries to define requirements, I get annoyed.
Admin
Uroboros. "The script apparently reads itself to find out what it’s doing."
Love it.
Admin
Admin
Sortof agree with you, but I'm convinced you QA person will never make it to Developer as he sees not to understand basic Computer Science
Admin
Step 1: ponder that Step 2: ??? Step 3: LISP!
Admin
Why are the latter on the list? Traditionally, politicians are of excellent quality and value for money - for those who actually buy them.
Admin
Admin
My favorite: /...[a-zA-Z].../i
Admin
Wasn't that proven wrong by the Dodge Neon SRT-4?
Admin
I certainly don't think that QA and developers are natural enemies, but I reject categorically the notion that my goal as a developer should be to raise corporate revenue by ensuring product quality. I don't think your model holds. It breaks down because the feedback from customer to developer is not instantaneous.
If the product is lacking in quality and customers don't buy it, it will take at least a few weeks before the impact of that revenue loss is felt. If the product is lacking in quality and the customers demand support, it will take months before management even notices the demands, let alone spends any money on providing that support. And even then it's a fair bet that management just decides to not spend the money to provide support at all, and they leave the customers out in the cold. And if the cost of ongoing support is truly greater than the revenue, it may take a year or more before that discrepancy sinks the company entirely.
Meanwhile, I already got paid for the code I turned in at the end of my two-week pay period, before any of these issues have been noticed. My goal is to get paid. I got paid for my work regardless of the quality of the end product.
Utter bollocks. Development controls only one aspect of quality, which is number of bugs created. Management (and in many companies, Sales & Marketing) controls everything else, including number of bugs fixed. In particular:
Development doesn't control the feature set of the product. When a manager says, "we need to have X, Y, and Z in our app," then it's development's job to put X, Y, and Z in the app. It's management's job to know, and care, whether customers actually want X, Y, and Z or whether they want A, B, and C instead. If that isn't what customers turn out to want, it's not like I'm allowed to say "no" and just go code up A, B, and C. I would be fired for that. So that mismatch between what the customer wanted and what we gave them is management's fault. (Dammit Jim, I'm a developer, not a market researcher.)
Development doesn't control the time frame. When a manager says "ship it on Tuesday, or else," we ship it on Tuesday. It's management's job to take factors like possible brand image issues into account when making these decisions (and any half-decent business school should have taught them this). If the product wasn't ready to go, it's not like I'm allowed to say "no" and keep fixing bugs on Wednesday and Thursday and just arbitrarily run over deadline. Management decided to ship it before it was done; if that leads to issues with quality, those issues are the fault of the one who made the decision, i.e. management.
So at the end of the day, why should I care about the customer's perception of quality? If that customer finds a product to have a quality issue, nine times out of ten, it's because management insisted on something that development told them twice was a bad plan. That customer's beef doesn't lessen the pay that we already received weeks ago for doing the work, nor is it anything we could have changed since management overruled our objections.
TL;DR: I'm not about to lie awake at night biting my nails over something that I can't control and that doesn't affect me, and I'm kind of incredulous that you believe I should.
Admin
Close, but not quite...The bug should be active and target the requirements document. If something is ambiguous, then it will create a never ending list of support issues.
Update the requirements to either allow [no coding change] or reject [coding change] lowercase, and you are golden for ever.
Admin
Likewise. I like the QA folks and the SMEs, too. I like the thought that I'm not just writing code, but producing something that has real world application.
Admin
Clearly we have different definitions of "development". I use the "development team, including its management structure" definition, and you are using "individual developers". Oh, and please go back and read the "for the pedants" sentence immediately after the sentence you quoted.
No matter what you say, it remains true that development is what places the bugs in the code, because it is development that creates the code. Equally true, development places the quality in the code, because it is development that creates (or fixes) the code.
Admin
I left out free software, so the model doesn't hold for everything. But in "for profit" companies, where development is paid by the company, and the company makes its money by selling software, the overall joint purpose is to sell the software.
You accurately state that there are timeframes through which the impact of lack of quality is felt. I did not say anything about timeframes in my original post, as it is not directly pertinent to the point - animosity between the teams, simply because they are different teams, is counter productive.
The examples people provided earlier in this thread, meant to justify distain for QE, are not examples of what's wrong with QE. They're examples of less effective QE persons, difficult to explain/diagnose issues, and communications problems. As in any specialty, some people in QE will be great, most will be average, and some will be muffinheads. Cherry picking stories about a couple muffinheads is a reasonable way to classify a whole group.
Admin
Please look up the meanings of "high strung" and "annoyed (at a common problem) ". You'll find that there's a difference.
Admin
[quote user="dkallen"][quote user="atk"][quote] ...this is the same goal as development has - to take the company's money and get laid. [/quote]
[/quote]
Glad to see you got one thing right.
Admin
[quote user="Tom"][quote user="RichP"]Shouldn't the plural of "mongoose" be "mongeese"?[/quote
And a baby mongoose would then be a "mongosling?"[/quote]
A female peacock is called a "peahen". The babies are "peachicks". It is not recorded whether they are fond of chickpeas.
Admin
I contend that the only valid response to such a message is either "yes" or "no", with no additional information, followed by severing all further contact.
Admin
Developers think how some code may solve problems. QA think of ways how some code may create problems.
You should NEVER ever let anybody with a QA hat anywhere near writing code.
I've been there, I've done that... and it ain't pretty (also if I hadn't deleted it shortly after, it may pretty well have ended up on this site)
Admin
I find it that it's my responsibility as a developer to give management and other interrested parties information about the current quailty of the product, but it's their responsibility to decide when the quality is good enough. They are, after all, the ones that deal with the money aspect. Code does not need to be perfect to make money, and that is what companies does, makes money... Spending to much time on perfecting software will make it so expensive that noone will buy it, and you lose money instead. I'm not particularly happy about it, since I want my code perfect. But as any other craftsmanship, you need to know what is essential and must be working correctly, and what needs less attention. If you cant differentiate those two, you are not a good developer.
Admin
[quote user="Swedish tard"][quote user="atk"]
I find it that it's my responsibility as a developer to give management and other interrested parties information about the current quailty of the product, but it's their responsibility to decide when the quality is good enough. They are, after all, the ones that deal with the money aspect. Code does not need to be perfect to make money, and that is what companies does, makes money... Spending to much time on perfecting software will make it so expensive that noone will buy it, and you lose money instead. I'm not particularly happy about it, since I want my code peerfect But as any other craftsmanship, you need to know what is essential and must be working correctly, and what needs less attention. If you cant differentiate those two, you are not a good developer.[/quote]
I entirely agree with the above statement. While my original rant was focused on the relationship between dev amd qa, it is absolutely true that there is a 'good enough' point for any project.
NB: seriously? The captcha cares about caps on the first letter, when many phones and tablets auto-capitalize it?
Admin
Yeah, I love Q/A as well. They help me improve by pointing out what I get wrong. I've noticed that a lot of developers skip testing their on stuff, since there is another testing instance though. That's not how to use Q/A. As a developer you should strive for a level of quality where Q/A really just needs to rubberstamp your stuff and send it off. That scenario will never happen though, since all code has problems. And a decent Q/A will find even the most obscure things.
And as with any other entity that interfaces with developers, there is the problem with different languages (even if they are both using english). Q/A may say something that a developer interprets in way that sounds ridiculus to a developer, but when digging a bit more it is a very reasonable feedback. Just because something isnt in the requirement doesnt mean it's wrong. Just a sign that your requirements need work.
Admin
I think it should be mongii, in analogy with virii and walrii.
Admin
I tried to break it down...
/^ [\s]* // any whitespace (?: // non-capturing (P.+?) // P+character at least once/zero or one [\s]+ // at least one whitespace (?: // non-capturing [_] // one underscore [\s]* // any whitespace [\n\r]+ // newlines )? )? (F.+) // F+character at least once [\s]+ // at least one whitespace (?: // non-capturing [_] // _ [\s]* // any whitespace [\n\r]+ // at least one newline )? ( // capturing [a-zA-Z] // any series of letters [\w]{0,254} // by up to 254 word characters ) (?: // non-capturing [\s\n\r_]* // white space, newlines and/or underscores \( // ( (?: // non-capturing [\s\n\r_]* // white space, newlines and/or underscores ( // capturing [a-zA-Z] // any series of letters [\w]{0,254} // by up to 254 word characters ) [,]? // optional comma [\s]* // any whitespace )* // any of the pattern \) // ) )?/giAdmin
Admin
Developers vs QA Developers vs DBAs Developers vs Network Ops Developers vs Management Developers vs Users
We're surrounded!!
Admin
Apparently some of you work in magical fairylands where the QA team isn't entirely comprised of underqualified college dropouts that think they can make up requirements on the spot and then record bugs against these imaginary missing functionality. I have worked for a lot of clients and only one single one had a QA team that wasn't entirely worthless.
Anecdote time: I once received a defect that claimed that a list box wasn't populating correctly. I looked at the code, saw that it was a simple, easy-to-fix problem (and it wasn't my code!) and implemented a fix, returning the ticket to the QA tester. Ten minutes later they sent me AND my manager an !URGENT! email about how the bug wasn't fixed, with a screenshot attached.
The list box was clearly populated in the screenshot. I mean the damn thing was completely full. I briefly considered tendering my resignation rather than continuing to submit to such lunacy, but instead I opened the screenshot in MSPaint, added a huge red box around the relevant form item, and sent it back to the tester without any text. Bug closed, lesson learned.
Admin
Again, we are in full agreement :)
Admin
Sometimes these problems are caused by the QA team being composed of incompetents. Sometimes these problems are caused due to lack of good documentation from development. Sometimes these problems are caused by lack of development training QA on the product. Sometimes these problems are cause because dev makes one assumption and qa makes another (especially common in different cultures, as pointed out above).
Yes, I've worked with qa in these states. I've also worked with excellent QA teams that some people in Dev thought were incompetent due to communications problems.
Admin
Fun programmer drinking game: Take turns converting random GIF's to ASCII art using a tool built for such a purpose. Feed said ASCII art into a Perl interpreter. If no errors, take a drink.
Admin
+1 for Invader Zim comments :D
Admin
I've worked at companies with good dev teams and good QA teams. I've worked at companies with shit QA teams and shit dev teams. I've never seen a company with shit QA and good devs - most of the bitching here is a severe case of the Dunning-Kruger effect.
Admin
Exactly right. I think this attitude arises because if QA are doing their jobs right they tend to argue with, or demand things from, the dev team a lot. And we all get defensive when our code is criticised. But that doesn't make us enemies; we have the same goal. My sister tells me I'm wrong a lot too; she's still on my side.
(I argue with my dev lead frequently, and occasionally loudly. That's not a flaw; she was in charge of QA hiring and picked me for QA lead because she thought I could argue with her. Often these arguments end when she tells me I'm wrong and goes on to prove it... which is a sign we've both done our jobs right.)
Admin
Wait, I'm a script?
Admin
Typical result of programmers from universities without practical knowledge.
Admin
What, no Cornify this time? I clicked on damn near everything trying to find it, only to finally give up and check the source—much to my dismay.
Remy, you're such a choex.
Admin
No, QA is there for validation ( are we build what we need ) not verification ( are we building what we said we would )
Admin
Don't shoot Mongoo - it just makes them angry!