Software Quality
September 19, 2008 by Raj Sheelvant
IT management tends to define QA as being simply “testing”. As such, they often view QA as just bringing in some warm bodies to run some test scripts once the coding is all finished. There is actually far more to QA than just testing, and there is far more to testing than just running test scripts. This according to Baseline article Second Class Software Quality in Major IT Projects. Also read Bruce Webster’s blog on QA here. The articles also notes that if the organizational challenges to QA were simply lack of time and money, then they could be readily solved by simply allocating more time and money. However, there is a second, more intractable issue. Put simply, an IT engineer who works in QA has less professional status than one who works in actual coding. The old IT joke is that you conjugate the verb “to program” thusly: “I architect, you code, he or she tests.”
I think this is a huge problem with the waterfall methodology of software development. Hence newer and better software development like Agile software developement makes more sense. Testing is not an afterthought. It’s part of the development process itself. Its not ‘he or she’ that tests the application, but it’s more like ‘we architect, we code and we test’. Its a bad idea to create professional ‘status’ when QA is delegated to someone with lower status. Wouldn’t the ‘senior’ or smart developer be passionate and responsible enough to ‘bake’ quality into the product he or she develops? How can you call someone a good developer if they can’t make their code and architecture bullet proof to outliers and extreme cases?
QA is the collectively responsibility of everyone involved in the project including Project Manager. The Project Manager also needs to smartly allocate time in the project time line to do some systematic testing. This should happen not at the end of the development but regularly after the functionaly is built and integrated.
Popularity: 29% [?]
Related posts:
