Comment On Psychic Code

Like snakes and mongooses , QA and developers are natural enemies. Through an unfortunate series of events, developer Bridget found herself working on a QA team. She was deep in enemy territory, and not full prepared for the rigors of QA, so she focused on her core developer skills. She helped the testers automate things. [expand full text]
« PrevPage 1 | Page 2Next »

Re: Psychic Code

2012-11-07 14:50 • by bgodot
Like Nazgûl and Hobbits.

Re: Psychic Code

2012-11-07 15:32 • by JoeT (unregistered)
394402 in reply to 394352
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?".

Re: Psychic Code

2012-11-07 15:44 • by C-Derb (unregistered)
394403 in reply to 394395
Hasse:
Any person that want to call himself a developer/programmer should work 2 years:

1: as a system administrator
2: in QA
3: as a maintenance programmer
You can't simply blame developers for not understanding the QA/Sys Admin/Maint Programmer point of view. This same logic needs to be applied to all 4 groups you have mentioned.

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." )

Re: Psychic Code

2012-11-07 15:56 • by Tom (unregistered)
394404 in reply to 394352
atk:
Like snakes and mongooses , QA and developers are natural enemies.


I've heard that bu11$#!t before, and it's still BS - even with the possibility that it's here only for humor.

[rant snipped for brevity]

BTW, I'm a developer.


And an awfully high-strung one, it seems. Try decaf.

Captcha: persto. "Persto! My self-aware regex-based script wroks!"

Re: Psychic Code

2012-11-07 15:58 • by C-Derb (unregistered)
394405 in reply to 394402
JoeT:

Bug 1: "The parser accepts both lowercase and uppercase commands. The [competing product] rejects lowercase. Please reject lowercase commands."
This is a perfect example of the seeds of animosity between QA and developer.

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."

Re: Psychic Code

2012-11-07 15:58 • by cdosrun
394406 in reply to 394402
JoeT:
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.


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".

Re: Psychic Code

2012-11-07 16:03 • by Tom (unregistered)
394407 in reply to 394359
[quote user="RichP"]Shouldn't the plural of "mongoose" be "mongeese"?[/quote

And a baby mongoose would then be a "mongosling?"

Re: Psychic Code

2012-11-07 16:12 • by Quincy (unregistered)
394408 in reply to 394405
C-Derb:
JoeT:

Bug 1: "The parser accepts both lowercase and uppercase commands. The [competing product] rejects lowercase. Please reject lowercase commands."
I have worked with QA people who find trivial issues like this that were never defined in the requirements
Maybe there's a hint there.

Close the bug report as "invalid bug submission: missing requirement ID"

Re: Psychic Code

2012-11-07 16:38 • by C-Derb (unregistered)
394409 in reply to 394408
Quincy:
C-Derb:
JoeT:

Bug 1: "The parser accepts both lowercase and uppercase commands. The [competing product] rejects lowercase. Please reject lowercase commands."
I have worked with QA people who find trivial issues like this that were never defined in the requirements
Maybe there's a hint there.

Close the bug report as "invalid bug submission: missing requirement ID"
You've got a point, as long as you are working somewhere that wants to use a software system to actually log bugs. Right now, the bugs get logged one of three ways: 1) the QA person interrupting my work with "Hey, this is a bug...", or 2)an IM interrupting my work with "Hey, this is a bug..." or 3)an email with "Hey, this is a bug..." immediately followed by 1) or 2) asking "did you get my email?"

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.

Re: Psychic Code

2012-11-07 16:39 • by Vlad Patryshev (unregistered)
Uroboros. "The script apparently reads itself to find out what it’s doing."

Love it.

Re: Psychic Code

2012-11-07 16:45 • by C-Derb (unregistered)
394411 in reply to 394406
cdosrun:

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".

Exactly.

Re: Psychic Code

2012-11-07 16:48 • by Hasse (unregistered)
394412 in reply to 394403
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

Re: Psychic Code

2012-11-07 16:57 • by realmerlyn
394413 in reply to 394349
gar37bic:

This bootstrap process gave me to think about creation and evolution, in the following manner. It's one thing to create something out of whole cloth - a butterfly, for instance. But it's an entirely different and much more interesting thing to create something by merely defining a set of rules by which an entire universe constructs itself, that evolves resulting in, of course, (and among other 'things'), us. :) It's sort of like aiming a gun by growing a tree to support the barrel. So since then I have never seen any essential conflict between this sort of original 'creation' (by whatever means) and 'evolution'.


