Project-level Groups of Testing Platforms
In Worksoft SaaS, 'Testing Platform' is a term that is used to combine the following:
- A combination of Browser, Operating System, and a Device (Desktop, Tablet or Phone) that you are interested in certifying your application(s) under test (AUTs for short) using automation that is created and executed within your Worksoft SaaS domain/project
- Your preferences for Screenshot capture, Video Capture, and Webdriver Log file capture when your tests get executed
- Language preferences and your preferences for enabling/disabling pop-ups and flash when the tests are executed.
A 'Testing Context' is a combination of a 'Testing Platform' and 'Project Environment' and 'Cloud Platform' and is applied to a specific Run Definition and/or Scenario within the Project.
A 'Testing Platform' is maintained at the Project level whereas 'Testing Context' is applicable in the context of a Run Definition or a Scenario. A Testing Platform' will NOT include the 'Cloud Platform', 'Project Environment'.
A Testing Platform is created within a 'Group' (called the Testing Platform Group) that is at the Project-level.
What is the relationship between a "Testing Platform" and a "Testing Context"?
A project can have one or more Testing Platforms Groups each of which can have any number of Testing Platforms in it.
The same Testing Platform can be part of more than one Testing Platform Group.
The whole purpose of Testing Platforms and Groups is to make the automation engineers highly productive in creating Testing Contexts for the Run Definitions and Scenarios that are assembled within the Project.
A Testing Context can be created from a single Testing Platform of a Group. When you create a Testing Context from the Testing Platform of a Group, the linkage to the originating Testing Platform and Group is internally maintained within Worksoft SaaS.
Why should I use Testing Platform Groups in my Project?
For you to realize the significant value (productivity increase) this feature offers you, consider the following example.
Let's assume that you have 200 manual test scenarios in the scope of automation for your project and your goal is to get your application/release certified for 10 testing platforms (browser, operating system, device combos) for all those scenarios. Let's also assume that you end up creating 200 run definitions in your Worksoft SaaS domain/project to implement those 200 manual test scenarios.
One inefficient way is for achieve creation of 10 testing contexts is to manually create the testing context for each of the 200 run definitions (2000 testing contexts in all). With the use of testing platforms feature, if you add the 10 Testing Platforms of your interest to a Group at the Project level, you can, with a few clicks, get the 10 Testing Contexts created.
The use of project-level Testing Platforms also makes you very efficient in making changes to any of the Testing Platforms within a (Project-level) Group, and pushing down the change(s) to Testing Contexts of Multiple Run Definitions and Scenarios so that you don't have to manually go in and make the edits to Testing Contexts of Multiple Run Definitions and Scenarios.
Let's assume that your automated test coverage involves certification of your application against top 5% of platforms (browsers, operating system, and device combos) that your end customers use to access your apps. If new browser/O.S/Device combinations appear in your top 5%, you can very easily go in and make changes to the Testing Platforms within a project-level Group and 'push' down that change in one click to all linked Run Definitions and Scenarios, gaining significant savings in manual effort.
Why would I need more than one Testing Platform Group within my Project(s)?
If you have more than one application (say a customer facing app and an internal administrative type app), it may be that you want to certify some application on a specific wider list of testing platforms while you may want to restrict the certification of some other application to a different or fewer testing platforms. In such use cases, the ability to create and maintain more than one testing platform group at the project level will come very handy.
How can I bulk create Testing Contexts for a Run Definition or Scenario using the a Testing Platform Group?Before you can do this, you must first create your (project-level) Testing Platform Group(s).
Use the hyperlinks in the section below to get to other useful articles you will benefit from.
After you read this article you may want to see:
- Managing Testing Platform Group(s)
- Adding a Testing Platform Group
- Bulk-Creation of Testing Contexts of a Run Definition (or Scenario) using Testing Platform Group(s)
- Linking/Adding a Testing Context of a Run Definition or Scenario to a Testing Platform Group
- Delinking a Testing Context of a Run Definition or Scenario from a Testing Platform Group
- Editing a Testing Platform Group (or its constituent Platforms)
- Deleting a Testing Platform Group (or its constituent Platforms)
- Cloning a Testing Platform Group
- Auto Creation of Testing Context from Testing Platform
- Drilling Down from a Testing Platform (or its constituent Platforms) to the linked Run Definitions or Scenarios
- Overlaying (Pushing Down) changes from a Testing Platform Group to linked Run Definitions or Scenarios