When you are part of a multi-team project in Android, it becomes relatively hard to have a common understanding of how components should be used. This is where Android Lint can help you! In this blog we will show you how you can write your own Lint rules and test them. As an example, we create a sample Lint Detector, which is used to detect whether you have excluded the "secret data" in your application from the Android Authobackup introduced in Android Marshmallow.
Maybe you’ve already read the diary of one of our mBots, if not I encourage you to do so first! So, what was this day all about? How did we come to organise this and what did the participants learn?
As companies decide to adopt a more agile way of working, they also start to form multidisciplinary scrum teams. However, there still is a big challenge. When you work with several disciplines in your scrum team, you are exposed to the risk that you still create mini-handovers. First the business analyst will make the design, the developer(s) will build it, the testers will test it and if you’re lucky the business is happy in the end. Team members tend to keep doing what they’ve always been doing. Nothing really changed! Of course, we cannot realistically expect that the business suddenly starts programming, but it would be great if they know the difficulties that developers cope with. It works the same the other way around. We need to learn from each other and bring our work closer together. Read more
Let me state the ‘bad news’ up front: you cannot fully avoid the confirmation bias. That’s actually a good thing, because if you could you wouldn’t be human. We jump to conclusions (with System 1) when our assumptions are likely to be correct and a mistake is acceptable. For example, when you meet a new person you immediately judge him or her based on stereotypes, what type of clothes the other person wears, his/her posture, etcetera. This happens so quickly that you cannot stop it.
However, jumping to conclusions can be a bad thing when the situation is unfamiliar, the stakes are high and when there is no time to collect more information . This screams ‘testing!!’ to me. We are often dealing with unfamiliar situations, the stakes are high and we usually face a deadline. How do we deal with this? Let’s explore what the confirmation bias has to do with testing.
To everyone who has read all or some of the past blog posts in this series: thank you so much for reading. I hope I have given you some food for thought on where you can improve as a tester (or developer who tests!).
In the past three blog posts we have explored some aspects of being an Ultimate Tester: How we can add value, how our curiosity helps us to test the crazy stuff and how we can build quality in. We learn a lot about these things during work time (and hopefully during personal time as well), but as the Ultimate Tester we want to take this as a step further. What do we have beyond learning? Sharing knowledge!
In this post I urge you all to become a quality ambassador; to share more about the things you’ve learned. Help the testing community further by giving back what you know. Don’t say “but others know so much more than I do, what can I possibly add to it?”. You know more than you think and you can share knowledge in many ways. I will give you some options, ranging from very easy to needing a lot of effort. Read more
The Test Masters series is created to experience testing in a fun and new way. Play games, use robots, experience new tooling and techniques to make yourself a better tester! During the meetups we organize you can try out these new tools and techniques and engage in a friendly competition with your peers. In the first serie we will dive into the Robot Challenge.
The Robot Challenge is a mix of feature/software/hardware testing that will make the Testers think out of the box. The Testers will work together in teams to work out the features presented by the Product Owner. When all features are worked out the teams get the chance to test the features on the presented robot. The biggest challenge will be having working software but still seeing the hardware responding differently. How will the teams handle that?
In 2014 Bill Sempf posted this Tweet:
QA Engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers. Orders a sfdeljknesv.
— Bill Sempf (@sempf) September 23, 2014
His message caused a chain reaction of awesome responses from people thinking of all the edge cases in this scenario. Among the most hilarious responses were:
— James Hollingshead (@bladesjester) September 24, 2014
@sempf Bartender pours one beer and says "Works on my machine"
— Chris McMahon (@chris_mcmahon) September 23, 2014
You can read the rest of the responses here.
This funny example illustrates perfectly how testers think. We think out of the box and don’t assume that some functionality will work because the developer said so and wrote some unit tests. Sure, automation in testing and scripting has its place and use (as we will discover in the next blog in this series), but it seldom proves that the application works as intended as a whole. Automated scripts are usually following a path without feeding the path new data every time. This can give a false sense of security, “we’ve covered this path”, when inputs matter more to find lingering errors. Read more
We’re running a few (virtual) servers, nothing special. It is rather easy to turn those machines into snowflakes. To counter this we introduced Salt. Salt does a nice job in deploying software to servers and upgrading them when run regularly. But how do we counter issues when changing the Salt configuration itself? The solution is simple: Test!