Having Quality Assurance resources is truly beneficial to any company producing software. This applies to whether it will be consumed by internal or external customers. Your department’s credibility depends on delivering high quality products. You must keep in mind that your products must meet basic performance expectations, adhere to the original user requirements, not break any other installations or corrupt data, as well as many other criteria that the user will run into through heavy application use over time. Therefore, having an experienced team that is adept at teasing out even the hard to find issues is a serious benefit.
So how can such a noble endeavor go wrong? There are lots of reasons, but the most challenging to control is the effect that occurs when the QA department sits in the shadow of Development.
There is sometime a perception that the QA engineers are inferior technically to the developers. If this is the understanding in your organization, then QA will occupy a lesser position in the social structure. This mindset sets up an environment where development has a greater influence over the solitary QA engineer than is advisable. Take as an example, the constant task of adding new features to your product. Any product in active development (not in maintenance) is continually growing and evolving to attract and keep customers. Too many times however QA is kept out of the process until the last minute for a cursory check. If the environment is 'development-on top', QA will ask look to the engineers for explanations of how the new features are supposed to operate. This puts too much power in the hands of the developer.
The reason for establishing a separate QA resource is to create an environment where an unbiased party can operate the product as a normal user. If they have to take guidance from development as to how or what to test or if behavior is as expected you may as well reassign the resource and let the development team do the testing.
Developers for the most part want to deliver quality products, but they think like developers. QA is there to think like users - smart ones and not so smart ones. Many times QA will create defect tickets to the annoyance of development. You'll hear "what are they doing, no one would do that", "that’s not a bug" and things of this nature. If development can squash a bug or "advise" QA that their test is invalid or even influence the test plans that they create, the product will not be thoroughly tested.
In a subsequent entry to this monograph I'll make QA recommendations.
No comments:
Post a Comment