End-to-end workflows: Examples

In Perforce Autonomous Testing, you can manage tests for multiple applications in separate projects.

When configuring a new project through chat, you can provide all information in your first chat message, or re-use existing configurations, or start with what's important and fill in the details later, all as part of the guided conversation.

Example - Let the assistant fill in the gaps

You are a returning user and you are prepared to provide partial details about the test in your first request. You see that the conversation is quite concise, because the assistant uses the given information (web site URL, test type, location) immediately and only asks for a few gaps.

User: I want to test the performance of Example.com under the load of user registrations from Europe.

Assistant:

I have added Example.com to the application switcher.

Please select from these load generators locations in Europe.

User: Frankfurt

Assistant: Please select which browsers and operating systems to test on.

User: the latest Edge and Firefox.

Assistant: I have saved these browsers as an environment in a new test suite.

The assistant opens Example.com in a browser and tries to sign up. It makes up plausible registration credentials because you mentioned testing user registrations, but didn't specify a username or password.

Assistant: I will save this scenario in the test suite. [...]

Example - Start tests fast in existing applications

You are a returning user and you open an existing project with test suites, scenarios, and environments. You don't need to have a long conversation anymore: Even if you do not provide details in your chat message, you can start test runs within seconds, because all information is available in the selected application and presented to you in a user-friendly way.

User: run the test

Assistant: Lists all test suites and environments

User: Selects a test suit and environment and clicks Run Test

Example - Create and schedule a test end-to-end

You are an experienced tester and you already have an application set up. You quickly want to schedule a new test, so you provide all information in one go. The assistant asks you to confirm the defaults and sets everything up.

User: For example.com, please test once per day in Safari whether the login works for joe@tester.com with password 123, warn me if logging in takes longer than 2 secs

Assistant:

I can definitely help with that. I will create a test scenario to validate the login process, a policy to check the login time, and then schedule it to run daily.

First, I've broken down your request into the following test steps for the scenario:

Scenario Name: Login Test for joe@tester.com

Test Steps:

  1. Action: Navigate to http://example.com

  2. Action: Type 'joe@tester.com' into the username field

  3. Action: Type '123' into the password field

  4. Action: Click the 'login' button

  5. ✅ Validation: Verify that the user is logged in successfully

I will now create this scenario with the steps above. Do you want me to proceed?

User: sounds good

Assistant:

Great! I've created a plan to set up your daily login test.

First, I'll create a policy to monitor the login time. What would you like to name this policy? For example, we could call it "Login Performance Policy".

User: ok

Assistant:

I've created the "Login Performance Policy" with the rule to check for a login time under 2 seconds.

Next, I'm creating the "Login Scenario" with the steps we discussed. [...]

I will now create a test suite to hold our new scenario. Do you have a name in mind for this suite, or should I use something like "Daily Login Check"?

User: yeah use 'Daily Login Check'

Assistant:

Excellent. The "Daily Login Check" suite has been created.

Now, let's set up the environment for this test. What would you like to name the environment? For example, we could call it "Production Environment".

User: Yes

Assistant: I've scheduled the "Daily Login Check" suite to run every day at 2:00 PM UTC.