Please note: this guide is currently released knowing some of it may be incomplete in areas. If there are any sections which do not make sense, need more information or are missing, please get in touch at support@maxtaf.com and the support team will quickly clarify any queries and work to rectify the document.

Getting Started with MaxTAF

Getting Started with MaxTAF has been designed to be as smooth as possible.

All you need to start is:

A working computer with internet access
Any modern browser

Registration

To create an account, go to beta.maxtaf.com.

From there you will be presented with a sign in screen

Click the ‘register’ tab, and put in your details

At the moment, the system will now let you in automatically and you can begin using MaxTAF.

Projects

The first area of MaxTAF you arrive at is the projects screen.

Projects are essentially unique sets of data, cases, suites and settings. They are useful for partitioning test data, and as the name suggests, should be used on a project to project basis.

All users are automatically added to the community ‘examples’ project. If you wish to contribute to this, you may do so, but for testing your own system with your own cases, it is necessary to create your own project.

Creating your First Project

Click the ‘+’ button, to create a new project.

Cases

When you have created your first project, you are taken to the project home page. From here, the choice of next activity is entirely optional, as you have now set up the minimum requirements for your own personal MaxTAF project.

However, typically the first thing to do will be to create a test case. Like any test automation strategy, everything revolves around your cases.

If you already have tests, libraries, Selenium IDE recordings or anything else from an existing set-up you wish to import, please follow the instructions here:

Importing Cases or Suites
Adding Libraries

Instructions for Selenium IDE import to be added

Navigating to the Cases Section

On the left hand menu, you will see ‘cases’ - click on that

This is the cases section, which displays all of the test cases in your project. Later we will organise our cases into groups called suites, but for now let’s create the first case

Creating a case

You have a few options for creating a case.

This guide will lead you through creating a brand new case in the most standard fashion.

Click ‘Create’ to create a blank test case
In the dialogue box, fill in the name and details for your preferred language and framework
Select the ‘Basic UI’ Template (see note) using the last drop-down box

Congratulations- you have created your first test case. This Case will head to Google, type ‘Hello World’ and then assert the page title is as expected.

Note: For your learning purposes, we would recommend that you use one of our templates - templates are user configurable ‘premade’ test cases. Typically these would act as starting points for tests of a particular class, e.g navigate through login -> click on user profile -> (steps to be defined). They essentially save time for certain, common, test situations in your QA regime.

Running your first test

To run the test case you created, press ‘Run’, and then ‘Run’ again.

This will be a very quick test case, so the MaxTAF live preview function will not be able to load in time to see it.

Once completed, a report of the run with key information such as run-time and pass/fail will be produced, and you should be taken straight there.

In the report, a tab named ‘video’ should appear automatically. This tab, as you would expect, contains a video recording of the test case so you can see what happened when the test ran.

Editing your first case

All development tasks for a test can be managed from its respective case in MaxTAF. This includes scripting.

We will now go through how to edit a test script from a case.

Head back to the case by clicking either ‘go to case’ from the report that was opened in the last section, or by going back to cases -> your test case.
Click on the ‘Script’ tab.

This will present you with an editor, which contains the lines of code used by the script.

Feel free to edit this in any way you wish. If you need an example, try adding another assert function beneath the one that already exists:

Example Code Snippet:

// assert that the search text box on the result page contains "Hello World"

String searchString = driver.findElement(By.name("q")).getAttribute("value");

Assert.assertEquals(searchString, "Hello World");

Click ‘Save’ -> ‘Run’(Hotkey Tip: Alt-r does both), and can check to see if your code has compiled correctly and runs.

Now you have edited your first test case.

The MaxTAF editor works in the same way as any other IDE editor (in fact it’s based on VSCode’s editor, Monaco) so you don’t need to worry about missing any desired IDE functionality. You can simply create cases as you are used to.

Next we will have a look at Suites, the way to group up tests for batch runs.

Suites

Suites are groups of tests (they can also group up suites, a useful feature). Typically they are used to organise your cases in a logical manner, such tests of a certain type (e.g UI/API tests) or tests for a certain area of your application.

Grouping tests in this way is critical for making the most of MaxTAF Allure reports (see below).

To create a suite you need multiple tests (obviously).

Duplicating tests

You can start to add cases from this point onward, or you can duplicate the test you created a couple of times for the purposes of this exercise.

To duplicate your case:

Head to cases
Enter on the case you desire to duplicate
Press Duplicate

Do this 3 or 4 times for the purposes of the exercise.

The Suites Section

Go to “Suites”, found in the left hand menu.

This section of MaxTAF is the place to administer all your suites.

Click Create
Give the suite a name and click Create.

You’ve now created your first suite!

To populate this suite, scroll down and click ‘add items’.
Add the test cases you’ve created.

Now you have a suite that, when ran, will run all of those cases, and produce a report at the end of it.

Running a Suite

To run your suite, simply press ‘Run’ (and ‘Run’ again in the advanced dialogue) when you’ve navigated to the suite.

You can change the sequence that the tests run in by changing the numbers in the ‘Sequence’ column in the items table. The lower the number, the earlier in the sequence it will run.

To run all the cases in parallel, set all the sequence numbers to the same number, e.g 10.

Reports

Running a Suite will automatically produce an Allure report on completion.

Allure Reports

Allure is a powerful open source test reporting framework. To find out more about it’s intricacies, editability and other details please visit the documentation for Allure here:

https://docs.qameta.io/allure/

To find the report, you will see some options around for ‘Allure Report’. If you press the ‘Allure Report’ Tab, you will open the report in-app. If you press the button to the right of ‘Go to Suite’, the report will open in a popout Tab.

Schedules

Schedules can easily be created.

Head to ‘Schedule’ from the left hand menu.
Click ‘Create’
Name it and Select the Case or Suite you wish to Schedule for
Press ‘Create’
To choose the frequency of the Schedule, Navigate to the schedule data box, find the ‘Schedule’ line, and press the Pencil Icon.

The options here are fairly self evident.

Finishing Up

This was the basic guide to MaxTAF, covering Account set-up, project/case/suite/schedule creation and other essential details.

Areas that have not been covered, but will become more essential as you progress through your MaxTAF development journey, are:

Parameters
Data Driven Testing
Workspace

Developing Test Cases

Script Editor Features

Code Completion

Every Major IDE has a code completion feature that is very useful when quickly developing test cases. The autocomplete feature should work out of the box as long as the language server status is enabled (green circle on the bottom right of the editor).

In order to see the code completion in action, start typing code and you should get suggestions as you type.

Code Lookup

Code Lookup is an innovative feature that allows users to have an example script opened alongside a script in development.

This is especially useful for referencing and code-reusage, a critical part of efficient Software Development In Testing.

Where to find it

The Code Lookup button is found in the script tab of a test case, to the far right of the toolbar

Pressing the Code Look-up button will allow you to use find and bring up any other script, from any of the projects you are a part of, to reference.

Code Snippets can be copied and pasted from Code Lookup views over to your main script.

Failure line jump

Failure line jump is a useful feature when writing test cases, it allows you to jump to and highlight the exact line of code which produces some error. To do so, you just need to click on the line number in the error message as shown below.

Code Formatting

As you type code for a test case, you are prone to making visual mistakes (like indentation, new lines, etc.). Language server has a great which you can use to format your code. This is particularly useful when you want to type fast and have beautifully formatted code.

In order to format your code, either right click somewhere inside the code editor then click on “Format Document”, or press “Shift + Alt + F” and the code will format itself.

Supported Languages

MaxTAF Cloud currently supports 4 different programming languages:

MXML
Java
Python
Javascript
C# (work in progress)

When you are creating a case, you can choose a language in which your could will be written.

