Its not Apple fault you believed its lies. Any company its looking for profit.
Apple's Mistake
281–285 of 285 posts
Re: Apple's Mistake
#282Earlier quoted context omitted.
The worst? Data Loss, or corruption, which is worse than "not working". Likewise, more likely it could just not work well, be buggy and require several updates to get it right, burning out your team's (or your company's) image with the customer. Before you deployed your fix, it's whoever changed the protocol at fault. After that, it's you that can't fix it. Again, not justifing it taking ages, just saying there's nev…
There wasn't any data. It did X with the external network. The worst case was that it maxes out the connection and burns through bandwidth. But that's something that can be monitored. The customer would have rather had something working with the network, than something broken with the network. In that particular circumstance, there's always an excuse to skip QA. IMHO.
there's always an excuse to skip QA. IMHO.
No, there isn't!
Re: Apple's Mistake
#283Earlier quoted context omitted.
I've always been treated well by QA. I'm sure there are problem QA departments out there but I doubt they are the rule. It's amazing to me that the parent got down moded for supporting the task of QA.
QA is awesome. I think people are responding to the suggestion that in general developers will subconsciously protect their ego by willfully ignoring flaws in their own software. That is just tremendously offensive to any real hacker, and if it were true the world of software would be a pale shadow of what it is today.
I don't think it's a slam on developers - I've hit and played outfield, and I know what each side feels like. It's not that developers wants to ship bad software, but haven't you ever avoided running a test because you're afraid of opening a can of worms? QA wants to open that can. There's a perverse glee in seeing all the worms get out.
When a new bug is found (a good one, not BS indentation) then QA has a justifiable joy in finding it before it got to the customer. The developer may also be devoted to quality, but doesn't your heart sink a little when you see a new bug? Overall you both want to ship good product, but your minute-to-minute motivations are just different.
Re: Apple's Mistake
#284A customer recently asked me to look into a program that used to run in 5 minutes but now took 1 to 4 hours. It's used by thousands of people all over the world all day long. It iterated through an array doing 3 SQL SELECTs against non-indexed files for each element. There used to be about 50 elements in the array; now there were more than 5000. I rewrote the whole thing in one day to do a total of 4 SELECTs and run…
What kind of insane person indents at 5 spaces. I get 2, 4, 8, but 5 is beyond me.
Re: Apple's Mistake
#285Earlier quoted context omitted.
You mean like functional tests, end-to-end integration tests, and view tests? No developer should limit themselves to unit tests.
Bullshit, its attitudes like this that lead to crap software. Developers should work with QA to find the bugs, they're not "QA's bugs" they're OUR Bugs, we're a team, right? When you change a component you should also be able to write a simple manual test to prove the functionality works you should also perform this test yourself. As an optional if the QA people are good then describe what else might be effected by t…
I'm really unsure of where your attitude here is coming from.
At ThoughtWorks we work with QAs constantly. It's a great relationship. There's no such thing as "QA's bugs".