At CARFAX, we have awesome Quality Assurance (QA) support for the CARFAX iOS app and other apps. In order to do an awesome job, QA needs adequate time to do adequate regression testing before the next release of an app. The question is how much time is needed?
I like to think about this in terms of balls of wax. Amongst other things, the total effort of a project includes both an amount of coding plus a certain amount of testing. Therefore, the coding-ball-of-wax plus the testing-ball-of-wax equals the whole ball-of-wax.
In order to give QA a feel for how long it will take to regression test at the end of a project, they need some data. One idea that I’ve heard a few times is to use Story Points. What Are Story Points?
As I put it once, Story Points are how much brain-power plus actual coding is required to make the change. Do Story Points help give QA a feel for how much functionality change is being introduced? Not always.
A Story Point size is reflective of how much effort a developer has to put into making the change. It’s not reflective of how much testing is needed for that specifically changed feature.
How can we give QA the data they need in order for them to size the amount of QA work? If one feeds into the process, a “Feature Change Amount“ that will give them the information they need. The Feature Change Amount could be sized the same way as Story Points are sized. As opposed to Story Points however, a Feature Change Amount directly reflects something useful by QA so they know how much QAing is needed.
How does your QA get a feel for how long it takes to QA a project before it’s released for your customers to use? Feel free to share it with me on Twitter!