Introduction

This document aims to get you starting with (GP). (GP) is a tool integrating executable specifications and automated functional testing into software development processes, thus reducing any ambiguity related to the expression of needs between all actors.

This document should be read for instance by

• Business analysts who are specifying the expected behaviour of the system under development,
• Programmers who are implementing of course the system under development, and programming a thick layer of code allowing the system to be tested thanks to (GP),
• Testers who are checking that the system under development is meeting the expected behaviours.

If you don’t know what is an executable specification please read carefully the section [What_Is_An_Executable_Specifications].

If your are familar with the executable specification concept you can directly dive into the section [What_GreenPepper_tools_do_I_need].

Information about the (GP) tools installation is given in the section [How_to_Install_GreenPepper].

Then you will find quick steps helping you to actually kick start with (GP) in section [How_to_Run_My_First_Executable_Specification].

Finally, please take advantage of the [Glossary] in which we have explained the most frequently used terms in this document.

What is an executable specification?

Now more than ever, the need of responsiveness and high quality regarding the software product we are delivering becomes urgent. Realization time from the concept to the solution (time to market) must be drastically shorten.

One of the most challenging issues is the time we invest to check that a software product meets perfectly the expected requirements. These days, dedicated teams are spending time to manually and massively write down the expected behaviour. The other side, additional teams are spending time to validate manually the realized product against the documented behaviour.

The fact is that alternative and more efficient ways exist and they adress both following goals : * reduce waste of time for the company, * deliver more valuable product to costumers.

How is it possible?

The traditional way is often similar to this one:

1. Team of Business analysts write down detailed specifications to heavy documents. They try to anticipate all the expected behaviours (functionalities) of the system under development. This step is done up front of the realization stage of the product under development. This stage can be long, very long.
2. After a relatively long stage of realization, comes the time of validation : QA people are taking test to check if the product mets the expectations described in the specification documents.
3. At the end of this validation stage, it is common to find out issues (or also called defect) and at that time, it is very difficult to predict when the product will be actually finished.

The new way to deal with specifications could be that one:

1. Business analysts are working close to (or into) the development team. They only work on a few behaviours (or functionalities) at the same time.
2. Business analysts write specifications into (GP) and programmers implement the corresponding functionnalities.
3. As soon as the functionnalities are done, anyone can execute the specifications and check if the system under development are meeting them

The benefits of the ES (executable specifications) approach regarding the traditional way are the following:

• the time to discover an issue in the product is highly reduced, so the corresponding cost are also saved,
• the risk of misunderstanding specifications is highly reduced since the specifications are directly executed and tested, there is no place for ambiguity,
• the risk of developping unused fonctionnalities are highly reduced because developpement team is working close to the specifications (we say here requirements development driven).

What GreenPepper tools do I need?

What is Confluence?

Managing executable specifications is done thanks to a wiki that every team member should access to. This wiki must be Confluence including the (GP) plug-in (also called (GP) Toolbox). To install Confluence and the (GP) plug-in, please read section [How_to_Install_GreenPepper_for_Confluence]. Use the Confluence wiki to create, edit and execute the (GP) specifications.

Work environment for Java

Writing the specifications in Confluence is not enough. To make them executable you need to implement source code called fixtures. Figure above gives an overview of the different (GP) tools within JAVA work environment.

As a JAVA developper you may use

• Eclipse plug-in to interact efficiently the system under test (JAVA source code) and the specifications (Confluence pages)
• Maven plug-in to automate the run of specifications