Our Development Methods

Development Methodology

Connamara uses development techniques drawn from the agile software development methodologies of Extreme Programing, Scrum, and Lean. Mainly, Connamara employs the disciplines of Test Driven Development, Continuous Integration, and Automated Testing.

Test Driven Development

At the heart of our development methodology is Test Driven Development. Before implementation begins, a Connamara Business Analyst will gather requirements, which we call “features”, for the project at hand. These features are simple statements, from the user or system perspective, describing what the user or application can and cannot do with the system. From these features, the Business Analyst will create an automated test that describes scenarios that can occur as a result of the feature.

Example of a Feature and an associated Scenario


 Feature:  As a user, I can login to the system.    Background:Given the following users:| username | password || jcdowns  | abcd1234 |
   Scenario: User enters valid username but invalid password.Given I am not logged in

When I login with username “jcdowns” and password “bogus”

Then I should see “Invalid username or password”

And I should not be logged in


The feature and associated scenarios are expressed as a Feature Test via a human-readable language, similar to the example above, called Gherkin.  Feature Tests are executed using the Connamara Testing Framework. The Connamara Testing Framework is based on the Cucumber testing framework. It must be noted that the Feature Tests are written before the code implementing the feature is written.

Once a test passes in our automated test environment, it is considered a regression test and must pass every time the application is built and tested.  The major advantage to this approach is that a suite of system level regression tests are created as the system is being developed, and not as an afterthought once the system is “code complete”.

Continuous Integration

Continuous Integration (CI) is the development practice of merging all developer changes to the source code of a project several times during the day. This practice eliminates the “integration hell” experienced when development teams wait till the last minute to commit their individual changes to the main source code branch of a project.

Connamara utilizes the Jenkins CI platform. Jenkins monitors the Connamara source code repository of a project. Once Jenkins detects a change in the code base for the project (a developer commit of a change), the source code is automatically checked out to a build server, built, and deployed. At this point, all the developer-written unit tests are run.  All Feature Tests (written by business analysts) describing the system features are then executed.  A test report is then produced and emailed to all interested parties.

A build is considered successful if all unit tests and feature tests that are identified to be “regression” have passed. At this point Connamara considers the application to be deployable to a production environment and able to deliver the features described by the passing regression tests.

Automated Testing

As mentioned previously, as part of the Connamara Continuous Integration Environment, the developer created unit tests and the business analyst feature tests are run automatically with each developer commit to the source code repository. The benefits of this approach is that testing is done “early and often”. This catches defects before they can make their way into production and eliminates the need for manual, error-prone, and lengthy manual testing.

Project Management

Connamara uses typical agile methods for project management. At the beginning of the project, features are estimated by the development team and assigned a point value based on their perceived complexity relative to other features. The development effort is broken into iterations (typically, an iteration lasts one to two weeks). At the end of an iteration, the total number of feature points completed (completed means that all scenarios for a feature are passing in the CI environment – no partial credit) are summed. This sum represents the development velocity for the implementation team– points per iteration. Using this velocity (or rather the average of all previous velocities) as an assumption for the future velocity provides an estimate of the time to complete the remaining features.

This velocity and the estimated completion date is reported to our clients at the end of each iteration.

What Connamara Brings to a Project

Connamara has seventeen years of experience delivering quality software to our clients. Our record of success is a direct result of the development methodology we employ, as described above, and our discipline to stick to it.


Previous Post
Blog Home