When I’m testing mobile apps, I often create quick screencasts to accompany my bug reports. Screencasts are especially useful for capturing issues that aren’t visible in a static screenshot and for demonstrating the exact steps to reproduce the issue. I try to keep them as short as possible for easy viewing.
Lately, I’ve been using Android Debug Bridge (adb) for these screencasts on my Android test devices. With adb, you can create a screencast on the command line — no need to install any apps on the device or deal with convoluted steps to transfer the files. It also means I don’t have to open up Android Studio just to record my device. Quick and easy!
On your Android device, go to Settings > System > About phone and tap Build Number seven times. This enables Developer options which you’ll now see under Settings > System. From there, you can enable USB debugging.
Once you have that setup done, connect your device to your computer via USB. You should get a prompt to allow USB debugging; you can set your device to always allow it from your computer, or choose to get that prompt each time you connect your device.
Now, recording a screencast is just four easy steps:
On the command line, run adb devices. This isn’t strictly required, but I do it to make sure my test device is connected and authorized for USB debugging.
Then, start the recording with adb shell screenrecord /sdcard/screencast.mp4 (specifying your desired directory/filename). The maximum recording time is 3 minutes.
Stop the recording with Control + C (Command + C on Mac).
Move the recording from your device to your computer with adb pull /sdcard/screencast.mp4. You can also specify a local destination for the recording, e.g. adb pull /sdcard/screencast.mp4 ~/Downloads/screencast.mp4.
That’s it! Your screencast is now available on your computer for you to handle however you need. You can also check out the adb documentation for more screen recording options and other useful actions you can take with adb.
Do you have any favorite tools for creating, editing, or sharing screencasts, especially on mobile devices? I’m always open to trying out something new!
When some of my teammates starting developing Simplenote again last year, one of my tasks was to pick up beta testing for it. I can’t give it the testing attention it deserves at this point (there are only so many hours in a day, and we have other apps to test!) which is why I really appreciate our community of users and beta testers who send in feedback — if you’d like to join in, there are links in the post below to our Android and iOS beta programs.
After a short hiatus, Simplenote is actively being developed again! We’ve been busy cleaning up the user interface, bringing old code up to date behind the scenes, and fixing some long-standing bugs. Check out the recent release notes below. Android Added search sorting by date created, date modified, and alphabetically with search history and suggestions. […]
I have always loved a good puzzle. You know there’s a problem, and a solution, and you just have to figure out how to get from one to the other. Lately I’ve been especially enjoying puzzle games where the problem itself is part of the mystery — you’re given some information and have to figure out where to start.
My brother is especially good at finding these kinds of puzzle games. For Christmas, he gave me a subscription to Hunt a Killer. It’s a detective game in a box, but no one tells you what you’re trying to solve. You just get puzzles and clues to put together, and each month (for 6 months) a new box arrives with more details. There are “aha!” moments when you solve an individual puzzle, and the slow burn of fitting together clues and piecing together theories about the underlying story.
Another game that came from my brother is Gorogoa, a computer puzzle game with beautiful illustrations and simple yet incredibly clever gameplay. Once again, you enter the game with no idea of what’s happening, but as it continues you get a sense of the logic and storyline. This one is relatively short but full of enjoyable moments.
In many ways, this is similar to how I approach testing. I want to know just enough about what I’m testing to have a purpose, but not so much that I am just blindly following someone’s directions. I try things out, see where my intuition leads me, and watch for the places where I get stuck. I look for the story, the journey taking me from one screen to another. My challenges turn into opportunities to improve the product, and my “aha!” moments are the places where I see why I’m having trouble. In my testing I may not always arrive at a solution (although I enjoy being part of those discussions, as well!) but the satisfaction is in the hunt, in putting myself in the right frame of mind to uncover what I’m looking for.
Do you enjoy puzzles? Any good ones you’d recommend?
Did you know that both iOS and Android have easy ways to build your apps for localization testing?
As someone who loves languages, I’m used to just switching a test device into another language for testing and dogfooding over a longer period of time. But even I get a little scared that one day I’m going to switch my iPhone’s device language to Arabic and never find my way back to the language settings. And for teammates who don’t speak another language, it can be even more intimidating. Here’s where iOS and Android come to the rescue with build options for localization testing.
In Xcode you can select a pseudolanguage in your build scheme. For regular localization testing you can choose Double-Length Pseudolanguage to see how your app works in languages with longer strings. (My teammate Eduardo also suggests using the iOS text size settings as another way to test this on the fly.) But for RTL testing it’s especially handy — choose either Right-to-Left Pseudolanguage to get an RTL layout with regular English strings or Right-to-Left Pseudolanguage with Right-to-Left Strings to see the English strings backwards in the RTL layout. Build your app and you can test out the RTL experience, no language classes required!
For Android, you can enable pseudolocales in your build.gradle file. Then, on your device or emulator, go to the device language settings and select English (XA) or Arabic (XB). (If you don’t see those languages, make sure developer options are enabled.) The first language gives you lengthened strings and all kinds of exciting accented characters, but the second is where RTL testing kicks in — you get English strings backward with an RTL layout.
Now, off to file some GitHub issues for the localization bugs I just noticed … 😉