As more and more teams move towards the Agile methodology in software development, we are getting an increased number of questions like:
“Could Hexawise still be applied, given iterative nature of requirement generation and uncertainty about the final state of the features?”
While we provide a brief overview of how Hexawise would deliver benefits in Agile environment, in this article we would like to discuss related applicability concerns and dive deeper into the Agile topic.
First, let’s talk about broader Hexawise applicability
While the question posed above is reasonable, Agile vs Waterfall is not the best classification criterium for applying Hexawise. The same is true for dividing the apps into GUI, non-GUI, micro services, etc. – it also does not align well with the Hexawise strengths.
Hexawise is a test design optimization tool which focuses on the early stages of the testing process and then integrates with tools responsible for the subsequent steps, like ALM. Speaking about the reduction of effort, the goal of applying Hexawise is to deal with such challenges of manual test creation as prolonged and error-prone scenario selection, gaps in test data coverage, tedious documentation, and excessive maintenance.
The methodology Hexawise facilitates is based on the research results about the causes of defects in production. Manually written test cases often represent a very fragmented view of the system, focusing on individual inputs while allowing redundancy or omissions in the remainder of the scenario. On the contrary, Hexawise provides complete control and traceability for each of the steps in the test case.
The tool can deliver significant benefits across project and application types, as long as their functional flows demonstrate sufficient interaction variety.
Thus, the key app characteristic is flow variations – in other words, the system overall should contain several decisions points and at least 2 steps in the process with multiple options per each. Higher number of those creates numerous possible paths through the system, therefore Hexawise could be applied to identify the optimal set to test them.
You can refer to the diagram below for the high-level applicability decision tree.
Most often, 10+ expected test cases mean it is reasonable to use Hexawise for suite generation. Although the application type is not the decisive factor for Hexawise applicability, the table below illustrates “happy path” examples for each category.
Note: sample plans are in process of being uploaded to all instances.
The use cases discussed so far demonstrate the applicability only from the perspective of inputs. While that is often the primary factor, it is important to consider other elements:
- Script Length
The minimal plans (2x2) make more sense if the script contains 10+ detailed steps with data-driven expected results. Manual copying of the script always has room for error.
- Output Format and Standardization
Creating a plan in Hexawise may be the fastest route to get the ALM, Gherkin, Java, etc. file with the test cases. Further, you guarantee the consistency of the export format across projects.
- Application Growth
The current release may have only the minimal information, but if the application keeps growing, you may want to get ahead of the curve and start building the Hexawise model in advance.
- Excessive Constraints
An application with numerous parameters (e.g. >=8) and values may not be a good fit for Hexawise if the interactions between the elements are heavily limited, leaving only a few possible paths through the system.
Hexawise Place in Agile
Next, let us focus more on how applying Hexawise is different in the Agile environment. To have an anchor/benchmark, in the waterfall world, by the time you reach testing, most information is well-defined, so you can start moving through all the traditional Hexawise six steps sequentially.
On the contrary, the iterative nature of the Agile process can be illustrated in the following diagram (Source):
There, Hexawise usage flow should ideally start as early as Sprint Planning and requirement definition. SMEs can leverage domain knowledge and application access to more accurately specify the inputs for each requirement. Then the majority of the work is performed during Sprint Execution. Testers would pick up the draft models and expand them to the execution-ready state at the acceptable coverage level. Finally, manual scripts would be exported to ALM or automated ones (in the BDD format) passed to the coders for adjustment based on the automation framework.
The key challenge is that not every user story may be applicable (from the number of inputs & variations perspective) and, consequently, not every sprint may have sufficient scope. It is quite common that Hexawise is used in every 2nd or 3rd sprint, once the testing model has enough elements to justify the combinatorial exploration. And of course, once it comes to regression for each release, Hexawise test plans can be easily updated to accommodate the new functionalities.
In the example from the previous article, if the two features are coming in different sprints, it would likely be necessary to wait until the second enhancement (if there are no other parameters known from the previous releases or from the application access/documentation).
It is also worth noting that sometimes a user story does not look applicable but thinking outside of boundaries will quickly change that assessment. For example, if a user story specifies the ability to log in correctly, it looks like a test with 2 parameters, 1 value each. However, if we look deeper, that requirement means a correct login for different allowed formats for usernames and passwords and an incorrect one for invalid options. Suddenly, thoroughly testing a simple user story can fully leverage Hexawise capabilities.
Hexawise as a Catalyst for BDD
At this point, it is also important to keep in mind the general role of the tool in BDD practices (which often accompany the Agile transformation). When we consider common BDD goals, we can think of these 3 as being important:
- Early Stakeholder Communication
- Clear and Thorough Software Requirements
- Accelerated Automated Testing and Maintenance Efforts
From the communication standpoint, reviewing the testing efforts at the model level (in tabular or mind map format) and analyzing the coverage with the help of visualizations should help reach the mutual understanding faster.
From the requirements standpoint, Gherkin already facilitates more clear understanding of those. On top of that, Hexawise provides the platform for people with 3 knowledge components (technical, business, and functional) to come together and make sure ambiguities are eliminated and each requirement clearly specifies all the critical input values.
From the automaton standpoint, model-based testing allows easier maintenance and reusability while writing Give-When-Then scripts inside the tool helps less technical users to contribute more to the creation of automated tests.
Thus, the focus of your decision making should revolve more around the universal benefits of Hexawise and whether those could improve your status quo.
Measuring the Applicability
Lastly, the answer to the question “Can Hexawise deliver benefits on this specific project?” is not always the same as the answer to “Can the delivered benefits outweigh the costs associated with the adoption/learning curve/etc.?” While applicability is indeed broad, we should always keep in mind the cost of leveraging any tool for a specific task.
In this section, we will briefly touch upon one approach to the ROI calculator and will also mention some of its limitations.
Limitations: data collection for benchmarking of the BAU values, delayed benefits from defect analysis.
Conclusion and Next Steps
If your experience is different or you disagree with anything stated in the article, feel free to connect with us to discuss.
If you agree, we are still looking forward to hearing more about your experiences and demonstrating how Hexawise could better help.