Thanks for returning to catch part 3 of this series. If you didn’t get a chance to read the previous 2 posts, check them out now:
- 30|60|90 Days to Automation, pt. 1.
An overview of the entire plan, why automation is important, and some assumptions about teams that would use this 90-day approach.
- 30|60|90 Days to Automation, pt. 2.
A deeper look into activities for the first 30 days of the plan.
Within this post we will explore details behind the second 30 days of the plan, before we get into those details, here is the overall plan once again. Think of it as a check-list of spikes, foundation stories & new tasks your team needs to account for during backlog refinement & sprint planning.
30 |
60 |
90 |
|
|
|
Automation on Local Boxes |
Automation in the Test Environment | Initial levels of Continuous Integration |
Days 31-60
The set of items focused on in this batch are focused on helping the team push all of their work to a central test environment and initiate automation within that shared workspace.
Start Scenario Analysis in Refinement Sessions
There is a robbing Peter to pay Paul situation that occurs with Backlog Refinement. The more you invest in refining stories, the less time you’re focused on the sprint tasks at hand. However, by incorporating scenario analysis into your library of techniques for refinement workshops you’re able to get a jump-start on automation. Defining scenarios just ahead of the sprint where the work is occurring allows the PO to be thoughtful and fully vet that you’re looking at the right scenarios. It also enables you to begin automation earlier in the sprint this incorporating beginning ideas of Behavior-Driven Development, Acceptance-Test-Driven Development and basic Test-Driven Development.
Define a Clean Test Environment
Automation practices become vastly more complicated when you do not have a clean and consistent environment for running tests. “A large part of making tests repeatable and robust is ensuring that the test fixture is torn down after each test. Leftover objects and database records, open files and connections can at best cause performance degradations and at worst cause tests to fail or systems to crash.1” By collectively agreeing to a definition for a clean test environment you have a common definition for all team members to use when writing and automating tests. Taking time to have commonality across multiple teams working on the same platform will enable the tests to scale and be reusable across multiple environments.
Write a Script to Trigger Tests on Build of the Code
Save your team one additional step of the process. Automate the execution of automated tests. Every team starts in the same place. Create a build of the code, then trigger tests to run. But, that is a repeatable step you have to do on every single build. Instead of spending a few precious moments on a redundant task, take the time to write a script that automatically triggers the tests to run every time there is a build of the code.
Automated Reporting of Pass/Fail
This is all about fast feedback. Whether it’s an e-mail, desktop notification, or a loud buzzer – make sure the team knows the results of the tests. The faster you get the feedback, the sooner you can resolve defects. Team members should not need to hunt and find the results of the tests.
Require Locally-Passing Unit Tests
This is a first step towards gated check-ins. Modify your team working agreements as well as Definition of Done to require that team members 1st pass all unit test locally before checking into the shared test environment. This forces you to start building quality in from the very beginning of the process and reduces the costs of defect remediation over the long-haul of the initiative.
Almost done…
This series is almost done. Come back next week and look for part 4 that uncovers extra detail behind the last segment of the plan!
Upcoming Webinar Opportunity
If you are struggling to maximize the agility of your teams and increase the quality and clarity of your release plans, be sure to register for our “Definition of Ready” webinar that is taking place on November 17th.
1 http://xunitpatterns.com/Automated%20Teardown.html
The post 30|60|90 Days to Automation, pt. 3 appeared first on Davisbase Consulting.