Skip to main content

Crystal ball - ETA chart

Given the nature of change within agile projects, it is good to try and foresee what is in store in the near future. This is where the use of a crystal ball is useful. Now, when i say crystal ball, i do not literally mean having a nice shiny circular translucent object that takes us into the future. I am talking of a chart which gives us a slight insight into what is going to be delivered. Lets call this Crystal ball as an ETA (Expected Time of Arrival) chart.

This ETA chart gives the team an insight into what is going to be delivered within an iteration. This ETA chart is a matrix where the columns represent the week days within a 1/2 week iteration and the rows are the dev pairs working on different stories. This is what it looks like



So the idea is to get the developer pairs signed up for stories to put up an ETA (Expected time of arrival) for the stories they are working on and put it against a day. So they would just put a sticky note with the story no and a brief desc of the story against a day. This ETA is re-visited and re-validated by the developers everyday after the stand-up in the morning.

The benefits a tester gets with the ETA chart are
  • The testers can plan their work better within the iteration since they have a better idea on what is being delivered first. Thus, they can focus on first writing test scenarios, writing automated tests for stories being delivered in the first week of the iteration.
  • This helps them not focus on stories that might be delivered in the second week of the iteration
  • The testers can finish up and sign-off stories being delivered within the first week of the iteration which gives them time to then focus on the stories being delivered in the 2nd week of the iteration.

Comments

Post a Comment

Popular posts from this blog

How does one decide what to automate?

A question that has been troubling me for years is how much to automate. We all like to achieve maximum coverage and build a robust safety net where possible in order to give us confidence about the system under test. Given there is ample time i would like to automate almost everything, but in the real world, this isn't possible. This is when we introduced the concept of Value and Cost for a test scenario. Every test scenario would be assigned either of these attributes. Lets call the attribute automation classification High Value - Low Cost High Value - High Cost Low Value - Low Cost Low Value - High Cost What this translates into is we are associating business value and cost to automate to every scenario. So, when a test scenario is of high business value and the cost to automate it is low, then this becomes our ideal automation candidate. You would like to start automating all test scenarios that fit into the High Value - Low Cost category first. See picture below If tim...
1 comment
Read more

Test your services and not your UI

As a tester, i have spent more than 6 years trying to automate tests at the UI layer. As years passed, better automation frameworks evolved resulting in writing more manageable and maintainable code, but the only thing that wasn't getting better was the cost of maintaining these tests, especially when the no. of tests were 500+. There are multiple reasons why i feel creating an automated regression suite of tests at the UI layer is not good. Some of them are Limitations on what the tool can do Time taken to execute these tests leading to longer feedback loop Success rate of tests is not 100% due to latency issues Change in UI and UI flow resulting in an increase in cost to maintain UI tests On the other hand, testing business logic without having to deal with the dumb UI was a concept that a friend of mine at ThoughtWorks, Chirag Doshi introduced to me. He sent me couple of blog links written by Alex Verkhovsky about why is it so hard to do functional test automation at th...
1 comment
Read more

BDD is over-rated

Over the past few years, I have tried to justify the use of a BDD (Behavioral Driven Development)  framework to express my tests, but not once have been able to say BDD has helped me address a  problem which writing tests the non BDD way would not have addressed. I do understand the value BDD brings to the table, but in most projects that I have implemented BDD on, we have tried to provide a solution (BDD) to a problem that does not exist. Let me try and explain. Lets look at the key benefits of expressing tests the BDD way (There could be more) Collaboration between Business and Development Ubiquitous Domain Language Focus on the behavior of the application Now, more often than not unless your business is co-located with the team, collaboration is not the easiest. The value BDD brings here, is the business validating our understanding by reading our tests expressed in the Given When Then format (BDD) and providing feedback, as BDD expresses the behavior of the syst...
1 comment
Read more