Behaviour Driven Development in a nutshell

Behaviour Driven Development in a nutshell

If you’re new to Behaviour Driven Development (BDD) and don’t understand the jargon surrounding it, this is the article for you. This article will explain the most fundamental concepts as well as the basic implementation of this agile methodology.

Let’s start by clearing up the misconceptions. BDD is not limited to test automation and it is not about tools. Fundamentally, BDD is actually about great communication, where an application is specified and designed by describing in detail how it should behave to an outside observer. In other words, BDD is about working in collaboration to achieve a shared level of understanding where everyone is on the same page. That’s the basic understanding you need to know. Easy enough.

So, what does this ‘great communication’ mean for software development?

Great communication means:

  • A usable product first time round, which allows you to get your product to market faster
  • A lower defect rate and higher overall quality
  • A workflow that allows for rapid change to your software
  • A very efficient and highly productive team

How is it done?

Meet our key stakeholders/teams:

Developers • Testers/QA • Project Manager/Scrum Master • Product Owners/BA

 

To illustrate what happens when you implement BDD, here are the before and after scenarios:

Before implementing BDD

Traditionally, software is designed in a waterfall approach where each stage happens in isolation and is then passed along to the next team. Think conveyor belt factory style:

  1. First the Business Analyst defines requirements
  2. Then the development team work on these requirements and sends for testing
  3. Then testing discovers lots of bugs and sends back to the development team
  4. Things are miscommunicated in transit so repeat steps 2 and 3 back and forth until you run out of time or budget
  5. Release software

The problem here is that everyone is in isolation, interpreting the requirements differently along the way. By the time code is handed in for release, resources are drained, and people are frustrated as there are issues that could have been avoided had everyone just been working together initially.

After implementing BDD

  1. Business and PO/BA have a set of requirements ready to implement
  2. BA, Developers & QA work collaboratively to refine these requirements by defining the behaviour of the software together. Thinking from the point of view of the user, they create detailed user stories. Throughout this process they address the business value of each user story and potential issues relating to QA that may crop up
  3. Each story is given an estimate of how complex it would be to implement
  4. The whole team now has a strong shared understanding of the behaviour of the software and when it will be considered complete
  5. Begin Sprint: Developers & QA then work together or in parallel to produce a product that is ready for release

 

BDD

 

This process saves time and money and is incredibly efficient. The core element of this efficiency is the team’s clear understanding of scope and what the fundamental features and behaviours required are. Because of the collaborative nature of BDD, issues are brought to light that otherwise would be an afterthought. For example, how a feature might behave differently on mobile or how a feature might deal with a large number of users. These are considerations that should be addressed from the outset.

What is the best way to implement BDD?

Just because people are in the same room or present at the same meeting doesn’t mean they will collaborate effectively. Each of the stakeholders play a crucial role and some teams/individuals may need to change their way of doing things to make sure that collaboration actually happens. The image below outlines the key deliverables for everyone involved when adopting BDD:

 

BDD

 

An example of BDD in practice

BDD is a risk-based approach to software development; it mitigates the likelihood of running into issues at crucial times. Teams at ECS Digital have been using the BDD process effectively, including  implementing a website feature for a popular media client. The client wanted to create a swipe feature where more mobile users could swipe to see different articles and move through the sections easily. Everyone was collaborating from the initial stages and the team was able to ensure high quality on the website throughout the process of implementation.

With a clear and shared definition of what the website would be like when completed, they were able to innovate further to mitigate the risk involved. They decided that during times of low traffic they would send users to the new website with the new swipe feature and get feedback. Then during risky times of high traffic users would have the usual website without the new feature. This allowed the team to ensure that when they made the feature a permanent part of the entire website they were taking as little risk as possible.

If this team was not utilising BDD techniques by defining the website’s behaviour in detail and involving each team in the development of requirements, they may have released the feature without such precautionary measures or run into many issues when approaching the release date.

If you’re interested in understanding more about BDD and delving into some of the jargon surrounding it – “gherkin syntax”, “the three amigos”, “impact mapping” & “living documentation” – read our previous article here: Behaviour Driven Development: It’s More Than Just Testing

Kouros AliabadiBehaviour Driven Development in a nutshell
read more
Tooling and efficiency teams

Tooling and efficiency teams

