Everybody Tests

The rent is too damn high. Okay, let's look at the topic of device clouds. Microsoft's recent purchase of Xamarin means that now Google, Amazon, and Microsoft (3 major cloud computing service providers) all have their own device clouds which they also lease time on to the public (well, Google's purchase of Appurify hasn't resulted in that yet but it's coming soon and is currently in Beta). That makes 3 major cloud players who also build mobile apps buying their own device clouds and renting their overhead to the public. To me that's purely confirmation that if you intend to use real devices and you're a developer or a company that does a lot of development and testing of mobile apps, particularly on Android, you had better have your own cloud. If it were cheaper to rent than to own, why would those three major cloud providers buy existing device cloud as a service platforms? In reality, Google Ventures was the primary early investor in the Y-combinat...

UI automation is like a dumb computer user; a really, really, profoundly dumb computer user. It will fail, it will be obvious that it is failing. But it won't always know immediately why. Sometimes just observing it's failures by means of a screenshot of the failure is all it takes. As you recall from my last post on the topic , screenshots on failure are a potent way to quickly reduce the time to answer the question of why a UI test case failed. Google's Android Test Tools team likes screenshots enough that they've included the capability inside the UiAutomator framework . Square likes it enough to have included it in their Spoon framework . And as we all remember, Robotium's been doing this for a long, long time . The main advantage to the approach I described previously is that screenshots would happen automatically based on errors of any kind in the test lifecycle. As of now, you're all probably migrating or have already migrated to the newer Android...

Android Fragmentation, UI Testing and You Last year, Eddie Vassallo over at Gigaom.com joined the rest of the well-informed tech bloggers in agreeing that at least as far as developers are concerned, " [it's] 2014, and Android fragmentation is no longer a problem. " While the developers have tools and patterns that will allow them to successfully build appealing, rich experiences for any screen size and support devices many years past their prime, just the term "Android fragmentation" can intimidate many people trying to decide what phone or tablet to buy. The developer has the ability to access powerful adaptive interface layout APIs and rely on Google Play Services to update crucial dependencies such as Maps and Push Notifications. That behind-the-scenes flexibility is meaningless to an end user staring at a dizzying array of devices from OEMs hellbent on stamping their unique mark on the user experience. Looking at phones such as the Samsung Galaxy Note...

Success is a journey, not a destination. So stop running. As a tester, one of my most repeated routines includes the following: downloading a new build from our CI server uninstalling the build from my test devices (note the plural) launching the app for a specific set of tests or investigations.  This happens many times a day, each day, all year. This routine also has many variations based on whether I just want to clear app data and relaunch it, whether I have a different method to launch the app in mind (different starting activity, different intent extras, etc). On top of all of this, there are details about the build which are relevant to any resultant actions I take in our task/bug tracking suite such as build number, device information, etc. This kind of jumble is cumbersome and time-consuming to manage manually. The whole reason to manage all of that process and information is to maintain a consistent practice of reliable reproducible tests and rich environment an...

Would W. Edwards Deming have a QA team if he ran a software company? For those of you who don't yet know where all this Agile stuff REALLY got started, here's some homework. reference:  http://en.wikipedia.org/wiki/W._Edwards_Deming .  The entire nation of Japan might be justified in thinking he's a pretty important guy. When I came across that article and it immediately forced me to question how any company that chooses to claim Agile development practices can have a QA team. My world was rocked just a little. Fascinating bit of history there, isn't it? If you're cheating and haven't yet read that article while simultaneously not yet knowing the man, his philosophies on Quality, and are simply reading my blog post further, you're cheating. Seriously go read it. I'll wait. For a quick summary, here are some important points to Deming's methodology: Quality is everyone's responsibility Eliminate quality control Encourage quality over ...