Categories
Mobile Testing

Beta releases for mobile apps

My team is going through a beta release for our mobile app to get early feedback. We’ve noticed that our android app is struggling compared to iOS. It seems that having an extra hurdle with signing up for the android beta program impacts installations. Naturally we’d expect the android engagement to lag a little behind iOS based on the Aussie mobile usage market analysis but there is still a significant drop.

We have 428 iOS installs, and 99 android installs. That’s a 19% Android installation rate. We have roughly 75-80% successful registrations and return log ins once people actually figure out how to install the app.

Google Groups vs Test Flight

We are using google groups to manage the distribution of the android beta app and because it’s harder to use than test flight for iOS we’ve gotten less installations. It’s fascinating how an extra hurdle in the sign up process can impact installations.

Return Logins

Our android numbers appear to be higher than usual here but I think it’s to do with the timeframe I’m collecting these numbers over. We’ve had a few people install the android app before we officially started the beta release and I think they’ve been counted in this statistics.

Tools

We are using adobe analytics, test flight and using a closed test track via google groups to help us manage the beta app releases and to gauge engagement metrics. You can read more about our general mobile app test strategy here if you like.

What were your experiences going through a beta release process? What worked well? How did you improve the process?

Categories
Software Testing

The Y2K bug in the year 2038

Do you remember how the world freaked out over the potential Y2K bug when the year was changing from 1999 to 2000? A large mitigation factor was a huge outsourcing effort to India and it helped to establish India as the global IT giant it is today. So when not many bugs eventuated it was a bit anti climatic. 


Globally; $308 billion dollars was spent on compliance and testing and it helped build more robust systems that survived the system crashes from the 9/11 terrorist attacks. 


Well the y2k bug would only impact systems that used 2 digits to represent the year, i.e. using the DDMMYY format to save on memory.

And the world updated this and their systems every where. Businesses did a pretty good job of patching that bug before it became an issue. Bugs still did come up but the world didn’t end.

Sometimes the fix was to push it out

Some fixes people implemented was to make 00 to 20 stand for 2000 and 2020 respectively. That’s only pushed out the problem and we’ve had some cases this year of this bug coming into effect. You can read more about this 2020 Y2K bug here.

There’s another bug for 2038

However did you know there is another Y2K bug scheduled for the year 2038? Basically the way our current 32 bit computer systems count time is the number of seconds since 1970. In the year 2038 we get a bit overflow issue and that counter resets to zero. This is more likely to impact cheap embedded systems with limited memory or old legacy systems.

If we switch to a 64 bit counter, our sun will explode before we get the same issue. It’s like going from ipV4 (we are already running out of ip addresses) to ipV6 for the internet.

IPv6 – Let the Sky Fall!

2038 might feel like a long way away but here’s a story about pension payments breaking in 2018 due to this bug (20 years before this bug is meant to occur):

Is your system at Risk?

So, are any of your legacy systems at risk? Do you think you’d have them migrated to cloud infrastructure before this issue occurs?

How about setting up a test environment that’s configured to be 6 months ahead of production? Would that give enough time to find and fix these issues when they occur?