Posts Tagged ‘acceptance criteria’

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.checking

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:

  1. Identify tests/checks that confirm system behaviour and that the output produced is what the user would expect given the inputs.
  2. 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:

Benefits Table of 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?

Advertisements

One of my three teams works mainly on a communications engine and provides a lot of operational support for new reports and static information, particularly around this time of the year. They’ve run Scrum without a Scrum Master for almost a year and have managed to keep things ticking over. After observing for one sprint (three weeks), I facilitated the following minor tweaks based on my observations:

  1. Sprints now have an overarching sprint goal that the team can swarm around where necessary. I find a sprint goal is a simple and useful tool for helping teams maintain focus and make good decisions. We agree on the goal with the Product Owner during Sprint Planning I. I know some advocate that the goal be agreed before planning and possibly even as early as at the Sprint Review for the previous sprint, however in our world where we don’t really have a product, it’s easier to do it together with the sprint commitment. The goal conversation has also already helped us during Planning I where the Product Owner had to re-prioritise based on the fact that we couldn’t achieve all the goals with the team capacity available, so he had to make a call on which goal was the most important goal. Having a goal also led to some of our developers volunteering to support some testing work by creating tools to ease data comparisons. This reduced the manual effort required significantly, leading to us achieving far more in a sprint than we otherwise would have.
  2. Defined our Definition of Done (DoD) which is now posted up on the board. For me the most useful part of doing this DoD was the exercise itself (see below) as it helped me better understand the release and testing cycles. For this team, most of the tasks are done at a story level and there was no work required at sprint boundaries to complete their DoD. The challenge across all teams within our IT department is that the first fully integrated testing environment is UAT, and this environment is only updated/available prior to major releases (which happen approx. every 9 weeks). This impediment is one which will need addressing over time and is on the Scrum Master forum’s radar.
  3. Revived the practice of acceptance criteria for stories. The team opted to have these written on the back of their story cards. In this team, the most valuable aspect of having acceptance criteria is the conversation required to identify them.

Useful tools / links: