ScriptlessAutomation
  • 👋Welcome to Scriptless Automation
  • Discover More About Automation
    • ⚙️Automation platform intro
    • 💡Advantages of Scriptless Automation
    • 🚀Release Notes
      • 📖Open Code
      • 📕License Code
  • Product tools
    • 📪Pre-request Tools
    • 🔧Project Dependencies
  • Automation Architecture
    • 🎨Flow diagram
  • Get Started
    • 🛠️Start with Automation
    • 📖Open Code Automation
      • 🌏Web Automation
      • ↔️API Automation
    • 🏢Maven Configuration
    • 🗜️Setting Up Maven Project in IntelliJ IDEA
    • 🎛️Scriptless Config
      • 🕸️BrowserConfiguration
        • chrome.properties
      • 👥CommunicationConfiguration
        • SlackConfiguration.properties
      • 📧MailConfiguration
        • gmailCredentials.properties
      • 🛂ReportConfiguration
        • extentReportConfiguration.properties
      • 🕵️TestManagementConfiguration
        • testRail.properties
        • zephyrscale.properties
        • testiny.properties
      • ⚙️testNgConfiguration.properties
    • 🍱TestData Configuration
    • 👨‍💼Gherkin Language and Scriptless Automation Framework
  • Automation Import Notes
    • 🎨Points to Remember
  • Automation Platforms
    • 👾ScriptlessApi Automation
      • 🖊️Introduction
      • 🗜️Api Automation Setup
      • 🔃Supported API Request Types
      • 🪧API Automation Template
      • 📚Example of API Requests
        • ⬇️GET
        • ↕️POST
        • ⤵️PUT
        • ❌DELETE
      • 🎯API Response Validation
      • 👨‍👦API Dependent TestCase
      • 📝Store API Variables
      • 📔API with JSON body
      • 🙋‍♂️Api Wait
      • 🗜️API Schema Validation
      • 🏗️API Tailor-Made coding
      • 👨‍🦯API Support Generator
      • ↘️Api Response Store Objects
      • ✍️API Test Report
      • 🚃Api Response Type Validation
    • 🌐ScriptlessWeb Automation
      • 🖊️Introduction
      • 🗜️Web Automation Setup
      • 🪧Web Automation Template
      • 🧮page_object_locators
      • 📜Web Automation Key Phrases
        • 📃PAGE_NAME
        • ⌛WAIT_TYPE
        • 📜SCROLL_TYPE
        • 👨‍💼ELEMENT_NAME
        • 🏎️ACTIONS
        • ⌨️SEND_KEYS
        • ✔️VALIDATION
        • ✅VALIDATION_TYPE
      • 👨‍👦Web Dependent Test Case
      • 🐒MOCK
      • 🛂AutomationAsserts
      • 🏗️Web Tailor-Made coding
      • 📝Store Web Variables
      • 🤼‍♀️Web & API integration
      • 🖇️Dynamic Strings
      • 🗣️ReadFile Annotation for Custom Code
      • 🖼️Page_Comparison
      • 👨‍💼Gherkin Template for Web Automation
    • 📱Mobile Automation
  • 🪶Automation features
    • 🌲Environment and System Variables
    • 🗝️KeyInitializers
      • Types of KeyInitializers
    • ✍️Reporting
      • Dashboard
      • Category
      • Tests
        • Screenshot Section
    • 👯Parallel Testing
    • 🏗️Tailor-Made Coding
  • ⏩Automation Demo
Powered by GitBook
On this page
  • 📝 Configuration Overview
  • 🛠️ Configuration Parameters
  • 🚀 Execution Strategy
  • 📊 Reporting
  • 💡 Conclusion
  • File

Was this helpful?

  1. Get Started
  2. Scriptless Config

testNgConfiguration.properties

📝 Configuration Overview

This document outlines the configuration of a TestNG-based automation suite, designed for versatile execution across different platforms and environments. The suite, named 'AutomationReport', is adaptable for various testing needs including API, Web, Mobile, and Desktop platforms.

