Speaker

Harsh Sahay from Cognizant – QA Engineer experienced across whole of Software testing lifecycle with 4 years of proven experience managing Adobe experience Manager within Digital Platform. He has extensive experience covering quality 360 degree right from functional, UI/UX, Compatibility, Visual Regression, Non Functional in Agile Pods. He also has strong knowledge in AWS and aspired to learn new Tools and implementing them successfully.

Day 1: Lightning talk Session on - Automated Visual Testing – Adobe Experience Manager Author and Front End – Let’s save time

Automated Visual Testing – Adobe Experience Manager Author and Front End – Let’s save time

Usually a manual QA team has been the only way to get insight into visual UI changes, but it’s time- consuming and error-prone. With Automated visual testing, teams can deliver updates on time,and keep up without sacrificing quality.The automation of visual testing is useful in Modern-day delivery, both for quality and velocity. As a consequence of which we need to make sure every possibility of automating a process should be attempted for.

Adobe Experience Manager

AEM (Adobe Experience Manager) is a content Management tool , provided by Adobe . AEM is beingused by many companies because of its interactive capabilities and features. So basically, if a normal personwithout much technical knowledge wants to manage a website content (Texts/videos/Images/Digital assets) inan interactive way, AEM could be a choice for them.

Visual Testing

Visual Testing AKA UI testing verifies software/application from a purely visual Standpoint. It tests everything end-users see and interact with. And the QA team needs to make sure it looks the same as the UI developer’s specification. Visual tests generate, analyse,  and compare browser snapshots to detect for any UI level changes. These changes from the original UI design specs are called visual diffs.

Need for Visual Testing in Front End pages of a UK Retailer eCommerce website

On any website, there are many dynamic pages and many static pages too. Static pages don’t change for a long time, but how about Dynamic pages which get updated/modified every day or every week. In this case,we need to do regression in the Front end for every release we do to make sure no page is breaking, or there are no UI changes.

Need for Visual Testing in AEM

AEM has a UI too, which is called Author UI. Those UI comes from AEMSPA bundles. Nowadays Sites are built using common SPA frame works such as React. And we can point to the react end point in AEM to get AEM author UI – to make the experience interactive and beautiful. So basically, if we make any changes to FE react code, it will Break AEMUI too. And this can cause blocker for authors/Customers who use AEM within that organisation. And on average every organisation does 10-15 Frontend releases every week,which basically means doing regression more than 15 times every week which takes both TIMEANDMONEY. What if we automate this? SO, every time a team goes for release to production, those Visual testing will be done Automatically through CI/CD pipeline and notifies us if it breaks? And luckily, we were able to IMPLEMENT THIS within Organisation

Implementation

In the current market, we have many third-party tools which can be used to proceed with visual regression testing. But the question here is-How can we implement them in a project to make It useful and productive. Knowing tools is very easy, but implementing them is difficult, but luckily, we were able to use a third-party tool – Percy  within the organisation because of its good features and integration features. Tests are integrated with CI/CD-Jenkins which makes it more independent. Also it’s Cross-browser testing feature , Page and component testing , Responsive testing. Automating FE and AEM visual Testing has not only saved efforts but has also saved money, as it required less manual intervention. Which ultimately means less Human interaction, which means company Saving in terms of money Because it is Said: TIME IS MONEY and we saved time.

Total Number of Screenshots per build
150
Time required to validate manually
300 mins
Time taken to validate using QE Team’s Automated solution
0
Total number of build Runs per month
60
i.e Total mins saved in a given month
37.5 PD saved

Hear what Harsh and Sakthikannan has to say about the Lightning talk session