Here at Waldo, most of us have been doing mobile app development for many years. I personally have been writing iOS apps for nearly nine years now. Anyone in the mobile app business knows how painful it can sometimes be to get a new release or update out the door in a timely fashion.
Believe me, we understand your frustration. In fact, we created Waldo, in large part, because we were tired of facing the same frustrations sprint after sprint, app after app, customer after customer. You can read more of that story here when you’re done with this post.
Here are four experiences I’ve personally faced that will likely sound familiar to any mobile app developer who’s been in the trenches.
Experience 1: Coding time vs. release mode
The scenario
Your team has been working for weeks to make a critical, new feature happen in your killer app. You’ve promised the app’s stakeholders that this feature will be delivered by a specific hard date. (It must be delivered by this date—no excuses.)
As we all know, estimating deliverable dates is notoriously difficult (unless your name is Nostradamus). Even though your team is cranking out code at warp speed, it’s still coming down to the wire to make that deliverable. Something has to give.
That something is usually testing—specifically, regression testing. (You know … that fun part of the development cycle when you actually run your test suite to make sure you didn’t break any previously developed—and tested—functionality in your app?)
The problem
When time grows short, regression testing gets pushed to the back of the queue. After all, making sure your bleeding-edge, new feature behaves as expected is always considered more important. As a result, compromises are made, corners are cut, and regression testing (perhaps even testing of the new feature itself) is not exhaustive. Not by a long shot.
The Waldo solution
With Waldo, this is never an issue, because regression testing will have been done for you already.
Experience 2: A/B testing
The scenario
Your company’s signature app displays an onboarding sequence to first-time users. This onboarding sequence comprises of four or five intro screens culminating in a sign-up screen. The app’s stakeholders are having trouble deciding which of these intro screens are really necessary, if any, and what order they should be visited in.
They decide to incorporate A/B testing to determine which particular onboarding sequence leads to the highest conversion of first-time users to registered users. Ultimately, they decide on seven (yes, seven) variants that need to be supported by the app.
The problem
Testing all seven variants to ensure that each sequence visits the correct screens will be a nightmare, especially since delivery is expected at the end of the current sprint.
The Waldo solution
With Waldo, life is so much easier. Seeing all seven variants laid out as Waldo flows makes QA testing a cinch. OK, maybe not a “cinch” exactly, but there will be much less bloodshed and fewer bottles of antacid consumed.
Experience 3: Constantly changing UX
The scenario
Your company’s signature app features a main screen with dozens of elements (labels, buttons, sliders—you name it). The designers request some kind of UI/UX change to the main screen nearly every sprint, or so it seems.
Sometimes it’s adding a new button. Sometimes it’s removing a button. Sometimes it’s simply moving a button from one location on the screen to another. Sometimes it’s moving a button back to the same location on the screen that it had two sprints ago. (Or was that three sprints ago?)
The Problem
Keeping track of all these element changes is a major challenge. Some weeks it feels like déjà vu all over again.
The Waldo solution
With Waldo, it’s super simple to look at flows in previous versions of the app to see what design changes have already been attempted in the past. No more Groundhog Day scenarios.
Experience 4: Stakeholder control issues
The scenario
Your team delivers updates for release at the end of every two-week sprint. A few days before release, the stakeholders examine the new or changed features of the app and “sign off” on them. This allows a small cushion of time to fix any bugs that may surface during final regression testing. Occasionally, a stakeholder will request a minor change at the last minute.
The problem
Not only does your team need to implement this last-minute change, but everything needs to be re-tested. Depending on the nature of the change, there may be significant re-testing involved. Smells like another late evening at the office.
The Waldo solution
With Waldo, stakeholders can see all new or updated flows almost as soon as they’re implemented. (Unfortunately, there are some changes that really need to be experienced with the device in hand before a stakeholder will be fully satisfied. That functionality will need to at least wait until Waldo VR® is a reality.
)
It’s a wrap!
While Waldo can’t solve all your mobile app problems, it can definitely ease the pain of many common scenarios and leave you more time to do the important stuff. (Like write more code.
)
What problems can Waldo help you solve today? Give it a try.
Automated E2E tests for your mobile app
Get true E2E testing in minutes, not months.
