A day in the life of an mbot

xebiamaaiketesterblogstorymbotdef

Today, I managed to find a diary hidden on one of the mbots we have at the office. I couldn't see it in the user interface, but when I was doing some maintenance on the robot a simple 'ls -la' command in the terminal showed me this hidden content. It was so cute that I wouldn't want to keep it from you! The robot is writing about a workshop my colleagues and I facilitated for ING. Stay tuned for a report about this day written by an actual human: my colleague Erik Zeedijk.

Kind regards,

The test professorRead more →

The Robot Framework Remote Library Interface: using the Remote Database Library to connect to IBM DB2

In the aftermath of my Robot Framework workshop at the Xebia 2015 TestWorks Conf, I received several e-mails from people who had attended the workshop. They were asking questions and describing (smaller and larger) problems surrounding various aspects of their test automation efforts with the Robot Framework. Some of these questions and problems are identical to those that, as a consultant, I encounter in the field. Since the involved topics may thus be of interest to a broader public, I decided to dedicate a series of blog posts to them. Better (very) late than never, right?

The first of these posts will show you how to use the Java Database Library while running RF on Python and also elaborate on why you may want to do so. As an extra, we will be putting the library into actual use as well, by connecting to an IBM DB2 database and, subsequently, running some keywords.

Please note that I will use these treatments also as an opportunity to shed some extra light on various aspects of the RF that we will encounter and that I feel may be of interest to those that would like a somewhat better understanding of RF's internals. So, for some readers this will feel like a mild and acceptable (and maybe even welcome) digression, while for the practically inclined it may constitute an inexcusable transgression. You can't win 'em all, I guess. 🙂

Read more →

Mapping Biases to Testing: Confirmation Bias

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: Sharing Knowledge

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 →

The Ultimate Tester: Build Quality In

XebiaTester_BQI_1

One of the most important aspects of agile working is the fast pace. In an ideal world, you can deliver to production constantly. However, if you deliver software fast, but it is full of bugs, your product has a lower chance of succeeding. As an agile tester, one of your focus points has to be to speed up the feedback loop while maintaining good quality. We no longer want to give feedback about the product with a manual regression testset that takes days or even weeks. That’s simply too much time to waste. Let’s stop that nonsense, we’re better than that.

Before you start automating your regression test on GUI level, hold on a second. Think about what you want to achieve first. What do you want to test on which layer of your application? There are a couple of helpful concepts to help guide you: the testing pyramid, testing scales (to help you map out components of your application and think about how how heavily you want to test those)  and the agile testing quadrants (to see what types of testing you have used and what you are still lacking). Always consider your context and where the risk is, do not write tests without asking yourself what value they provide.Read more →

Test Masters - Robot Challenge

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

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 →

The Ultimate Tester: Value Creation

rsz_value_creation3

Once upon a time, when project managers still thought that building software was a completely manageable and predictable activity, and testers were put in a seperate team to ensure independence, the result was shitty software and frustrated people. Even though the rise of the agile way of working has improved some aspects of software development, the journey will never end. We still have a lot of work to do. Creating good software starts with the people making it, the team. As an agile tester, a tester 3.0 if you will, you are a frontrunner of this paradigm change. 

No longer do you have to sit in a seperate team, crunching requirements to make test scripts that you then manually execute, pretending to be a human computer (how silly is that!). No longer do you have to fake your belief in a Master Test Plan that your test manager urges you to honour. No longer do you have to put your defects in a defect management tool, and then wait for a couple of releases for your findings to be solved.

It is time to take matters in your own hands. It is time to start creating value from the start.Read more →