Developing A Quality Assurance Framework For An Agile Environment

The essence of Quality Assurance in development or project management is primarily to ensure that requirements from business sponsors are delivered as defined on time and to budget. Hence, Quality Assurance implies the function of software quality, that assures that the standards, processes and procedures are appropriate for the project and are correctly implemented. Naturally, the need for Quality Assurance procedures could be as basic as having a rich automated regression test suite or defining an entire test/QA process that compliments development approaches like the Test Driven, Waterfall and SCRUM development methodologies.

In many environments around the world, which are naturally fast paced and agile, the approach has always been to have an idea (requirement), simply code/develop it and subsequently go live. New ideas are further developed or present ideas are enhanced (new features), they are coded and pushed live. This cycle is usually continuous. The cycle (as in many agile fast paced environments) leaves little room for detailed requirements analysis documentation, formal reviews, quality assurance, control or software testing. The end result is usually a back log of bugs (usually detected by users and most expensive to fix) or poor quality software.

The major challenge in reconciling an agile environment to a quality assurance framework is that ideally, the present process works. It works in the sense that it delivers what the business sponsors want (never mind that the process leads to a backlog of bugs and an unmanageable bug life cycle or that its implementation is inefficient in relation to time and budget), though this is not always true with reference to time and budget constrained projects. The second challenge is that, since these processes are in constant use for business features that have deadlines, attempting to reconcile QA to the present practices would imply slowing the team's pace in delivering features or projects. Nobody likes to be blamed for the late delivery of a project.

Reconciling an agile environment to a Quality Assurance framework requires a comprehensive assimilation of the product or service specification of the company, the development methodology in use , the approach to development and the timescale objectives (i.e seeing the bigger picture of the entire project, product or service). This involves planning every little bit along the way. Hence, the first and most important step in reconciling any agile approach to efficient quality assurance procedures is to strategise, this explains the need for a test strategy document.

The primary objective of strategising is to have a detailed and well defined road map indicating where we are going with regards to the quality overview of the software and also how these metrics would be achieved. It would be a road map that guides in ensuring that the overall primary objective of Quality Assurance ensures that the standards, processes and procedures are appropriate for the project and are correctly implemented.

The test strategy document would ideally contain all the quality assurance phases or testing realities, risks and expectations in the given environment. The beauty of this is that, test strategies are merely a proposal by QA to inject best practices into an already existing development methodology, and hence, require the approval and sign off of a project manager (or in practice the head of development team). By signing off a test strategy document, it is assumed that the project manager is able to embrace the reality of the imminent changes that are bound to be encountered while implementing QA procedures.

In conclusion, given the task of managing the quality assurance aspect of an organisation or a given project, your best bet is to immediately commence working on a test strategy document with the intention of getting it signed off by your line manager for subsequent implementation. And who says a test strategy document cannot contain a detailed requirements analysis of your own interpretation?