This Adobe Experience Manager (AEM) tip isn’t really about AEM, but more about the process for our team in working on AEM projects. Also, unlike our other tips, this post uses a dialog format to present the subject of test automation. See what you think. 


Team lead (TL): We should automate our testing processes!

Manual QA (QA): What?!

Using a QA automation framework

TL: Well, didn’t you complain that we have a lot of routine regression that demoralizes you?

QA: Yes. You’re right. We frequently have regression issues which take a lot of time and team effort. We have to maintain compatibility with several browsers. We recently had to migrate to a new environment. It’s just impossible to cover all the pages all the time.

But… We are manual QAs! What about automation?

TL: It’s very easy. We have a QA automation framework in place. You don’t need any special knowledge to use it.

QA: Hmm… Really? What do we do?

Writing JSON files

TL: Test pages that are covered by manual test cases already exist. You should rework your cases into an understandable view for the QA automation tool—as a JavaScript Object Notation (JSON) file. There are a lot of JSON editors you can use: Visual Studio Code, IntelliJ IDEA, Notepad++, etc.

For example, we might need to check the typography (font family, font color, alignment) and visibility on a page of a specific element in a browser window with a particular size (765px width and 1024px height). Here’s how the JSON configuration would look:

QA: So… By varying the browser window size settings we can verify the behavior of elements on different screen sizes like desktop, tablet, or mobile. Right?

TL: Exactly! That’s the idea.

Selecting an element

QA: But how does the framework decide which element we should check?

TL: The framework searches for an element on the page using an XPath selector.

QA: What is an XPath selector?

TL: XPath can be used to navigate through elements and attributes in an HTML page.

Here is an easy way to get XPath selector for an element in a page:

  1. Right click on the element on the page
  2. Select Inspect
  3. Right click on the element in the page code
  4. Select Copy -> Copy XPath

Scope of the QA automation framework

QA: What can be checked by this automation framework?

TL:

  • Design (font size, font color, background color, etc.)
  • Responsive behavior
  • Element location on page (width, height, x, y)
  • Video (play, pause, full screen, etc.)
  • Cookie verification
  • Search
  • Different links
  • Analytics

Running tests

QA: Ok, we’ve rewritten a test case in the appropriate JSON format. How do I run the test?

TL: Upload the file to gitHub and run a job in Jenkins. (An automation job should have already been created in Jenkins.) Then, just click on the Build with Parameters button.

Select the needed environment, test suite, and browser. Finally, click the Build button.

Here is an example of configuring the build parameters:

Just wait a bit till you get an Allure report with all results in a clear visual format:

Passed cases have a green icon. Failed cases are marked by a red icon. For these failed cases you can expand results and see where the problem is. In addition, screenshots help to understand what was wrong.

What’s in the tech stack

QA: Hm… What is inside this magic tool? How does it work?

TL: Oh, there are a lot of “scary” terms:

Technologies such as:

  • Selenium WebDriver
  • TestNG
  • WebDriver Manager
  • Rest-Assured
  • Maven
  • Jenkins
  • Allure Reports

Pluses and minuses

QA: OK, I see! 🙂 So, the main pluses of a QA automation framework are:

  • Manual QAs can write tests on their own
  • No need for any special technical knowledge, even junior QAs can write autotests
  • Different environments and devices can be covered by automation tests
  • A great amount of work can be done in a short time by one person
  • Test execution can be run at any time, unlimited times

Sounds too cool! But, I can’t believe that such a framework doesn’t have minuses.

TL: Well, I have to admit this automation framework is applicable to the testing of web applications (sites) only. Also, it’s hard to support tests for dynamic content.

QA: That’s acceptable for us!

Let’s try it! We will save time and save wear and tear on our nerves.

How can we help you?
Contact Us