Software delivery teams across the industry have embraced agile delivery methods in order to promote collaboration between teams and deliver new software at unprecedented speeds. Although many teams boast agile delivery methods, one thing that still plagues the SDLC is poor requirements. How can this be, given the core goal of “Agile” in promoting better cross-team communication? For agile to truly be agile, QA must “Shift Left” to the design stage. This is the key to empowering cross team collaboration, improving requirements and reducing costly system faults in later stages of the SDLC.
Requirements still cause 35% of production defects [1] and on average it costs 15 times more to fix a defect found in the testing phase and a towering 100 times more in the maintenance phase of the SDLC [2]. Many organisations are therefore rightly seeking ways to improve their software requirements and boost collaboration between software designers, developers and testers.
One commonly taken Approach is Behaviour-Driven Development (BDD). BDD as a software delivery method has been a key part of agile software development. BDD aims to promote collaboration between software designers, developers, testers and non-technical or business participants throughout the software delivery lifecycle (SDLC). Taking advantage of ubiquitous languages such as Gherkin, for writing user stories and requirements, and then converting them into tests using a BDD automation framework such as Cucumber. BDD allows software developers to move straight from user stories to tests, which sounds great in theory, however the quality of requirements has continued to be a major cause of defects.
This is because popular BDD formats and methods used to capture software requirements such as Gherkin are ill-matched to reflect complex system logic. Managing a large set of Gherkin feature files and linking them to form a complete picture of a system is a nightmare for developers. Additionally, natural language is ambiguous and incomplete, leading to miscommunication rather than collaboration. These misunderstanding in the requirements, lead to costly and time-consuming rework. “Shift Left” is therefore crucial, especially when fixing software defects after the design phase requires far more resources. So, how does a software delivery team “Shift Left”?
A study was performed by the IBM System Science Institute in order to determine the relative cost to fix defects within the SDLC [2].
Curiosity recently hosted a webinar “More Sprint Planning Won’t Fix It: Why do requirements still let quality down?” Featuring Colin Hammond, CEO of ScopeMaster, in which we discussed how rapid requirements analysis can eradicate bugs before they impact code. Discover requirements driven testing for short iterations.
Given the pervasiveness of design defects and the exponential costs of fixing them at later stages of the SDLC, requirements are the clear target for improving software delivery. Introducing QA earlier in the SDLC allows software delivery teams to detect the majority of defects as they emerge. Doing so in the design phase gives delivery teams greater control over the project and therefore a higher chance of delivering quality software on time and within budget. Modelling requirements is one way for QA to “Shift Left”.
BPMN style flowchart modelling offers a way to model complex system requirements. Missing logic is far easier to spot in consolidated visual models when compared to a collection of unconnected written requirements. Furthermore, BPMN flowcharts offer a significant advantage when connecting teams in the development process, as they are already used by BAs. Flows therefore retain a ubiquitous visual language, which enables QA, developers and BAs to work collaboratively and in parallel from the same system design, a core goal of BDD. In doing so, flows remove ambiguity and incompleteness from the design phase. This in turn allows QA to “Shift Left”, promoting quality earlier in the SDLC.
Flowcharts are key to maintaining rigorous in-sprint test automation throughout the SDLC. Implementing visual flows to your BDD frameworks will reduce the risk of failure and costly faults. All of this is made possible with Test Modeller.
A visual flowchart clearly depicts the test requirements of a new user registration page.
Curiosity’s Test Modeller is primarily a collaboration hub that assists testers to keep pace with the speed of agile delivery. Test Modeller does this by identifying what needs testing, and then generating the test cases and automation scripts needed to run those tests. In Test Modeller, BPMN style flowcharts or models are the centerpiece for collaboration. These models are generated and managed in Test Modeller.
Models allow teams to identify critical change impacts quickly and visually. Models express test logic abstracted from independent applications or services, which provides context to help testers collaborate across team boundaries. Behaviour-Driven requirements and existing tests can be converted automatically to models, for instance using Gherkin importers, BPMN diagrams, recorded test activity or a UI recorder. Otherwise, fragmented requirements and change requests can therefore be consolidated rapidly in the central models, maintaining a single source of truth as systems evolve.
Facilitating a “Shift Left” approach with Test Modeller, enables testers to help build better quality, testable systems, removing potentially costly defects during the design phase. Additionally, when a new user story or requirement is reflected in one modelled subprocess, the impact of this change will ripple across all interdependent, modelled components. Models allow any tester, technical or non-technical, to access data, automate actions and collaborate with different teams from the same models. Test Modeller has significantly reduced the time and technical knowledge needed to model complex systems.
Test Modeller comes with all the agility of BDD, while introducing the rigour of model-based testing. Model-based testing enables a visual behaviour-driven approach to requirements and system testing, reducing the risks of discovering design faults later in the SDLC.
With Curiosity’s Test Modeller, the act of modelling new or existing requirements eradicates defects before they enter code. “Shift Left” the QA process and reduce the risk of finding faults later in the SDLC. Test Modeller embraces Visual Behaviour-Driven Development, helping your software development teams collaborate and deliver fully tested, quality software at speed.
Follow Curiosity on LinkedIn, Twitter, Facebook or subscribe to our YouTube Channel.
Footnotes:
[1] Aditi Kulkarni, Global Assets Engineering Lead, Accenture – Software Intelligence Conference 2021.
[2] Dawson, Maurice & Burrell, Darrell & Rahim, Emad & Brewster, Stephen. (2010). Integrating Software Assurance into the Software Development Life Cycle (SDLC). Journal of Information Systems Technology and Planning. 3. 49-53.