Step 1: ponder that
Step 2: ???
Step 3: LISP!

Re: Psychic Code

2012-11-07 17:40 • by Simon (unregistered)
394414 in reply to 394373
Ralph:
atk:
If the product is lacking in quality, ... customers won't buy it
OK, I know I'm evaluating one half of an "or", but clearly this has a vanishingly small probability and therefore should be optimized out. Consider:

Microsoft
Oracle
Adobe
SAP
HP
...
Members of Congress
...


Why are the latter on the list? Traditionally, politicians are of excellent quality and value for money - for those who actually buy them.

Re: Psychic Code

2012-11-07 17:56 • by Silverhill
394415 in reply to 394391
Herp:
Yes, some bad code is so bad that it is not salvageable.
Or, as Sam Goldwyn (of MGM) put it, "You can't polish a turd."


JoeT:
Never mind that [QA people] provide no way to reproduce.
Would that that were so. If they couldn't reproduce, we wouldn't have to deal with so many of them!

Re: Psychic Code

2012-11-07 17:58 • by Quality Porpoise (unregistered)
My favorite: /...[a-zA-Z].../i

Re: Psychic Code

2012-11-07 18:05 • by chubertdev
394417 in reply to 394415
Silverhill:
Or, as Sam Goldwyn (of MGM) put it, "You can't polish a turd."


Wasn't that proven wrong by the Dodge Neon SRT-4?

Re: Psychic Code

2012-11-07 18:24 • by Jazz (unregistered)
394419 in reply to 394352
atk:
Like snakes and mongooses , QA and developers are natural enemies.

If the product is lacking in quality, either customers won't buy it, or they'll demand support. If they don't buy it, the company doesn't make money and nobody gets paid. If customers demand support, that costs the company money. If it costs the company too much money, and support is equally or more expensive than profits, the company loses money and nobody gets paid.
...
Whether developers, professors, or anyone else realize it or not, this is the same goal as development has - to make the company money and get paid.


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.

atk:
All quality and all bugs come from development. Development is fully responsible for the quality (or lack thereof) in a product. Nobody else writes the code. Nobody else creates the bugs. (For the pedants, product management is responsible for requesting a product that customers will want, but they're still not the ones that do or do not build in quality.)


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.

Re: Psychic Code

2012-11-07 18:55 • by TheCPUWizard
394421 in reply to 394408
Quincy:
C-Derb:
JoeT:

Bug 1: "The parser accepts both lowercase and uppercase commands. The [competing product] rejects lowercase. Please reject lowercase commands."
I have worked with QA people who find trivial issues like this that were never defined in the requirements
Maybe there's a hint there.

Close the bug report as "invalid bug submission: missing requirement ID"


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.

Re: Psychic Code

2012-11-07 18:56 • by Meep (unregistered)
394422 in reply to 394353
Bubbles:
What's with the dev/QA hate? I love our QA team, they're very good and they help us devs a ton. And we go out for beers together too.


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.

Re: Psychic Code

2012-11-07 21:08 • by atk (unregistered)
394423 in reply to 394419
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.


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.

Re: Psychic Code

2012-11-07 21:16 • by atk (unregistered)
394424 in reply to 394423
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.


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.

Re: Psychic Code

2012-11-07 21:20 • by atk (unregistered)
394425 in reply to 394404
Please look up the meanings of "high strung" and "annoyed (at a common problem) ". You'll find that there's a difference.

Re: Psychic Code

2012-11-07 21:21 • by atk (unregistered)
394426 in reply to 394358
[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.

Re: Psychic Code

2012-11-08 01:23 • by da Doctah
394428 in reply to 394407
[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.

Re: Psychic Code

2012-11-08 01:25 • by da Doctah
394429 in reply to 394409
C-Derb:
or 3)an email with "Hey, this is a bug..." immediately followed by 1) or 2) asking "did you get my email?"


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.

Re: Psychic Code

2012-11-08 04:30 • by jarfil (unregistered)
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)

Re: Psychic Code

