What's different about Test-Driven DevOps Design as opposed to regular old DevOps
Taking a more direct-path to the software Development lifecycle according to the client requirements, then testing the results after trying many different things quickly is what fundamentally differentiates the Test-Driven DevOps approach from other DevOps approaches which are often very compatible. Service-classes and priorities based on both functional and non-functional requirements are combined to form a Design pattern. The pattern can be delivered or polished into a Blueprint and the blueprint can be delivered. Patterns and blueprints are Templates which can be rinsed and repeated to produce output at a highly efficient rate. Time is managed in a Kanban style, but capabilities are measured as milestones in every iteration to measure velocity and progress. Because failure occurs more rapidly in this approach new capabilities can be discovered faster and improved upon much faster. It is expected that (assuming a steady supply of resources) velocity increases in every iteration. The approach fits into Agile, Waterfall, Kanban and other styles of project management, but be careful about impedence mismatches when fitting any approach into waterfall. The methodologies may vary across domains, programmes, and projects. What you might find interesting is when capabilities are delivered so quickly that people tend to forget what they are capable of.. and that's really the biggest problem with the approach.. it's just too good!
What kind of tools are used in a Test-Driven DevOps Design approach?
Generally if you can take this approach, tools will actually be the output of each iteration, but other tools which already exist may be tested against interoperability constraints in the Design process.