🛠️ Configuration Parameters

  1. ReportName: AutomationReport

    • Defines the name of the automation report. This name is used for generating and archiving test results, providing a consistent reference across different test executions.

  2. Platform

    • Type: Selectable (API/Web/Mobile/Desktop) 🌐

    • This parameter specifies the target platform for the test execution. It guides the selection of appropriate tools and libraries for API, web, mobile, or desktop automation, ensuring compatibility and efficiency.

  3. Env

    • Type: Environment Specification (e.g., staging, production, development) 🏞️

    • Determines the environment in which the tests will be executed. This could be a staging environment (as in the provided example), production, development, or any other predefined test environment. This flexibility allows for targeted testing under different conditions.

  4. ThreadCount: 2

    • Enables parallel execution using 2 threads. This setting is important for reducing total test time and uncovering concurrency issues, and is applicable across different platforms and environments. 🔀

  5. FAILED_RETRY_COUNT: 0

    • Specifies the number of times a failed test should be retried before it is finally marked as failed. Setting this to 0 disables the retry mechanism, ensuring that test results reflect the behavior from the first run. This parameter is crucial for accurately identifying issues without the influence of retries, which can sometimes mask or complicate the diagnosis of underlying problems. ❌

  6. SET_TEST_SUITE_NAME: Scriptless

    • Sets the name of the test suite to 'Scriptless'. This parameter provides an additional layer of organization, allowing for easier identification and grouping of test suites.

  7. SET_TEST_NAME: Regression Testing

    • Specifies 'Regression Testing' as the name for the test execution. This designation helps in categorizing the tests based on their purpose or functionality.

  8. TEST_IDS: SCRIP-T2,SCRIP-T3

    • Defines specific test IDs to be included in the test execution, allowing for targeted testing of certain features or functionalities within the application. If the goal is to execute all available test cases, this parameter can be set to ALL. This flexibility ensures that testers can either focus on specific areas of the application as needed or conduct comprehensive testing across the entire application.

      1. To Execute Specific Tests: Set TEST_IDS to the specific IDs of the tests you wish to run (e.g., TEST_IDS=SCRIP-T2,SCRIP-T3).

      2. To Execute All Tests: Simply set TEST_IDS to ALL, indicating that every test case within the suite should be executed (TEST_IDS=ALL). This is particularly useful for full regression testing or ensuring comprehensive coverage across the application.

  9. DISABLE_TEST_IDS:

    • An option to specify test IDs that should be excluded from execution. This feature is useful for temporarily disabling tests without removing them from the test suite.

  10. GROUPS: sanity

    Specifies test groups, such as 'sanity', to be executed. This allows for the execution of a subset of tests that fulfill specific criteria, facilitating focused testing efforts.

🚀 Execution Strategy

  • The tests can be executed across different platforms (API, Web, Mobile, Desktop), allowing for a broad range of automated testing scenarios.

  • The specified environment (e.g., staging, production) directs the tests to run under conditions that mimic the selected environment, ensuring relevant and reliable test outcomes.

  • Parallel execution and a strict approach to handling test failures ensure efficiency and reliability, regardless of the chosen platform or environment.

📊 Reporting

  • Test results are consolidated into the 'AutomationReport', offering a detailed overview of the testing activities across various platforms and environments. 📈

  • This report serves as a key tool for stakeholders, providing insights into the application's performance and stability under different testing scenarios.

💡 Conclusion

This TestNG configuration provides a flexible and robust framework for automated testing across multiple platforms and environments. The ability to specify the platform and environment, coupled with efficient execution strategies, makes it an effective tool for comprehensive application testing, from development stages to production readiness.

File

Previoustestiny.propertiesNextTestData Configuration

Last updated 1 year ago

Was this helpful?

🎛️
⚙️
235B
testNgConfiguration.properties