6.1 Reuse Existing Assets to Create Structure Diagrams Automatically
Over the past years numerous importers have been developed to create structure diagrams and from various existing assets such as automation information (like framework functions, object repository recordings from various test automation tools like HP UFT/QTP and Tricentis Tosca, etc), application information (like WSDL versus WADL versus OpenAPI web service definitions, SOAP versus JSON web service captures, etc), simple Excel based interface specifications (GUI versus mainframe interfaces), etc.
...
Recommendation: Instead of starting with an empty project and blank initial structure diagrams, save valuable time in modelling, and reduce time to eventually automate execution of generated tests. Make use of various importers to complement or even just create a starting point for interface object specification in structure diagrams.
If you have any automation or application assets in a format which is currently not supported by importers reach out to support@conformiq.com for help.
Importers generally expect input sources to be provided to follow a correct format. In particular when it comes to failures in web service definition imports, the validity of the source should be checked with 3rd party tools.
...
Recommendation: Use online web service definition validators available or other 3rd party tools supporting the file format to be imported to ensure that interface definitions to be imported comply to the respective standards.
When creating structure diagrams from external sources care should be taken to import only the relevant parts of the interfaces, i.e., avoid importing complete web service definitions but instead import only the message and information elements you need from a definitions file, or do not import complete web pages modify object repositories to only contain the widgets you need for modeling the functionality to be tested. Notice this also helps to reduce model complexity.
...
Recommendation: Restrict the import of interface information to only those definitions, e.g., message, parameters, widgets, etc required for modeling the functionality to be testing in the current Creator project.
6.2 Only Model Items Required for Functional Testing
Structure diagrams represent the interfaces available for testing a given functionality. A common early modelling mistake is to just re-create (and layout) 1-1 interfaces like screens or web services that capturing every detail available in that interfaces like every widget or every optional field.
...
Recommendation: Limit your initial interface definitions in structure diagrams and specify only the parts needed for functional testing. If you use importers to automatically create structure diagrams even delete definitions which are not relevant. Add additional widgets or fields as you need them or reimport your existing assets.
Remember that modelling is most powerful when you focus and abstract. This allows you to construct models faster and reduce model complexity (see section MODEL COMPLEXITY).
...
Recommendation: When modelling an application GUI with lots of tabs and tab content consider modelling each tab as a separate screen instead to simplify screen specifications in the structure diagram and reduce specification complexity in activity diagrams.
6.3 Use Structure Diagram (SD) Libraries to Reuse Interfaces across Multiple Projects
Sometime deployments hesitate to distribute functionality across multiple Creator projects since they fear to spend additional effort to maintain and update interface specifications across multiple Creator projects. This issue can be elegantly resolved by using the Conformiq Creator concept of Structure Diagram libraries (see in Conformiq Manual Chapter 5. Creating Models with Conformiq Creator > Structure Diagram Libraries). Note that any Conformiq user can produce and use structure diagram libraries.
Similar as library concepts in programming languages, structure diagrams should have one source Creator project and always include a documentation note with a contact point for changes. We recommend that CoE teams or possibly even automation teams should act as the owners of SD libraries. Whereas extension or additions to libraries are easy to manage, care should be taken about modification to libraries (in particular deletions) since they are likely to require updates to activity diagrams which use the previous version of the library. An important side effect of structure diagram libraries is that they ease the automation of generated test cases because they force users to reuse the exact same definition for same interaction with the system under test.
...
Recommendation: Collect structure diagrams with common interface definitions in one of your Creator projects and export them as a Structure Diagram (SD) library for use in any other Creator project. Document every structure diagram in the library source project with Note object that specifies library version, author, and contact information. Share and (re)use SD libraries across multiple teams.
Note that Conformiq’s Excel based interface importers have already an option to create structure diagram libraries instead of editable structure diagrams.
An important issue to remember is that diagrams in SD libraries also have diagram version numbers. Since Creator 2.2, SD libraries are handled in a special way, i.e., they are automatically and silently updated to current diagram version if they are of a lower version. But note that if a SD library has been created with a later tool version it will generate errors in a lower tool version.
...
Recommendation: CoE teams should develop, maintain, and export structure diagram (SD) libraries using the lowest Creator version deployed by all users - so that all users can use this SD library (lowest should be Creator 2.2). Indicate the Creator version number in the file name to provide clarity.
6.4 Minimize (Direct) Use of Custom Actions
Custom actions were originally added to the Creator modelling language to provide an extension point for expert users, i.e., to enable to specify interactions via interfaces that are neither GUI nor message based. In practice, however, many non-expert users have started to extensively use custom actions, e.g., to redefine pre-defined GUI actions to affect especially the textual rendering in test cases. Note the proper way to affect textual rendering of actions is to customize scripting backends – not to use custom actions. In addition, many conceptual mistakes (like having input actions named “Verify that …”) are commonly made. Finally, the effort required to maintain models with loads of custom actions is significantly higher compared to using pre-defined actions.
...
Recommendation: Try to use generic GUI modelling support wherever possible and avoid redefining GUI actions using custom actions. Consult expert users before adding any custom action to your model. Ensure there is not already a structure diagram library available that addresses your need.
A rule of thumb since years in the Conformiq manual is to limit the amount of custom action definitions in a project to a maximum of 20% of the overall specified interactions (not counting custom action definitions within SD libraries).
What many users do not realize is that direct use of custom actions is problematic in the next step, i.e., the automation of generated tests. They cannot easily be converted into test automation code since – by definition - they can mean anything, i.e., each custom action has to be manually automated.
...
Recommendation: Try to use or define custom actions mainly in the context or as part of SD libraries. Also, keep all Custom Actions in a single SD file, so that this SD file can be verified for existing actions before creating new one. Discuss with Automation COE on “best definition” of a ne Custom Action. This fixes custom actions, avoids duplicity and enables automation.
Note that this idea can be easily extended, e.g., automation teams can provide and maintain SD libraries with custom actions based on keywords available in their automation framework which will enables a fully automatic conversion to tests running in their framework.