Contact us on 01603 666 073 or [email protected]

How to get what you want from the app development process

How to get what you want from the app development process

How to talk with a ‘Techy’

One of the biggest obstacles faced by developers building mobile or web applications is communication. The app development process is often complicated and requires a lot input from client and developer. Like many technical people, developers speak a language all of their own, which can be quite difficult for a layman to understand. Equally, our clients come from many different industries with which developers are not familiar, so they may struggle to understand what the client wants. Sometimes the client may also struggle to describe how they want something to work. It’s easy to mock up how you want a website to look, put it in front of the client, and say “Is this how you want it to look?”. It’s much harder to mock up the behaviour of a web application – the only way you can mock it up is by actually building a prototype, which can take a lot of time.

As a result, it can sometimes feel like the developer and the client are speaking an entirely different language. This can often cause difficulties on projects, because if there’s a misunderstanding, a developer may spend a week building some functionality to present to the client, only for the client to turn around and say “That’s not what I meant”. This can result in wasted development time, and frustration for both the client and the developer.

Find a common language to discuss the app development process

To help us avoid these kinds of problems, we use a system called Gherkin to describe how we want a web application or mobile app to work. With Gherkin, for every feature you want an application to have, you create a feature file that contains one or more scenarios describing how your application works. It’s very simple and easy to understand, and allows you to describe the behaviour of your application in plain English. Gherkin help us to simplify the app development process.

The body of a Gherkin scenario is structured as follows:

  •     GIven x
  •     When y
  •     Then Z

 

The Given section describes the initial conditions. The When section describes what happens, and the Then section describes how you know the scenario has worked as expected. You can also use And to add additional conditions at any point, like this:

  •     Given x
  •     And y
  •     When z
  •     And a
  •     Then b
  •     And c

 

Let’s use the app development process to buy some Fish and Chips

For example, here’s a simple Gherkin scenario that illustrates how you might go about buying a portion of fish and chips:

Feature: Buying fish and chips

 In order to have something to eat
As a customer
I want to buy a portion of fish and chips

Scenario: Buying fish and chips
Given I am at the fish and chip shop
And I have five pounds
When I ask for battered cod and large chips
And I hand over the money
Then I should receive my change
And I should receive battered cod and a large portion of chips

Note at the top we describe what the feature is. We then have three lines of comments going into further detail about what we want to be able to do – these are optional. Then we give the individual scenario a title – here we represent the act of buying fish and chips.

When you’re buying fish and chips, there are some prerequisites. You have to be at the fish and chip shop – it’s no good trying this scenario if you’re in a DIY shop, for instance. You also have to have the money to hand, otherwise the scenario will fail. As these are the initial conditions, they belong in the Given section.

We then go through the actions required to buy a portion of fish and chips, in this case asking for battered cod and large chips, and handing over the money. These details what happens during the scenario, so they belong in the When section.

Finally, we set out what we happen if the scenario is successfully. In this case, we want to receive our change, and our fish and chips, so they go in the Then section.

App development process in the real world

Now, that’s all very well, but how does that relate to web or app development process? Well, you can apply the same ideas quite easily. Just describe a particular piece of functionality in the same way. For instance, here’s how a shopping cart might work:

Feature: Cart

In order to use the site
As a user
I should be able to add products to my shopping cart

Scenario: Add item to cart
Given I am on the page for “SuperSprocket 3000”
When I click the button “Add to cart”
Then I should see the text “Added to cart”
And the number in “Items in cart” should increase by 1

This should be easy to understand. We start off on the page for a specific product. We click the button “Add to cart”. As a result of this, we should see a message saying “Added to cart”, and the number of items in the cart should increase by 1.

Again, this is fairly easy to understand. Even if you don’t know what a shopping cart is, you can easily understand what is meant to happen.

For a more substantial example, here’s how you might describe the core functionality of Twitter:

Feature: Twitter

In order to use the site
As a user
I should be able to log in, register, log out and tweet

Scenario: Register
Given I am on the signup page
And I am not logged in
When I fill in the “fullname” field with “Bob Smith”
And I fill in the “email” field with “[email protected]
And I fill in the “password” field with “secret”
And I click the button “Sign up to Twitter”
Then I should see the main page
And I should receive a confirmation email

Scenario: Login
Given I am on the signup page
And I am not logged in
When I fill in the “email” field with “[email protected]
And I fill in the “password” field with “secret”
And I click the button “Sign in”
Then I should see the main page

Scenario: Logout
Given I am on the main page
And I am logged in
When I click the button “Sign out”
Then I should see the text “You have been signed out”

Scenario: Send tweet
Given I am on the main page
And I am logged in
When I fill in the “tweet” field with “This is my first tweet”
And I click the button “Tweet”
Then I should see my tweet in my timeline with the text “This is my first tweet”

Again, this is very simple and easy to understand, even if you aren’t familiar with Twitter. The registration, login and logout scenarios are common to many web applications, so you can easily adapt them for your own application. The Send tweet scenario tells the developer that you want to be able to submit a tweet and see it on your timeline

The really great thing about Gherkin is that it’s not just a way to describe how an application is going to work that can be understood by both clients and developers, but it can also be used as the basis for automated tests. Once we’ve agreed on a set of Gherkin scenarios that describe how the application you want to build works, we can then write automated tests that verify that the application works in exactly the way you want. When those tests pass, we know that the application is feature-complete, so as long as both client and developer have agreed on a set of Gherkin scenarios that describe how the application should work to everyone’s satisfaction, then we know exactly what we have to do to deliver a product that our client will be delighted with.

We don’t expect our clients to come to us with a full set of Gherkin scenarios that describe everything their planned application will do – that would be unrealistic. However, it’s very helpful to us if when you contact us, you already have as much of the functionality planned out as possible, and Gherkin is a great way to do that. We’ll help you refine your initial draft scenarios into something that fully describes your application to everyone’s satisfaction, and because we know right from when we start building it exactly what we need to produce, we’ll be able to do it quicker and more efficiently.

This website uses cookies to offer you the best experience online. By continuing to use our website, you agree to the use of cookies.