Estimating Test Automation Story Points is a Total Waste of Time

95+% of test automation efforts are on test maintenance & regression testing

Image Credit: https://rubygarage.org/blog/how-to-estimate-with-story-points

This article is one of the “Be aware of Fake Test Automation/DevOps Engineers” series.

Many fake “agile project managers/agile coaches” are fixated on Velocity Charts. The so-called “velocity” is based on the rate of completing the story points estimated by the team. As a result, “story estimation sessions” are a part of “Agile Ceremonies” in some projects, along with“stand-up meetings”, “retrospectives”, and “sprint planning”. (see the end of the article for Kent Beck’s, the father of Agile, view on these ‘agile ceremonies’)

I do not estimate points/time for developing automated tests for a user story. The reason is simple: it does not make sense.

Below is a slide from a presentation I gave in 2015.

It has three charts:

1. A typical Scrum Sprint: 10 working days (2 weeks)
   The planning sessions are on the first day, and the showcase & retrospective are on the last day. Software development activities (coding, testing) occurred on the 8 days in the middle.
2. Assume the team is trying to do Agile, and a completed user story is verified by one or more automated end-to-end tests (“Done, Done”). From Sprint 2 onwards, the testing activities consist of the following:
   - Prepare the automated tests for this sprint
   - Develop the new automated tests
   - Regression, make sure the automated tests created in the previous sprints are still valid (common sense, right?). Besides test execution, this includes test maintenance, such as updating test scripts/data along with application changes, stabilizing test execution, and refining/refactoring test scripts.
3. The regression effort, as you can see, will accumulate quickly along with the development. Maybe on Sprint 3 (or maybe even earlier), the regression testing effort will exceed all other test automation activities.