MXML is MaxTAF Cloud’s custom language that uses XML tags and makes it easier for the person who is not a developer to actually write code. MXML transpiles into Java code which is then compiled. You can read in depth about MXML in the MXML section of the developers guide.

Java is a standard language for writing test cases. You can also use custom .jar or third party libraries inside your test case.

Python is minimal and doesn’t have the need for compilation. It also supports custom or third party libraries.

Javascript is somewhere between Java/Python and also doesn’t need to be compiled.

Parameters

Parameters are a powerful and flexible tool for system configuration in MaxTAF Cloud.

Reserved Parameters

Below is a list of all reserved parameters. Reserved parameters can have custom values but the key cannot be used for any other task:

mx.test.##	mx.datadriven.file	mx.selenium.server
mx.suite.##	mx.datadriven.runtype	mx.selenium.enable_video_recording
mx.user.##	mx.datadriven.name.##	mx.selenium.browser
mx.project.##	mx.datadriven.col.##	mx.selenium.mode
mx.system.##	mx.selenium.slow_down_level
mx.time_to_live	mx.bridge.address	mx.selenium.proxy
mx.params.source	mx.notify
mx.params.method	mx.notify.email
mx.params.method.source	mx.notify.on_outcome
mx.mxml.schemaFormat

mx.params

All three parameters need to respect their own rules. That means that if you set them like this:

mx.params=user-suite-test

mx.params.method=intersection

mx.params.method.source=test

They are not going to be applied inside the “project” layer, because the “project” layer (where they are defined) is not going to be taken into consideration when setting parameters. Look at “mx.params.source” as an example.

If the parameters were defined like this:

mx.params=user-suite-test-project

mx.params.method=intersection

mx.params.method.source=test

Then they are not going to be applied inside the “project”, “suite” or “user” layer, because these layers will not be in intersection if not defined so in “test”. Look at “mx.params.method” and “mx.params.method.source” as an example.

mx.params.source

Default value	mx.params.source=user-suite-test-project
Possible values	‘test’, ‘suite’, ‘user’, ‘project’, ‘system’, separated by -
Meaning	Determines which layers will be used to set parameters for run. Determines which layer has bigger priority.

Layers that are defined first have bigger priority:

Example: ‘mx.params.source=user-test-project’

‘user’ layer has top priority, then ‘test’ and then ‘project’ layer. That means that if the same parameter is defined in the “user” and “test” and “project” layer, the one in the “user” layer will be used.

If the parameter is only declared and it’s value is not defined, it’s value could be the value from some layer that has lower priority. Example 5 explains in which situations that happens.

“suite” layer exists only if suite is running

The value “system” should not be used in “mx.params.source” parameter

Examples:

layers

user	suite	test	project	system
fruit=cherry	fruit=banana	fruit=apple	fruit=pear	fruit=grapes
..	..	..	..	..

1) If “test” layer had the parameter “mx.params.source=test”, the result would be:

fruit=apple

Because the parameter “mx.params.source” is set to “test”, the “test” layer will be used for parameter setup. Other layers will be ignored.

2) If “suite” or “test” layer had the parameter “mx.params.source=suite-test”, the result would be:

fruit=banana

Because the same parameter is in the “suite” and “test” layer, the parameter from the layer with bigger priority will be used. In this case the “suite” layer has a bigger priority than the “test” layer.

3) If “user”, “suite”, “test” or “project” layer had the parameter “mx.params.source=user-suite-test-project”, the result would be:

fruit=cherry

Because the same parameter is in different layers, the parameter from the layer with the biggest priority will be used. In this case the “user” layer has the biggest priority.

4) If “test”, “suite” or “project” layer had the parameter “mx.params.source=test-suite-project-test”, the result would be:

fruit=apple

You can mention one layer multiple times.

Because the “test” layer has the biggest priority, the value of the parameter is “apple”

layers

user	suite	test	project	system
fruit=	fruit=banana	fruit=	fruit=pear	fruit=
..	..	..	..	..

5) If the “test” or “project” layer had the parameter “mx.params.source=suite-test-project”, the result would be:

If suite is run:

fruit=banana

Because the test is run from a suite, we have a “suite” layer. Because “suite” layer has bigger priority than “test” and “project” layers, parameter will take value from the “suite” layer

If test case is run:

fruit=pear

If the test case is run individually, “suite” layer doesn’t exist, so we compare “test” and “project” layers. “test” layer has bigger priority, but the parameter “fruit” doesn’t have a value in the “test” layer, so in that case if the value is not set, the layer with smaller priority will be picked. If the parameter exists, we would be using it.

If we wanted to not set the parameter value, we could’ve done that in two ways. One way is to delete the parameter “fruit” from the “project” layer, or we could’ve changed the value of the parameter mx.params.source to mx.params.source=user-suite-test, so the “project” layer is not included.

For more examples, look at the bottom of the “mx.params” category, because in order to understand everything, you need to know what “mx.params.method” and “mx.params.method.source” parameters do.

mx.params.method

Default value	mx.params.method=intersection
Possible values	‘union’, ‘intersection’
Meaning	Explains the way in which layers will merge

If the value is “union”, then all parameters from the layer specified in mx.params.source will be merged together.

If the value is “intersection”, then all parameters of the layer will be intersected with the layer specified in mx.params.method.source

“intersection”, are not common elements in all layer but intersection in relation to layer specified with parameter mx.params.method.source

Examples:

layers

user	suite	test	project	system
fruit=cherry	fruit=banana	fruit=apple	fruit=pear	fruit=grapes
		food=pizza
			seasons=winter

If “test” or “project” layers had the following parameters: ‘mx.params.source=test-project’ i ‘mx.params.method=union’ the result would be:

fruit=apple

food=pizza

seasons=winter

If “test” or “project” layers had the following parameters: ‘mx.params.source=test-project’ i ‘mx.params.method=intersection’ the result would be:

fruit=apple

food=pizza

If you wonder why the result is not

fruit=apple

Look at the explanation of parameter ‘mx.params.method.source’

For more examples look at the end of mx.params category, because in order to understand everything you need to know what “mx.params.source” and “mx.params.method.source” parameters do.

mx.params.method.source

Default value	mx.params.method.source=test
Possible values	‘test’, ‘suite’, ‘user’, ‘project’, ‘system’
Meaning	Determines what is intersection for layers when parameter ‘mx.params.method’ has value ‘intersection’

Default value

mx.params.method.source=test

Possible values

‘test’, ‘suite’, ‘user’, ‘project’, ‘system’

Meaning

Determines what is intersection for layers when parameter ‘mx.params.method’ has value ‘intersection’

If the value of parameter “mx.params.method” is “union”, the parameter “mx.params.method.source” is ignored.

The value “system” should not be used.

Examples:

layers

user	suite	test	project	system
fruit=cherry	fruit=banana	fruit=apple	fruit=pear
		animal=cat	animal=dog
seasons=summer			seasons=winter
		food=pizza
				instrument=guitar

If the test parameters were ‘mx.params.source=user-suite-test-project’, ‘mx.params.method=intersection’ and ‘mx.params.method.source=test’ the result would have parameters:

fruit=cherry

animal=cat

food=pizza

Because the value of parameter ‘mx.params.method.source’ is ‘test’ we will have only “test” layer parameters.

If the test parameters were ‘mx.params.source=user-suite-test-project’, ‘mx.params.method=intersection’ and ‘mx.params.method.source=suite’ the result would have parameters:

fruit=cherry

Because the value of parameter ‘mx.params.method.source’ is ‘suite’ we will have only “suite” layer parameters.

If the test parameters were ‘mx.params.source=user-suite-test-project’, ‘mx.params.method=union’ and ‘mx.params.method.source=user the result would have parameters:

fruit=cherry

animal=cat

seasons=summer

food=pizza

