It is time again for my reading recommendations. I hope you have already missed them. In the last 3 weeks I was on vacation to recharge my batteries and to think about new blog posts. During that time I was mainly offline and the time was just great! You should try it as well :).
However, now it is time again for some really great software testing content that you should read. The 42nd edition of the reading recommendations contains 6 blog posts with different topics. There is a post about flaky tests, a post from Stephen Janaway is providing a cheat sheet for mobile testing which is really great. Katharina Clokie provided again another great pathway this time with the topic “Testing for Non-Testers”. Other posts are “Bug Automation”, “Why Social Skills Are Trumping Cognitive Skills” and “The 10 Do’s, and 500* Don’ts of Automated Acceptance Testing”.
Enjoy reading the posts and send me posts that are worth reading and I will mention you and link to your social links or blog.
Your tests aren’t flaky | WatirMelonThis is a talk I delivered at the Google Test Automation Conference (GTAC) on Tuesday 10th November at Google in Cambridge, Massachusetts. I am going to be using the F-word a lot in this talk. Like a lot. I apologize in advance if I offend. You know the F-Word don’t you? Also known as the…
Lately I was interviewed by Ryan Arsenault from Aberdeen Group on the blog TechProEssentials and by Srinivas Kadiyala for the Testing Circus magazine. Both interviews had a focus on mobile testing, my role as mobile tester, my current challenges at work, how I started my career in software testing and how I started my book about mobile testing. Maybe my interviews on mobile testing are interesting for you and will provide you with some new insights in my daily work life.
The following list is an excerpt from the questions I answered for the TechProEssentials: Read more
This article contains excerpts from my book „Hands-On Mobile App Testing“ published with Pearson Education.
As you can see in the following image, the typical pyramid consists of three layers. At the bottom, there is the automated unit-testing layer, in the middle the automated integration testing layer and at the top there is the automated end-to-end testing layer (including the user interface tests). Each layer has a different size, indicating the number of tests that should be written within each stage. Manual testing is not part of the test pyramid, hence it is shown as a cloud for additional testing work.
But this pyramid is not applicable to mobile apps and mobile test automation. Mobile testing requires a totally different set of testing activities like movement, sensors, different devices and networks compared to other software like desktop or web applications. Lots of manual testing is required to be sure that a mobile app is working as expected in the different usage scenarios. Read more
This time in the “People in Testing” series, I had the chance to interview Katrina Clokie. Katrina is a very passionate software testing expert in various testing fields. She is an active contributor to the software testing community and the editor of the Testing Trapeze magazine. If you have any kind of question to Katrina, you can contact her on twitter.
Daniel: What is currently your biggest challenge at work? Katrina: Since April I’ve been working in a test coaching role. My biggest challenge has been establishing good individual relationships with all the testers I work with. I spend a lot of time thinking about the number of interactions we have and what they are, as I know their primary responsibility is to their delivery teams and in some ways my work is a distraction from that. I am aiming to be approachable and helpful, without being overbearing and annoying. I hope I’m finding the right balance. Read more
You probably all know that Google has started with the rollout of Android M (Marshmallow). Android app developers and testers must know the new features that are coming with the latest version of Android M. Next to the brand new permission system, Android M also introduces Doze and App standby to save battery.
If a user leaves a device unplugged and stationary for a period of time, with the screen off, the device enters Doze mode. In Doze mode, the system attempts to conserve battery by restricting apps’ access to network and CPU-intensive services. It also prevents apps from accessing the network and defers their jobs, syncs, and standard alarms. Periodically, the system exits Doze for a brief time to let apps complete their deferred activities. During this maintenance window, the system runs all pending syncs, jobs, and alarms, and lets apps access the network. (Source: Google documentation)
In order to be sure that your app is able to handle Doze and app Standby, Google provided some documentation on that. Here are the steps to make sure your app handles Doze (instructions copied from the documentation):
Testing your app with Doze
You can test Doze mode by following these steps: Read more
Manage Cookie Consent
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.