On Tue, May 29, 2012 at 11:12 AM, Ian Walls <koha.sekjal@gmail.com> wrote:

To me, the role of QA is to be highly conservative.  The QA team needs to look at a piece of incoming code, and not only judge it on how well it does it's intended purpose, but how it affects all the other code and workflows that surround it.  The folks creating and signing off on code are often looking to answer the question "does it work?".  I approach the QA process asking the question "what does it break?". 

Often times, the answer is "nothing", and we get a great new feature in our codebase. But sometimes the patch changes a core function or variable declaration in a way that isn't spotted, and only applicable on certain use cases.  Or a new dependency is added that conflicts with something existing.  Or a security hole is introduced under some conditions.  A person asking "does this work?" isn't necessarily going to spot these things in their testing; our code is very complex.  I'm sure we can all recall cases where piece of code was committed to do one thing, and then required a followup because it broke something else under specific circumstances.

I strongly believe that having a 'neutral party' to do the QA work is essential to keeping our codebase strong and healthy.  We need the fresh set of eyes, the different perspective, the alternate use case.  We need someone asking "what does it break?", and I don't think the folks who've been asking the question "does it work?" are the best suited to that task.