Because the value of parameter ‘mx.params.method’ is ‘union’, parameter ‘mx.params.method.source’ is ignored and result contains union of parameters from all the layers that are mentioned in “mx.params.source” parameter.

Examples:

layers

user	suite	test	project	system
fruit=cherry	fruit=banana	fruit=apple	fruit=pear
		animal=cat	animal=dog
vegetables=carrot	vegetables=pepper
seasons=summer			seasons=winter
			drink=beer	drink=water
		food=pizza
color=green	color=red		color=pink
	sport=basketball	sport=	sport=tennis
				instrument=guitar

All 3 parameters have default value and they are not defined in any layer (we can do that in test parameters)

mx.params.source=user-suite-test-project

mx.params.method=intersection

mx.params.method.source=test

The result would be:

fruit=cherry

animal=cat

vegetables=carrot

food=pizza

sport=basketball or tennis

- The result has only parameters that “test” layer has, because parameter “mx.params.method” has value “intersection”, which means that the intersection of the layer will be made in relation to “test” layer that we see from parameter “mx.params.method.source=test”

- The value for fruit is “cherry” because parameter “mx.params.source” has a “user” layer, then “suite”, then “test” and, in the end, “project” layer. When the same parameter exists in multiple layers the one with highest priority compared to the “test” layer will be used (mx.params.method.source=test), and in this case that’s “user” layer.

- The value for animal is “cat” because that parameter is not defined in any layer with higher priority (“user” and “suite”) compared to “test” layer (mx.params.method.source=test). It is however defined in a layer with lower priority but will not be applied because the parameter has value in the “test” layer.

- The value for food is “pizza” because that parameter is not defined in layer with higher priority (“user” and “suite”) compared to “test” layer (mx.params.method.source=test)

- The value for sport depends if the test is run inside the suite or on it’s own. If it’s run inside a suite, the value will be “basketball” because the “suite” layer has higher priority than the “test” layer. If it’s run on its own, the “suite” doesn’t exist and the parameter sport exists in two places: in the “test” layer and in the “project” layer. In that case the “test” layer has higher priorities, but because parameter sport in the “test” layer doesn’t have value, the value will be looked in layers that have lower priority and if it exists it will be used. In this case, parameter sport exists in the “project” layer and has value “tennis” so that value will be used.

If we use “union” instead of “intersection” for mx.params.method and we define these 3 parameters somewhere in “user”, “suite”, “test” or “project”:

mx.params.source=user-suite-test-project

mx.params.method=union

mx.params.method.source=test

The result would be:

fruit=cherry

animal=cat

seasons=summer

drink=beer

food=pizza

color=green

sport=basketball or tennis

Parameter ‘mx.params.method.source’ is ignored because the value of the parameter ‘mx.params.method’ is ‘union’.

Because the value of the parameter “mx.params.method” is “union”, the result contains all parameters that are defined in layers which are specified in “mx.params.source”. In our case that’s “user”, “suite”, “test” and “project” layers. Parameters from the “system” layer are not included in the utmost result because that layer is not defined in parameter “mx.params.source”, therefore we don’t have parameter “instrument”. That’s good because “system” layer parameters should be avoided in “mx.params.source”.

- The value for fruit is “cherry” because parameter ‘mx.params.source’ has a ‘user’ layer, then ‘suite’, then ‘test’ and in the end, ‘project’ as the last layer. When the same parameter exists in multiple layers, the one with the higher priority will be used, and in this case that's the “user” layer.

- The value for animal is “cat” because the layer with the highest priority is ‘test’ layer.

- The value for seasons is “summer” because parameter ‘mx.params.source’ has a ‘user’ layer, then ‘suite’, then ‘test’ and in the end ‘project’ as the last layer. When the same parameter exists in multiple layers, the one with the higher priority will be used, and in this case that's the “user” layer.

- Value for food is “pizza” because the layer with the highest priority is “project” layer.

- The value for color is "green” because parameter ‘mx.params.source’ has a ‘user’ layer, then ‘suite’, then ‘test’ and in the end, ‘project’ as the last layer. When the same parameter exists in multiple layers, the one with the higher priority will be used, and in this case that's the “user” layer.

- The value for sport depends if the test is run inside a suite or on it’s own. If it’s run inside suite, the value will be “basketball”, because “suite” layer has bigger priority than “test” layer, but if it’s run on its own, then “suite” layer doesn’t exist and parameter sport exists in two places: in “test” layer and in “project” layer. In that case the “test” layer has higher priority, but because parameter sport doesn’t have value in the “test” layer, it will be searched for in layers that have smaller priority, and it will be used if it exists. In this case parameter sport exists in the “project” layer and has value “tennis” so that the value will be used.

If the parameters are defined inside suite parameter:

mx.params.source=test-suite

mx.params.method=intersection

mx.params.method.source=suite

Then the result would be:

fruit=apple

vegetables=pepper

color=red

sport=basketball

This makes sense only for suite runs, so we will cover that case only.

- The result has only parameters that “suite” layer has, because parameter “mx.params.method” has value “intersection”, which means that intersection will be applied to layer in relation to “suite” layer, based on parameter “mx.params.method.source=suite”.

- The value for fruit is “apple”, not “banana”, because in parameter “mx.params.source” we specified that the “test” layer parameter has higher priority than “suite” layer. Also because the value “mx.params.source” doesn’t contain a “user” nor “project” layer, their parameters will be ignored, so the value can’t be taken from them.

- The value of vegetable is “pepper” because in parameter “mx.params.source”, we specified which layer will be looked at and which priority the layers have. There is no layer with higher priority that has that parameter. Other layers that have it aren’t included because we didn’t specify them in “mx.params.source”.

- Value of parameter color is “red” because in parameter “mx.params.source” we specified which layer will be looked at and which priority the layers have. There is no layer with higher priority that has that parameter. Other layers that have it aren’t included because we didn’t specify them in “mx.params.source”.

- Value for sport is basketball though the ‘test’ layer has higher priorities, but because parameter sport in ‘test’ layer doesn’t have value, it will be looked for in a layer that has lower priority and if exists, will be used. In our case, parameter sport exists in the “suite” layer and has the value “basketball”, so that the value will be used.

mx.time_to_live

Default value	mx.time_to_live=300
Possible values	Number between 0 and 300
Meaning	Specifies maximum allowed time for a test case run in seconds

- If we don’t have the parameter set, the default value will be used

- Maximum time for every test is 300 seconds (5 minutes) and can’t be higher than that.

- The user can put in a smaller value than 300 seconds, for example 60 seconds. If the test would finish in 20 seconds, everything would be fine, but if the test carries on for more than 60 seconds it will fail with a message that the maximum time exceeded.

Examples

mx.time_to_live=60

With this parameter, we limited the test run to 60 seconds.
If the test is finished in 20 seconds everything will be alright.
If the test would run for more than 60 seconds, it will be stopped in 60th second with a notification that the maximum time duration is passed.

mx.time_to_live=360

With this parameter, we specified that the maximum time duration of a test is 360 seconds, but because the maximum value for parameter “mx.time_to_live” is 300 seconds, the value will be ignored and 300 seconds will be applied as parameter value.
If the test would run for less than 300 seconds, for example 90 seconds, everything would be alright
If the test runs for more than 300 seconds, the test will be stopped on the 300th second with a notification that the maximum time duration is passed.

mx.notify

Default value	mx.notify=false
Possible values	‘true’ or ‘false’
Meaning	Specifies if we should get an email notification about test run results.

mx.notify.email

Default value	Email address of the owner of the project
Possible values	Email address, or email addresses separated by ‘,’ (comma) character
Meaning	If the parameter “mx.notify” has value “true”, then this parameter specifies to which email addresses should the notification be sent.

