In support of the Testing Manifesto.


The Testing Manifesto was compiled in 2013 by agile coaches Karen Greaves and Samantha Laing to complement the famous Agile Manifesto.

The Testing Manifesto initially gave a rallying point to people who were feeling the pain of the testing habits leftover from waterfall methodologies. More recently, it has served to point up that while modern software development practices have evolved through better management of code and infrastructure, lack of effective data management has left testing poorly equipped to keep up.

The Testing Manifesto is as follows:

Testing Manifesto

In this blog post we will look at how Dotmesh and Dothub provide much-needed support to the principles valued in the manifesto.

1. Testing throughout OVER testing at the end.

The earlier you can catch bugs the less work it is to fix them and the fewer knock-on fixes you’ll need to make. So while developing it makes sense to optimise your local environment and CI pipeline for spotting bugs as you go. Dotmesh gives you the means to trivially capture your application state and organise and share it via Dothub. This gives you a library of states that you can invoke at will to develop and test against. Managing your state to give you a predictable working environment lets you build data hygiene into your workflows and stay sane when spotting and reproducing bugs.

2. Preventing bugs OVER finding bugs.

A key part of preventing bugs is to find a clear way of communicating functional requirements and expectations of software behaviour. In many cases TDD (Test Driven Development) and BDD (Behaviour Driven Development) are used to set out what a successful outcome should be. Providing datasets for input and capturing output state are two simple ways that Dotmesh and Dothub can provide a structured data management layer for TDD and BDD.

3. Testing understanding OVER checking functionality.

Checking functionality is a job which should be automated wherever possible. This frees up more human brain cycles for making sure that there is collaboration on everyone understanding what the software should do and assessing its delivered usability through user testing. Dotmesh supports automation of functional testing through its ability to snapshot application state. For example, it helps to speed up CI runs through caching and can help debugging in CI by capturing the state of failed runs.

4. Building the system OVER breaking the system.

Here we look at how considering testing from the outset will reduce the need to try to “break the system” to find bugs at the end. Building quality into the system through testing requires intelligent use of the full range of testing strategies e.g. Unit testing, Integration Testing, System/Functional testing. As part of a considered testing approach it’s necessary to decide the part that data will play in supporting this. Dotmesh can be used with Dothub to create a versioned repository of test or application states and also to capture test results, bringing structure and control to the process.

5. Team responsibility for quality OVER tester responsibility.

Maybe you have a dedicated tester, test engineer or QA person, or maybe testing is distributed equally in your team. Either way, quality is everyone’s responsibility. Dotmesh and Dothub give you the means to collaborate across the team by capturing and organizing application state for development and testing. You can quickly and easily share a state from your local environment to a co-worker’s machine. Or switch between test user accounts, or feature branches with state. Dotmesh opens up super low-friction sharing of state.

So, I hope we’ve shared with you some of the ways we want to support the Testing Manifesto by giving you Dotmesh to improve quality, increase the speed of CI, and… decrease the number of bugs!

Written by:

Alice Sowerby