The QA Trap
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.
There’s another variation on this trap that I’ve seen and that is when QA is over developmen — whether in actual reporting structure or pure political power within the organization. When this happens, QA is effectively driving the development process. Their schedule is imposed on the developers.
QA needs a build first thing Monday morning! Well, what if dev isn’t ready to give QA a build? Without equality between the departments or a capable arbiter, dev will be forced to overextend their resources (ie, work late hours or the weekends, resulting in lower morale and quality) or pass along an incomplete or buggy build to QA, thus wasting valuable time and possibly jeopardizing the schedule.
Another risk of having QA-over-Dev is that the development schedule may bloat to accommodate QA’s demands. When the schedule needs to be pulled in, management will be forced to cut features or testing time, neither of which results in a good, quality product.
The takeaway:
QA/QE and Development must be equals within the organization, preferably with a slight adversarial relationship.
Filed under: Editorial
Leave a Reply