Examples
Development and Test
Here are a few ideas that demonstrate a custom approach to development and test. From a bespoke agile perspective - a development team is responsible for merging code into a target branch at the right quality and the right time. This includes validating design with product management, curating manual and automated test cases, supporting continuous integration initiatives (CI), and orchestrating delivery of related tickets that might be under development by different teams… All of this before an epic that represents some incremental feature change is updated to ‘done.’ Here are several details:
- If every team opts into using versioned feature branches…
- And curates the set of collaborative tests that define each element of the feature prior to a merge; adding, deprecating, or removing relevant tests tagged with feature branch versions
- And child feature branches are rebased to versioned parent branches for every pull request
- … a certain amount of magic happens!
Notes:
This is not an invitation to a culture war on gitflow strategies - I believe these generic patterns apply to any gitflow…
Versioned builds can be converted to a release candidate and pushed to production with well understood tests that pass..
The most important tests are not unit tests, but ones that can be run manually. These can be decomposed to a set of smaller test cases that can become the basis for automation (more later)
What happens if you have no tests? It’s a brand-new product or feature? Well that’s addressed by an ‘incremental’ approach..
Each scrum team must add a test to the test management system only for the current code being written! No boiling the ocean. It won’t take long for a comprehensive set of tests to get developed
When developers can clone a set of manual tests to run before submitting pull requests, they are doing more of their own QA with less thinking (most developers like to write walls of code, and not do exploratory testing)
Back to Automation:
The set of tests that CHANGE THE LEAST can be converted to automation…
the ‘sets of smaller test cases’ that automation consumes can be run to create versioned initial conditions for both manual and automated tests…
These versioned initial conditions for automation can be ‘inherited’ by every team, and run as regression on those feature branch before merging to whatever equivalent of release candidate branch is in use…
These are small, incremental, and achievable tasks that allow each team to increase their velocity. The feedback loops where team members suddenly realize they have more time to do what they love is relatively speedy - usually from three to six months. Consider this time frame compared to putting out fires, and asking your team member to context switch to solve preventable problems.
