Automatically generating test cases from Business-Requirements
When a business application is non-trivial and subject to changes frequently, there may be benefits by creating an “Auto-Gen test cases” process. This generally includes these 3 things:
1) Well-structured business requirements: The business requirements that outline the functionality of the application must be well-structured and complete.
2) Translating the business requirements to SRL (Structured Requirement Language): An application or process to interpret/translate the business requirements to a structured requirement language is essential to auto building test cases
3) Generating test cases from SRL (Structured Requirement Language) : is a custom application or process that relies heavily on the test case generation practices defined by a company’s overall testing best practices, as well as the SRL for the given application.
Note: I will share an example of this in a future article.
A few notes regarding the above processes include:
- Rarely will a company gather and represent their business requirements in a structured way, unless there is a compelling reason to do so (such as this Auto-Gen test case process). This takes time and money. Well-Structured requirements are generally NOT the same representation that the business community will originally create. It will take an extra step of verification and validation of the business requirements, to get to a well-formed set of requirements. This is seen as an extra time-consuming step that takes time and energy to complete. Only producing value if the entire Auto-Gen test case process is completed and documented.
- Translating the business requirements to SRL (step 2, above) is a custom application/process that depends on the accurate well-structured requirements (step 1) documentation to complete.
- Creating the Test-Cases from SRL is a custom application/process that relies heavily on the SRL (from step 2) and the organizations testing practices (detailed in a future article) to create the test cases in accordance to a given set of best practices.
- If done correctly, thousands of test cases can be generated in a matter of minutes. Auto-Gen’d test cases can then be used to test, verify and validate application logic in the same way we do it today (be it automated or manual).
Auto-Generating test cases for a given application (set of business requirements) is not a process that should be undertaken lightly. It is generally done when there are frequent changes to business logic. This Auto-Gen process requires a more structured set of business requirements to facilitate the test case generation process, as well as a tight connection to the Testing Best Practices outlined by a given company/organization.
A recent use case for this activity:
Company ABC was releasing an application framework that was purchased as a COTS product by many different customers. These customers would then insert their own domain knowledge and need to verify and validate their changes along with the base framework application (from ABC). By auto generating the test cases using structured well-formed requirements, the customers can verify and validate their custom knowledge much faster and cheaper than ever before (by using ABC’s Auto-Gen process). They can import the test cases from the framework testing library and then augment the new domain knowledge test cases into a new combined regression testing library.
Dave I saw the words faster and cheaper. Which usually peaks the interest of business, but how much effort and upfront cost does a customer have to invest? What would you define as well defined and complete requirements? With frequent changes what is the cost to maintain it? What are these types of changes, e.g. simple value changes or complete new business logic? How well do you see it working with the new no code/low code tools?
Hi Dave, This is good food for thought. I know this is an interesting approach because I’ve seen you implement similar frameworks at a couple of clients. They were FINTECH and health insurance, so this method works across industries. I am impressed that you said all that and wrote all this yet somehow you didn’t use the ‘rule’ word once! About regenerating test cases when business logic changes, what happens to the previous test cases that were needed to validate the original logic — Are they still valid scenarios for testing after the changes? Also wondering if you use requirements + rules to generate the test scenarios with expected results (answers). Looking forward to seeing your examples. Nice to catch up and read what you’re thinking about.