Sense and Nonsense of a QA Team

After deciding to go to holidays from postnuke Qa i started thinking and reviewing the last months. The result is a little set of laws to follow in your open source projects (or postnuke) to make your Qaist Happy and get a effective Result.

§1: QA is NOT (only) a security auditor.

Keep in mind that web security is a special part of the development and in terms of the whole project some other factors are really more important. That does not mean that youre getting hints and notes on general security like for example:

Do not bundle Demo and Example files or any other unused code with your project.

If youre questioning the QA for a exact proof of this theory you might miss the point of a QA Team a bit: Its not the job of the qa Team to develop exploits for the products, but to give some advisory where possbly these could be.

The results of ignorance regarding such hints fro your qa team might be this one:

http://news.postnuke.com/index.php?name=News&file=article&sid=2747

§2 QA Team is not a general Education Team

It must be sure that every one commiting to a projects CVS knows the language and kind of software he or she is commiting to. Basic principles like for example: Why are undefined variables bad and lead to quality problems. Or why do i need to cast variables or check the contents of them must be knowhow of everyone participating. If its not these people should not commit directly to cvs, but have all their code reviewed by someone who gets very anal about every line of it.

Reference: All PNSA's with regards to „missing input validation“.

§3 Do not discuss with QA

Its alwas possible to discuss about the found issues by the QA team, but its not a good habbit to look for argumentation against it. Everyone knows how hard it is to be told whats wrong with the own code, especially when the list is starting with very basic things and contains some very bad mistakes. If youre ignoring QA reports or postpone themto another version of the software youre missing the point. The worst arguments against QA work in Open Source Projects are:

• I am a privateer and not a professional programmer, so i dont like to work this way (dont code for the public tehn)

• error_reporting mustbe configured NOT to show errors, then everything is ok

• We will fix that in another Version

With discussing with the Qa Team members youre wasting your own time and QA's. Accept the bug reports filed and fix them away.

§4 Specs

Specs, in written form, are a very basic thing in softwaredevelopment: They make things easy and controllable, its just defined where the dev team is talking about. If you like to have specific bug reports that relate to actual development, write Specs. The QA Team is not the one to write specs, except a test plan, where the Qaists define what has to be tested and how. The specs on the tasks that the software has to perform, can be easily written in rfc style format. Btw: All basic technologies have been written as rfc and advanced programmers tend to read those to know how the net is working. Its a real good source of knowledge when youre working with web software.

Dont blame the qa if youre missunderstanding Software Development basically and didnt write specs before you started coding. Its your Job and not the Qas. Youre just missing a point about effective software development when youre working without specs: Its not possible. That is not implying that specs cant change .. they can every day, but that is a abolute different thing.