Testing - Automation Learning Path (Business, Codeless, Gherkin)

Pros & Cons of Automation - Automation can save time and money.
  • Automated tests can test as multiple users testing an application at the same time. Automated tests resemble hundreds or thousands of users testing at once, which would be impossible with manual testing.
  • Automation can also take repetitive tasks such as adding numbers for a multitude of various similar test scenarios.
  • Automation is particularly good for regression testing.
  • Test automation can speed up your testing time as compared to manually testing.
  • There can be scenarios that are too complex for automated testing and therefore would not justify the time it would take to set up the test automation scripts.
  • Automated tests should be easy to maintain and have high usability, meaning tests are used repetitively.
  • Test should not be too specific. Create tests which that are shareable across projects or work groups.

Testing Roles

Roles in a test automation process are the Stakeholder, Developer and Tester.
Stakeholder: This position oversees the components of the final project, but they are not there to run the day to day operations. They can decide what user stories are included for development but have no input on the actual sprints and development.
Developer: The developer wears many hats. Developing code is foremost, then there is code review, helping testers with automation, sprint planning and sprint review. Developers need to know automation tools, which tools that projects will be using, and setting up these different automation tools.
Tester: A manual tester has a lot to learn when it comes to automation. There are so many different applications that can be utilized. This is overwhelming at first. As a tester has had the time to go through this training path and play around with some of them, it seems less daunting. Testers can learn business processes, new software, and new techniques by applying everyday life skills to asking common sense questions. Testers can apply those concepts to writing test cases, user stories, and automation tasks.

Where to Test

  • Automated tests must be configured to run in multiple:
  • Environments, such as Windows or on the Apple.
  • Browsers, such as Firefox, Chrome, Safari, and Explorer
  • Devices, such as laptops, tablets, and cell phones.
  • Other differences include urls, login information, and database information.
  • When setting up automated test cases this information should be kept separate and instead be replaced with artifacts like property files.

Testing Pyramid

There are three levels to the testing pyramid. From the top down are the UI, Service, and Unit levels.
Unit Level:

It is always faster to test at the unit level, and the bulk of the automated tests should be here. Testing at the unit level leaves the test plan open to less pitfalls than when testing at the UI or Service level. Testing close to the production code lets automated tests run as quickly as possible. Unit testing can be done locally and does not involve web services or the complexities of going through the steps in the user interface.
Service Level:

The next level is the Service level. This level contains any services such as, web services, integration tests and API tests. This level can be used to test business logic outside of the UI.
UI Level:

Testing at the UI level is time consuming and tests are more apt to be brittle at this level.

Testing Tools

There are many different software applications for automating tests. Some of these are:
  • Cucumber with Gherkin Scripts: Gherkin scripts are based on behavior driven development that comes from the end user perspective. This is driven by keywords such as scenario, when, then, and, and but. For example, 'as a customer service representative, I need access to a list of customers that have purchased merchandise in the last thirty days'. Acceptance criteria is used to verify that the coding and testing were done correctly.
  • GitHub: Git and SVN are version control systems that track application versions and changes to the application. Versions can be thought of like trees. You have your main 'trunk' which is the core of your application. 'Branches' allow for changes in the trunk that may or may not be used by all customers. There can be multiple versions of the branches for specific customer needs.
  • Selenium: is a tool that can be called by the test framework that helps in automating web applications.
  • Postman: Postman ensures continuous integration and delivery when integrating automated test that will not break the API.
  • Applitools: Applitools can automatically run functional powered tests at scale across every application, operating software, and browsers.
  • Sikuli: Sikuli allows testing automation on screen captures of images. Use Sikuli on installable apps with no API. It is also good for testing online games.

    The best coding applications for test automation include:

  • Java
  • Java Script
  • C#
  • Ruby
  • Python

Using the Gherkin Languages to Write User Stories

User stories need to start with a background, or scenario or both if possible. For example a background could be

Many customers are complaining about the inability to login if they enter their username wrong.

SCENARIO: Create a Gherkin script that purposely enters an incorrect username to see why once the user name is entered wrong, then what is preventing a correct log in from happening.

GIVEN: The user is a member of the website and is on the website’s login page.

WHEN: After entering a wrong user name and then a correct password and selecting the login button,

AND: The user has received an error message indicating that the user name or password is incorrect.

THEN: The user attempts to log in again with the correct username and password

AND: User receives the error message.

Concepts of the Gherkin Scripts

Feature: summary name of the Gherkin user story.

Background: A series of steps that needs to be performed before the scenario. These steps can be applied across multiple scenarios, hopefully.

Scenario: Is the description of the test being run.

Scenario Outline: Shows multiple test examples for a common scenario.

3 core keywords: Given, When and Then

Scenario vs. Scenario Outline: Instead of entering a lot of repetitive data for testing, a scenario outline allows the user to enter the main data one time while listing the many variables below.

Git Hub

  • Version control is the naming of different versions or branches so it is easier to know which was the most current version as opposed to say the first version.
  • Git is a locally installed source control system, while GItHub is a cloud based platform that uses the Git tool.
  • A commit pulls changes from a branch or a different version into the master or a different
Git Real World Example - A vendor that produces software that runs school districts has multiple districts in different states. Each district in each state has different ways to calculate a student's grade point average. For instance in California, the Los Angeles Unified School District would calculate a student's GPA on different factors. Is the student going to attend a UC College or a CSU college, or maybe a Community College? Does the student need to obtain financial aid for college? All these scenarios would get a different GPA calculation. (was this legal, probably not) In Georgia, districts did not need to have this capability. State Reporting for California was different than Georgia, and different from Illinois. The software vendor branched their current version into a different branch for each state, depending upon the unique requirements of the district. As the main software program was updated for customers in other states, decisions had to be made as to if the enhancements or bug fixes that were completed in the main software would be updated to the different branches. Some districts did not want the new enhancements and some did not have the versions that the bug fixes were created for. The vendor had to keep multiple repositories for all of the updates and branches.
Automation in the Agile Process

If a team is working in sprints, it would be the best practice for the automation scripts to be written in each sprint where the development is taking place. Setup, navigation, and cleanup are scripts that can be written and do not need to have the exact code inserted until after the code is completed.

Test cases can be built incrementally in this process, and not necessarily for an entire new page.

-- AliciaHarrison - 20 Oct 2020
Topic revision: r6 - 30 Nov 2020, AliciaHarrison
© 2020 Ultranauts - 75 Broad Street, 2nd Floor, Suite 206, New York, NY 10004 - info@ultranauts.co