How to manage large amount of tests with Agilitest

  • They are stored in directories which can be local or shared and on which the operating system tools are operative (searches, replacements …).
  • A test corresponds to an ATS script and you have no additional binaries, (obviously unless you use the graphic recognition).
  • VYou can use sub-scripts and share them between scripts.
  • Act on the granularity of the tests
  • Act on test data
  • Act on test execution environments

Test management

With Agilitest you have three possibilities to manage your tests:

Flat management

All your “root” tests are in a single directory and you can use naming rules to identify them and identify the different functional areas they cover. It’s not so easy when you have a lot of tests, but this solution enables you to see all of your tests at a glance. Remember that each test can be represented by a single file in the base directory, and that you can then put the sub-scripts in dedicated sub-directories.

Package management

You can create as many sub-directories as you have functional domains to cover by your tests, the advantage is that each functional domain is identified and that the number of tests is reduced by domain. Unfortunately, you will have difficulty managing cross-domain tests.

Management by groups

  • Different functional areas of your application: groups allow a test to belong to several functional areas
  • Different execution priorities: depending on your delivery needs, it may be useful to restrict your test lists to make quick non-regressions, or to replay everything at night …
  • Different typing of tests: you can have tests which cover functionalities and which were carried out during the development of these, other tests can respond to the correction of a bug.
  • Execution environments: you can type your tests according to the environments on which you want to run them: different browsers, mobility.

The granularity of the tests

Agilitest is a a graphical tool, but allows you to manage tests that still have a large number of actions.

Test data

The tests must be deterministic: each test must know in advance what should be the results sent by the application and always check its own data. (This also allows you to consider more calmly the parallelization of nocturnal replays …).

Each test creates its data

It is the simplest to implement with the use of sub-scripts and data files which will allow you to quickly import a set of relevant data.

Data is created by the continuous integration system beforehand

The principle is to generate a set of test data before launching the test campaign, which is based on the CSV or JSON files stored in the test tree, and subsequently, the tests will check that the data is correctly reported by the application.

Test execution environments

Agilitest simply allows create executions that will act on different test execution environments and use them with continuous integration systems.

  • A succession of mobiles with different graphic properties.
  • Lists of terminals which can vary from one execution to another
  • Different data files from one run to the next

Implementation

  • There is a set of mechanisms which make it possible to provide a lot of pooling, re-use and combinatorics that are simple to implement in order to increase the testing capabilities.
  • The flexibility of ATS: text files, shared directories and possible mass editions allow you to quickly consider and implement changes.
  • Agilitest allows a great productivity and a speed of correction of tests which will allow you to easily manage all of these tests.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store