Best Practice | Read the latest blogs, news and views from Infomentum. (2)

Web development is accelerating at an incredible rate - new frameworks seem to pop up every day. Whilst this is exciting (at least to a front-end geek like me!), it can be difficult knowing which new tools are any good and which ones you should be using.

In my last article, The evolution of test documentation; lessons learned from implementing Cucumber, I explained two things. Firstly, how we at Infomentum have adopted Behaviour-Driven Development to define test scenarios, and secondly, how we use Cucumber JVM as an implementation platform for running these scenarios as automated tests.

The old way

I'm going to let you in on a secret. I learnt my trade in a traditional software testing consultancy - I'm talking a waterfall approach to test planning, test case definition and test scripting. Over the last 5 years at Infomentum, I've evolved and have worked hard to optimise Infomentum's testing practices to suit our agile development environment. 

Wait: you need to read part 1 and part 2 first!

The fun side of cultural change

You’ll remember that last week I discussed the crucial need for a cultural change in how we dealt with time logging. After the CX team’s thorough research, we were ready to take the findings – and our ideas – to our board of directors. 

Hint: you'll need to read part 1 first for this post to make sense.

Phase 2: Imagine

The CX team got together to discuss the problems and carry out an internal ideation workshop to tackle them. We knew that we had 3 key tasks:

• Improve people’s knowledge of why time logging is important
• Create a culture of time logging as a habit; and
• Make the systems they needed to use simpler and clearer while having less of them!

I’ve wanted to write something about Infomentum's scrum board since its inception in late 2012. Now seemed as good a time as any to share the story...

During an end of sprint retrospective, one of our developers Jakub said “I'm bored of the board.” That didn’t surprise me.

Wait! Have you read 'What are microservices' blog posts part 1 and part 2? You need to cover those out before reading on.

When it comes to microservices, the million dollar question is: “How do I decompose my monolith into microservices?”. Well, as you can imagine this can be done in many ways, and here I will be suggesting some guidelines.

I’m going to pick up from last week’s post when we discussed the microservices definition, and looked at the alternative approach to microservices, aka the monolith. Make sure you read that before carrying on with this post.

Why is the microservices approach different? Let’s explore the main features one by one.