This is the fifth article in a series on optimising project delivery in an agency environment. I have covered fostering positive conflict, adapting the resourcing model and blockers. Last time I wrote about the principle of feeling the pain. In this article I am going to look at how approaches to QA, more commonly used in traditional agile orientated environments, can increase quality and profit margin.
The Third Role
Throughout these articles I have used the term 'makers' to refer to developers, designers and other creatives and the term 'specifiers' to refer to product owners, account managers or any other form of business stakeholders. In this article we will see that QA experts and testers are a mixture of both and why, for certain roles, this can be OK.
Testers fall into a third role which sits alongside the conflicting roles of 'specifier' and 'maker'. We shall call these people 'critics'. The responsibility of critics is to look at an output and, if necessary, require an additional output. QA experts are unique in that they are generally pure critics and nothing else. As teams develop then both specifiers and makers are encouraged to also be critics of both their own work and those around them. The value of dedicated critics is that they will be able to see issues that those responsible for creating the environment under criticism will not be capable of seeing because they are too close to it.
How the 'Critic' is used Traditionally
In a traditional waterfall environment then these dedicated critics tend to get involved at the end of the life-cycle and they will then be responsible for testing the delivered product end to end to look for software bugs and situations where the software contradicts the specification. This is traditionally done by following a variety of, specification based, test plans alongside exploratory testing.
The traditional approach has many disadvantages. The most obvious of these is that the testing is not targeted. As product work is reworked this creates notable inefficiencies in performing detailed testing over and over again without a direct connection between what has tested and what has changed then it is not possible to focus on higher risk areas.
The biggest, and often overlooked, disadvantage however is that testing this way is late. This is a key principle in a good evolved agile workflow. To minimise cost and maximise quality it is essential to identify bugs as early as possible in the development life-cycle. This is the principle behind Test Driven Development.
The key fault here is in the view of that the critic represents. The critic is looked at within the project as verifying that a given product is as specified. There is also an unspoken expectation that everything is fine. This is incorrect and failure should be the default expectation rather than success to enable more accurate planning.
How to use the 'Critic' in the Life-cycle
To maximise the quality of the product and minimise the cost of delivery the critic role is essential at three key phases of the development life-cycle.
Planning and Specification
Involving the critics at specification time is extremely beneficial. While a Specifier will have a key view of what they want to see delivered the Critic will be able to see past the desire of the Specifier and the technical details that the Makers are interested in to pick out the 'what if...' cases. These cases can be used to form part of the specification itself and form the heart of Business Driven Development techniques.
Test Driven development techniques can go a long way to increase the quality of code that developers produce but, at a slightly higher level, it is important that a developers work can be criticised independently. XP techniques like pairing or code review aid this from a technical point of view but not from the QA perspective, where the product not the tools used are being looked at.
If the QA department finds a bug in a piece of work that a developer did 2 weeks ago then, once the bug is reported, the developer will then have to track down the bug themselves, locate a solution to the problem and fix it over an extended period of time. The original developer may not even be available. The quicker that a bug is identified the less time it will take for the developer to be able to isolate the area where the issue lies. The next logical step, once this reality is accepted, is that if the work is actually critiqued separately after the development work is complete then not only is the location of the fault quickly evident but the failing change can be isolated until such a time as it is fixed, ensuring that a viable stream of quality, deliverable product is maintained.
Traditional end to end and exploratory testing by the critic roles still has a definite place. Unexpected issues can still slip through testing earlier in the life-cycle but it will happen far less frequently with earlier stage testing implemented.
Planning 'Critic' time
The earlier in the life-cycle that the critics of a project become involved the easier it is to predict the time that a piece of work will take both from a creative perspective and the investment spent on critic roles themselves.
In the same way 'Failing to plan is planning to fail', 'If you plan for failure you can only succeed'.
In my next article in the series 'Optimising Project Delivery' I'll be looking, in the simplest possible terms, at how essential the process of enabling change is for the ongoing health and profitability of an agency. In my final article in this series I will deal with, what I believe should always be both the beginning and the end, the retrospective.