NYCPHP Meetup

[David Krings]

On 4/3/2011 10:01 AM, Donald J. Organ IV wrote:
> So what your saying is after your QS person finds issues, they go into the
> code/design and fix it themselves??

Been there, done that and was important, because shortly after the developers 
got laid off and knowing how to fix things was very helpful in supporting the 
product. But QA people must have sufficient development skills, at least 
enough to know when the developers are just being lazy. How many times have I 
heard "this will take three weeks" just to have it get done in half an hour 
after insisting on a fix (because I knew it wasn't rocket science to fix it). 
Or the whiny "this cannot be done in X" with X being any programming language 
used for a project. Of course it can be done! The dev was just too lazy to 
google for the code snippet or look at the other places in the app where the 
exact same functionality exists and works flawlessly. Many bright minds 
pointed out in the past that QA must own the design and requirements, because 
they are the ones who know best when it is stupid, won't work, or isn't worth 
the effort.

I'm not knocking the developers in general. Many I work and worked with have 
excellent skills and a superb understanding of the business, but - 
understandably so - are not keen on tedious work such as bug fixing, writing 
tech docs, or analyzing requirements. Some tend to code whatever they are 
asked to code, even if they know it is dumb. That is why smart businesses 
outsource coding work to Russia, Hungary or Bulgaria. Sure, the developers 
there are not as cheap as the ones in India, but they tend to ask the tough 
questions.

As for QA, QA is nothing more than a mirror developers have to look into.

David