Here at 7digital, we see the relationship between the customer and the developer as one of the most important aspects of software development. We treat software development as more of a craft than an engineering discipline. Craftsmen back in the day would have constant communication with their customers, receiving regular visits from their customer to discuss progress and alterations as the item takes shape.

 

Over the last twenty years, the agile software movement and extreme programming in particular has championed this with its short iterations, customer showcases and active customer participation in the creation of features.

 

Processes like Behaviour Driven Development (BDD) have attempted to bridge the gap between craftsman and customer, giving developers processes to guide software development based on the desired behaviour of the system rather than through more traditional software engineering disciplines.

 

Tools, such as Cucumber, actualise this process. Cucumber (and similar, older tools such as Fit, Fitnesse and Storyteller) provides an interface between the customer and the developer by providing a human readable specification of the software that is also understood by the computer. Based on the description, the computer executes the software accordingly.  The customer can then see immediately if the software behaves according to the specification.

 

Of course, translating human text into instructions for a computer isn’t easy. While modern programming languages on the surface do read like English, and tend to use English words, it takes a certain amount of experience to appreciate what the actual behavior of a piece of software is just by reading the code. The skill in using tools like Cucumber is in translating what the customer understands into something the machine can interpret.

 

If you’ve been looking for some time for a resource that offers a good grounding in using a tool like Cucumber then you’ll be pleased to hear that one has arrived courtesy of Matt Wynne and his Cucumber School.

 

The Cucumber School is a series of video tutorials for learning and practising how to do this. Matt Wynne takes you on a journey from the initial planning session with the customer through developing an application (‘Shouty’ - a social networking app). Throughout he highlights potential pitfalls that many teams using this tooling hit the first time they try it out. He does this with wit and aplomb. The videos are lovingly animated and include advice that Matt has built up from his many years of using and contributing to Cucumber. All this advice is condensed into six 20 minute chapters and it is advice that would otherwise take you hours and hours of trawling through blog posts and talks to discover.

 

Cucumber School covers just about everything you would want to tell developers about BDD in a little over 2 hours. To get a flavour of the style of the course the first video is available for free at the Cucumber School website and in itself demonstrates the power of BDD as a communication tool.

 

At the heart of successful software development is constant communication between the development team and customers with a business problem to solve. Cucumber provides an effective way of taking these conversations and turning them into a set of automated specifications that describe the software built. Introducing Cucumber to your development process can initially seem daunting so to get you started try The Cucumber School, which will help you to get well on the way to making it a useful and valuable part of your development process.

 

 

About the author:

For nearly two decades Leon Hewitt has been creating software to solve people's problems. He has worked at 7digital since 2012. When he's not waxing lyrical about software you can hear him chat about his favourite television programme Doctor Who on the Never Cruel or Cowardly podcast. @DocLeon

 

Tag: 
Cucumber
Learning
Code Learning
Test Framework
anna.siegel@7digital.com
Wednesday, May 11, 2016 - 04:20

Today marks the beginning of the Technical Academy Tour as Academy Coordinator, Miles Pool, VP Technology, Paul Shannon and later, former apprentice, Mia Filisch head out across the UK to talk about our Technical Academy.

 

Continuous learning has always been part of the culture at 7digital and the Technical Academy allowed us to focus those ideas and start hiring apprentices. Changing the team entry requirements and providing a defined period of training allowed us to attract people from more diverse backgrounds and has increased the proportion of female developers in our team; it’s also strengthened the culture of learning and knowledge sharing at every level.

Emma-Ashley Liles
Monday, April 4, 2016 - 13:48

Since I started at 7digital I’ve loved our belief in continuous improvement. Throughout our history as a company we have had a number of influential women working in various parts of organisation yet I knew there was more we could do to improve the diversity of our tech team.

 

Mia.Filisch
Tuesday, December 1, 2015 - 20:10

7digital software developer Mia Filisch attended the October 28th Velocity conference in Amsterdam. She was kind enough to share her account of the core takeaways here with us. She found that the core recurring theme around security was enough to inspire some internal knowledge sharing sessions she has already started scheming on. The diversity of insights led to a productive and informative conference. See below for her notes.

 

Key takeaways from specific sessions:

Anonymous
Friday, July 17, 2015 - 20:18

by Alan Hannaway, 7digital Product Owner for Data 

We often ask ourselves How different do you think our listening experience will be in the next ten years? It’s a difficult question to answer, but a great one to ask. Serving an industry where there is constant change, the question brings us right back to where we should be focused: the way people experience music and radio.

Having powered music and radio services for over 10 years, 7digital knows how to deliver listening experiences that delight millions of people. We regularly reflect on what works, and what doesn’t. Sometimes it is clear what works well, and if you have a culture where you fail early and loudly (we do; it is part of our tech manifesto) you can sometimes see exactly what you did wrong. It’s not always easy though, and when the reason for something happening is not at all clear, finding out why it happened is difficult. How can you make sure the reasons you say something happened, are because of the reason you have identified? Correlation does not imply causation.