- If we want the notification to be sent to email@example.com, we would do that in the following way:

mx.notify.email=email@example.com

- If we want to send the notifications to multiple email addresses, we would do that in the following way:

mx.notify.email=email.1@example.com, email.2@example.com

- If parameter “mx.notify” has value “false”, parameter “mx.notify.email” will be ignored.

mx.notify.on_outcome

Default value	mx.notify.on_outcome=fail
Possible values	‘fail’ or ‘pass’ or ‘always’
Meaning	If the parameter “mx.notify” has value “true”, then this parameter specifies in which cases would the notification be sent.

- If the value is ‘fail’ the notification will be sent only if the test run fails.

- If the value is ‘pass’ the notification will be sent only if the test run succeeded.

- If the value is ‘always’ the notification will be sent when the test run finishes.

- If the parameter “mx.notify” is set to “false”, the parameter “mx.notify_on_outcome” will be ignored.

Examples:

1) If the parameters for notify were set in the following way:

mx.notify=true

The email would be sent to the owner of the project, only if the test failed.

2) If the parameters for notify were set in the following way:

mx.notify.email=email@example.com

mx.notify.on_outcome=always

Because the parameter “mx.notify” has the default value “false”, the other parameters will be ignored, and the notification won’t get sent.

3) If the parameters for notify were set in the following way:

mx.notify=true

mx.notify.email=email@example.com

mx.notify.on_outcome=pass

If the test run succeeds, the notification will be sent to the email address: email@example.com

4) If the parameters for notify were set in the following way:

mx.notify=true

mx.notify.email=email.1@example.com, email.2@example.com, email.3@example.com

Because parameter “mx.notify.on_outcome” has default value “fail”, if the fails, the notification would be sent to the following email addresses: email.1@example.com, email.2@example.com, email.3@example.com

mx.datadriven

mx.datadriven.file

Default value
Possible values	Location of the data driven file Example: mx.datadriven.file=/dd/data.csv
Meaning	Specifies test as a data driven test and points to a location of the data driven file.

- Supported file types (extensions) are .csv and .xls (.xlsx)

- If the value of the parameter is “mx.datadriven.file” value is “/dd/data.csv”, but before we run a test we pass a data driven file from UI, the parameter will be ignored, and the file that was passed from the UI will be used.

- If the parameter “mx.datadriven.file” has a set value, the test will count as a data driven test.

Example:

1) If the parameter ‘mx.datadriven.file’ was set in the following way:

mx.datadriven.file=/dd/data.csv

That would mean that the test is data driven and that the data driven file is on the location “/dd/data.csv”

mx.datadriven.runtype

Default value	mx.datadriven.runtype=serial
Possible values	‘serial’ or ‘parallel’
Meaning	Specifies in what way would we execute the rows from the data driven file.

- If the value of the parameter is set to “parallel”, but we set it to “serial” from UI, the data driven rows would be executed in serial because the UI dialog has higher priority.

mx.datadriven.name.###

Meaning

With the help of that parameter, we can get the value of the column from a data driven file by a column name.

- This parameter is always used as a variable.

Examples:

If we want to get value for parameter “place” for a column named “city” inside the data driven file, we could do that in the following way:

place=${mx.datadriven.name.city}

For “${}” usage, refer to our documentation.

mx.datadriven.col.###

Meaning

With the help of that parameter, we can get the value of the column from a data driven file by a column number.

- This parameter is always used as a variable.

Examples:

If we want to get value for parameter “place” from 3rd column inside the data driven file, we could do that in the following way:
place=${mx.datadriven.col.3}

For “${}” usage, refer to our documentation.

mx.bridge.address

Values	If the bridge is active, the value of the parameter is bridge address, if not, it has no value
Meaning	Specifies bridge address

- It’s specification is in the “user” layer.

- It exists only when MaxTAF Bridge is active (Look at MaxTAF Bridge documentation).

mx.selenium

mx.selenium.server

Default value

Possible values

“${mx.system.common_pool}”,

“${mx.system.private_pool}”

or selenium server address.

Example: “http://1.1.1.1:4444/wd/hub”

Meaning

This parameter specifies the selenium server address on which tests should be executed

- If the value is “${mx.system.common_pool}”, the common pool will be used for running the tests. Common pool is a pool of selenium nodes that everyone using MaxTAF Cloud shares. See more in the common pool section.

- If the value is “${mx.system.private_pool}”, the private pool will be used for running the tests. Private pool is a pool of selenium nodes that only you use, and are created on demand. See more in the private pool section.

- If the bridge is active, the parameter will have the following value: ‘mx.selenium.server=${mx.user.mx.bridge.address}/wd/hub’. The configuration for this is in the “user” layer.

mx.selenium.enable_video_recording

Default value	mx.selenium.enable_video_recording=false
Possible values	‘true’ or ‘false’
Meaning	This parameter specifies if the video of the test run should be recorded for later analysis

- If the parameter “mx.selenium.enable_video_recording” is set to “true”, the video will be recorded during run, and when the test finishes, the video will appear inside the “video” tab which can be expanded.

mx.selenium.browser

Default value	mx.selenium.browser=chrome
Possible values	‘internetexplorer’, ‘edge’, ‘chrome’ or ‘firefox’
Meaning	Specifies which browser should be used when running a test

mx.selenium.mode

Default value	mx.selenium.mode=remote
Possible values	‘remote’ or ‘local’
Meaning	Specifies if the remote selenium server should be used for running the tests, or if the tests are going to be run locally.

mx.selenium.slow_down_level

Default value	mx.selenium.slow_down_level=0
Possible values	Any number greater than 0
Meaning	How much the tests should be slowed if they are too quick for you to monitor them by eyes (in seconds)

mx.selenium.proxy

Default value
Possible values	Address of any HTTP proxy server
Meaning	Specifies which HTTP proxy server should be used in order to route requests

- Pretty useful if you want location consistency. For example a test that does Google Searches in the United Kingdom only.

mx.[layer].###

In order to understand these parameters, it is necessary to understand layers and variables.

mx.test.### mx.suite.### mx.user.### mx.project.### mx.system.### are not parameters but prefixes, and they are used for retrieving values of the parameters that exist in some other layer.

“mx” stands for “MaxTAF”, and next word specifies the layer and can be test, suite, user, project or system

Example:

If we have parameter “time” inside “project“ layer and we want to get its value, we could do that in the following way:

timeValue=${mx.project.time}

If we have a parameter “time” in “user” layer and we want to get its value, we could do that in the following way:

timeValue=${mx.user.time}

If we have parameter “time” in “suite” layer and we want to get its value, we could do that in the following way:

timeValue=${mx.suite.time}

That will only work if we ran a test case inside a suite, because if we do not, there will be no “suite” layer

Using the Workspace (File System)

Adding Libraries

