I recently attended the regional Scrum Gathering for 2015 in Johannesburg. This is a post in a series on the talks that I attended. All posts are based on the sketch-notes that I took in the sessions.
Initially, this talk was called “Automated Testing”. Apparently testing can not be automated because testing implies trying to break things when you don’t know what you’re looking for. The preferred term for when code can automatically check itself is “Automated Checking”.
Joshua had an interesting perspective in terms of a test approach. It’s based on the premise that the most important thing, at the end of the day, is the value delivered to the user and this is where all testing should start. His proposed approach is an outside-in approach:
- Identify tests/checks that confirm system behaviour and that the output produced is what the user would expect given the inputs.
- Once you have identified these checks (typically at the user interface level) then find the highest level where you can write automated checks without increasing the cost to a point where the cost of automation exceeds its benefits.
He did acknowledge that this kind of outside-in approach will not help one find where things are breaking. However, there are certain other benefits to consider when it comes to high level checks:
For those who are strong advocates of Test Driven Design, that did get a mention. Joshua acknowledged that when writing complicated pieces of code where there is a large amount of uncertainty, unit tests could be helpful in finding one’s way. He called these Scaffold Tests and drew the analogy to the scaffolding used when constructing tall buildings. Similarly to scaffolding, remove these tests once they have served their purpose, otherwise they become an unnecessary maintenance overhead.
What is your take on an outside-in rather than inside-out approach to automated checking?
Reflections of a Scrum Master 