This project aims at defining some basic rules regarding a flow manager test automation solution.
The core purpose is to highlight the context mindset to allow a functional, modular and scalable framework design for test automation solutions regardless of the domains or business rules implemented within the system under test.
Some generic rules guiding the design:
- For any activity based on fragile (e.g. persistent) state of SUT there is no assurance of idempotence
- Given the fact that SUT state is a function of Time, for any A(d1) @ ti and A(d1) @ ti+1 the resulting state of the system under test will be different (there should exist at least one instance)
- Due to these (and other) aspects, the TAS should create/be responsible the entire dependency stack of changes for a given business flow
Entities of the Flow Model:
- Actor: represents the actor entity (of a TAS) which interacts with the SUT in order to achieve a business outcome
- Action: represents the activity entity (of a TAS) that is performed by a given Actor onto the SUT
- Task: represents a set of actions (in a predefined order) to achieve a larger business outcome
- Flow: is a group of tasks which performed with solve a business problem (i.e. business capability of the system)
- Role: is a restrictive attribute of SUT access in order to perform a given action
- Completion Check: represents a post-condition that verifies a given actions was successfully applied
Design Patterns applied:
- chain of responsibilities
- command