DTAP (Development, Test, Acceptance, Production) is a real waterfall concept, since it represents the types of environments that are used within a waterfall software development method. It does not argue there is just one D, one T, one A and one P, but it emphasizes that each stage in the waterfall method has its own demands on the environment.
DTAP is an anachronism in an Agile environment
This also endures in Agile development, but Agile does not exhibit one generic staging sequence that applies to all forms and shapes of Agile. In either method, your environment is one of the important, if not the most important, test tools and the requirements to it are directly derived from its use: (continuous) unit testing, functional testing, acceptance testing, performance testing or what have you. This variety of uses and derived requirements lead to the more appropriate term of Non-Production Environment, or NPE in short.
So how do we employ NPE’s in an Agile setting and why would DTAP not suffice? Let me take you through a typical (one of many!) enterprise Agile development setting.
The first activity that puts claims on the environment is ‘development/unit testing’. This is a private 'sandbox’ environment in which the developer, sometimes in collaboration with a tester, writes and tests code.
Ideally, all code is subject to Continuous Integration. In order to automatically test the integrated code is a second type of environment is needed: the 'team Integration’ environment. Both test activities so far are whitebox testing.
Within a sprint blackbox progression – mostly manual exploratory testing - and regression test - preferably automated - takes place with an acceptance character, this is a third environment.
The software now meets the DoD and is potentially shippable, or is it? It has yet to be integrated into larger programs with potentially shippable software from other Scrum teams that work on the same product.
This integration supersedes the responsibility of any one of the Scrum teams mentioned so far and is done by a separate Agile team and for this it needs its own extended integration environment, a second integration environment and the fourth environment in total.
In the first couple of stages the acceptance criteria were based on user stories, the acceptance criteria at this ‘integration stage’ are based on the overarching features that constitute the starting point of those user stories. This 'feature test’ is the final test and takes place on a fifth environment.
The five types of tests that have been mentioned above each have their own requirements to their environment. The same applies to any additional tests like performance tests or pen-testing (security).
And this is just one example of how Agile development can be put into practice!
DTAP as umbrella term for the set of environments that support the software development lifecycle loses its value within Agile, because the stages “development >> test >> acceptance >>production” are no longer valid. It is better to refer to the environments as NPE, non-production environments, each wit hits own specifics.
Ben Visser is a management consultant testing. He works for Sogeti.