Keeping in mind that our integration capabilities are constantly evolving, we can consider the following simplified toolchain as the status quo for this discussion:
Note: the specific tools around Hexawise in the image above are mentioned for example purposes and do not represent the exhaustive list.
Let's look at both integration sides from Hexawise perspective in more detail.
The first part is to link the project from Hexawise to Jira using "Project Name + Model Name" as the link label.
The second part is to include traceability notes inside the Hexawise plan identifying which part of the model is affected by which story (there are largely 3 categories you can see on the image below).
Additional traceability elements include the Mind Maps (you can put the REQ ID in the value name), Forced Interactions, and in-line/per-tab comments in Scripts.
These steps reduce redundancy risk across the test suite given common one-to-many relationships between tests and requirements.
Left Side – how is "Best Practice" different?
Potential improvement #1: Write story descriptions in Gherkin. That would not only improve the clarity and communication, but would also provide the kickstart to scripting in Hexawise.
Potential improvement #2: Group parameters & values together in their own part of the story (similar to “Description” or "Acceptance Criteria"), in the mind map format (for visual analysis) and/or in the parameter table one (for direct import into Hexawise). That speeds up the process of reading through paragraphs of text to identify the key model elements.
Potential improvement #3: Include the “mini scenarios table” that covers the most important interactions from the story (which can also be imported directly into Hexawise). It can help clarify ambiguities in complex rules much sooner.
Potential improvement #4: Add “Hexawise” label and relationship link type “shares assets with”. Displaying both labels and links in the sprint board view will provide the quick view into possible connections and increase collaboration efficiency.
The primary method is exporting from Hexawise into compatible CSV and importing into test management tools (like Xray or ALM). Hexawise also supports export into the formats directly compatible with the execution tools at the last stage of the toolchain (like Cucumber or Robot).
How to deal with changes
Once the Hexawise model is built, the story link + traceability notes would map the requirement updates and let the user know which parts to change. The interaction coverage can be focused on the new areas via Mixed-strength and Parameter structure (e.g., more Value Expansions for less important parameters).
TCs in Jira/Xray would be updated via re-import, either for the full scope or only for the new elements using Freeze/Script features in Hexawise.
If the execution history must be preserved, the import is typically either performed into a new repository folder/Xray test plan or with overwriting the existing Issue IDs. Also, Xray Archive function or this solution (the new test execution item) can also be considered.
If it doesn't have to be preserved, the existing tests can just be deleted and the new ones imported.
Integration work doesn't stop
The purpose of this article is to describe the current state of Hexawise features and how they can be leveraged to optimize the SDLC process. We also have a couple of improvements in the pipeline.
However, many versions of the toolchain exist across our current and prospective clients, so if the information here does not cover your needs, we would be happy to discuss additional customizations. You can reach out to us at firstname.lastname@example.org.