I'm a title. Click here to edit me.
Why it's important when you perform Automation Testing, you should not perform manual testing?
Why it's important when you perform Automation Testing, you should not perform manual testing same time? Read my detailed experience sharing in this post. Most Companies these days ask testers to split the day into 2 parts: Part 1: Manual Testing Part 2: Automation Testing This practice looks very good on paper but in real projects, it's not going to work so easily unless you are extra ordinary talented while at work. It's always recommended you should perform functional and automation on a week-to-week basis rather than combining both on any given day. The situation is similar you are dating 2 ladies same time and when you date 1st lady you think about 2nd lady and when you date with 2nd lady you think about 1st lady. Combining both functional and automation test every day not only makes your day hectic but also significantly impact your productivity while at work. While I perform automation for any of my clients, I make sure there should not be any other tasks with me same time. The more I try to multi-tasking, the more difficult for me to deliver the best quality code. And if this happens to me, it can happen to most QA Engineers in real-time. The approach I followed is as below: Assuming I need to functional test 200 test cases and do automation for 50 test cases. I make sure first I execute 50 test cases that are part of automation in functional tests. And if 50 test cases are subsets then I accordingly divide my automation development into multiple phases depending on my functional test execution. I find myself more engaged in the later part of the week, so most times I start the week with a manual testing on Monday to Wednesday and Thursday and Friday focusing only on automation in any given week. And in some scenarios, I stretch the work during the weekend as I am already in automation flow at the end of Friday. Again, it varies from the QA Engineer's perspective on how he can plan his work but whatever works with me effectively while working with major clients like Mercedes-Benz, Germany and many others I have mentioned the same as part of this post. If you need any guidance for anything related to testing, you can send me a mail at email@example.com. I will try to respond to your query whenever I get some time. --------------------------------------------------------------------------------------------------------------------------- Next Generation Automation Learn Enterprise Level Test Automation Program Live Now. Interested QA Engineers can subscribe program and Learn enterprise level test development from scratch. And once you master the contents of program, I take your responsibility to brand you as expert QA Engineers at global level which no other learning program offer till date to any of its members. Program URL: https://www.nextgenerationautomation.com/learn-enterprise-level-test-automation Ankur Chaudhry Founder, Next Generation Automation Munich, Germany
Test Automation Framework Design Guidelines
In this post, I share important test automation framework design guidelines that helps you develop test automation project with better test coverage and less maintenance effort. Design Principle 1: Test Configuration Configurable items like Application Url, Username, Password, Browser type, Secret key, Driver.exe path should be kept in an external file. This will make sure while you change any configuration there should be minimum effort involved. Design Principle 2: Test Setup Information Any kind of test setup must be done by the @BeforeSuite, @BeforeClass TestNG annotations. Similar manner test clean up should be done by the @AftersSuite, @AfterClass TestNG annotations if you are using Test NG Based automation framework in your project. Design Principle 3: Test Folder and Main Folder All Test classes should be saved inside a folder called “test” and it MUST be a kind of mirror of main folder, meaning it will follow the same structure of the main project folder, but it will only contain tests. As shown, com.nga will be the group-id for both test and main folder. And all test class methods part of src/test/java package. Design Principle 4: Maintain Object identification repository Most common issues faced during automation are object identification changes. Framework should be able to patch such changes easily. Good design approach creates Object identifiers in page class and also map the object identifiers with page interaction methods in the same Page Class. Example Snapshot Design Principle 5: Status monitoring using debug logs and Exception Handling A framework should allow monitoring of the test execution status in real time and should be capable of sending alerts in case of failure using exception handling. This design approach ensures quick turnaround time in event of a test scripts failure. Example Logging Snapshot Design Principle 6: Reporting The framework should support html/Excel/Pdf report formats with details about test pass/fail for each test case/suite/test run. Example Report Snapshot Design Principle 7: Test Scripts and Test Data Test scripts and test data should always be separate from each other. Test data input can be in various forms like Excel, Ini, database inputs, hash maps etc. Example Test Scripts and Test Data Snapshot Design Principle 8: Creation of Utility Methods Utility method contain all reusable components. It includes both generic functions, and application specific functions. Tests should be exposed only to the implemented utility methods and tests should be performed by invoking these utility methods only. Example Utility Class Methods Snapshot Design Principle 9: Right code placement Automation projects tend to grow fast. Along with new tests, new shared code like page objects and data models keep adding during the test development. Maintaining a good, organized structure is necessary for project scalability and teamwork. Test cases should be organized by feature area. Common code should be abstracted from test cases and put into shared libraries. Example Multiple Test Classes Snapshot Design Principle 10: Avoid Code Duplication Many testing operations are inherently repetitive. QA Engineers sometimes just copy-paste code blocks, rather than seek existing methods or add new helper methods, to save development time. Such Coding practice must be strictly avoided as it not only makes code base in huge size but also result maintenance effort extremely high. Design Principle11: Multi-Platform Support Today's business applications run on multiple platforms same time: Multiple Web Browsers, Android Device, IOS Device and some cases Windows Version of application also available Automation framework must have capability to add on new platform if required by application in future Browser Factory design pattern provide multi-platform support once implemented in the framework. To implement all mentioned Test Automation Framework design principles, you can subscribe NGA in house developed Learn Enterprise Level Test Automation program. Also, Full mentorship support will be made available to understand development concepts as covered in the program with help of prerecorded videos. For more details about program, Visit below URL: https://www.nextgenerationautomation.com/learn-enterprise-level-test-automation Ankur Chaudhry Founder, Next Generation Automation
Learn Enterprise Level Test Automation
Learn Enterprise Level Automation program from Next Generation Automation helps QA Engineers to master test automation development in support with Next Generation Automation Founder, Ankur Chaudhry. Program Salient features as below: Program give QA Engineers enterprise level Automation experience Phase 1 of Program lets QA Engineers build framework architecture in a multi-threaded environment using Java as a programming language and Selenium as an automation API. Program let QA Engineers understand pain areas which automation engineers face while at work and how to fix the same. Program gives real world Automation Experience to QA Engineers and all automation exercises covered during program based on enterprise level automation scenarios Program helps QA Engineers build a developer mindset. How to approach complex business flow for automation and what should be QA Engineer design and coding approach while at work. Successful course completion and evaluation gives Star awards to all certified members. Star awards helps QA Engineers to brand them self both at international & domestic level and help them chase Overseas QA Automation jobs at very attractive salary packages. Block Diagram Learn Enterprise Level Automation program as below: Image shown above subject to copyright of Next Generation Automation and for learning purpose only. Learn Enterprise Level Automation Program divided into multiple sections to reduce the complexity and build scale able automation architecture as per enterprise needs. Section 1: Execution Engine This will be the start point for test scripts execution and execute test scripts in multiple Java threads. Each test class will be assigned 1 Thread for execution at run time by Execution Engine. Multi threading feature helps executing huge numbers of test scripts in a smaller time frame without compromising test quality. Section 2: Test Data Factory Modern business applications require a lot of data to be entered or verified. Such test data requirements will be served by the Test Data factory design pattern developed by NGA. At this point multiple storage formats are already integrated with developed architecture that includes Excel, Ini and MySQL. QA Engineers depending on project requirements can scale the test data factory to other storage formats as well in future. Section 3: Test Container Test container section holds actual test scripts that need to be developed as per application functionality. This section is specific to projects assigned to QA Engineers. Learn Enterprise Level Automation program let QA Engineers build test scripts for NGA Website. Later based on expertise gained, they can automate any other business application as part of working live projects. Section 4: Browser Factory Browser Factory will be the core of Automation Architecture and determines which browser to consider for test execution and how to maintain driver instances in case of multi-threading based / parallel test execution. Also, it sets up initial project environment like initializing Logging, Reporting and Configuration Files.
Browser Factory independent of application under test and will be a reusable component across multiple applications under test. Section 5: Business Layer Business Layer holds actual business workflows that need to be developed based on Application functionality. Learn Enterprise Level Automation Program takes into consideration NGA business workflows as part of this layer. This layer is specific to the project and depending on the application under test this layer can be developed. Section 6: Logging Logging keeps a log of all test execution steps and helps QA Engineers debug the test scripts for any failures and verify whether results generated as per written test scripts or not. Log files keep updating in real time based on test steps execution both at development console and text file format. Section 7: Reporting Reporting section generate test scripts pass and fail count in real time along with test dashboard creation in HTML format. If test execution in parallel, this module will fetch the results from all test scripts and generate consolidate test execution report once entire test execution get completed. For each thread class, separate report instance assigned at run time to capture test execution steps along with failures or exceptions generated from application if any. Section 8: Page Classes Page classes hold information about specific web pages. This includes building page elements along with page interaction methods. Page Class layer specific to project and depending on application under test this layer can be further developed. Section 9: Utility Classes Utility classes hold information about common utilities methods required for test script execution. Common Utilities include Excel Reader, Data Base Reader, Element Finder, Working with Frames, Buttons, Check Box, Drop Down components of application and many others. Utility classes independent of application under test and will be a reusable component across multiple applications under test.
Both utility classes and Page Classes at end of program are going to integrate with Spring Dependency injection Framework to provide ease of test scripts development and without worry to initialize every page and utility class object during test execution. Overall framework architecture and course contents developed keeping in mind IT Industry latest testing trends and development in Automation field over the last few years. Architecture developed as part of a program subject to upgrades in future even after its Phase 1 release. Interested QA Engineers can subscribe for program as per below link: https://www.nextgenerationautomation.com/learn-enterprise-level-test-automation For any details, you may connect with NGA at firstname.lastname@example.org. Ankur Chaudhry Founder, Next Generation Automation Building better QA for tomorrow
Commonly Asked Questions from Overseas Employers
Dear Job Seeker, While looking for any new job, it's very important to put some effort into understanding which Questions Employers look for while hiring the candidates. And if you are well prepared to answer questions from Employers, you are in a good position to chase Overseas High paying jobs without any significant efforts. Now you can discover all such jobs at NGA Platform as part of Overseas Hiring Model. Link to know more about the service offered below and if you have any questions you can call at 91-95883-35889 to discuss about your queries or if you need any support once you become a member of Overseas Hiring model. Overseas Hiring Model URL: https://www.nextgenerationautomation.com/overseas-hiring-model Commonly asked Questions from Overseas Employers as below: Question 1: Overall working experience as QA developer or SDET a) less than 5 years b) 5-10 years c) more than 10 years Question 2: Please describe your latest QA and/or SDET project? Answer: Mention more details here Question 3: Did you develop test plans and test cases that approximate real-world environments and scenarios. a) YES b) NO Question4: Ability to write effective code: a) Java b) Spring c) HTML d) Java Script e) XML f) AJAX g) Microservices h) SOA i) REST j) JSON k) Python l) C# m) Ruby Question 5: Different Types of Testing types you have worked? a) Accessibility testing b) Acceptance testing c) Black box testing d) End to end testing e) Functional testing f) Interactive testing g) Integration testing h) Load testing i) Non functional testing j) Performance testing k) Regression testing l) Sanity testing m) Security testing n) Smoke testing o) Stress testing p) Unit testing q) White-box testing Question 6: Experience and good knowledge of a) Object Oriented Analysis and Design(OOAD) b) Development of software using UML Methodology c) J2EE design patterns and Core Java design patterns Question 7: Do you have expertise in Docker? a) No experience b) Yes, but less than a year c) Yes,1-3 years d) Yes, 3-5 years e) Yes, more than 5 years Question 8: Do you have expertise in Kubernetes? a) No experience b) Yes, but less than a year c) Yes,1-3 years d) Yes, 3-5 years e) Yes, more than 5 years Question 9: Do you have expertise in XCUITest? a) No experience b) Yes, but less than a year c) Yes,1-3 years d) Yes, 3-5 years e) Yes, more than 5 years Question 10: Do you have expertise in Espresso? a) No experience b) Yes, but less than a year c) Yes,1-3 years d) Yes, 3-5 years e) Yes, more than 5 years Question 11: Do you have expertise in Gherkin? a) No experience b) Yes, but less than a year c) Yes,1-3 years d) Yes, 3-5 years e) Yes, more than 5 years Question 12: Do you have expertise in Protractor? a) No experience b) Yes, but less than a year c) Yes,1-3 years d) Yes, 3-5 years e) Yes, more than 5 years Question 13: Do you have expertise in GIT? a) No experience b) Yes, but less than a year c) Yes,1-3 years d) Yes, 3-5 years e) Yes, more than 5 years Question 14: Do you have expertise in Cucumber? a) No experience b) Yes, but less than a year c) Yes,1-3 years d) Yes, 3-5 years e) Yes, more than 5 years Question 15: Do you have expertise in Newman? a) No experience b) Yes, but less than a year c) Yes,1-3 years d) Yes, 3-5 years e) Yes, more than 5 years Question 16: Do you have expertise in Postman? a) No experience b) Yes, but less than a year c) Yes,1-3 years d) Yes, 3-5 years e) Yes, more than 5 years Question 17: Do you have expertise in Jenkins? a) No experience b) Yes, but less than a year c) Yes,1-3 years d) Yes, 3-5 years e) Yes, more than 5 years Question 18: Do you have expertise in Spinnaker? a) No experience b) Yes, but less than a year c) Yes,1-3 years d) Yes, 3-5 years e) Yes, more than 5 years Question 19: Do you have expertise in Datadog? a) No experience b) Yes, but less than a year c) Yes,1-3 years d) Yes, 3-5 years e) Yes, more than 5 years Question 20: Do you have expertise in Continuous Integration and Continuous Delivery? a) No experience b) Yes, but less than a year c) Yes,1-3 years d) Yes, 3-5 years e) Yes, more than 5 years Question 21: Experience in QA with exposure to: a) white box testing b) API Testing using REST c) none of above Question 22: Do you have expertise in Selenium ? a) No experience b) Yes, but less than a year c) Yes, 1-3 years d) Yes, 3-5 years e) Yes, more than 5 years Question 23: Do you have expertise in Cypress? a) No experience b) Yes, but less than a year c) Yes, 1-3 years d) Yes, 3-5 years e) Yes, more than 5 years Question 24: Do you have expertise in Appium? a) No experience b) Yes, but less than a year c) Yes,1-3 years d) Yes, 3-5 years e) Yes, more than 5 years Ankur Chaudhry Founder, NGA
Python Test Automation Frameworks
In this post, NGA will walk you through major Python frameworks that can be used for test automation and building robust test automation frameworks for your clients. UI Automation Frameworks: selenium webdriver - Browser automation tool. robotframework-selenium2library - Web testing library for Robot Framework. selene - Concise UI tests in Python + Ajax support + PageObjects + Widgets seleniumbase - A simple Python framework for building test automation with Selenium WebDriver. It depends on pytest or noose modules to run. When used with noose a HTML report can be generated in the end of the test run. Toolium - Toolium is a Python wrapper tool of Selenium and Appium libraries to test web and mobile applications in a single project. It provides a way of choosing and configuring the driver through a configuration file, implements a Page Object pattern and includes a simple visual testing solution. webdriver_manager - The main idea is to simplify managemet of binary drivers for different browsers. gauge - Gauge is a light weight cross-platform test automation tool. It provides the ability to author test cases in the business language, actually written in golang with python language driver. Pylenium.io - Pylenium brings the best of Selenium, Cypress and Python into one package. Playwright - Playwright is a Python library to automate Chromium, Firefox and WebKit browsers with a single API. Playwright delivers automation that is ever-green, capable, reliable and fast. splinter - A tool for test web applications with a simple for find elements, form actions, and others browser actions. testutils sst - A web test framework that uses Python to generate functional browser-based tests. wtframework - Framework for configurable Web Tests in Python. webium - A Page Object pattern implementation library for Python elementium - jQuery-style syntactic sugar for highly reliable automated browser testing in Python slickqa - The slick-webdriver-python project is a wrapper around the python webdriver client bindings. hitch - A high level integration testing framework for service based applications. Needle - Needle is a tool for testing visuals with Selenium and nose. It checks that CSS renders correctly by taking screenshots of portions of a website and comparing them against known good screenshots. It also provides tools for testing calculated CSS values and the position of HTML elements. PyPOM - PyPOM is a Python Page Object Model library for Selenium and Splinter tests. pypom_form - PyPOM based page object model for schema based forms. POM - POM is Page-Object-Model microframework to develop web UI tests easy, quickly and with pleasure. websmith - A Domain Specific Language (DSL) for Web Testing. pages - lightweight page object and component Python library for UI tests. Golem - Golem is a complete test automation tool and framework for end-to-end testing. It creates powerful, robust and maintainable test suites, it's easy to learn even without a lot of programming knowledge. It is based on Selenium Webdriver and it can be extended using Python Pylenium.io - Pylenium brings the best of Selenium, Cypress and Python into one package. Mailosaur - Python client for email testing/automation via Mailosaur. Rest API Automation Frameworks: Rester - Framework for testing (RESTful) HTTP APIs pyresttest - A REST testing and API microbenchmarking tool siesta - Python REST Client play_requests - pytest-play plugin driving the famous python requests library for making HTTP calls using plain YAML files gabbi - a tool for running HTTP tests where requests and responses are expressed as declarations in YAML files. Schemathesis - Schemathesis is a tool for property-based testing of applications based on Open API & Swagger specs. It reads the application schema and generates test cases which will ensure that your application is compliant with its schema. Includes pytest & unittest integrations. Mobile Automation Frameworks: appium - An open source test automation framework for use with native, hybrid and mobile web apps. It drives iOS and Android apps using the WebDriver protocol. Airtest - Airtest is a cross-platform automated testing framework focusing mainly on games, but can also be used for native apps. robotframework-androidlibrary - A Robot Framework test library for all your Android automation needs. robotframework-appiumlibrary - An appium testing library for RobotFramework. robotframework-ioslibrary - A Robot Framework test library for all your iOS automation needs. uiautomator - Python wrapper of Android uiautomator test tool, it works on Android 4.1+ simply with Android device attached via adb. ATX - Smart phone automation tool. Support iOS, Android, WebApp and game. Reporting Frameworks: allure pytest - Allure adapter for PyTest framework. HTMLTestRunner - An extension to the Python standard library's unittest module. It generates easy to use HTML test reports. unittest-xml-reporting - A unittest test runner that can save test results to XML files that can be consumed by a wide range of tools, such as build systems, IDEs and continuous integration servers. PrettyTable - Python library to generate nice table reports right in console. Unit Testing Frameworks: unittest - is a library to make unit testing distributed with python out of the box. unittest2 - is a backport of the new features added to the unittest testing framework in Python 2.7 and onwards. pytest - is a mature full-featured Python testing tool that helps you write better programs. plugincompat - Test execution and compatibility checks for pytest plugins test-junkie - Highly configurable modern testing framework. nosetests - is a nicer testing for python. slash - is a testing framework written in Python. lemoncheesecake - is a Python framework intended to functional testing, it provides fixtures, matchers, test organization through test suites hierarchy and metadata (test/suite name, description, tags, properties, links), rich reporting features and various report formats (JSON, XML, HTML, Junit) Extension Frameworks: proboscis - is a Python test framework that extends Python’s built-in unittest module and Nose with features from TestNG. grail - is a library which allows test script creation based on steps. testify - unit test framework, provides Enhanced test fixture setup, Split test suites into buckets for easy parallelization, PEP8 naming conventions & Fancy color test runner with lots of logging / reporting option. trial - Extension of unittest to support writing asynchronous unit tests using Deferreds and new result types ('skip' and 'todo'). Includes a command-line program that does test discovery and integrates with doctest and coverage. subunit - Transparently adds support for running unittest test cases/suites in a separate process : prevents system wide changes by a test destabilising the test runner. It also allows reporting from tests in another process into the unittest framework, giving a single integrated test environment. testresources - Provides a mechanism for managing 'resources' - expensive bits of infrastructure - that are needed by multiple tests. Resources are constructed and free on demand, but with an optional TestSuite?, the test run order is optimised to reduce the number of resource constructions and releases needed. Compatible with unittest. testtools - Useful extensions to unittest derived from custom extensions by projects such as Twisted and Bazaar. Sancho - Sancho 2.1 runs tests, and provides output for tests that fail; Sancho 2.1 does not count tests passed or failed; targets projects that do not maintain failing tests zope.testing - Powerful test runner that includes support for post-mortem debugging of test failures. Also includes profiling and coverage reporting. This is a standalone package that has no dependencies on Zope and works just fine with projects that don't use Zope. pythoscope - Tool that will automatically, or semi-automatically, generate unit tests for legacy systems written in Python. testlib - Gives more power to standard unittest. More assert* methods; support for module level setup/teardown; skip test feature... dutest - An object oriented interface to retrieve unittest test cases out of doctests. Hides initialization from doctests by allowing setUp and tearDown for each interactive example. Allows control over all the options provided by doctest. Specialized classes allow selective test discovery across a package hierarchy. green - Green is a clean, colorful test runner for Python unit tests. Compare it to nose or trial. ddt - Data-Driven tests with unittest pytractor is an extension to the Selenium bindings for Python. Its goal is to make testing of angular.js applications easier with Python. stestr - A parallel Python test runner built around subunit. AddOns: Editors, IDE, consoles: pycharm - Smart code editor provides first-class support for Python pydev - Full featured python ide based on eclipse sublime - A sophisticated text editor for code, markup and prose. ipython - A command shell for interactive computing in multiple programming languages, originally developed for the Python programming language VSCode - Very Neat Editor for python with loads of plugins #NGAutomation
Design patterns for test automation frameworks
In this post QA Automation Engineers will understand most commonly used design pattern for test automation frameworks. Lets first understand how poorly designed automation frameworks will lead to projects failures in long run. A poorly designed architecture is a major reason why test automation frameworks fail. Engineers need to identify problems and adopt the right design patterns upfront. Common factors that result in bad design are: Those implementing the work are new to or unfamiliar with test automation tactics. The project’s timeline is strict. The scale is unclear. Engineers lack basic programming knowledge and, as a result, don’t use the right principles. Design patterns: A better software testing technique and must take into consideration by every Automation Engineer. Design patterns provide a general reusable solution for the common problems that occur in software design. Design patterns are like collections of best practices as they provide a concept but not particular implementations. Design patterns help reduce code complexity as well as make code more extensible, and maintainable. Basically Design patterns are grouped into three categories: Structural patterns explain how to assemble objects and classes into larger structures while keeping these structures flexible and efficient. Creational patterns provide various object creation mechanisms, which increase flexibility and reuse of existing code. Behavioral patterns are concerned with algorithms and the assignment of responsibilities between objects. In this post, I’ll go over the most popular structural, creational, and behavioral design patterns, outlining what they are, why they’re useful, and how to structure them. Before diving into design patterns, it’s important to become familiar with SOLID principles that help make software design more understandable, flexible, and maintainable. The Single Responsibility Principle - A class should have one, and only one reason to change. The Open Closed Principle - You should be able to extend a class behavior without modifying it. The Liskov Substitution Principle - Derived classes must be substitutable for its base classes. The Interface Segregation Principle - Make fine grained interfaces that are client-specific. The Dependency Inversion Principle - Depend on abstractions, not on concretions. Structural design patterns Page Object Models (POM) What are they? This is the most popular structural design pattern and is commonly used in building test automation frameworks to automate UI test cases. The pattern abstracts any page information away from the actual tests. Why are they useful? POM’s are beneficial because: Developers don't need to write duplicate code. They create page components (e.g., input fields, buttons, etc.) which are used when building other page objects. The pattern provides encapsulation and abstraction. Page objects encapsulate web elements, or other class members and provide access to wrapper methods that hide all the logic (i.e., the mechanics used to locate or change data). Creating and organizing page objects makes it easier for developers to understand the structure of the automation solution via usage, new test creations, creation of new page components, and readability of tests. How are they structured? Page objects are like interfaces for web pages or web page components, also known as loadable components. These components support the same interaction with other web pages and should consist of: preferably encapsulated web elements other page objects methods to operate with page object and return other page objects by design no assertions should be used on page objects Below Block Diagram shows how commonly used POM looks like: To implement POM effectively, follow a folder and file structure to organize and keep page objects easily accessible. Page objects can be implemented in a functional or structural manner, depending on the approach and need. Composite patterns What are they? This pattern composes objects into tree structures to represent part-whole hierarchies. Composites let clients treat individual objects and compositions of objects uniformly. Why are they useful? A composite pattern is beneficial because: The simplified representation of a complex tree structures components as branches with the help of polymorphism and recursion. Implementing new items to the structure without altering the code (Open/Close principle) is easy. How are they structured? Composite patterns in automation solutions stem from a collection of page objects built up, forming a tree structure. While true, the main point of a composite pattern is to treat individual objects and compositions of objects uniformly. The structure gives the client control to operate through abstract the component interface. Engineers use a composite pattern to create components that benefit from a tree structure (e.g., menus needing sub-menus, sub-sub-menus, etc.) to get, select, or print all the items via recursion. For more complex needs, include custom iterators. In the image above, the TreeItem could be implemented as an interface or as an abstract class (if one would like to add default methods implementation). TreeLeaf is a basic element with most of the time all the code lives in these elements and does not feature other elements. TreeBranches hold other TreeItems and delegate all the work to child elements (i.e., tree leaves). Facade patterns What are they? The facade pattern provides a unified interface to a set of interfaces in a subsystem. The facade defines a higher-level interface that makes the subsystem easier to use. Why are they used? A façade pattern is beneficial because: Developers are able to create structure, consisting of layers of subsystems. Developers are able to simplify/hide code complexity from consumers. How are they structured? Facade is another structural design pattern that helps hide the complexity of one or more classes and provide one or more reasonable interfaces. The pattern still leaves direct access to the complex classes in case the user needs advanced functionality. Besides simplifying the interface, a facade pattern also decouples the client from inner system components. In test automation, a facade is mostly used to combine a few page objects/actions and provide uniform actions for consumers. For example, when a complex API needs to be executed in a specific order, create a facade for the designated functionality and provide a simplified interface for operating. Decorator patterns What are they? This pattern attaches additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality. Why are they useful? A decorator pattern is beneficial because: Developers are able to add new functionality to already existing objects without modifying its code (Open/Closed Principle). Developers are able to follow the single-responsibility principle allowing them to have multiple smaller classes divided by functionality. How are they structured? Decorators attach new behaviors to objects by placing the objects inside special wrapper objects that contain new behaviors. For example, to add logging functionality without a lot of changes to test automation solution using Webdriver, simply wrap (i.e., decorate) the Webdriver into EventFiringWebDriver. IWebdriver, IWebElement, INavigation, IOptions, ITargetLocator, and ITimeouts wrap with multiple new responsibilities. As a result, EventFiringWebDriver fires events on the main actions attached and listen to. With EventFiringWebDriver implemented, engineers easily access screenshots and logging on every exception or other action. To assemble: Create a listener class. Implement a method to capture screenshot and logging. Call that method on a specific event. Register the event listener to EventFiringWebDriver. Creational design patterns Factory method patterns What are they? This pattern defines an interface for creating an object but allows subclasses to decide which class to instantiate. Factory methods let a class defer instantiation to subclasses. Why are they useful? A factory method pattern is beneficial because: Having all objects initialization in a single place makes support much easier later (Single Responsibility Principle). The pattern is easily extendable without altering existing code (e.g., open/close principle). Scalability is easy to handle for tests runs (e.g., using Selenium Grid/ Docker containers). How are they structured? A factory method pattern is a creational pattern used for encapsulating the instantiation of concrete types, avoiding tight coupling between the creator and concrete products. Engineers don’t need to modify any code to extend the codebase. One of the best examples of a test automation framework is with the Selenium WebDriver initialization. While most of the initializations require some kind of setup afterward, when all Webdrivers share the same "IWebDriver" interface, refer Webdrivers through that interface. Adding another Webdriver (if necessary) is easy. Simply extend the factory method, which does not modify already existing code. The Webdriver includes a builtin factory method called PageFactory responsible for all page element initialization. To implement, declare the web elements and provide additional attributes if needed. Builder patterns What are they? This creational design pattern lets developers construct complex objects step by step. The pattern produces different types and representations of an object using the same construction code. Why are they useful? A builder pattern is beneficial because: Developers are able to create multiple representations of an object. The pattern isolates complex and the repetitive construction code in an object. How are they structured? As with any automation solution for software, a builder pattern is used to create an object needing many different representations. Representations with telescopic constructors are hard to maintain with difficulties generating readable code. Use the builder pattern to create fluent page objects. A builder pattern is easy to implement and understand. For example, when orchestrating a data transfer objects (DTO), like permissions for an object, with permissions such as read, create, update, and delete or any other object permission that needs to be built dynamically. When engineers need to build already predefined objects, consider introducing a director-class responsible for wrapping the builder defined steps in some kind of order (e.g., buildCRUD(Builder builder) which calls addCreate(), addRead(), addUpdate(), and addDelete() builder steps). Singleton patterns What are they? This pattern ensures a class has only one instance and provides a global point of access. Why are they useful? A singleton pattern is beneficial because: There’s only one instance of an object. In most cases, the pattern is used for Logger, Connections, or External Resources. Developers need a global access point to a class instance. How are they structured? Behavioral design patterns Strategy patterns What are they? This pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy patterns let the algorithm vary independently from the clients that use it. Why are they used? A strategy pattern is beneficial because: Engineers have various algorithms to complete a task, and that can switch depending on the specific task at the run time. Developers are able to easily add new strategies without altering the code (Open/Close principle). How are they structured? In test automation, strategy patterns are useful in various fields. For example, an application includes multiple payment methods on a checkout page or a different implementation on the same action, like account creation. One pattern uses UI, and another uses RESTful calls. These algorithms (strategies) are easily defined, encapsulated, and used for various needs. Engineers take all the logic from page objects and lets page objects delegate all the work to the strategy objects. Summary Design patterns and its application is an exceptionally worthwhile investment, despite the initial learning curve. To ease and speed up development test automation: Constantly evaluate and identify potential issues. Review the current design before implementing a new feature Keep engineers up to date on current objectives and future plans. Document most of the agreements on paper Have a backlog and actively work on corresponding tasks. Take time to understand the problem at hand and what design pattern solves the problem. Remember, constantly evaluate and identify problems to keep code clean. Needs change. Be mindful. Add a pattern when there’s a practical need for one. Sometimes the simplest solution is no pattern at all. Adding a pattern without just cause adds unnecessary complexity to an automation solution. When designing, address problems in the simplest way possible. Just keep it simple. #NGAutomation
Moving Beyond Selenium
Selenium Locator Strategies
Check commonly used locator strategies to find web elements while working complex web applications. XPATH Selectors CSS Selectors #NGAutomation
Selenium Commonly Used Commands
Check commonly used selenium commands which can be referred by UI Automation Developers anytime WebDriver Initialization Finding Web Elements Basic Browser Operations Basic Element Operations Advance Element Operations Advance Browser Operations Advance Browser Configurations #NGAutomation
Next Generation Automation Whats App Broadcast feed Live Now
Silent features of Whats App Broadcast feed from Next Generation Automation: 1. Feed let QA Engineers get latest technology updates related to testing as shared by NGA 2. Sharing Grow India Model updates and how its performing 3. Sharing Training Programs Updates where team actively working 4. Sharing Webinar invite links to let maximum QAs join the interactive sessions live hosted by NGA Academy 5. Sharing project openings where NGA is working actively for Clients 6. Participate in Proof of Concepts where NGA Academy actively working Membership free for a lifetime unless any QA like to quit by his choice. Click below URL and launch in your chrome browser to join the group: Group Join Invite link Click here #NGAutomation Building better QA for tomorrow
Evaluation Criteria to Hire Automation QAs now a days
In this post, I will share 4 important parameters that every QA Engineer must worked before appearing for any Automation Interview: Parameter1: Knowledge about Testing Tools Automation, API Testing, Selenium, Rest Assured, Jmeter We obsess on giving the best error and bug-free experience to our user. And therefore, you will be assessed on your skills in automation testing and using Frameworks like Selenium, Appium, Espresso to do so. Parameter 2: Scenario Assessment Automation Knowledge, Scenario Creation, Testing Concepts, Blackbox Testing Techniques, Linux basics. You will be assessed in detail on automation and on your ability to create positive/negative scenarios for testing. We also expect you to be well informed testing concepts like Blackbox testing techniques and Linux basics. Parameter 3: Project Experience Past Projects, Real Time Assessment, Simulation Exercise After thoroughly assessing your testing skills, we will now deep dive into your previous projects and understand their synergy and relevance with the projects where we are working currently. We will also challenge you with some real time simulation exercises. Brace up for some testing, folks! Parameter 4: Team Fitment Behavioral Assessment, Culture Fit, Project Knowledge, Role Operation Be yourself. It works out better for everyone if we're genuinely and can see if we're a cultural fit for each other. Everyone here is focused on our mission, so you should figure out what it is. #NGAutomation