MaxTAF Cloud fully supports Java libraries. You can also use custom or third party libraries (for example from https://mvnrepository.com).

In order to use libraries do the following:

Go to “Workspace”
Depending on your java_ext_libs_path project parameter, you should navigate to it’s value in the folder tree (or by default /java/libs)
Once you navigate to Java libraries folder, upload the .jar by right clicking on the folder and selecting Upload
Once the .jar is uploaded, you can use it inside your test case code for compilation and autocompletion support

Working with Drive

After you successfully mount a drive, you can use it with your IDE of choice.

We usually recommend IntelliJ IDEA.

To use the drive as a Java project with IntelliJ IDEA, do the following:

Start up IntelliJ IDEA
Go to File => Open… and select “X:/java” for Windows or “/mnt//java” for Linux
You can now start using your project normally as a Java project

Test Management

Suites

Suites are batches of tests, used for running groups of tests.

They can be used to either run an entire pack of tests, or to batch tests up according to themes, system areas tested, types of test or any other level of refinement required.

Grouping tests in this way allows for more granular reporting, giving testers and developers better and more precise insight into system health.

Creating a suite

Creating a suite is simple.

Head to the Suites section of MaxTAF, which is found in the left-hand menu

Press ‘create’
Enter name, press create
In the items box, click “Add items”
Select the cases you want to add
Click “add” to confirm selection

Sequencing suite runs

Your test runs can be sequenced in any configuration or order that you choose.

In the items table, under the sequence column, the number dictates how early in the sequence tests will run.

If you select the same sequence number for different tests, then the tests will run in parallel.

Running a suite

Running a suite follows mostly the same rules as running cases, found here.

Sharing Data Between suite run tests

Cases can share information during a suite run. This is especially needed when one case creates some data object that will then be further processed by another case that runs after it.

The mechanism that MaxTAF Cloud uses is similar to a bulletin board, in the sense that the cases that participate in the same suite run can post information to and read information from a jointly accessible area.

To post a piece of information, a case will use ApiService method setSharedRunValue(name, value)
To read posted information, a case will use ApiService method getSharedRunValue(name)

Even for hierarchically structured suites (when a suite contains other suites), the values that are posted to the bulletin board are available to all cases in all suites that belong to the hierarchy.

Note: It is very important to correctly sequence the cases in the suite as otherwise you may end up reading a shared value before it has been set yet.

Example:

Suite Structure:

Sequence No	Case
10	Create_Invoice
20	Approve_Invoice

Java:

Create_Invoice code:

public class Create_Invoice extends Base {
		private ApiService mxService = super.getApiService();
		@Test
		public void test() { 
		mxService.setSharedRunValue("invoice_no", "INV123");
		}
	}

Approve_Invoice code:

	public class Approve_Invoice extends Base {
		private ApiService mxService = super.getApiService();
	...
		@Test
		public void test() { 
			String invoice_no = mxService.getSharedRunValue("invoice_no");

_____________________________________________________________

C#:

Create_Invoice code:

[AllureNUnit]
public class Create_Invoice : Base
{
	ApiService MxService;
	...
	[Test]
	public void Test1()
	{
	MxService.SetSharedRunValue("invoice_no","INV123");
	}
}

Approve_Invoice code:

[AllureNUnit]
public class Approve_Invoice : Base
{
	ApiService MxService;
	...
	[Test]
	public void Test1()
	{
		string invoice_no = MxService.GetSharedRunValue("invoice_no");
	}
}

_____________________________________________________________

Python:

Create_Invoice code:

class Create_Invoice(Base):

  def setup_class(self):
    self.mxService = Base.getApiService(Base)
    
  def testBasepy(self):
    self.mxService.setSharedRunValue("invoice_no","Hello from test!")

Approve_Invoice code:
class Approve_Invoice(Base):

  def setup_class(self):
    self.mxService = Base.getApiService(Base)
    
  def testBasepy(self):
    invoice_no = self.mxService.getSharedRunValue("invoice_no","Hello from test!")

_____________________________________________________________

JavaScript:

Create_Invoice code:

describe("Create_Invoice", function() {
  let mxService

  before(function() {
    mxService = base.getApiService()
  })

  it("posts invoice no", async function() {
    mxService.setSharedRunValue("invoice_no","INV123")
  })
})

Approve_Invoice code:
describe("Approve_Invoice", function() {
  let mxService

  before(function() {
    mxService = base.getApiService()
  })

  it("reads invoice no", async function() {
    invoice_no = await mxService.getSharedRunValue("invoice_no")
  })
})

Suites of Suites

Suites can be also batched up into meta-suites.

To create a suite of suites, follow the same process for cases, but when you enter the ‘add items’ dialogue, there is a tab at the top in which suites can be selected instead of cases.

Suite Parameters

The guide on suite parameters can be found here Check out Documentation on Parameters here

Scheduling Suites

Check out Documentation on Scheduling here

Templates

What are templates on MaxTAF Cloud?

Templates are used to create test cases with predefined code and parameters. Each test case on MaxTAF Cloud is created from a template. You can choose from many predefined templates in your project to create a test case.

Each template is a JSON object which has the following:

Case description
Case parameters
Case code
Language
Testing framework
Template description

Where are templates stored?

Templates are stored on your workspace. You can find them by opening Workspace > Templates.

How can I create my own templates?

You can create as many templates as you wish by exporting specific test cases as templates.

First, you have to create a test case (or choose an existing one) with the same combination of language and testing framework as you want your template to be, then feel free to change code and parameters according to your needs. When your test case is ready to become a template, simply click the Export button and check the Template option, give your new template a name and description (this is optional) and click Export.

Can I use my templates in other projects?

Yes you can. Just download the templates you want to use in other projects and upload them in the corresponding workspace folders for the projects in which you want to use them.

Exporting and Importing Cases or Suites

Exporting allows you to download a test case or suite in either XML or JSON format. To do so, follow these steps:

Navigate to the Suites/Cases page via the navigation menu
From the list on either page you can click on the suite/case that you want to export
Once on the page for your selected suite/case, you can press the export button near the top
From the dialog that appears you can choose whether you want to export it as an XML or JSON file
Press “Export” to download the suite or case as a file

If you decide to export a suite, all the contents or said suite will be within the resulting download file, including the test cases and suites within.

Importing allows you to upload a previously downloaded suite or case file to your project, allowing you to use them as you normally would. In order to import a case or suite you must follow these steps:

Navigate to the Suites/Cases page via the navigation menu
From here, you can click the import button at the top of the list of suites or cases
Within the prompt, you can use the file input to choose the file you want to upload by clicking browse or by dragging the file over it like you can in windows explorer
The dialog will automatically check the correct file type in the options below if it has the right extension
Click “Upload” and after a short delay the case or suite will appear in the list before you

Execution

Case Execution

Running a test case

Running a test case simply requires pressing the ‘Run’ button from either the script tab or the main tab when you are inside a particular test case.

You can also Run a test case directly from the workspace - See information here

Advanced Runs Dialogue

When you run a case, you will be presented with the option to either run the case, or to run using advanced settings

Basic Run

Simply press run again if you want to run the test case as is.

Instructions for Advanced Execution import to be added

Data Driven Testing

Data Driven Testing is possible to conduct in MaxTAF Cloud.

What is Data Driven Testing?

Data Driven Testing is the process whereby parameterized regression scripts are procedurally run with a different data scenarios, provided by rows of data in a spreadsheet.

In simple English, when you run a data driven test, you run the same script many times, but different variables such as asset types or failure classes are fed into the test for each iteration.

The nature of the data is determined by a spreadsheet you supply, with the number of rows equalling the number of runs (data scenarios) and each column referring to a discrete piece of data in the data scenario.

How do I run Data Driven Testing with MaxTAF?

Data Driven Testing requires preparation in three areas:

Parameters:

In the parameters in your main tab, configure parameters so that those prepared in your script can be fed data from your spreadsheet.

Data is contained in a file in the workspace specified by "mx.datadriven.file" parameter.

Add a new parameter in "Main" tab called mx.datadriven.file and set its value to the location of the data driven file relative to your workspace, for example:

mx.datadriven.file=/dd/google_search.csv

This parameter will search the file in root folder, then dd folder and there it will find google_search.csv

After that, specify parameters with custom names for columns and take the columns from data driven file like this:

language=${mx.datadriven.name.language} min_hits=${mx.datadriven.name.min_hits}

At run time, there will be a separate run for every row in the data file and each time, the test parameters will receive new values from the columns with specified name e.g. ${datadriven.name.language}

When there is no column title, the value can be specified by the column's number e.g. ${datadriven.col.2}

The first column in data driven file is treated as header column and it is used to identify the column by name (example: mx.datadriven.name.language)

Then you need to specify if the rows inside data driven file are to be treated and run as parallel test cases:

mx.datadriven.runtype=parallel

Script:

Follow the instructions to parameterize your script where you wish the data to be changed, so that you may modify your script parameters in the ‘main’ tab.

All you need to do in your test case script is get the data driven parameter you set in parameters (via mxService for example) and use them like you would with normal parameters:

String query = mxService.getParam("language");
long minExpectedHits = Long.parseLong(mxService.getParam("min_hits"));

Spreadsheet:

The spreadsheet you use can be created in either CSV or Excel format.

Each row will correspond to a different data scenario/ test run.

Each column will correspond to the different parameters you have defined.

Running Tests in Parallel or in Sequence

MaxTAF handles parallel test coordination as a basic feature.

Note: You may be limited by your plan on the number of parallel nodes you can deploy. If you exceed the number of nodes you have available, MaxTAF will use the max number available and sequentially run through your runs in batches.

Parallel Runs of Multiple Individual Cases

To run an individual case in parallel, usually used for basic performance checks, you must:

Press Run from your case’s page
Select the ‘Advanced’ dropdown menu
Select the ‘Performance’ dropdown menu
Set the ‘Run type’ option to ‘Parallel’
Choose the number of parallel runs you want
Click run

Parallel Suite Runs

Tests within suites can be run in parallel using the following steps.

Steps:

Suites -> [your suite]
Find the box labelled ‘Items’
The Sequence column dictates the run order of the suite.
If you set all the numbers to the same, e.g 10, they will run in parallel
You can also set some tests to run in parallel and some in sequence, for maximum control over your run order.

Data Driven

If your case is set up for Data Driven Testing See here, follow the above steps but instead of performance select data driven.

You can change the run type to Parallel and your data driven test will run in parallel for as many nodes as there are available.

Browser And OS Combos

MaxTAF Cloud officially supports:

Internet Explorer
Microsoft Edge
Google Chrome
Mozilla Firefox

The browser that we recommend as it was tested the most is Google Chrome.

In order to use a specific browser with a test, do the following:

Open any UI test case
In the “Params” section click on the pencil icon to edit the parameters for that case
Set the mx.selenium.browser parameter to “internetexplorer”, “edge”, “chrome” or “firefox” just as it is done in the picture below:

By default, if the “mx.selenium.browser” parameter is not set, MaxTAF Cloud will use Google Chrome.

Since selenium nodes from the common/private pools are run on a linux machine, the only browsers you can use with them are Google Chrome and Mozilla Firefox. In order to use Internet Explorer or Microsoft Edge you need to specify your own selenium hub/node that’s run on Microsoft Windows. You can do that by changing the parameter “mx.selenium.server” to your own selenium hub/node address.

Example:

“mx.selenium.server=http://111.111.111.111:4444/wd/hub”

Email Notifications

Email Notifications are available for case and suite runs.

See the parameters to set up notifications here

Notification Parameters

Scheduling Runs

You can schedule tests in a few ways.

Schedule Section

The schedule section, accessed from the left hand menu, allows you to create schedules for any case or suite.

Steps:

Navigate to the schedule section via the navigation menu
Press “Create”
Give the Schedule a name
Select the desired Case or Suite
Input details (note, to set the time for the schedule, press the pencil icon next to Schedule under Schedule Data.)

From a Case or Suite

You can also set schedules from the schedules tab inside individual Suites or cases.

These can be administered from the schedule menu as well.

Network and Infrastructure

API Service

API Service provides communication between MaxTAF Cloud and test cases. API Service is required for passing test case parameters to test, saving screenshots, generating xml reports etc. MaxTAF Cloud has an ApiService class for every supported language.

Getting started with API Service

Java

To use the API Service in a Java test, your test class needs to extend Base class and then instantiate ApiService by calling the getApiService method from the extended Base class.

package com.maxtaf;
import org.junit.Test;
import com.maxtaf.ApiService;
import com.maxtaf.Base;

public class JavaTestClass extends Base {

	private ApiService mxService = super.getApiService();

	@Test
	public void test() {
		// Your test code
	}

}

If you need to instantiate ApiService within static method you will have to call the static method from the Base class like this:

package com.maxtaf;
import com.maxtaf.ApiService;
import com.maxtaf.Base;

public class JavaTestClass extends Base {

	public static void main(String[] args) {
		Base.init(args);
		ApiService mxService = Base.getApiService();
	}
}

Python

To use API Service in a Python test, your test class needs to extend the Base class and then instantiate ApiService by calling the getApiService method from the extended Base class.

import pytest
from maxtafbase import Base

class TestPython(Base):
def setup_class(self):
self.cdlmApi = Base.getApiService(Base)
def testMethod(self):
	# Your test code

if __name__ == '__main__':
 	Base.init(Base)
 	pytest.main([__file__, *Base.args])

JavaScript

To use API Service in a JavaScript test, you have to import the Base class and then instantiate ApiService by calling the getApiService method from the imported Base class.

const assert = require("assert")
const base = require("../maxtaf/maxtafbase.js")

describe("JavaScriptTest", function() {
 	let mxService

 	before(function() {
mxService = base.getApiService()
})

it("should be test", async function() {
// Your test code
})
})

API Service methods

JAVA

Method name	getAllParams
Input parameters	none
Return type	String
Throws	Exception
Description	This method is used to get all test case parameters as a String divided by \n
Example	String myCaseParams = mxService.getAllParams();

Method name	getParam
Input parameters	paramName: String
Return type	String
Throws	Exception
Description	This method is used to get a specific test case parameter as a String
Example	String myCaseParam = mxService.getParam(“nameOfMyParam”);

Method name	getAllSystemParams
Input parameters	none
Return type	List<SystemParam>
Throws	Exception
Description	This method is used to get all system parameters as a list of type SystemParam
Example	List<SystemParam> systemParams = mxService.getAllSystemParams();

Method name	getSystemParam
Input parameters	paramName: String
Return type	String
Throws	Exception
Description	This method is used to get a specific system parameter value as a String
Example	String systemParamValue = mxService.getSystemParam(“someSystemParam”);

Method name	getAllProjectParams
Input parameters	none
Return type	List<ProjectParam>
Throws	Exception
Description	This method is used to get all project parameters as a list of type ProjectParam
Example	List<ProjectParam> projectParam = mxService.getAllProjectParams();

Method name	getProjectParam
Input parameters	paramName: String
Return type	String
Throws	Exception
Description	This method is used to get a specific project parameter value as a String
Example	String projectParamValue = mxService.getProjectParam(“someProjectParam”);

Method name	setProjectParam
Input parameters	projectParam: ProjectParam
Return type	ProjectParam
Throws	Exception
Description	This method is used to create/update a project parameter (if a project parameter with the same name already exists then that parameter will be updated, otherwise a new project parameter will be created)
Example	ProjectParam myProjectParam = new ProjectParam(); myProjectParam.setName(“projectParamName”); myProjectParam.setValue(“this is a value”); myProjectParam.setAutoIncrement(false); myProjectParam.setDescription(“This is example project param”); myProjectParam = mxService.setProjectParam(myProjectParam); // or mxService.setProjectParam(myProjectParam);

Method name	setProjectParam
Input parameters	paramName: String paramValue: String
Return type	ProjectParam
Throws	Exception
Description	This method is used to create/update a project parameter with “autoIncrement=true”(if a project parameter with the same name already exists then that parameter will be updated, otherwise a new project parameter will be created)
Example	ProjectParam myProjectParam = mxService.setProjectParam(“projectParamName”, “projectParamValue”); //or mxService.setProjectParam(“projectParamName”, “projectParamValue”);

Method name	setProjectParam
Input parameters	paramName: String paramValue: String autoIncrement: boolean
Return type	ProjectParam
Throws	Exception
Description	This method is used to create/update a project parameter (if a project parameter with same name already exists then that parameter will be updated, otherwise a new project parameter will be created)
Example	ProjectParam myProjectParam = mxService.setProjectParam(“projectParamName”, “projectParamValue”, false); // or mxService.setProjectParam(“projectParamName”, “projectParamValue”, false);

Method name	incrementProjectParam
Input parameters	paramName: String
Return type	String
Throws	Exception
Description	This method is used to increment a project parameter and return the incremented value as a String. If the parameter can’t be incremented, the method will return null
Example	String incrementedValue = mxService.incrementProjectParam(“projectParamName”);

Method name	deleteProjectParam
Input parameters	paramName: String
Return type	void
Throws	Exception
Description	This method is used to delete a project parameter
Example	mxService.deleteProjectParam(“projectParamName”);

Method name	setRunProgress
Input parameters	progress: int
Return type	void
Throws	Exception
Description	This method is used to set the overall run progress represented as a percentage
Example	mxService.setRunProgress(17); mxService.setRunProgress(50); mxService.setRunProgress(89); mxService.setRunProgress(100);

Method name	addLog
Input parameters	log: String
Return type	void
Throws	Exception
Description	This method is used to append a new String to the run log
Example	mxService.addLog(“This is a log”);

Method name	addLogLine
Input parameters	log: String
Return type	void
Throws	Exception
Description	This method is used to append a String to the run log with the new line character at the end
Example	mxService.addLogLine(“This is a log line”);

Method name	createReport
Input parameters	title: String description: String testClass: String author: String date: Date
Return type	void
Throws	Exception
Description	This method is used to create a new run report. This should be done before any test methods are called
Example	Date date = new Date(); mxService.createReport("Report title", "Report description", "testClass", "Name of author", date);
Result

Method name	setReportStatus
Input parameters	status: String (PASSED or FAILED)
Return type	void
Throws	Exception
Description	This method is used to set run the report status. This should be done after every test method has been called
Example	mxService.setReportStatus(“PASSED”);
Result

Method name	addTestReport
Input parameters	name: String
Return type	void
Throws	Exception
Description	This method is used to create a new test report. This should be done once per test method
Example	mxService.addTestReport(“My test report”);
Result

Method name	addTestReportStep
Input parameters	testReportName: String (must be same as report name you want to add it to) stepNumber: int action: String expectedResult: String actualResult: String status: String
Return type	void
Throws	Exception
Description	This method is used to append a test step to an already created test report. This should be done as many times as you need per test method
Example	mxService.addTestReportStep("My test report", 1, "Some action", "63", "78", "FAILED"); mxService.addTestReportStep("My test report", 2, "Another action", "true", "true", "PASSED");
Result

Method name	setSharedRunValue
Input parameters	paramName: String paramValue: String
Return type	void
Throws	Exception
Description	This method is used to create/update a parameter which is shared between all runs in a specific suite or multirun
Example	mxService.setSharedRunValue(“paramName”, “paramValue”);

Method name	getSharedRunValue
Input parameters	paramName: String
Return type	String
Throws	Exception
Description	This method is used to get a shared parameter value as a String
Example	String sharedParamValue = mxService.getSharedRunValue(“paramName”);

Method name	saveScreenshot
Input parameters	screenshot: byte[]
Return type	void
Throws	Exception
Description	This method is used to save an array of bytes as a screenshot from the Selenium WebDriver
Example	byte[] screenshot = ((TakesScreenshot) driver).getScreenshotAs(OutputType.BYTES); mxService.saveScreenshot(screenshot);
Result

Method name	runCase
Input parameters	caseName: String
Return type	CaseRunResult
Throws	Exception
Description	This method is used to run a test case
Example	mxService.runCase(“My case”);

Method name	runCase
Input parameters	caseName: String runDetails: RunDetails
Return type	CaseRunResult
Throws	Exception
Description	This method is used to run a test case with additional run details
Example	RunDetails runDetails = new RunDetails(); runDetails.setSyncAsync(SyncAsync.SYNC); runDetails.setRepeatRun(5); mxService.runSuite("My case", runDetails);

Method name	getCaseRunResult
Input parameters	runId: int
Return type	CaseRunResult
Throws	Exception
Description	This method is used to get the run details of a specific run
Example	CaseRunResult runResult = mxService.getCaseRunResult(1563);

Method name	runSuite
Input parameters	suiteName: String
Return type	SuiteRunResult
Throws	Exception
Description	This method is used to run a suite
Example	mxService.runSuite(“My suite”);

Method name	runSuite
Input parameters	suiteName: String runDetails: RunDetails
Return type	SuiteRunResult
Throws	Exception
Description	This method is used to run a suite with additional run details
Example	RunDetails runDetails = new RunDetails(); runDetails.setSyncAsync(SyncAsync.SYNC); runDetails.setRepeatRun(5); mxService.runSuite("My suite", runDetails);

Method name	getSuiteRunResult
Input parameters	runId: int
Return type	SuiteRunResult
Throws	Exception
Description	This method is used to get the run details of a specific run
Example	SuiteRunResult runResult = mxService.getSuiteRunResult(135);

Method name	stopRun
Input parameters	runId: int
Return type	void
Throws	Exception
Description	This method is used to stop an active run
Example	mxService.stopRun(1235);

Node Pools

Common Pool

Common pool is a pool of selenium nodes that you can run tests on. By default, it is a shared pool that all MaxTAF Cloud users can use between themselves. When you run a test on a common pool, the test is added to the queue. After checking for availability the test is sent to the first available selenium node, where it is executed. If all the nodes are busy, the test will wait in a queue for execution. After one of the nodes is available again, the test will continue with execution.

In order to use common pool for your case/suite, do the following:

Go to Cases/Suites and choose a case/suite
In the “Params” section click on the pencil icon to edit parameters for that case/suite
Set the mx.selenium.server parameter to ${mx.system.common_pool} as shown in the picture below: mx.selenium.server=${mx.system.common_pool}

You can also use a common pool to run tests in parallel. The maximum number of parallel cases vary by user, but the default is usually 10. MaxTAF Cloud will give you an error if you try to run too many (more than the common pool can handle).

Same goes for parallel cases/suites. If you run 10 tests and 5 nodes are available at that point in time, the first 5 will be run in parallel and the next 5 will wait in queue. When the nodes become available again, they will continue with execution.

Private Pool

Private pool is another cluster of selenium nodes in which you can run your tests. Unlike the common pool, a private pool is not shared by other MaxTAF Cloud users and is exclusive to the project. Nodes from the private pool are created on demand.

When the test is run on a private pool, a node is created. After some time (usually about 30 seconds) when the node is fully functional, the test continues with execution.

In order to use private pool for your case/suite, do the following:

Go to Cases/Suites and choose a case/suite
In the “Params” section click on the pencil icon to edit parameters for that case/suite
Set the mx.selenium.server parameter to ${mx.system.private_pool} just as shown in the picture below: mx.selenium.server=${mx.system.private_pool}

You can also use a private pool to run tests in parallel just like you would with the common pool. After all the tests are finished, the nodes will automatically shut themselves down.

MaxTAF Bridge

MaxTAF Bridge is a package that lets you execute the Selenium tests on your computer.

MaxTAF Bridge establishes an internet connection between your computer and MaxTAF Cloud server and then when you run one of your cases, you can have them launch the browser on your computer. A typical use-case for this is, if you need to test a site that is on your side of the firewall, and as such is not visible to the Selenium nodes that are hosted by MaxTAF.

Installation

To install MaxTAF Bridge do the following:

Download the MaxTAF Bridge package from <>
Unzip the zip file in a directory of your choice
Modify resources/application.properties and enter your MaxTAF.com username, password and the id of the project that holds the test cases that you want to run. The id of the project can be found by going to Settings -> Project via the navigation menu. Note: if, for security reasons, you do not wish to keep login details in this file, you can leave it empty and then supply the login details each time you run the application.

External Software Dependencies:

Independent of MaxTAF bridge installation, you will also need to have on your computer:

Browsers that you want to use for testing
Selenium Server software
Browser drivers

Browsers that you want to use for testing

When running your cases through MaxTAF Bridge, they will be run on browsers that you have on your computer. Therefore you must install all of the different browsers that you plan to use for testing.

Selenium Server

To install and run a selenium server on your computer, follow the instructions from https://www.selenium.dev/downloads/ in the section marked “Selenium Server (Grid)”.

Note that Selenium server can be configured to any port number, but will default to 4444 if no specific port value is specified. MaxTAF bridge will establish connection on port 4444 by default. If this value is changed for the Selenium server, then the app.properties file needs to be modified by adding the following line:

Browser Drivers

A Selenium Server requires browsers drivers to run tests in the specific browsers you intend to use. These drivers are separate pieces of software that you need to install. Follow the instructions from the “Browsers” section of the https://www.selenium.dev/downloads/ web page. There you will find links to specific drivers (eg, chrome, firefox etc). Follow these links to get detailed instructions for download and installation.

Note: As browser versions change, it is likely that their drivers will change too. Therefore make sure that your drivers are kept up to date.

Running MaxTAF Bridge

Preconditions:

Before you start MaxTAF Bridge, make sure that you have first started your Selenium Server (following instructions from selenium.dev website) and that your browser drivers are correctly installed and configured according to the manufacturer's instructions (e.g. that they are visible to the Selenium Server).

A correctly started Selenium Server should look something like this:

To start MaxTAF Bridge, open a terminal (command line interface) and then navigate go to the root directory of the MaxTAF Bridge package. From there enter the following:

For Windows, enter start-bridge.bat

For Linux, enter start-bridge.sh

If started correctly, you should see something like this:

To confirm, if you login to MaxTAF cloud, open your target project, and navigate to Settings - User, you should see the bridge status indicator as green in color:

Now when you run a case from your project, communication will be established between MaxTAF Servers and your Selenium Server

How To Map A Drive

Mapping a drive is a functionality that lets you use your workspace from your personal computer.

Mapping your workspace folder to your computer allows you to use it directly from an IDE like a project.

To map your workspace folder, do the following:

Go to the MaxTAF Cloud Dashboard
Go to Settings => Project
Open the cmd/terminal
Execute the corresponding command (found in the project settings page under “Mount workspace”) to mount the drive
On Windows, the mounted folder should appear in “This PC” and on Linux in “/mnt”

Reports

Basic Reporting

MaxTAF has basic run results that are accessible immediately after a case or suite has finished running.

You can access this in a few ways:

After a test run

You should be taken straight to a basic report after your test has begun running. When completed it will update with the final information of that test run.

Completed runs section

Runs (left hand menu) -> Completed

This is a raw list of all runs completed on the system. It can be useful for understanding the entire scope of testing that is ran at any one time across your entire project.

Details

Most of the details are self explanatory here, but there are some things you could miss:

Failures: If a test fails, details of the failure are presented.

This includes whatever failure message has been prompted, as well as the stack trace for the failure in the script code.

Pressing the Line number (e.g Line 19 in the image below), will open the code tab lower in the report, and take you to the precise line where the test/script failed.

Log: if the script prints anything to the log, this is shown in the log dropdown. Note: this will update live as the test runs.

Console Output: Details the output of the browser console during the script run.

Params: details any params used during the test run.

Code: presents the code used during the run. Useful for version control/record keeping etc.

Allure (Graphical Reporting)

Allure is an open-source framework designed to create test execution reports that are clear to everyone in the team. You can read more about allure on Allure official website.

MaxTAF Cloud has integrated support for Allure reports. Each run automatically generates an Allure report.

How to generate an Allure report?

MaxTAF Cloud automatically generates an Allure report for each run. You can view the generated report from the Run details page by clicking the Allure report button.

Can I generate an Allure report for multiple test cases?

Yes you can. First, you have to create a Suite with the test cases you want. When the Suite is ready, run it. After the run is completed you will be able to click Allure report button.

Collaboration

Examples Project

About Examples

The examples project is a community driven project of example tests.

It is intended for MaxTAF users to refer to for their own automation problem solving tasks.

Every user is included in the examples project by default.

Uploading to examples

Any user can upload new tests to the examples project, in the same way they would do for their own projects.

Finding Examples

Example tests can be found by accessing through the project page or by switching projects using the menu at the top of the screen.

You may also use the Code Lookup in the script tab for a case and find other cases to lookup from Examples.

Settings

Project Settings

Projects are administered from the project settings menu, accessed under settings.

Users tab

Multiple Users can be added to a single project, allowing for frictionless collaboration on a shared workspace.

In Settings -> Project -> Users, users can be added to the project

Pressing ‘Add User’ will allow you to add users by email.

Note: Users do not need a MaxTAF account to be added, but must make one if they wish to use MaxTAF.

User Settings

Individual Users have a few unique settings that can be set for them.

Properties

You can also administer their ‘Properties’, which is an alternative term for Parameters. Users may run tests with parameters which are unique to them. Check out Documentation on Parameters here

Users requests Tab

Users who you have added to your project but have not yet created an account appear here.

Project Params Tab

You can administer parameters on the project layer here.

Check out Documentation on Parameters here

Table of Contents

User Guide

for MaxTAF Cloud

Getting Started with MaxTAF

Registration

Projects

Cases

Suites

Reports

Finishing Up

Developing Test Cases

Script Editor Features

Code Completion

Code Lookup

Failure line jump

Code Formatting

Supported Languages

Parameters

Reserved Parameters

mx.params

mx.params.source

Examples:

1) If “test” layer had the parameter “mx.params.source=test”, the result would be:

2) If “suite” or “test” layer had the parameter “mx.params.source=suite-test”, the result would be:

3) If “user”, “suite”, “test” or “project” layer had the parameter “mx.params.source=user-suite-test-project”, the result would be:

