I am of the opinion that the local QAEs (Quality Assurance Engineers) are doing a good job as compared to the developers. But they say, "Quality is a process and not a goal," indicating that there is always room for improvement.
This post identifies two very common issues with Quality Assurance and their causes.
Has your QA team ever reported anything like "this feature is difficult to comprehend for novice users" or "it takes too much time to start the application?" The activity in the arena of better software is mostly related to testing only - the whole emphasis is on finding the sequence of inputs that make the application crash and that's it. We must understand the difference between mere testing and quality assurance and thus, in a Test Engineer (TE) and a Quality Assurance Engineer (QAE).
The problem partly has its roots in non-availability of vision/ specification documents. How can the QA team report performance issues if there was no such criteria /metric defined at the start of the project? Just how easy was it meant to be? Just how fast it was supposed to be? No document in the software development life cycle is as important as the feature specification document. The QA team needs to emphasize on the availability of this document before the first testing iteration begins.
The second problem lies in the us versus them attitude between QAEs and Software Engineers (SEs). Developers, in general, don't like to re-work on something. When they are told of bugs in their software, the majority tries to shun the responsibility. Most of the time the response is, "But it works on my machine." Also, the developer gets annoyed at the very poor description of the problem. A QAE makes the problem worse by creating a mockery out of this thing. The QA people can help in changing the attitudes by being courteous and by providing a correct description of the problem as well as sufficient details for reproducing the bug.
The two problems (testing instead of quality assurance and us-versus-them attitude) have a single, common cause. There is always a knowledge gap between QAEs and Software Engineers (SEs). Certainly, a QAE isn't required to know how a particular feature is implemented but knowing internals won't hurt either. Most of the places don't require QA people to work extra hours (as compared to developers who invariably do late sittings and work more than 40 hours a week). I would advise the QA personnel to try to build expertise (in their spare time) on at the least one programming language - VB, C# and Java are very good choices. And more importantly, try to learn the inner working of Operating Systems and Application Servers. This way, you can tell what bugs/ issues are with the software you are testing and which problems are due to improper configuration of databases, OS and other third party tools. With every project try out newer ideas such as automated testing, unit testing frameworks, etc.
An organization that practices self-improvement is difficult to beat. QA folks can help by minimizing the knowledge gap that exists between them and the developers.
A fool with a tool is still a fool.
(Grady Booch)
No comments:
Post a Comment