ECS Digital has been operating in the DevOps space for over 20 years and this success is mostly down to our focus on self-improvement and innovating for the benefit of our clients. Our recent acquisition of QAWorks was largely initiated to support the continued efforts in the digital transformation sphere, focusing primarily on strengthening our expertise in software quality and delivery.

What we’ve seen since this coming-together is a greater offering for our clients – not to mention an increase in the number of smart-minds looking to evolve our existing tools and processes. This ‘fresh blood’ has a mix of experience – with some primarily working within big teams in large organisations where the division between development and test was not aligned to delivering business value.

As has been seen from successful adoptions of modern software delivery techniques, shifting left to a more agile methodology results in your development and operation teams working for each other. It also offers them more autonomy – resulting in smaller wait times and reduced feedback loops.

But what happens when you begin to scale this model within larger organisations?

For ECS Digital, the first step of any digital transformation is enabling you to successfully integrate an agile process. Part of this is helping you communicate and adopt a new culture, as well as introducing an engineering mindset to test– this can involve introducing SDETs to your development teams to ensure any feedback or strategies can be put in place quicker. Quicker feedback means improved lead-time and higher quality of applications.

Once you reach a level of confidence in your new process and are comfortable with the effectiveness of your teams and automated tools, our consultants begin to look at reusability – taking an in-depth view of your processes and offering recommendations of how to take them to the next level.

Focused primarily on larger organisations, our team has developed a quality assurance strategy that supports businesses who have around 25 or more working within the software delivery structure. Once you reach this magic number, an opportunity cost presents itself. 

This opportunity looks to do the following:

  • Reduce duplicated efforts,
  • Improve efficiencies of individuals and teams,
  • Recognise issues that are affecting more than one teamand create a reusable solution,
  • Remove the risk of gatekeeping behaviour by breaking down the silos and cultivating a culture of collaboration between teams 

Internally, this opportunity is known as introducing a ‘tooling and efficiency team’ (official name to be confirmed). Not only are these teams proving successful in current client work, they are a logical next step for those wishing to maximise their agile business model.

In short, this team consists of engineers with a broad skillset and sits within your business permanently. They are responsible for keeping a comprehensive eye over all your development and operation processes and specifically look for areas that are underperforming or no longer fit for purpose. Once identified, they create reusable solutions to combat individual and company-wide inefficiencies.

But if your agile methodology is already delivering on all your performance targets, why is this new team important?

Performance

By analogy, if you have a one-man operation and you invite an additional person to join this team, you are doubling your effectiveness. If work-demands require a third or fourth member of the team, you are again increasing your efficiencies – but as you scale, this math only works to a certain number. It is very much a balancing act, but what we’ve found whilst working with clients is once you reach a large development team of around 25, each new member starts to become less efficient.

By creating a one-stop-shop in the form of a tooling and efficiency team who can afford to spend the time looking for and creating tools to keep your business adapting, you are maximising ROI because you are making the most of the staff you have. This can be seen in our recent client work with NewsUK.

A reoccurring long-term objective for our clients is to increase the speed of delivery whilst maintaining quality. Quality assurance and automated testing are essential to helping them achieve this – and is the reason why a tooling and efficiency team is working so well. We work alongside our clients’ principal engineers to maintain a clear direction for this new team to move towards, measuring against agreed targets periodically. The benefits have so far been a strengthening in DevOps capabilities, as well as a strong improvement in development efficiencies and overall quality.

“ECS Digital consistently provide intelligent, hard-working and professional individuals who always manage to work well together. Kouros provides a strong organisational and delivery focused attitude that resonates through the team – who have made some invaluable and original open source products that will benefit us and others in the future. They are more than simply a QA team, but can-do developers who aren’t afraid of a challenge and putting the client first”

Craig Bilner, Principle Developer at NewsUK.

The transition to this efficiency model requires a level of collaborative consultancy to help oversee the adoption of the new team and integrate them with others already in the structure. ECS Digital engineers have the capability to enable adoption by working alongside your current team or by operating autonomously / self-managed within your business.

Their ability to constantly inspect, improve and adapt aligns with the very nature of agile methodologies, making it an ideal structural change to invest in long term.

Whilst our tooling and efficiency teams are an additional offering to our DevOps consultancy, it is a necessary next step for those wishing to take their agile business model to the next level.

