Charles Perry and Joe Cieplinski from the Release Notes podcast have recently talked about their approach to beta testing iOS apps.
It’s useful to hear how other developers approach this. They talk about things like:
- How to enlist beta testers
- How they distribute builds
- What type of feedback they ask for (design critique vs. stability and bugs)
- Ways to guide and motivate beta testers
I was particularly interested by a comment that Joe makes, which I’m sure will resonate with a lot of other developers, too. Something close to:
“[indy developers can be] afraid to beta test… they’re afraid of that feedback where it’s like, if they say that they don’t like this, or that this doesn’t work, I’m going to have to start all over again, or make a major change”.
Getting feedback on a design, workflow or idea can be scary. What if that feedback suggests it’s not working? As an indy developer you’ve got to take responsibility for dealing with that feedback…
The prospect of re-work or lots of additional work can be difficult to bear. It’s more time (and cost) for one, but it can also be frustrating and/or demotivating. And sometimes it feels like you’re simply too close to shipping to make changes.
On the other hand, wanting to ship could itself be a valid reason to avoid additional work. After all, not shipping is often a criticism of the development process.
Finding a good approach will vary from project to project, from release to release. Do you need design/workflow feedback, or is it more a question of stability? The answer to that question will effect when you should think about getting that feedback and what you need to do in order to get effective feedback.
Whatever your project, it’s a good idea to consider what feedback you’re going to want/need and what role beta testing will play in that. On that note, the above episode of Release Notes is worth listening to.