Have Different Feature Files For Different User Interfaces
How does one specify the various User Interface behaviours for keyboard or voice activation, touch-enabled device taps and mouse clicks?
The short answer is: the software component context is king!
Each different interface should be considered another dimensional axis of the same set of behaviours. In this situation, I recommend different feature files for each different type of User Interface. I suggest one feature file for the voice interface behaviours of this component, a different feature file for the touch-enabled interface behaviours, and another for the mouse-based desktop computer interactions, etcetera. Each feature file would have the exact same set of Behaviour Specifications and step wording. The context – which User Interface type the feature file refers to – conveys the understanding of the User Interface implementation mechanism, and how, for example a button’s click action is triggered.
Again, there is no need in the Behaviour Specification to specify implementation details, and if those details are desired, they should be available in the test run output.
If a team would like to document the fact that all these different User Interface interaction mechanisms are available, then fantastic – but that belongs in a User Interface Guide and not as Behaviour Specifications in a feature file!