QA Automation Overview

Overview

1. What is Automation QA?

➢ Vokal QA Automation testing means running a series of test scripts to validate predetermined acceptance criteria as quickly and as efficiently as possible through our CI/CD process.
➢ It improves overall test coverage of our applications and helps catch regression issues as early as possible while also reducing the time it takes to ensure the application is compatible on all supported environments.

2. Why do we need it?

➢ Every software development group tests its products, yet delivered software always has defects. Test engineers strive to catch them before the product is released but they always creep in and they often reappear, even with the best manual testing processes. Test Automation software is the best way to increase the effectiveness, efficiency and coverage of your software testing.

Manual software testing is performed by a human sitting in front of a computer carefully going through application screens, trying various usage and input combinations, comparing the results to the expected behavior and recording their observations. Manual tests are repeated often during development cycles for source code changes and other situations like multiple operating environments and hardware configurations. An automated testing tool is able to playback pre-recorded and predefined actions, compare the results to the expected behavior and report the success or failure of these manual tests to a test engineer. Once automated tests are created they can easily be repeated and they can be extended to perform tasks impossible with manual testing. Because of this, savvy managers have found that automated software testing is an essential component of successful development projects.

Here are some of the key advantages of automation testing:

• Automated software testing saves time and money as minimal human interaction is needed once the scripts are ready. It saves the tester from re-running manual tests either for regression testing, smoke testing, integration testing, etc as automated tests take fraction of a time compared to manual test.
• Vastly Increases your test coverage. Automated software testing can increase the depth and scope of tests to help improve software quality. Lengthy tests that are often avoided during manual testing can be run unattended. They can even be run on multiple computers with different configurations. Automated software testing can look inside an application and see memory contents, data tables, file contents, and internal program states to determine if the product is behaving as expected.
• Improves Accuracy of test. Even the most conscientious tester will make mistakes during monotonous manual testing. Automated tests perform the same steps precisely every time they are executed and never forget to record detailed results. Testers freed from repetitive manual tests have more time to create new automated software tests and deal with complex features

3. What type of projects should we consider for Automation?

➢ You can consider any types of project for Automation but mostly long term projects should be considered for automation. As Automation is most advantageous when repeated manual testing for a functionality is needed, if the project is small scale it doesn't always give enough time for QA to implement automation scripts. Also the time needed to maintain the automation scripts is mostly found in long term projects where it yields better results.

4. When in project do we execute Automation tests?

➢ Automation tests are mostly executed during regression testing period. As automation is to save time when doing repeated testing and regression testing is to test pre existing functionalities of the app. You can also consider executing Automation tests for smoke tests. If we have a functionality rich application it's also recommended to run nightly automation during development phase to catch bugs before QA starts Manual testing of new development work.

5. What tools are we using for our Automation?

➢ We are using a combination of tools for our Automation test framework with the Key component being Selenium Webdriver. Our framework is built around the concepts of Cucumber using Java as the programming language.

Processes & Walkthrough

• Creating a new Project: For every new application we need to add for automation tests, following files need to be created.

  1. Locator file.
     Locator.xml is a file where you will be saving the element Xpath's to be used by your test scenarios. Create a copy of a pre existing Locator file and change the name to the new application ( ApplicationNameLocators.xml). Note: If mobile application contains both iOS and Android, it will require two separate locators file. Path to be created at: src/main/resources/com/tnow/qa

  2. Page.java file.
     Page.java is a class file where you will be writing application specific methods for test steps. Example: If you require a method to verify specific content before click on a button, the method for this step will be written in this file. Create a copy of a pre existing Page.java file and change the name to the new application (ApplicationNamePage.java). If the new application is a mobile application then create a copy of a pre existing MobilePage.java as those have different extended mobileProduct.java class which is required for basic functions such as tap, send values, etc. Path to be created at: src/main/java/com/tnow/qa

  3. Properties file.
     Properties file is where default build properties are set for the test. This is where you will provide default info such as what browser to run tests on, what locator file to consider for these tests, URL for the application if web or path of the .ipa or .apk if mobile, etc. Create a copy of a pre existing .Properties file and change the name to the new application (ApplicationNameType.properties). If the new application is a mobile application then create a copy of a pre existing Mobile.properties file as those have mandatory default parameters required inorder to begin test. Note: If mobile application contains both iOS and Android, it will require two separate properties file. Path to be created at: src/test/resources/com/tnow/qa

  4. Feature files.
     Feature files are where your test scripts will live. Each feature file can consist of multiple test scenarios. Each feature file has a feature file level tag (ex: @LousMobile_1_LoginTest&CreateAccount) and also has scenario level tags (ex: @LousMobile_LoginTest_1). The test scripts are written in simple Gherkins format with pre created test steps with glue code for each step. Before we create a feature file, we need to create a folder for the new project. Create a folder with Application name at path: src/test/resources/com/tnow/qa/features/ Once you have created a folder, now you need to create a new feature file. This can be done by copying a pre existing feature file or by right clicking on the newly created folder then > New > File and naming the file sample.feature (Recommended to copy from the top till end of first scenario to this newly created file and renaming the components)

  5. Test.java file.
     Test.java file is what you will execute in order to run your test scripts. In this file you will provide the tag/tags of the scenario's you want to execute. If the new application you are testing is a mobile application, this test file will also include the download application from Hockey method call and turning on the Appium server manually. Create a new test.java file by copying an existing test.java file (if mobile copy a mobile test.java). Note: for mobile applications, you will have to create two separate test.java files one for iOS and one for Android. Path to be created at: src/test/java/com/tnow/qa

  6. Updating ScenarioSteps.java file.
     ScenarioSteps.Java file is where all the glue code for each of the test scenario steps live. In order for us to be able to execute these steps, we need to update ScenarioSteps.java with addition of new application. First we need to add a static and boolean variable of the new application. Add following two lines under the list of all other variables:

     Public static AppNamePage AppNamePage; (replace "AppName" with the name provided while creating the page.java file, ex: VokalWebsitePage)

     Public static boolean AppName = false; (replace "AppName" with the name of the application given, if needed include type of application as well ex: VokalWebsite)

     Once we have added those two variables, we need to update the @given method. Find the method and scroll down to the if conditions. Add another "else if" condition as follow:

  ( Web application )

  

  ( Mobile application )

  

• Writing a test scenario:
  Writing a test scenario is like writing a detailed test case but in Gherkins format. Each of the test scenario should have a unique tag which can be used to run that specific scenario. Scenario Outline or Scenario should tell what those set of steps will be testing/verifying. It should start with Given (App name, devices want to run the test on). Now to perform certain actions, a pre established step will be used. for ex: for a tap/click action the step would be "And I click on 'ElementName_InLocatorsFile' button". In the same way each of the actions to be performed has a pre established steps. Sample screenshots:

Source:

• https://searchsoftwarequality.techtarget.com/definition/automated-software-testing
• https://smartbear.com/learn/automated-testing/