From the Danish Royal Guard (seriously!) to the automations team at Planday, Brazilian-born Dane Oliver Charity brings a deep passion for understanding problems and designing systems in a new way to our Copenhagen product team. He recently showcased this in a MeetUp with the Ministry of Testing and The Planday Blog caught up with Oliver to find out what this means for our platform.
Oliver Charity takes his love of technology seriously.
From sci-fi to adventure, a passion for using digital tools to solve manual problems — and even electric unicycles! — Oliver is eager to play a part in the way technology can make to make people’s lives easier.
Concrete rules, examples — and a common language — are the key elements of the BDD process Oliver is championing at Planday so that when things go right, they make a subtle but substantial change to your Planday user experience.
What is BDD?
Every day Planday works harder so you don’t have to.
“Behaviour Driven Development brings everyone together — the developers, the Quality Assurance (QA) team and business participants — to get some concrete rules and a common language to collaborate with, and then agree on shared goals about what the platform should be able to do,” Oliver says.
Whether it’s making sign-on to Planday simpler or designing a feature specific to an enterprise business, BDD gets everyone on the same page before we start writing code.
“One of the great things about technology and BDD is that when you have a meeting with a business and you discover all the different parts of it, you write concrete rules and we use those to build it,” Oliver says.
Working in an agile framework in scrum teams, with continuous delivery in fortnightly sprint cycles, our product team has a continuous feedback loop to help design new features and improvements at Planday that help you focus on what really matters.
“BDD is an agile process. We pick the highest-priority feature from the backlog and usually that will have to do with the customer. The customer will speak to the business, and the business will figure out what is the highest priority items, and we draw it in.”
Why do we need BDD?
It’s often said that when a designer and developers’ job is done well, you barely notice it. But behind the scenes, BDD is a big part of making Planday easy-to-use and efficient no matter how you use it.
“Basically, BDD is something that has developed over the last few years. It’s relatively new and it came from that need to get better descriptions of what we’re trying to achieve and better understanding by the team of what we’re doing,” Oliver says.
“In the testing community in general and the software community more specifically, it’s gaining a lot of popularity and attraction. Many companies are really trying to strive for it. We’re still a bit in the early stages at Planday with BDD, but I think compared to other companies, we’re way ahead.”
What does this mean at Planday?
No two businesses — and no two Planday users — are the same, so getting people together to better plan how our user experience makes your every day easier has some real practicality at Planday, Oliver tells The Planday Blog.
“BDD is a really critical part of what we do at Planday,” Oliver says.
“We have a first stage meeting where at least one person from each area is involved, and we literally start with an empty whiteboard. We start just by brainstorming and questioning ourselves.
“What are all the different elements that we need to understand this? So who are the actors in this feature? Are there different types of employees? Are there managers? Is there anything Planday has to do to fit this all together?
“We write all the actors, all the people who are involved in this process or in this feature we’re designing, and then we start writing, “Okay, so what do we try to achieve?”
“To give a more concrete example, I work in the salaries and revenue team, and right now we’re building a brand new page that will allow managers to log on and see how many hours employees have worked, how many hours they are supposed to work, then understand what is the difference between these hours?”
Oliver says getting everyone in the same room helps align everyone to the same purpose.
“One of the great things about BDD is that when you have this meeting and you discover all the different parts of it, you can write concrete rules: you have a single source of truth and everyone is working towards the same goal,” Oliver says.
What’s a single source of truth?
In a busy and scaling company like Planday — with a global reach and an ambitious growth plan — keeping clear about goals and aspirations for the product or feature is essential. Oliver says a single source of truth is a vital part of making BDD a success.
“BDD enables for a single source of truth. So in one place with one piece of text, you have both your requirements from the business perspective, you have the automated acceptance tests from the testing perspective, and you also have documentation, living documentation that is all the time being updated almost by itself,” Oliver says.
“Because if I run the test one day — and let’s say the hours do not match – there’s different scenarios here. It could be that it’s just a bug. Maybe a developer made a change somewhere else that broke that, but if we realise it early we can fix it. So it adds value to the customer, and the customer knows that it will always work as it is supposed to.
What’s a gherkin got do with it?
A Gherkin is more than the topping you throw off your hamburger, Oliver says.
“Gherkin is a notation we use to enable people to both read it in the English language or in any language you select, but also for the machine to understand what it’s supposed to do too,” Oliver says.
“For example, if I have a very simple scenario written in Gherkin, Gherkin is the format to write scenarios in. Given, when, then is the structure of Gherkin. So say, given I’m on the homepage, when I enter valid credentials, then I should log in. I should be in the homepage, right? People can read this very easily, but then it can tell the computer when there is this word entered on the homepage, then you should load the homepage.
“So it’s a way of translating plain English into code so that the machine can read and run the commands or requests you have made of it. It’s like a translator between people and machines.”
And something about a cucumber?
If a gherkin is something you throw off a hamburger, then surely a cucumber is something you use in a facial, right!? But apparently it’s much more than that, Oliver tells The Planday Blog.
“So Gherkin is the way we write it, right? We write these scenarios, and cucumber is the way that we actually manage to make the computer run these Gherkins,” Oliver says.
“We have the Gherkin, which was just the actual notation. Then you have cucumber and it’s the bit that is written to say how to search for a sentence. When the system finds it, it will run a piece of code.
“If Gherkin is the language people can understand, then cucumber is the interpreter that enables computers to be able to understand our language.”
Life at Planday
We already know Oliver is the electric unicycle-riding former Danish Royal Guard from Brazil, but The Planday Blog loves to ask a few more questions of Planday people to see just how diverse our global team can be.
What is your role at Planday?
My role at Planday is as an Automation Test Engineer and I’m part of the quality assurance team. We also refer to just QA.
How long have you worked here?
What made you want to work at Planday?
I dove into the website and read a little bit about it, but actually I think the number one thing that really made me realise that I really wanted to work for Planday was actually watching the customer spotlight videos.
I saw how Planday changed actually their lives and how they’re saving so much time; the employees are happier because they can manage their schedule better.
They know how much they’ll be paid. If there’s an important family event that is happening, they can have flexibility to plan and work around that. So very quickly I realised that this is not just scheduling software, but it’s actually a lot more for the people who use the software.
What does a typical day look like for you?
A typical work day for me starts with the stand up meeting, a usual activity in the agile way of working. I tell people what I worked on yesterday, where I’m going to be today, if there’s any blockers to my success – anything my team can help me with.
Then I would say probably about 30 per cent of my time is spent actually manually testing things. The developers create a feature, and I manually go through them and ensure that there’s no defects, that everything is working as expected.
Then the other 30 per cent of time I spend automating these tests because the more we can automate, the more we can cover without using my own time doing it. So automation is actually key with testing.
Then the other third of my time is spent in meetings, trying to improve our processes, figuring out where we are, how can we move faster towards our goals.
So that’s actually one of the things I really like about my role. I think it’s very varied. I get to work on both the technical side where I get to code and I get to experience the technology, but I also get the human side, having meetings with people, understanding how the products are supposed to work.
How would you describe Planday in three words?
I would say agile, revolutionary, and … It’s funny; I’m thinking about the word happy! I feel like people are happy at Planday!
Tell us something other Plandayers would not know about you
I don’t really have any skeletons. But I am addicted to ice cream!
Even in the winter months, it can be minus five degrees, and I can still eat an ice cream. I love it!