February 18th, 2014 by Adam Sandman
As the requirements are developed, the requirements team, which should include some of the QA team, would be responsible for developing data sets which will be used to validate and test the eventual end product. This further enhances the development effort in that now development not only has a requirement of application A must perform task B, but they have actual data to use as a part of their unit and integration testing.
As the application reaches levels of maturity, the QA team can build testing units, even harnessing off of the unit tests delivered by development. All of the artifacts are stored in the code repository. These artifacts would include requirements, test requirements, test data, unit tests, and code.
As the application is moved through the life-cycle of development (ALM/SDLC/TDLC/BPT, etc...) the compiler process would also combine the appropriate units of the user stories, test cases, and requirements to make a more complete document, showing the interrelation of units. the compiler process would also process the units of test data into consolidated forms for use by the test harness. this process would also concatenate, in the right order, units of test with relationships to the test data, to deliver unified test/development efforts.
The end result of this dream is that as a continuous integration, or automated build engine, would drive the process of documentation, development, requirements, data consolidation, resource planning, and test harness production into a singular effort. this may be a singular effort but it would include lots of moving parts.
To this I would propose a new development paradigm, one which takes the best from waterfall, Agile, XP, and whatever else is in the flavor of the month brigade. we would take these "best practices" and develop a unifying process that ties the origination of the application to the final testing.
Jenkins, cruise control, Ant, etc.. do not do this alone, but they are part of the DevOps/TestOps infrastructure that would perform such duties. Add in requirements management tools, Scrum boards, Kanban boards, test management tools, defect-tracking systems, test automation and you start to build the whole picture.
It will take innovation, and a bit of trial and error with early adopters to unify the process. all the moving pieces are out there, we just need to tie them together in a smooth and invisible way... This we call TestOps...