ECS Digital is an experienced digital transformation consultancy that helps clients deliver better products faster through the adoption of modern software delivery methods. Our recent acquisition of the UK’s leading technical software testing organisation, QAWorks, means we’re well placed to offer expert advice about how tooling and efficiency teams can bolster your digital environments.

If you’d like to know more about how the tooling and efficiency approach could benefit your business, drop us a message here.

Kouros AliabadiTooling and efficiency teams
read more
Applying an engineering mind-set to test

Applying an engineering mind-set to test

How do you continually deliver software with limited time and resources? Where manual testing has been an integral part of software development since the introduction of waterfall methodologies, this process takes a lot of time. And unfortunately, time equals money.

DevOps and automation are two ways modern businesses have responded to the need for increased speeds and agility, especially when it comes to application deployment. Both enable features to be released quicker, giving businesses the chance to react to market changes in realtime and keep ahead of their competitors.

Software Development Engineers in Test (SDETs) are an integral part of any agile transformation. They are the key to ensuring that software can be developed quickly and with confidence, building a bridge between development and testing.

Testing is a rapidly evolving field and key to good software development practices. Today, manual testing is too time consuming and resource hungry to be practical. Instead, automation enables organisations to release features and react to market changes faster.

SDETs have long been a feature of DevOps methodologies, helping to improve automation and give developers more ownership of their applications. They play a vital role in the process of shifting from waterfall models to agile methodologies and represent just how far application development has come over the years.

The problem with waterfall

Traditionally, software development used waterfall models, with progress on the project flowing steadily downward (like a waterfall) through several phases. The origins of this methodology lie in the industrial age. A factory production line has a number of stages to create the finished product, at the end of which it’s tested to make sure it works as designed.

This is fine for an assembly line but it has a number of serious problems as a system for releasing software, including:

  • Software releases are infrequent – potentially months apart – because each iteration needs to go through the entire waterfall process
  • It’s slow to deliver new features and react to requests from the business / customers for the same reason
  • There tends to be a lot of bugs in the finished product. Fixing them is often scheduled for the next release, months down the line

An agile solution

Agile methodologies attempt to solve these issues by bringing all the processes closer to the development team. This is known as ‘shift left’, instilling the idea of fail early, fail fast. The intention is to catch problems as early in the process as possible, rather than seeing testing as an entirely separate stage in the creation process.

It works. Today, software is being released faster and more regularly thanks to agile methodologies. However, this increased velocity means that organisations no longer have the capacity for a team of testers to manually verify every stage of the development process.

To cope with this, organisations need to be moving towards a modern testing strategy – with automation and SDETs as integral parts.

Why using SDETs is the way to transition successfully

Organisations already using agile methodologies such as DevOps often rely on SDETs to think differently, providing robust fast feedback to developers on how an application is behaving and writing automation code.

They are responsible for creating a shared understanding of the feature and thinking about potential edge cases or unhappy paths and asking questions that explore the features further. SDETs are also capable of looking at developer workflows to find inefficiencies. As a result of this, they will inspect and adapt the current quality pipeline.

This all-encompassing role has stemmed for a wider cultural shift, where teams own the quality of an application and everyone in that team has the responsibility to deliver a feature from inception to production.

At ECS Digital, SDETs need to have skillsets that can deliver on modern approaches to testing and for organisations that are undergoing digital transformation. This makes them an essential part of implementing the informed technical approach we take to testing and quality.

Our recent work with Global News Corporation and a world leader in the oil and gas industry demonstrates the importance of coupling SDETs with any transformation process. Global News Corporation, for example, optimised the role of a SDET whilst we helped deliver an engineering transformation. This transformation included the implementation of a continuous delivery process and culture which saw their delivery teams fully build, test and deploy within 20 minutes. Their reduction of regression test times also decreased from three hours to ten minutes and they had a healthy boost in sales thanks to an increase in their average app store rating which jumped from 3 to 4.5 stars.

Comparatively, we successfully introduced a test first approach throughout engineering and a full CI pipeline and culture for our world leader in the oil and gas industry client. This positively changed delivery across the oil trading platform, reducing regression times from four weeks to 30 minutes and providing a $50million a year saving.

What follows a successful transformation?

Our approach recommends that once clients have an agile methodology in place and feel they have made progress with fulfilling their digital implementation objectives, they can start to look at making efficiencies elsewhere. This usually comes at a time when a client’s digital agility has matured enough that the teams supporting these efforts would benefit from the recommendations of a ‘tooling efficiency’ model.

