In this webinar, Luc van Vugt shares his thoughts on getting all disciplines involved in a Business Central project – functional consultants, developers, and testers – facing the same direction by writing requirement specifications as behavioural descriptions instead of prose. David Singleton moderates the session. Luc originally presented a shorter version of this story at Directions; here he has more time to elaborate and demonstrate the approach with a real example.
The Problem: Requirements Get Interpreted
Luc opens with a problem statement: requirement specifications are most often conceptual descriptions – prose that describes what a customer wishes to do. He compares this to a fairy tale or the game of passing a whispered message around a circle: everyone who reads a conceptual description forms their own mental image of it, and details get lost or changed along the way depending on the reader’s background and focus.
In a traditional, waterfall-style sequence – requirements, then app coding, then testing – each handoff is an opportunity for a fresh interpretation. That is where bugs get introduced, and it is why go-live often comes with a list of things still to be fixed.
The move from on-premises to cloud makes this more urgent. With monthly updates and an ever-shorter cycle from customer wish to a feature published on AppSource, there is less room to rework things after the fact. Poorly tested extensions that reach unknown users on AppSource simply get uninstalled.
From Concept to Behaviour
Luc’s challenge statement: how do you get from a concept to a software feature without losing details? His proposed solution is to convert requirement specifications from a conceptual description into a behavioural description.
The reasoning starts from the end of the chain: what is software testing actually about? Specifications lead to a software package, and a software package is nothing more than a collection of behaviours. Testing verifies that the new behaviour of the software matches the specification. If the specification itself is written in terms of behaviour rather than concept, developers and testers both have a much closer, more direct target to implement and verify against.
Luc’s two favourite tools for expressing behaviour are flowcharts and ATDD (Acceptance Test-Driven Development) test definitions written as Given/When/Then scenarios.
The Business Case: Automatically Setting the Posting Period
To make the approach concrete, Luc walks through a real feature he implemented at The Learning Network: automatically updating the allowed posting period in the General Ledger Setup and User Setup at the start of each month. Previously this was a manual step performed by an administrator after each month-end close, across as many as 180 users in high season – error-prone, and occasionally forgotten, which blocked posting entirely until fixed.
The conceptual description of the desired situation reads like a typical requirement: dates should be changed automatically by a batch job, based on accounting periods and the system date, with specific users exempted and the user activating the batch job able to adjust the dates. It is clear prose, but it does not tell a developer exactly how the pieces should behave, and – as Luc points out – if four or five people implemented this from the prose alone, they would likely produce four or five different results.
Behavioural Description: Flowcharts
The first step toward a behavioural description is a flowchart. Luc writes it before writing any code – effectively sketching the “story” of the feature as a flow of decisions and actions across swimlanes for the user (or job queue), the batch report, and the routine that sets the starting and ending dates.
A flowchart is useful for more than personal clarity. Once it exists, the whole team has something concrete to discuss – “you’ve put this condition here, but isn’t there a third option?” – rather than debating an abstract story. Flowcharts also make holes in the logic easier to spot and review than prose does. The downside is that flowcharts can become complex for elaborate features, but Luc frames that as a feature, not a bug: complexity in the flowchart is a signal that the underlying feature needs more rigorous testing, and possibly that it should be broken down into smaller atomic parts.
Behavioural Description: ATDD Scenarios
A flowchart shows the flow, but it does not pin down an exact relationship between input and output. That is what test scenarios add. Luc uses the ATDD format – Given (set up context and data), When (exercise the action), Then (verify the outcome) – noting that other formats such as four-phase testing (setup, exercise, verify, teardown) or arrange-act-assert boil down to the same three-step structure.
For the posting period example, Luc identified three features to test – the batch report’s request page, the G/L Setup, and the User Setup – broken down into ten individual scenarios in total. Scenario numbers are not necessarily consecutive; when a review uncovers a missed case, it gets a higher number rather than being renumbered, so the team can see at a glance that a gap was found and closed later.
📖 Docs: Testing the application overview – Business Central – Microsoft’s reference on test codeunits, test runner codeunits, and recommended testing practices in AL.
From Spreadsheet to AL Test Code
Luc demonstrates the approach on a public GitHub repository he maintains with several worked examples, each pairing a flowchart, a conceptual description issue, and the resulting AL code and test app.
📖 Resource: fluxxus-nl/Test-Automation-Examples on GitHub – the repository Luc demos, containing flowcharts, conceptual descriptions, and AL app/test projects for three worked examples, including the posting period feature covered in this webinar.
The full detail lives in an Excel sheet: one row per scenario, with Given/When/Then columns and macros that generate both an ATDD-formatted comment block and a matching AL code skeleton.
From there, Luc copies a scenario’s generated text into a PowerShell script and runs a converter command-let that turns it into a starting AL test codeunit – not a finished implementation, but enough scaffolding that a developer can immediately see what needs to be built out. He notes that the team is working on a further stage of tooling to import directly from the Excel sheet and, eventually, export back out again as scenarios evolve. Importantly, Luc designed the flowcharts and the test scenarios for this feature himself, while a colleague, Peter Conijn, implemented the actual app and test code – deliberately keeping the person who tests a feature separate from the person who develops it.
Overall Advantages
Luc closes with what teams gain from writing requirements this way: better-detailed requirements up front, and more meaningful discussion between developers, testers, and product owners while reviewing and implementing a feature – discussions that keep surfacing gaps even after a team has been doing this for a while. He argues that responsibility for a bug in production should land on the whole team rather than solely on the developer, since it is just as often a gap in the requirement or the testing as a coding mistake.
Because a large part of the test scaffolding already exists once the ATDD scenarios are written, developers can start implementing against failing tests immediately, and later use the same automated tests to verify that changes have not broken existing behaviour.
A Book That Confirms the Approach
While preparing his Directions presentation, Luc was pointed to Gojko Adzic’s Specification by Example: How Successful Teams Deliver the Right Software – a book based on research across more than fifty projects at thirty companies. He had not read it beforehand, but found it described, in different terminology, largely the same conclusions he reaches in this talk: specifications should move from concept to concrete examples of behaviour. He recommends it as a non-technical read suitable for the whole team, including key users.
📖 Book: Specification by Example by Gojko Adzic (Manning, 2011) – based on research across more than fifty projects, the book documents patterns successful teams use to specify, test, and deliver the right software.
Q&A: Budgeting for Testing
During the Q&A, moderator David Singleton adds his own perspective from partner projects: when he analysed the finances of a partner in financial difficulty, actual development work accounted for only 5-15% of total project cost, while quotes to customers budgeted 40-50% for development – meaning testing and the rest of the delivery lifecycle were effectively unbudgeted and given away for free. He connects this directly to Luc’s point that shrinking release cycles under the cloud model no longer allow teams to postpone testing until the end.
Asked how much technical knowledge is needed to write the behavioural description and test scripts, Luc explains that his flowcharts are typically user-oriented and can be drawn by a non-technical person who understands the application’s process, though some technical detail creeps in where needed. The functional-level ATDD scenarios he describes are, in his view, always a functional responsibility – unit tests remain a separate, developer-owned concern.
This post was drafted with AI assistance based on the webinar transcript and video content.