Skip to main content

Test Case Creation Approaches

Eggplant Testing Strategies​

Eggplant test case creation can be structured into 4 distinct approaches:

  • Direct Script Execution
  • Model based aggregation and prioritisation
  • Model based State based exploratory
  • Model based full exploratory

For the best practices, we will focus on guiding teams on the first 2 approaches as shown below (Hover over to zoom in):

Script Based Testcases​

The Script Based Testing approach is where Eggplant Functional test scripts are executed directly in Eggplant DAI, through a Test Config. A test config effectively being a grouping of tests.

A testcase is built by a calling a sequence of functions (reflecting test steps) within an Eggplant script. Each script within the Testcases folder should represent a testcase. Execution parameters, are defined at the test config level within DAI, while persisted configurations are held within the Eggplant Functional Suite. A testcase is run by executing either the testcase individually or through a test config (either manually or scheduled). (See the Testcase Execution In Eggplant section for more details)

Why Use This Approach
  • This approach provides a simple entry to testing within Eggplant that aligns with traditional automation approaches and documentation.
  • For manual testing teams who have limited exposure, this approach is a fast and easy route to automation, while the team learns modelling approaches.
  • The approach lends itself well to linear and procedural test cases, which must always follow certain paths/rules, commonly found in Banking, Healthcare or Defence applications. If you are from an organisation that already have well developed frameworks in other scripting languages and are now adopting Eggplant, then this strategy would be a like-for-like approach to developing the automated test cases.
  • This approach should also be considered when testing a complex application, e.g. with a lot of variations, as it may be too hard / time-consuming to create a model for the application.

Model Based​

The Model Based Testing approach in Eggplant allows the AUT/SUT to be digitally represented in graphical form in Eggplant DAI as models/sub-models.

The Models will have States and Actions which represent the functionality of the System/Application. Attached to these States/Actions are Eggplant Functional 'snippets' of code which is performed when the model test/run is executed.

The path of the Model execution is determined by either built DAI test cases, or when running in exploratory mode to maximise the bug-hunting and coverage engine. For more information refer to the Eggplant DAI Model Executions page of the Eggplant Documentation

To adopt this strategy, modular snippets of Eggplant code must be written so that they can be attached to the model states/actions.

Why Use This Approach
  • Creating a Model instantly allows the user to visualise the AUT/SUT in graphical form and see a fully representative digital twin of the application. Users can easily generate Test Cases directly from the model by creating the paths of states and actions.
  • Creating a framework in this way encourages modularisation for simple maintenance and addition of test assets, allowing for rapid release testing when new features are added.
  • Using the Aggregation and Prioritisation approach - building out the testcases - but in a manner where states and actions have a 1:N relationship to testcases, allows for traditional test based execution, but incorporating prioritisation of tests based on historic bugs and new features.
  • This approach should be considered when testing against a modular AUT/SUT, where deviations from the critical paths are allowed, e.g. Certain Retail/Web Systems or applications. It should also be considered when testing against large applications where functionality can be split into smaller sub-models or can be introduced incrementally.
Last updated on