Removing Quality Bottlenecks in CI/CD and DevOps
Curiosity often discuss barriers to “in-sprint testing”, focusing on techniques for reliably releasing fast-changing systems. These solutions...
Design Complex Systems, Create Visual Models, Collaborate on Requirements, Eradicate Bugs and Deliver Quality!
Product Overview | Solutions |
Success Stories | Integrations |
Book a Demo | Release Notes |
Free Trial | Brochure |
Pricing |
Our innovative solutions help you deliver quality software earlier, and at less cost!
AI Accelerated Quality Scalable AI accelerated test creation for improved quality and faster software delivery.
Test Case Design Generate the smallest set of test cases needed to test complex systems.
Data Subsetting & Cloning Extract the smallest data sets needed for referential integrity and coverage.
API Test Automation Make complex API testing simple, using a visual approach to generate rigorous API tests.
Synthetic Data Generation Generate complete and compliant synthetic data on-demand for every scenario.
Data Allocation Automatically find and make data for every possible test, testing continuously and in parallel.
Requirements Modelling Model complex systems and requirements as complete flowcharts in-sprint.
Data Masking Identify and mask sensitive information across databases and files.
Legacy TDM Replacement Move to a modern test data solution with cutting-edge capabilities.
See how we empower customer success, watch our latest webinars, read our newest eBooks and more.
Events Join the Curiosity team in person or virtually at our upcoming events and conferences.
Blog Discover software quality trends and thought leadership brought to you by the Curiosity team.
Help & Support Find a solution, request expert support and contact Curiosity.
Success Stories Learn how our customers found success with Curiosity's Modeller and Enterprise Test Data.
Documentation Get started with the Curiosity Platform, discover our learning portal and find solutions.
Integrations Explore Modeller's wide range of connections and integrations.
Curiosity are your partners for designing and building complex systems in short sprints!
Meet Our Team Meet our team of world leading experts in software quality and test data.
Our History Explore Curiosity's long history of creating market-defining solutions and success.
Our Mission Discover how we aim to revolutionize the quality and speed of software delivery.
Our Partners Learn about our partners and how we can help you solve your software delivery challenges.
Careers Join our growing team of industry veterans, experts, innovators and specialists.
Press Releases Read the latest Curiosity news and company updates.
Success Stories Learn how our customers found success with Curiosity's Modeller and Enterprise Test Data.
Blog Discover software quality trends and thought leadership brought to you by the Curiosity team.
Contact Us Get in touch with a Curiosity expert or leave us a message.
Welcome to the final instalment of 5 Reasons to Model During QA! If you have missed any of the previous four articles, jump back in to find out how modelling can:
This last article in the series shifts focus to consider modelling within the broader context of the Software Delivery Lifecycle. It goes beyond QA, considering how models deliver value to the BAs, developers and testers who can work collaboratively from them.
The need for greater collaboration between the “three musketeers” of software delivery has been in sharp focus since at least the advent of Agile principles. Methodologies like Behaviour Driven Development (BDD) have re-iterated the need to work from a common understanding of how the system should function. The goal is to avoid miscommunication and the frustrating rework it creates.
This close collaboration requires a ‘ubiquitous language’ that BAs, Developers and Testers can all speak, regardless of their technical skillset. It must be bridge language that can be used to agree a shared vision of the system being delivered.
However, different stakeholders require different information regarding a system in order to perform their role effective. Their roles also require different levels of technical granularity. Any ubiquitous language must therefore enable discussions between stakeholders, while allowing individuals to drill down into the level information they need.
Working from an agreed picture of the system not only avoids misunderstanding, it also facilitates a parallel and iterative approach to software delivery. Testers for instance no longer need to wait for the design and development of a system to finish but can begin creating tests directly from the designs themselves. They can also improve the designs, performing the “shift left” QA that was set out in part one of this series.
However, the ideal of parallel development and a shared understanding of the system is often difficult to achieve in practice. A siloed approach often persists, and iterations frequently become mini-Waterfalls in which systems are designed, developed and tested in a linear order. Testers and developers must still furthermore translate requirements into formats that they can use, introducing further disruption and bottlenecks:
A linear approach to the SDLC, with numerous manual “information hops” between artefacts.
Modelling offers a way to overcome these challenges, particularly when using a format already familiar to BAs, developers and testers.
Flowcharts provide a modelling language capable of specifying complex software logic, while remaining accessible to all stakeholders. In principle, anyone can read a flowchart, without requiring specialist coding skills or subject matter expertise of given components.
Flowcharts therefore provide a way of pooling and centralising knowledge from across an SDLC. Test Modeller, can generate flowcharts from these existing requirements models, while models can also be built from scratch. A range of additionally connectors augment the models, for instance importing test cases and Gherkin specifications. The same models can also be supplemented after a system has been built, importing process logs, page object scans and UI recordings. This works to build a more complete picture of the system under development.
Flowcharts offer the significant advantage of being widely used by Business Analysts, who often already use specification languages like Business Process Modelling Notation (BPMN).
Critically, they also deliver value directly to testers and developers. Subflows can be used to embed lower level, technical specifications within master flowcharts. The master models provide an overview of the system, while also allowing developers to drill down into logically precise models of individual components.
Testers can also work collaboratively from the same models, generating test cases directly from the models. They can overlay automation logic and test data variables, creating a complete test suite from the flowcharts. This testing can occur from the moment the flowcharts are created, for truly parallel and “shift left” QA.
Flowchart models: A BPMN Requirement that houses the complete test suite needed
to test it.
The process of Model-Based test creation is set out in parts two and three of this series. What’s important to emphasise here is how this process does not undermine the value of the flowcharts to BAs and developers: the test automation logic and data is assigned to blocks of the model without thereby editing the look and feel of the model itself. The flowchart remains a BPMN model for BAs; for testers it houses the complete test suite.
Flowcharts in this instance serves as a single source of truth for designing, developing and testing a system. They house a shared understanding that can be added to iteratively, pooling and preserving knowledge. The more accurate the picture, the more reliable and informed the development and testing.
A model will never technically be “complete”, as systems evolve constantly while some information will always remain unknown in complex systems. However, storing known information in a central asset works to avoid miscommunication and technical debt. It reduces the frustration of thinking “If only someone had told me that!”[1], and the rework that follows.
Along with the quality and efficiency gains associated with “shift left” QA and automated test asset generation, modelling appears to be a sure fire way to reliably deliver software earlier, and at less cost to fix.
[1] Dan North & Associates (2006), Introducing BDD, retrieved from https://dannorth.net/introducing-bdd/ on 30-May-2019.
[Image: Pixabay]
Curiosity often discuss barriers to “in-sprint testing”, focusing on techniques for reliably releasing fast-changing systems. These solutions...
Continuous Integration (CI) and Continuous Delivery or Continuous Deployment (CD) pipelines have been largely adopted across the software development...
This is part one of three of the “Philosophy of Application Delivery” eBook. The eBook contains Curiosity Software Ireland’s musings on the nature of...
The new tool scales generative AI throughout DevOps and CI/CD, providing visibility, optimal test generation, pipeline integration and cross-team...
Behaviour-Driven Development (BDD) emerged in 2006 [1], partly in response to perennial test and development painpoints lingering in spite of “agile”...
The 2020/1 edition of the World Quality Report (WQR) highlights how the expectation placed on test teams has been growing steadily. QA teams today...
Welcome to part 3/5 of 5 Reasons to Model During QA! Part one of this series discussed how modelling enables “shift left” QA, eradicating potentially...
In the dynamic, interconnected world of software development, clarity is key. Yet, requirements engineering - the process of defining, documenting,...
Application development and testing has been revolutionised in the past several years with artifact and package repositories, enabling delivery of...