2012-11-08 06:14 • by Swedish tard (unregistered)
394431 in reply to 394423
atk:
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.


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.


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.

Re: Psychic Code

2012-11-08 07:29 • by Atk (unregistered)
394433 in reply to 394431
[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?

Re: Psychic Code

2012-11-08 07:51 • by Swedish tard (unregistered)
394434 in reply to 394433
Atk:

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?


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.

Re: Psychic Code

2012-11-08 11:15 • by fa2k (unregistered)
I think it should be mongii, in analogy with virii and walrii.

Re: Psychic Code

2012-11-08 13:05 • by RegAxel (unregistered)
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

\) // )
)?/gi

Re: Psychic Code

2012-11-08 13:20 • by Paul Neumann (unregistered)
394519 in reply to 394352
atk:
Like snakes and mongooses , QA and developers are natural enemies.


I've heard that bu11$#!t before, and it's still BS - even with the possibility that it's here only for humor. <snip reason="If you really care about the original, click the &quot;394352&quot; link above" /> -- to make the company money and get paid.

BTW, I'm a developer.
This here is tdwtf. That level of rationale and professionalism will not be tolerated!

Re: Psychic Code

2012-11-08 13:22 • by Slapout (unregistered)
394520 in reply to 394341
dkackman:
"Like snakes and mongooses , QA and developers are natural enemies."

Best quote ever. Putting on my whiteboard


Developers vs QA
Developers vs DBAs
Developers vs Network Ops
Developers vs Management
Developers vs Users

We're surrounded!!

Re: Psychic Code

2012-11-08 15:54 • by Dann of Thursday (unregistered)
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.

Re: Psychic Code

2012-11-08 17:57 • by atk (unregistered)
394551 in reply to 394434
Swedish tard:


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.


Again, we are in full agreement :)

Re: Psychic Code

2012-11-08 18:00 • by atk (unregistered)
394552 in reply to 394536
Dann of Thursday:
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.


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.

Re: Psychic Code

2012-11-08 18:42 • by ekolis
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.

Re: Psychic Code

2012-11-08 18:45 • by Veldan (unregistered)
+1 for Invader Zim comments :D

Re: Psychic Code

2012-11-09 06:57 • by I'm an SDET, I look down on both sides (unregistered)
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.

Re: Psychic Code

2012-11-09 07:49 • by Tynam (unregistered)
394590 in reply to 394352
atk:
Like snakes and mongooses , QA and developers are natural enemies.


I've heard that bu11$#!t before, and it's still BS - even with the possibility that it's here only for humor. You'd expect to see attitudes like this from immature, fresh-out-of-school programmers. But sadly, we see it from many experienced developers, management, and even college professors. It's attitudes like this that create unnecessary tension between teams whose joint purpose is to deliver a product to market that people will buy.
...


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.)

Re: Psychic Code

2012-11-09 12:50 • by Your Mom (unregistered)
Wait, I'm a script?

Re: Psychic Code

2012-11-09 13:24 • by Trident (unregistered)
394614 in reply to 394351
Typical result of programmers from universities without practical knowledge.

Re: Psychic Code

2012-11-09 16:43 • by Danny (unregistered)
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.

Re: Psychic Code

2012-11-09 17:51 • by justme (unregistered)
394628 in reply to 394409
C-Derb:
Quincy:
C-Derb:
JoeT:

Bug 1: "The parser accepts both lowercase and uppercase commands. The [competing product] rejects lowercase. Please reject lowercase commands."
I have worked with QA people who find trivial issues like this that were never defined in the requirements
Maybe there's a hint there.

Close the bug report as "invalid bug submission: missing requirement ID"
You've got a point, as long as you are working somewhere that wants to use a software system to actually log bugs. Right now, the bugs get logged one of three ways: 1) the QA person interrupting my work with "Hey, this is a bug...", or 2)an IM interrupting my work with "Hey, this is a bug..." or 3)an email with "Hey, this is a bug..." immediately followed by 1) or 2) asking "did you get my email?"

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.


No, QA is there for validation ( are we build what we need ) not verification ( are we building what we said we would )

Re: Psychic Code

2012-11-09 23:26 • by Seele (unregistered)
394631 in reply to 394366
Don't shoot Mongoo - it just makes them angry!
« PrevPage 1 | Page 2Next »

Add Comment