At ECS Digital, this is just one of the new models we are recommending to clients well into their agile methodology transformation, since it removes SDETs from development teams with the following key changes:

  • Developers becoming wholly responsible for the quality and testing of applications, including writing automation testing code.
  • SDETs focus on creating tools to make writing tests for developers trivial, as well as looking at developer workflow in order to increase the efficiency and confidence of the application.

We are successfully implementing this model in current client work. It’s a step up for organisations who are already running agile confidently and want to move up to the next level. It’s also a proven process for those wanting to implement agile methodologies but who need a trusted partner that offers a progressive business-first approach and a team with the knowhow to elevate their business before they do.

Transitioning to an SDET model is our recommended approach to begin in agile testing and digital transformations. Creating a communal ownership of quality is a key part of this and by bringing the traditional test and development roles closer together this is made a lot easier.

If you’re looking for help accelerating change within your business, get in touch with us here.

Efficiencies you can share across team

Kouros AliabadiApplying an engineering mind-set to test
read more
Why Continuous Testing is crucial to DevOps

Why Continuous Testing is crucial to DevOps

Getting testing right – or wrong – can have enormous consequences for businesses in all walks of life, from both reputational and financial perspectives. Take British Airways, who suffered a disastrous datacenter outage in May 2017 that led to flights from Heathrow and Gatwick being grounded for almost 48 hours. Or market-making firm Knight Capital Group, who lost $440 million in 30 minutes in August 2012, owing to a bug in its trading software.

While most software testing goes unnoticed by consumers unless something goes wrong, there are companies who proactively enhance their reputations by sharing what they do. Netflix’s Tech Blog contains a remarkable amount of detail on the streaming giant’s continuous testing practices.

Continuous testing and automation is a crucial piece of the DevOps jigsaw, where the full benefits can only be realised if everything is in place, with automation and monitoring at all stages of software development and operations.

Worldwide, more and more companies are trying to implement DevOps across their software development and operations – the State of Testing Report 2017 saw a 12% increase in DevOps use compared to 2015.

This is a significant rise but, from our experience, problems often occur when DevOps is implemented but testing is left behind. Continuous testing and automation should be seen as a precursor for a DevOps implementation, rather than something to fit in as and when.

Automated testing

If the ultimate aim of DevOps is to have the confidence to release at any given moment, knowing that neither your infrastructure nor application will fall apart, then testing based on old working practices just won’t cut the mustard.

Ideally, all the required elements for DevOps are ready before any kind of development begins but businesses usually need to implement DevOps on to an existing organisation, full of processes and tools that are at different stages of readiness. DevOps is more often an upgrade, not a clean install.

For release on a regular basis, whether that’s daily or another timescale, you need a set of tests you can automate and have confidence in. An old-fashioned testing cycle of two weeks, say, ties your hands; you can either release quickly or be confident about the quality of the release, but not both.

It’s also important to remember that ensuring things are working is only part of a good testing model. A major aspect often overlooked by methodologies outside of continuous testing is the role that testing plays in helping to communicate, define and deliver the original business objectives using techniques such as Behaviour Driven Development (BDD).

Getting it right 

Good infrastructure and platforms are integral to successful testing and a DevOps mindset can help make this happen. A good example of where these worlds come together to enable more effective and quicker testing is containerisation. One of the many benefits is that you can have a production-like environment that you can start up and bring down quickly and easily. You also have complete control over that environment, so you can change the data, simulate network interruptions, simulate load and so on, with complete safety.

Many organisations have tried to adopt Test Automation with varying degrees of success. According to the State of Testing Report 2017, 85% of businesses are using automation to some extent in their testing processes but under a quarter of those are applying it to the majority of their test cases.

Ultimately, implementing a DevOps process is futile without backing it up with good continuous testing and automation. The rewards are there to be claimed. Getting testing right is the key to achieving the full benefits of DevOps and actualising business value.

Over the coming months we will be posting more articles where we delve deeper into the relationship between DevOps and continuous testing, and the benefits it can bring to your business.

Here at ECS Digital we’re always happy to talk about what we do, why and how. If you’re interested in finding out how we can help you, please do get in touch.

Kouros AliabadiWhy Continuous Testing is crucial to DevOps
read more