Design-Driven Automation Testing for Software Sprints
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional automation testing methods are limited in automating testing for new software sprints and require manual testing, leading to inefficiencies and delays, as they cannot automate testing for subsequent sprints and require test cases to be prepared only after a module is ready.
Innovation Solution
A method and device for design-driven development based automation testing, which involves receiving a design document, extracting functionality, converting it into test scripts, replacing design objects with real objects, and executing the scripts to test the developed product, enabling automation of testing for current and future sprints.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Extent of automation
If conventional automation testing methods are used, then testing automation is achieved for previous sprints, but new software sprints and future sprints cannot be automated and require manual testing
Solution Approach 1:
The patent applies preliminary action by creating executable test scripts from design documents before the actual software development begins. Test scripts are generated during the design phase (N-2 sprint) based on design documents, allowing automation to be ready in advance for future sprints (Nth, N+1, N+2 sprints) rather than waiting until after development is complete.
Solution Approach 2:
The patent uses design documents as an intermediary artifact that bridges the gap between requirements and test automation. The design documents serve as a mediator that can be parsed and converted into executable test scripts, enabling automation without requiring the actual software to be built yet. This intermediary allows test automation to proceed in parallel with development.
2Measurement precision
If test cases are prepared only after a module is ready, then testing accuracy is ensured, but significant time is wasted waiting for the module to be ready
Solution Approach 1:
The patent enables preliminary preparation of test cases by parsing design documents and generating executable test scripts before the software module is actually developed. This allows the testing team to prepare automation scripts during the design phase rather than waiting for development completion, significantly reducing waiting time while maintaining testing accuracy through subsequent object replacement.
Solution Approach 2:
The patent creates a virtual copy of the software structure through design document parsing. Instead of waiting for the actual software to exist, the system creates a simulated representation from design documents, generates test scripts against this virtual model, and then replaces virtual objects with real software objects later. This copying approach enables early test preparation without sacrificing accuracy.
3Reliability
If manual testing is performed for new sprints, then testing thoroughness is maintained, but product release time is extended
Solution Approach 1:
The patent performs preliminary generation of executable test scripts from design documents before software development begins. By preparing automation scripts in advance during the design phase, the system enables rapid automated execution during and after development, maintaining thoroughness while dramatically reducing the time required compared to manual testing of new sprints.
Solution Approach 2:
The patent replaces the mechanical manual testing process with an automated system that parses design documents, generates executable scripts, and automatically executes tests. This substitution of manual mechanics with automated mechanisms maintains testing thoroughness while significantly increasing productivity and reducing release time.
Data Source
AI summary
A method and device for design driven development based automation testing is disclosed. The method includes receiving a design document comprising an overview of a proposed product. The method further includes extracting functionality of the proposed product based on an analysis of at least one design object in the design document. The method includes converting the functionality of the proposed product into at least one test script based on the at least one design object. The method includes replacing one or more of the at least one design object with a corresponding real object in a developed product associated with the proposed product. The method further includes executing the at least one test script to test the developed product, in response to the replacing.