Tradex

System logic specification and test case writing for BDD of transaction engine

Background

At the end of the design phase for Tradex, we had created a fairly detailed design specification for the product. But still, there were details that needed to be fleshed out as part of build. Most of these were related to how transactions would actually be handled, how each transaction affects different parts of the system, and what changes needed to be kept track of. With this in mind, we proposed to the client that we work on the transaction engine first, before implementing any of the interfaces.

My role

  • Worked with developers to define process for build
  • Wrote test cases to specify business-based logic for BDD process
  • Guided client through validation process

Design process and key challenges

One of the biggest challenges in this part of the project was how to tackle it at all – the engine was largely driven by business rules which the client was ultimately responsible for, but in the final product, the workings of this engine would be almost invisible to anyone but the developers.

We needed a way to allow the client to be involved in developing and validating the rules without being able to read code. After throwing around a few different ideas, the lead developer suggested using a behaviour-driven development approach which would allow rules to be expressed as test scenarios in readable language, and the same scenarios could be used to test the actual implementation.

Once this was decided, my job was to work out how to write the test scenarios – at what level of granularity should we be working at? How do I set up the scenarios so that they’re easy to understand when someone reads them? How do I make sure that we cover everything we need to cover?

After some back-and-forth with the developer and several early attempts at some simple test cases, I realised that I needed a clear mental model of the relationships between the different variables that made up the system. I drew a diagram linking all the different variables required to make the different calculations specified by the business rules, then onto that, I marked how each specific user action would interact with these relationships. I decided this would be the first thing the client needed validate.

From here, I used the diagram to systematically write the test scenarios for every possible action the system would accommodate. With the system mapped out in this way, it was much easier to see what variables should and shouldn’t change with any action at a glance, making it easy to get a sense of what to test for. The diagram also made it easier to get a good sense of what kind of actions would require more thorough testing (because of the number of variables it touched), which helped us plan our efforts appropriately.

The sets of completed test scenarios, written using Gherkin syntax, were passed on to the client to validate. Although the language is not exactly “plain English”, it’s close enough so that with a little instruction, the client could follow the logic of the calculations, and make any corrections where required. The validated test scenarios were then fed back to the development system to test the implementation against.

As development continued, any questions raised by the developers were collated each sprint, and I sent back clarifications in the form of new test scenarios developed with the client. The development of this engine is still in progress, but we can conclude that this process has allowed a tight collaboration between client and developers which is often required but not easy to achieve.

If you’d like more details about this project or any others in my folio, please contact me.