DemoQA is a demo site for QA engineers, learning selenium.
Made by Tools QA.
Consists of website with training forms and example of bookshop with open API.

• Description
• Tools and technologies
• How to run
  • Gradle command
  • Property files
  • Run in Jenkins
• Telegram Notifications
• Test results report in Allure Report
• Allure TestOps integration
  • Project in Allure TestOps
  • Start a run of custom set of tests
  • Dashboard
  • Defects
• Video of running tests

The test project consists of Web and API tests.
A brief list of interesting facts about the project:

• Page Object with steps using Chain of Invocations
• Fake data generating with Faker library
• Parametrized tests
• Parametrized build
• Different configuration files for test running depending on build parameters
• Config with Owner library
• Use Lombok for models in API tests
• Objects serialization/deserialization for API requests/responses using Jackson
• Using request/response specifications for API tests
• Custom Allure listener for beautiful API requests/responses logging
• Allure TestOps integration
• Autotests as test documentation
• Parallel execution
• Failing tests retries

The autotests in this project are written in Java using Selenide framework.
Gradle - is used as a build automation tool.
JUnit5 - to execute tests.
REST Assured - for easy API testing of REST services.
Jenkins - CI/CD for running tests remotely.
Selenoid - to remote launching browsers in Docker containers.
Allure Report - for test results visualisation.
Telegram Bot - for test results notifications.
Allure TestOps - as Test Management System.

Back to the table of contents ⬆

To run locally the following command can be is used:

gradle clean test

Additional parameters:

-Dthreads=<number_of_threads> can be added for parallel tests execution
-Denv=remote can be added for remote tests execution when remote url is set in remote.properties

-Dtag=<tag> - tests with this tag will be executed:

• api
• ui

Additional properties are retrieved from the corresponding properties files:

./resources/config/${value}.properties

Back to the table of contents ⬆

Possible properties in a ${env}.properties file, local or remote:

browserName=
browserVersion=
browserSize=
baseURL=
isRemote=
remoteURL=

• browserName - browser for Web tests, chrome and firefox supported
• browserVersion - version of browser for Web tests
• browserSize - size of browser for Web tests
• baseUrl - base URL for Web tests
• isRemote - defines local or remote environments
• remoteURL - URL for remote WebDriver

Possible properties in a user.properties file:

username=
password=

• username - for authorization by old user that has a Git Pocket Guide book added in profile
• password - used for all users in tests

Back to the table of contents ⬆

Main page of the build:

A parametrized Jenkins job can be launched with needed parameters:

Sensitive config files are created in build workspace on build start.
Relatively safe information transferred to the build by gradle arguments (see Gradle command section, 'Additional parameters').

After the build is done the test results are available in:

• Allure Report
• Allure TestOps - results are uploaded there and the automated test-cases can be automatically updated accordingly to the recent changes in the code.

Back to the table of contents ⬆

Telegram bot sends a brief report to a specified telegram chat by results of each build.

Back to the table of contents ⬆

Main page of Allure report contains the following blocks:

• ALLURE REPORT - displays date and time of the test, overall number of launched tests, and a diagram with percent and number of passed, failed or broken tests
• TREND - displays trend of running tests for all runs
• SUITES - displays distribution of tests by suites
• CATEGORIES - displays distribution of unsuccessful tests by defect types

On the page the list of the tests grouped by suites with status shown for each test.
Full info about each test can be shown: tags, severity, duration, detailed steps.

Also additional test artifacts are available:

• Screenshot
• Page Source
• Browser console log
• Video

Back to the table of contents ⬆

Test-cases in the project are imported and constantly updated from the code, so there is no need in complex process of synchronization manual test-cases and autotests.
It is enough to create and update an autotest in the code and the test-case in TMS always will be in actual state.
Manual test-cases also can be added in TMS in case of need (via web interface or via code).

Any person not related to autotest creation can select a set of tests, environment parameters and start a run.
Allure TestOps run will be created, Jenkins job triggered with correct parameters. And results of the job will be seamlessly integrated into Allure TestOps.

As soon as the Jenkins job is done, corresponding tests get their statuses. A tester can finish manual tests (if any) and click "Close launch".

After that all these test-cases(names, steps, tags etc.) will be updated according to the recent code changes.

Back to the table of contents ⬆

Automation trends charts, distribution tests by some different parameters etc.:

Back to the table of contents ⬆

Knows defects are automatically recognized by defined patterns for test fails in further launches.

Back to the table of contents ⬆

Back to the table of contents ⬆