“Automate All the Things!” your team cheers. But it’s easier said than done—particularly with new features in need of testing every sprint and near-constant support demands that cannot wait. When there’s always something that seems higher priority how do you find the time to tackle tech debt, and more specifically test automation debt? I’d like to share my team’s lessons learned as we waded in to address our automation debt. Starting with automated test coverage that focused too heavily on UI tests, we committed to shoring up our unit test coverage and getting our tests in SonarQube so we could effectively monitor product health—and test debt progress. Since our long-term goal is to get right with CI/CD, we also linked up tests to run as part of our build process in TFS. Come learn from our hits and misses on the path to automating all the things!
Topics that will be covered:
- Acknowledging “shiny object syndrome” and learning to balance new demands with test debt.
- “Who’s wearing the automation hat?” Our grand experiment to build discipline by committing one Quality Engineer to test automation each sprint.
- “We look forward to seeing you fail”: Championing quality for the team, with the team.
- Using SMART goals to battle our mountain of test debt and avoid capacity crunch.
- “Leveling up” coding skills through paired programming between Development Engineers and Quality Engineers.
- Bringing in expertise from outside the team to support our efforts, such as when the path was unclear for our unit tests written in F#.
What You'll Learn
- TBA