A Kanban focused Test Project – Part I

Introduction

This blog post is about a Test Project I am currently running. Although I am a supporter of Agile Methodologies like Scrum and Kanban there is still a need for “traditional” Test Projects.

So how can we approach such a Test Project with some inputs from Agile Methodologies?

Given the time constraint and unclear requirements (even for the development teams) we chose a Risk Based approach combined with Kanban and Session Based Test Management. James Bach and Michael Bolton are a great inspiration when it comes to Exploratory Testing and the Rapid Software Testing framework.

Why Kanban?

Kanban is a flow based apporach. Due to the fact that there is a tight timeline and there are no real requirements  the most suitable solution that came to our mind was to work on exactly those test items that are

  • available and ready for testing
  • risky to the client when there is a problem

Our Kanban board shows the next 3, 5, 8, 13 and 20 test items in the backlog. Test items in our case are not scripted Test Cases. They simply describe a model of the test area with all the information we have got about it.

Initially we came up with a rough prioritization of the planned test activities. For each test activity we might perform one or more test sessions. Should the priority change for whatever reason, we simply update the Kanban board. So we only put analysis effort into the next few tasks.

You might say that we need to test everything. But given the time constraints we focus on those things first where we see risk. Additionally we need to align our test activities with the schedule of the various projects. If one project gets delayed, it is of course not good but we need to react to the new situation very quickly and do this by changing the priority of the test items within the backlog.

Once we can start testing we are going to use the Kanban workboard which consists of the following columns shown in the picture below (it is just a sample of how it could look like)

The idea is to limit the testing activities per Test Engineer and also to highlight how many bugs are currently open and waiting for a bug fix.

This is all I can tell you at the moment. The project has started and we are a few steps away from getting access to the Systems Under Test.  We will see how it goes and I will keep you up to date with a follow up blog post. So watch out!