Creating a cascading resource import structure for Robot Framework: Pt. 1/3 - Introduction to resource sharing

This is the second post in a series that will address some of the problems and questions surrounding the usage of the Robot Framework (RF), that I encounter frequently in the field. Click here to take a look at the first of these posts. As I have stated in the introduction to that post, I will sometimes use these treatments also as an opportunity to make small digressions, so as to shed some light on the internals of the RF.

This post will show you how to implement a simple and yet very efficient mechanism for resource sharing within the framework. Actually, I will use three separate posts to do so. The post you're reading now, will be the first of these.

Robot Framework provides an out-of-the-box mechanism for sharing, i.e. re-using, various types of resources. However, depending on the size and complexity of your test automation project, this mechanism can sometimes entail quite some maintenance work in and of itself. In three posts I will describe a setup for sharing, that will virtually eliminate the involved maintenance effort. Additionally, this setup will provide you with a few, very fundamental, abstraction layers that you will have to apply in any given test project.

So, let's first have a look at the main types of RF resources and at how these resources can be reused within the RF (first post). Then we will describe the problem surrounding this native mechanism (second post). Finally, we'll be providing a solution to this problem (third and final post).

Read more →

SPACEMAP - organising a motivational environment

Introducing the SPACEMAP! A 'map' to gain insight into motivational problems within an organization/department, so that coaches and managers no longer have to talk about vague motivation problems, but instead tackling the lack of autonomy within the teams.

The map consists of generic 'work factors' that are required to create a motivational environment.

SPACEMAP - organising a motivational environment

the SPACEMAP was developed by Xebia coaches

Read more →

Combining Domain Driven Design and Behaviour Driven Development

In my previous post, I discussed why we want to write software with empathy in mind; software that is understandable for peers. For us to create software with empathy in mind, we need to create a shared understanding of the users' needs; the needs we are trying to satisfy with our software. Practices like Domain Driven Design (DDD) and Behaviour Driven Development (BDD) can help us achieve this. By using Feature Mapping (a technique from BDD) and improving this with Event Storming (a technique from DDD), we can create executable specifications and a model for our business needs at the same time. This way, we can write software and tests that match the shared understanding the business has, which enables us to ship more value faster.

Read more →

Using Specification by Example / BDD for your refinements

When I'm joining new teams at clients it often becomes clear that the added value of refinements is not always seen. Team members complain that hours are wasted. The refinement sessions shouldn't be long draining meetings with endless discussions. Refinements should instead provide a clear added value in the form of requirements that the whole team can work with to deliver added value. How do you shape your refinements in a way that they add value? Read on to see how BDD / Specification by Example can help you!

Read more →

Kubernetes and on-demand CI builders

Let's say you've got a CI/CD pipeline and you would like to run builds in containers. You could just configure Docker on one of your machines and point your builds there, but why not use something a bit more scalable? Enter Kubernetes, a leading container orchestration platform, which luckily offers several options for using its self-contained pods as on-demand CI builders. Things like sharing sources between containers and networking will be handled for you, so all you'll have to worry about is specifying the desired image.

In this blog, I'll be exploring two of those options in commonly used CI tools, namely Gitlab and Jenkins, and will explain how to configure the Gitlab-runner or Jenkins Kubernetes plugin to run on-demand CI builders on a Kubernetes (or "K8s") cluster.

Read more →

Autonomy – Taking the wheel

I remember when the Product Owner stepped into our room with a new user story. He asked if we could make a minor change to one of our web pages. What he did not know is that nobody understood the code, nor the ancient documentation that was written for this webpage.  After running a few tests we even discovered that half of the features did not even work. We made a proposition: we implement this user story if we get three extra weeks to rebuild this page and rewrite the documentation. Luckily our awesome Product Owner understood our situation and we managed to get these extra weeks.

Read more →

Running Kubernetes locally with Docker on Mac OS X

Fast feedback loops are instrumental to gaining confidence in changes and achieving a steady pace of delivery. In many teams, Docker has been an important force behind removing delays in the pipeline to production. Taking control of your environments is a powerful move to make as a scrum team.

Seeing that Kubernetes appears to be becoming the leading orchestration platform, chances are that the containerized applications you and your team are working on will land on a Kubernetes cluster. That is why I was excited to see that in the latest version of Docker it is now possible to run a local Kubernetes cluster. In this blog you will learn how to start a local Kubernetes cluster with the latest Docker version.

Read more →

Mastery - being the best version of yourself

I was 21. I just graduated from MBO college, it was night and I was strolling around town with a couple of friends. We just celebrated our graduation and did not want to go home. After a few hours, we got lost and arrived at this big haunted mansion. We saw a sleek figure standing at the entrance. He was looking directly at us, and asked: “Would you like a tour?”, inviting us in. For a second we looked at each other and then we succumbed to our curiosity, following the man into the mansion. With no idea what could happen next.

Throughout my life, I have done several stupid things like the example above. And I knew these were not my brightest moments, but my curiosity simply took over. I wanted to explore or discover something (and I also love to get a good story out of it).

But whether you love taking risks and doing stupid things, or you prefer to dive into books and study in a safe zone, we all have the same internal drive to learn, to grow and to become the best version of ourselves. This is called ‘mastery’ and it is the subject of this blog post.

Read more →

Version control strategies and Continuous Delivery

Continuous delivery is a software development practice in which a team or a company strives to keep their software in a deliverable state at all times. Closely related is continuous deployment, in which the software itself is actually released to production as often as possible. Continuous delivery is a prerequisite to continuous deployment. From a business point of view, continuous delivery allows a company to quickly adapt to changing market developments, respond to user feedback, etcetera. However, what is in my opinion a much stronger argument in favor of CD is that it enforces a large number of software development practices; it’s a core principle which can be referred to when making decisions about the practice of software development, ranging from how version control is handled, test and release automation, etcetera.

In this post I’ll go into the software development practice of version control, and discuss a number of strategies in the context of continuous delivery.

Read more →

The behavioural economics of bugs in robots

All contending teams, without exception, experience a moment at which all members are standing around the table, looking at the robot; this is not what’s supposed to happen. Shouldn’t be a surprise, we told them in advance there would be bugs. Unfamiliar with the codebase and the hardware, it is now their job to find the bugs and fix them. They do know what the robot should do: ‘it should follow the black line, once you press the start button’.

We have been doing these robot challenge workshops for a while now. They’re great fun, for creating a shared understanding between business and IT, or experiencing an acceptance test-driven approach to software development. The mBot robots bring a highly visible aspect to the software’s behaviour.

Read more →

Share This