This is a guest post by Carol Brands.
Every journey starts with a single step, and my team has finally made the first step on our path to DevOps.
In an earlier post, I talked about some of the challenges we had as we planned our move toward a DevOps development style. Here, I’ll talk about our first attempt at defining how testing will be carried out on a DevOps team.
Development had just finished working on a support and test tool for our newest product. We decided to take this opportunity to practice working as a DevOps team by re-examining the project and putting it through some additional product development kickoff meetings, even though the development had technically been completed.
This meant the release of this tool would be delayed slightly as we analyzed how the tool might have been developed with a fully stacked team, including a product owner, a tester and an operations person. But we felt this represented a low-cost experiment whose value was worth the extra few days of work.
We started by evaluating what writing user stories and features might look like as a fully stacked DevOps team. We determined that the development team created a few features that exceeded what the full-stack team would have called a “minimum viable product.” We decided to treat the product as though those features had not been developed, simply removing access to them rather than removing them entirely, since they would likely be useful in a future version.
Considering development had already been completed, after reworking the initial backlog creation project we decided to work on creating a new testing process. We knew there were two main problems we wanted to address: faster feedback during development, and coming up with a strategy to use automated tools in addition to our usual testing.
Previously, testers were responsible for all testing activities, and we carried out our work at the user story level. We would examine each user story and its associated requirements and map out all the happy path, domain and exploratory testing for each one. However, we would find problems with the happy path or at the domain level — such as user input quirks like large strings — often enough that little time usually remained for exploratory work.
In our new process, we wanted testing activities to be open to all members of the team. We decided that one way we could do this was by having the testers on the team write test charters immediately after the team finished fleshing out each feature and its user story. This would mean that the test charter would be ready for anyone to pick up as soon as a feature was deployed.
However, we still needed to find a way to deliver even faster feedback to the development process, and get testers involved before the features were deployed. We decided to adapt the “Shake ‘n Bake” session format described by James Bach.
Prior to merging changes into the build, a tester and a developer sit side by side and go through the acceptance criteria, carrying out simple happy-path and domain testing to determine the readiness of the user story for additional testing. Any problems can be fixed and tested right there at the developer’s machine. The pair may identify some additional exploration that’s needed and add test charters to the feature to address that need.
Initially, we imagined that this session would take place at the user story level, but as we started to put this into practice, we decided that we may want to carry out these sessions even more frequently.
The final process we imagined looks like this:
- A feature with fully fleshed-out user stories exits the fully stacked team meetings
- The tester begins writing an informal test outline to be used during the upcoming “Shake ‘n Bake” sessions for each user story, as well as test charters for the feature
- As user stories (or any portion thereof) are completed, the developer initiates a “Shake ‘n Bake” session with a tester, and they work together at the developer’s machine
- As features become available in the build, any member of the team — developer, tester or otherwise — can carry out the testing required to complete the test charter
Using this method, the most obvious problems can be resolved during the “Shake ‘n Bake” session, which means the exploratory charters are not slowed down by finding and waiting for resolutions to simple problems. This also gives us the faster feedback to development that we were hoping for.
Every new project gives us an opportunity to try something new and take another step toward a DevOps way of working. Our next plans will include figuring out when to identify and write automated tests as part of this process. I’m looking forward to the road ahead.
Carol Brands is a Software Tester at DNV GL Software. Originally from New Orleans, she is now based in Oregon and has lived there for about 13 years. Carol is also a volunteer at the Association for Software Testing.
