Testing

How to create your own Lint rule

jwillemsen@xebia.com

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.

 Read more

Robots bring business and IT together

Erik Zeedijk

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?

Changing teams

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

Mapping Biases to Testing: Confirmation Bias

Maaike Brinkhof

I use terminology from earlier blog posts about biases. If you have missed those posts, read part 1 here. I explain the terminology there. In the second post I wrote about the Anchoring Effect.

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[1] 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.

confirmationHowever, 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[2] . 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.

 Read more

The Ultimate Tester: Wrap-Up

Maaike Brinkhof

ultimate_tester1

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!). 

 Read more

The Ultimate Tester: Sharing Knowledge

Maaike Brinkhof

sharing_knowledge_small

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

Test Masters - Robot Challenge

Xavier Viuda

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 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?

 Read more

The Ultimate Tester: Curiosity

Maaike Brinkhof

In 2014 Bill Sempf posted this Tweet:

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:

 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

Testing Promises with Mocha

wvenema@xebia.com

If you test Javascript promises with Mocha, there are several styles you can use to write your tests. If you follow the Mocha docs on testing asynchronous code you risk writing 'evergreen' tests. Evergreen tests never fail, even if your code is broken. That is something you clearly do not want to happen. So what is the safest way to write asynchronous tests with Mocha?
Read more

The Ultimate Tester

Maaike Brinkhof

xebior1

 

 

Testing infrastructure with Saltstack, Docker and Testinfra

Arjan Molenaar

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!
 Read more