Archive for July, 2015

The pyramid and the dog-bone revisited

Wednesday, July 22nd, 2015

I previously talked about the dog-bone approach to testing, and how we testers love our shapes such as the Test Pyramid.  But I did not connect the pyramid to the dog-bone.  Now permit me to remedy that


This is the Test Pyramid introduced by Mike Cohn in 2009


In brief it says

Unit Testing is foundational because

  • It is earliest in the development cycle
  • It gives specific information on the source of the bug (down to the line number in code)
  • It is easiest to automate

UI tests should be kept to a minimum because they

  • Are brittle, expensive, and time consuming
  • Often redundant with Unit Tests, hitting the same code paths repeatedly through multiple UI tests

And service level testing is necessary to fill the gap that unit testing cannot test, but that we do not want to test through the UI.


Take the pyramid and turn it on its side, and you have a great start to testing in your development cycle.  But I maintain that if your goal for testing is to understand the quality of your system, then something is missing especially after you go to production.   You must leverage the rich data from real users and real usage in production to understand the quality of your system.


The techniques by which we use this production data are called Testing in Production, therefore we get the dog-bone approach to testing

Analysis and Design as named columns in Kanban? In Scrum?

Friday, July 17th, 2015

I came across this Kanban board


[it is this blog post, but the while the post is interesting, it actually does not at all address what I am about to talk about]

What I found interesting was the Analysis and Design columns. Reflecting on this, this can work for Kanban because it is continuous flow and the Analysis (by the business analysts or Product Owners) does not need to precede the planning stage as it does for Scrum.

So what are the implications here? On one hand it eliminates Spike stories which seems good. On the other hand does Analysis and Design as stages on the board truly deliver value to the customer, or are they just means to an end and therefore should not be reflected in our agile management process?

Leaving Analysis aside because of its aforementioned impact on planning, how about the Design column? How does that help? For “standard” scrum design would just be another “In Process” task along with coding, testing, etc. Does the separate Design column add anything?