4) If “test”, “suite” or “project” layer had the parameter “mx.params.source=test-suite-project-test”, the result would be:

5) If the “test” or “project” layer had the parameter “mx.params.source=suite-test-project”, the result would be:

mx.params.method

Examples:

mx.params.method.source

Examples:

Examples:

mx.time_to_live

Examples

mx.time_to_live=60

mx.time_to_live=360

mx.notify

mx.notify

mx.notify.email

mx.notify.on_outcome

Examples:

1) If the parameters for notify were set in the following way:

2) If the parameters for notify were set in the following way:

3) If the parameters for notify were set in the following way:

4) If the parameters for notify were set in the following way:

mx.datadriven

mx.datadriven.file

Example:

1) If the parameter ‘mx.datadriven.file’ was set in the following way:

mx.datadriven.runtype

mx.datadriven.name.###

Examples:

mx.datadriven.col.###

Examples:

mx.bridge.address

mx.selenium

mx.selenium.server

mx.selenium.enable_video_recording

mx.selenium.browser

mx.selenium.mode

mx.selenium.slow_down_level

mx.selenium.proxy

mx.[layer].###

Example:

Using the Workspace (File System)

Adding Libraries

Working with Drive

Test Management

Suites

Sharing Data Between suite run tests

Templates

What are templates on MaxTAF Cloud?

Where are templates stored?

How can I create my own templates?

Can I use my templates in other projects?

Exporting and Importing Cases or Suites

Execution

Case Execution

Data Driven Testing

Running Tests in Parallel or in Sequence