A Context is a placeholder that represents a particular state of an application (UI testing) or one that acts as a container of related functionality (API, DB testing, etc.) in your application.
When you are working with UI automation, a Context represents a particular page (on web app), a screen (on a mobile app), or a window that offers end-user functionality. For example, QBank Login Page, QBank Account Summary Page, Salesforce Admin Page, etc. Each of these Contexts (pages) offers some end-user functionality.
Context contains Actions
Depending on the functionality offered by a page, you may define Actions relevant for your testing. For example,
A Context, QB Login Page may have the following Actions
- Login to QBank
- Initiate Forgot Password
- Verify Footer links etc.
A Context, QBank Summary Page may have the following Actions
- Verify Account Balance
- Initiate Funds Transfer
- Verify Recent Transactions etc.
When you are creating an Action, you choose "Owner" Context that indicates where a particular Action will be defined. At the same time, you also choose "Destination" Context which indicates the Context (page) an application will land in after the Action is completed.
Based on the definition of "Owner" and "Destination" Contexts, the system helps the user to identify relevant steps while building a Test Scenario.
You can learn more about Actions here.
Context has Views
A View is a screen recording of the application page which the Context is representing. Views are helpful to build logic in Actions.
Here is the "View" for QBank Login Page.
A given Context (representing a UI page) may consist of one or more Views. Each View may have captured a different sub-state of the page. For example, the following screens represent different Views of the Travelocity Home Page. Flights View displays fields necessary to search for a flight and the Hotels View displays fields necessary to search for a hotel.
Learn more about recording Views and managing Views.
Context manages Element Repository
Element identification is integral to the automation test logic. Automating a user interaction on a screen is all about identifying the element on the screen and then performing the required operation. Every page (or Context) offers a set of elements required for building logic for the Actions defined in that Context.
In ACCELQ, elements are managed separately for each Context, and all Actions in a Context share these elements for building logic. So, if your application has 10 pages (Contexts), you will have 10 Element Repositories, each managing the elements in the respective page.
Learn more about element repository and element management.
Context for non-UI testing
For non-UI testing, a Context is simply a group that holds together Actions for related functionality being tested. Most commonly you may define Library Actions in such Contexts.
Please sign in to leave a comment.