Intention is better than a perfectly described but ineffective process
In 1970, Winston Royce proposed a very linear software systems development process that is now called "Waterfall" [Royce 1970] [Moustier 2020]. He knew that this approach had little chance of success and his doubt can be explained today by the Cynefin framework [Snowden 2007].
The value of the importance of individuals and their interactions rather than processes and tools in the agile manifesto [Beck 2001] is a direct consequence of this kind of environment whereas a definitive process-oriented approach is more applicable to the 'obvious' Cynefin environments where a categorisation of the problem is sufficient to apply a predefined approach.
The development of new applications is a process that is inherently complex. It involves regular adaptation of working methods that emerge from observations of the environment in which the solution is evolving, and imagining well-defined processes quickly proves to be cumbersome and detrimental to adaptability. However, on a good-sized project, it is necessary to have a minimum of structure to provide a framework that is sufficiently defined to allow a simple interface between people and teams, and sufficiently flexible to support the variability assumption [SAFe 2021-3].
Whether testing is a step (as in the case of Waterfall) or an activity integrated with development in your software lifecycle, testing also has a strong interest in being "agile" in the sense that it should enable software quality and not be a constraint. From this perspective, testing should also focus on the value of the importance of people and their interactions rather than on the testing process, let alone the test case.
A test case so detailed that it would allow a passer-by to be picked up off the street and have him run the script manually is thus a poor goal because questioning the content of the solution would require all the scripts to be updated before you even start testing the product. It is good practice to describe tests by their intent rather than extensively.
This generic test case approach should also be supplemented by a test objective to consolidate this approach in case the scenario is so upset that the tester can adapt the scenario to the situation being tested. Another advantage of the test objective is that it allows the tester to try to achieve the objective by any means at his disposal; even if he encounters bugs, it will not be the test that is "KO'd", these anomalies will just be incidents encountered (which obviously deserve correction) but on a high level test report, the test whose objective is achieved would not be "KO'd" and the requirement to which it is attached is then verified.
In this mindset of intensional testing, there is in fact the underlying exploratory testing approach with the objective (or even the scenario idea) as a charter and a more reasonable duration than an entire campaign.
To be automated, a scenario written by intension obviously requires an exhaustive description of each stage and seems to prevent this principle of "rough definition" of the script.
However, agilitest has two approaches :