Right and Wrong Ways of Software QA...

http://motherboard.vice.com/read/how-is-critical-life-or-death-software-tested

There are all sorts of different methodologies for doing this, but fundamentally, there are two ways to get stuff done in software engineering.

The right way  is to have a well-defined process that looks after everything. Essentially, the whole process of software engineering becomes software manufacturing (I wonder when that will become a buzzword...).

One right way is test-driven development. Write the automated test first, fulfill the requirement, then refactor the code. This ensures everything is always going to be on track, down to the most specific requirement. Software QA teams also necessary as it gets bigger.

The wrong way, but by far the most common way, is far less rigorous and prone to human error. It is to rely on human conditions like talent, intelligence, creativity, tenacity, work environment, or as Boeing did, to put its engineers on the first plane running their code.

 I call this way wrong because it is not stable. The most intelligent human beings are still fallible and prone to human error. For this reason, everybody is always trying to systematize everything, on every level.

And given time, what was once laborious will become automated. People used to have to write machine code. Then there was assembly. Then compilers wrote the assembly and humans wrote the C, then humans wrote the Java and virtual machine did the translation. (Sidethought. How far will this go? How far can it go?)

But to get results now, successful software companies employ all of these. Without good brains, the system may not be implemented or created. Without the system, good brains are wasted.