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.
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.
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.
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.
I like to use mind maps to help me test. Mind maps are a visual way of brainstorming different ideas. On a previous mobile team I printed and laminated this mind map to bring along to every planning session to help remind me to ask questions like, “What about accessibility? Automation? Security? or Performance?”:
As I go through exploratory testing (or pair testing), I’ll tick things off as I go and take session notes. Often this will involve having conversations with people, sometimes bugs are raised. Here is a quick mind map I’ll use for log in testing:
Heuristics for testing
This mind map approach can be combined with a heuristic test strategy approach or a nemonic test approach. Heuristics is a rule of thumb that helps you solve problems, they often have gaps because no mental model is perfect.
SFDPOT is a common nemonic that was developed by James Bach; who also developed Rapid Software Testing; a context driven methodology. James Developed his RST course with Michael Bolton.
Gene Kim is a well established author and consultant in the DevOps space. He’s written The Phoenix Project, The DevOps Handbook and now his third book The Unicorn Project. I’m looking forward to reading the next one in the series. You can see a similar talk from DevOps Days Portland on youtube here:
Day 2: Troy Hunt and we are all pwned
Troy Hunt always gives an entertaining presentation and he’s a security expert from the Gold Coast, Queensland. He runs a website called, Have I been PWNED and the answer is most definitely always yes. He’s got a similar talk from NDC Sydney here:
Graphs & Investigative Journalism by Michael Hunger
Quantum Computing by Matthew Keesan
Growing your own Design Heuristics by Rebecca Wirfs-Brock
Interaction Protocols by Martin Thompson
Level Up Quality, Security and Safety by Todd Montgomery
When I start talking about diversity in tech there’s a few points I usually like to make. Because I come from both a tech and engineering background there is a lot of overlap with women in Engineering roles and women working in tech. This blog post will compare diversity in tech and engineering.
We nearly had 40% female graduates in Computer Science
Traditional engineering fields such as mechanical engineering have always had low female participation rates at the university level. Where as computer science didn’t have that problem. A common reason why people think women stopped studying computer science was the personal computer came out in the 80’s and was marketed exclusively to boys. This was also around the time when Lego changed it’s marketing towards exclusive “boys toys”. (Lego was struggling financially before this point). This video below compares Lego’s 80’s advertising to current day advertising.
Some engineering fields have more diversity
What draws women to study Environmental and Biomedical engineering over Mechanical Engineering? I’d say it’s a perception thing, as a smart young women entering university, the amount of courses you could study is almost endless. You want to do something that feels like it’s going to benefit society as well as stimulate you intellectually.
Environmental Engineering definitely sounds like it’s going to benefit society more than Petroleum Engineering… Just saying.
Women and international students pass engineering degrees at higher rates
Once women decide to study Engineering they are more likely to see it through to successfully graduate. If women had some sort of innate ability that made them not good at engineering, you’d expect this number to be lower.
Some Muslim countries have better diversity in Engineering
Malaysia boasts about 30 – 40% of women engineering graduates
People tend to associate Muslim countries with oppression of women, however choosing a STEM career is seen as a way for setting yourself up for financial independence in a lot of these countries. There’s a different cultural perception of value for these careers. People in these countries don’t think that maths is a skill you a born with and only boys are good at it. They believe to be good at this skill you need to study hard. There is a blog post on cultural influences here.
Women leave the field more frequently than men
To become an Engineer you have to be a smart cookie, it’s not an easy thing to do. I know this because I tried and failed in my efforts. But once you start working there’s lots of issues that constantly chip away at your sense of satisfaction in work. There’s also tons of non engineering fields out there that value transferable engineering skills, can be just as rewarding on an intellectual level and offer better work life balance.
Research also shows that women are disproportionately likely to move away from the most technical career paths and toward roles that involve technical supervision or management as their careers progress.
We truly live in a global and inter connected society. But have you tested your app using a Right to Left (RTL) language such as Arabic? This blog post is a reflection on some of the design considerations to keep in mind when accomodating this.
Why does this matter?
Arabic is one of the top 5 spoken languages in the world with around 3 hundred million speakers and it is the third most spoken language in Australia. Even if you only release apps for the Australian market someone out there will have Arabic set as their default device language. It’s ok if you haven’t translated your app, but you should check that these people can still use it.
How do I test this?
Enable developer options and select “Force RTL layout direction”. On My Samsung S10 this is what my screen and options look like after enabling this option:
In Xcode you can change the build target language to a Pseudo RTL language to see how your app renders in this way without having to change the language on your device.
You don’t actually need to render your key pads in Right To Left, in fact it’s actually more jarring to render numbers in a RTL arrangement because ATM’s and phone pads are left to right in Arabic. Most Arab’s are use to globalised number pads. Samsung has an in-depth article on when RTL should be applied.
When I have RTL rendering set on my android phone, the log in pin screen and phone call functionality is in LTR. However some of my banking apps render their pin pads in RTL.
Common RTL Issues
I was pleasantry surprised to find out how many of my apps weren’t broken when I switched to RTL rendering. Facebook, twitter and email still look very good. Some apps (like my calculator) do not make sense to render RTL and they remain LTR:
Bug One: Overlapping labels
You will have to watch out for when labels overlap like in the domain app here:
Bug Two: Visuals doesn’t match written language
And when your text is rendered RTL but the visual cue is still LTR like in the shade bar for representing countries visitors to my blog in this wordpress statistics view:
Bug Three: Menu’s that animate from the side
In the app I’m helping build, the side menu renders pretty funkily in RTL mode, I can’t show you a screenshot of this behaviour but it’s probably the quirkiest RTL bug I’ve seen. If you find an app with bad side menu behavior in RTL please share your screenshots with me.
But here are some screenshots of the CommSec app on android (LTR on the left and RTL on the right for comparison)
Bug Four: Icon’s aren’t flipped
Often icon’s have a direction associated with them like the walking person when you get google maps directions. Sometimes it can look a little odd when they aren’t flipped correctly (as if they are walking backwards).
Have you seen these bugs before?
Please let me know your thoughts or experiences in supporting RTL languages. I’d love to hear your stories.
I attended Serverless Days in Sydney Today. Overall it had a good sense of community, the venue and food was top notch. This is a community run conference and there’s always good representation from the main serverless cloud providers here. *Cough* Google/AWS/Microsoft *Cough*. Alibaba made an appearance too.
Ben Kehoe – a Cloud Robotics Research Scientist at @iRobot gave us lessons learned in applying this mindset to more than just web applications. He goes over how as engineers we need to shift our mindset to focus on delivering business value and not get caught up on feeling like the centre of the business. Any code your write is a liability. That’s why I advocate for lean test code that adds value.
On a side note, anyone who gets to work in robotics professionally is super cool in my books. My favourite presentation is one where I present Tappy McTapface – a robot for mobile app testing. You can watch a previous talk by Ben on a similar idea here:
Did you miss out on the action?
Some of the speakers have given their presentations at previous conferences/meetup groups. Like Jessica Flanagan at YOW! Data this year. And Denis Bauer at YOW! Perth last year.
I Previously live streamed the Serverless Sydney meetup group and the Node user group on twitch (however these video’s are only stored on twitch for up to 60 days post live stream).
Serverless Icon Showdown
Who has the best logo? There’s Google Cloud Functions, AWS Lambda Functions, Microsoft Azure Functions and Alibaba Cloud Function Compute. Handsdown I think Microsoft Azure functions is the best logo here.
Are you using Serverless in production yet? what are some of the challenges you are facing? How should testers get up to speed with this technology?
Have you heard of micro services? This is like that but even smaller. What’s the smallest service you could possible deploy? a single function. Server less still uses a server, but the infrastructure is abstracted away by your cloud provider of choice. If no one is hitting your API, there’s no server running and costing you money. Cloud providers spin up an instance when needed as soon as something calls your function.
Test strategy, what a funny concept. Now this strategy isn’t going to help you win any battles (this is where the word strategy comes from after all) but for lack of a better well understood term, this blog post is a reflection on what I imagine will work for my team*.
*disclaimer: what might work for my team might not work for yours. People are amazingly diverse and your team and company context is fundamentally different. Also this here is a wish list of what I think will work. It’s subject to change as we learn and evolve.
First let’s set the scene. Our scrum team includes 1 Android developer, 1 iOS developer, 2 back end developers, 2 business analysts (1 is our scrum master), 2 testers and a team/tech lead. We are changing our team structure and I’ve come on board as a software engineer in test. Our team closely collaborates with the design team and they are included in our group email threads but don’t come to our retro’s. We have a 10 day sprint cycle that looks a little like this:
We have a daily standup, a few kick off meetings at the start of the sprint to lock in what we are working on for the next 2 weeks, some mid sprint review/next sprint refinement sessions and a few meetings at the end that help tie up what we’ve completed. Consider this a crash course in Scrum Agile if you will. Not everyone is required to attend all of these meetings and I won’t be covering these meetings in detail in this blog post.
Get to the Test Strategy
Yes I know, that was a rambling tangent but the context is important. Before I get into the good bits I’ll ask you a question;
Why do we even bother with testing?
Some people say, “to ensure the product works as expected” or, “to find bugs”, “it’s my job to test things” and these are all ok answers but they miss the point a little. Here’s my answer:
We test to get feedback on the state of the product. To help us answer the question, “are there any known risks with shipping this product to production?”
Paraphrased from conversations with Michael Bolton, the tester not the singer
Every part of the following strategy is all tied into facilitating feedback. The more timely and accurate the feedback the better.
Testing and quality is a team responsibility, it’s not just up to one person to be the quality gate keeper. My role is to help facilitate feedback
Layer One: The product design feedback loop
This is all a little out of scope of my teams day to day activities but this how our design team tests if we are building the right thing that users need.
This might involve researching our market for current trends. How many of our customers care about their superannuation? What is their financial literacy? What type’s of problems are they facing? What are our competitors doing and how does their experience deliver value?
Eventually someone will need to start sketching out some design ideas. What’s the user flow through a particular feature?
This won’t happen for every new design, for example log in hasn’t gone through this process. Our new big features will go through this type of testing. This helps get feedback on the design and layout. Does it all make sense?
Design and user story creation
Out of all of the work, eventually the design team and the business analyst will work together to create acceptance criteria, refine the UI and get the rest of the team up to speed with the context of a feature. Our user stories and designs are usually shared on a confluence page and linked to Jira tasks. We use a GIVEN WHEN THEN structure for our user stories.
Layer Two: The code feedback loop
All testing is exploratory in nature, its front and centre. It’s across everything we do. chaos engineering is a type of it as well as building the code locally. We use our skills, plans and judgement to determine when and how much testing is needed at any point.
When we do the code review we will do exploratory testing based on the risk of the feature. Time boxed to a session or two depending on what has been built. We will look at the user stories, brain storm any more edge cases and consider if they are worth testing. Checking if the experience of the feature makes sense and if there are any ways people can get into some sticky unexpected situations.
As a developer builds a feature, they will create unit tests based on the user acceptance criteria. Developers will use the tools they are most comfortable with the write these tests. If you’d like to read more Martin Fowler has this blog post on Unit Testing.
I have my visual risk board next to our team which we use to prioritise how much testing we build at this layer. We use Espresso for Android and XCUITest for the iOS app.
“Why not Appium?”, I hear you ask
Simple, when test code lives in a repository outside of your production code, you decrease collaboration with the whole team. Also you can’t easily run your appium tests during pre commit testing or locally as a developer. You can follow the interactive visual risk for UI automation exercise here to understand more.
When a new API is being developed, I’ll often pair with the developer to do a code review. We will talk about the architecture, brain storm testing ideas, do a bit of testing (usually through postman if we are testing an API), we will chat about test coverage. Is it adequate? Is there any thing missing? Can we see the tests fail under the expected conditions?
If it’s a front end feature, I’ll check out the code locally and use a different emulator/simulator than what the developer uses. I’ll give the feature a good shake out and check the test coverage. I’ll also test for accessibility if it’s a new front end feature.
For our mobile app, we are able to do most of our code review testing without ever talking to a backend. The engineers have built some mock servers into out apps, when the app would call an API, our mock server returns a canned response. This helps us test that the UI and the flow hangs together even when test environments aren’t available. If you’d like to read more, check out this article on mock testing for android or this one for iOS.
We have different pipelines for different applications. We are using TeamCity as our Continuous Integration tool. Generally all of our unit tests and UI tests will be run. Maybe our contract tests. I have a few other ideas to increase the value from our build pipelines that I’ll talk about in Chaos Testing. If our main builds start failing, we won’t release the software.
We don’t necessarily focus on doing device testing for each feature that comes through. I try to pick a different emulator/simulator than what the developers do. I always make sure features get tested on a Samsung. Some features, if they are 3 star features from our risk analyst we will spend more time testing on a wide variety of devices. We currently have an on premise mobile device cloud server delivered by Mobile Labs. If you don’t have a device cloud, you could set up your own device farm.
Samsung has a wide market saturation and they always do funky stuff to the android UI. The android emulators are awesome at vanilla android. However, most people out there aren’t using vanilla Android :(.
We are moving towards having contract testing in place that lets us know if an API starts to break, if someone changes the JSON payload in an API our contract will break and someone will know the have more stuff to clean up. We don’t have contract testing for our mobile app yet but some of our downstream micro services are starting to build these. If you’d like to find more, read this article by Martin Fowler.
We have an integration test environment where our code is being constantly deployed into. Sometimes it can mean an API is down because it’s being deployed. We do a lot of our API testing in this environment.
With android there’s this command line tool called chaos monkey. This tool is a UI exerciser, it throws random user input at your UI to try and find where it crashes. I’m hoping to include this in a build pipeline for an overnight build. Run it for a few hours on an android device and see if it crashes. The next night, do the same thing but on a different device/os combination. This will give us reasonable device testing over a sprint. I don’t know of a similar tool for iOS. You can read more about chaos engineering on wikipedia.
Layer Three: Shipping the product feedback loop
A few days before the end of the sprint, our team and invited guests will sit down and do some exploratory testing on the features that have just been built. If anyone wants to explore a new API that’s been built, they can. If they’ve had their head in unit tests lately, they have the chance to explore some of the new UI. You can read how to run a bug bash to find out more. If major bugs are found here we won’t release the software. We might do a mob programming session when we don’t have enough features for a bug bash.
On the last day of the sprint we will demo our features to a broader audience. Feedback is gathered and turned into Jira items/research for the design team.
Then we release to internal staff members. Many other companies call this “eating your own dog food”. This gives people the chance to raise more feedback before we put the product in front of customers. You can read more on wikipedia here.
We can release our app to our high value or digitally savvy customers who want to ahead of the curve. This is a customer engagement strategy as well as a test strategy.
Percentage roll outs
The google play store allows you to do percentage rollouts. Say you rollout to 5% on the new version, monitor production for any new crashes or customers complaining. If it’s all smooth for a few days you can continue the rollout to 50% and then 100%. The google play store allows you to roll back if major bugs do occur. The apple play store has a similar feature.
Monitoring in production
What metrics should be communicated back to the team? How can we respond to issues in production? I like this quote from a 5 minute google talk back in 2007:
Sufficiently Advanced Monitoring is Indistinguishable from Testing
Layer Four: Supporting the product feedback loop
We should support all of the devices that 80% of our market uses. We will be support from Android 6 (marsh-mellow) and from iOS 11. There probably will be some obscure android devices out there that don’t play nice with our app. Android is a beast like that.
Facilitating customer feedback
There will be an easy way for customers to provide feedback in app. I have some ideas on how to make that experience better but there are privacy concerns to consider. We will also be monitoring our google/apple play store reviews for bugs.
Someone should be monitoring all of this feedback, attempting to reproduce bugs if customers are facing them and raising them in the teams backlog for prioritisation next sprint.
Soap Opera Testing
Maybe in the future, we could try some soap opera testing with the business? Soap opera testing is a condensed and over dramatised approach to testing. What are the wackiest scenarios our customers have actually tried? How does our system break? You can read more about this exercise here.
Why the layers?
Consider each of these layers like a net. It won’t catch everything, bugs in production will still happen. But when we have all of these feedback loops layered on top of each other, we get a pretty tight net, where hopefully no major issues get into production.
What about auditing or compliance?
Our source of truth is the code, Jira and Confluence. When we have all of it integrated, we can prove we tested a feature thoroughly without too much extra overhead. An auditors mindset and a testers mindset are very similar. Testers are concerned with product risks, auditors are concerned with business risk.
Their main question is, “did you do what you say you do? Did you follow your process?” and, “Is the existing process adequate?”.
Where are your test cases?
Michael Bolton has a 7 part series on breaking the test case addiction. You can read series one here. You don’t need test cases to prove you did adequate testing. They create unnecessary overhead that detract from adding business value.
What else is missing?
Security testing is not included in this test strategy. Neither is performance testing. Getting these included can be challenging. I’m open to your suggestions in how I can incorporate this type of feedback in a timely manner.