Skip to content

Commit a55f5b6

Browse files
mravi1126VenkataRaviMajjarirobinsonzimmermann
authored
Feature/visual testing (#75)
* Visual Testing using playwright blogpost * Visual Testing using playwright blogpost * Update 2023-11-03-visual-testing-using-playwright.md * Update 2023-11-03-visual-testing-using-playwright.md * Update 2023-11-03-visual-testing-using-playwright.md * Update _posts/2023-11-03-visual-testing-using-playwright.md Co-authored-by: Robinson Zimmermann <16561945+robinsonzimmermann@users.noreply.github.com> * Delete assets/images/post/visual-testing-banner.png * Add files via upload * Update 2023-11-03-visual-testing-using-playwright.md * Apply suggestions from code review Co-authored-by: Robinson Zimmermann <16561945+robinsonzimmermann@users.noreply.github.com> * Update 2023-11-03-visual-testing-using-playwright.md * Update 2023-11-03-visual-testing-using-playwright.md * Update 2023-11-03-visual-testing-using-playwright.md * Update 2023-11-03-visual-testing-using-playwright.md --------- Co-authored-by: venkatam <venkatam@backbase.com> Co-authored-by: Robinson Zimmermann <16561945+robinsonzimmermann@users.noreply.github.com>
1 parent 9542b88 commit a55f5b6

13 files changed

+212
-0
lines changed

_data/authors.yml

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -89,3 +89,8 @@ Utku:
8989
name : "Utku"
9090
avatar : "assets/images/avatars/utku.jpeg"
9191
bio : "Frontend Engineer - Customer Success"
92+
93+
Venkata Ravi Majjari:
94+
name : "Venkata Ravi Majjari"
95+
avatar : "assets/images/avatars/venkataravi_majjari.jpg"
96+
bio : "Senior QA Engineer - Customer Success"
Lines changed: 207 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,207 @@
1+
---
2+
3+
title: "Visual Testing using Playwright"
4+
excerpt: "Visual testing helps to find issues that are important for end-users that cannot be caught by other types of testing"
5+
tags: Testing, Quality Assurance
6+
authors:
7+
- Venkata Ravi Majjari
8+
header:
9+
teaser: /assets/images/post/visual-testing-banner.png
10+
teaser_alt: Quality Assistance Approach
11+
category: Software Quality Assurance
12+
13+
---
14+
15+
![](/assets/images/post/visual-testing-banner.png)
16+
17+
**Visual testing**” is a software testing technique that evaluates the visible output of an app and compares that output against the results expected by a known-good source, such as a design mockup created in Photoshop or Figma, or a screenshot from a previous version of the same app.
18+
19+
Visual testing also aims to verify that the app’s **visual elements** like **colors, images, fonts, and layouts,** are displayed correctly and consistently across different devices, operating systems, and browsers.
20+
21+
22+
## **Why is visual testing important?**
23+
24+
- Visual testing captures defects that other types of UI tests cannot
25+
- Visual testing is essential for ensuring a positive user experience with your app
26+
- Maintaining a visually perfect UI is important for retaining customers
27+
- Visual testing is important to reduce the revenue impact
28+
29+
**List of Visual Bugs:-** below are the list of visual defects that may occur
30+
- Pixel-by-pixel differences
31+
- Alignment shifts
32+
- Page layout
33+
- Rendering problems
34+
- Element overlap
35+
- Responsive layout
36+
- Font differences
37+
- Color differences
38+
39+
**Example 1:- Element Overlap Scenario**
40+
41+
{% include
42+
components/figure.html
43+
url="/assets/images/post/visual-testing1.png"
44+
%}
45+
46+
Look at this UI, how did this happen in production?
47+
The text and advertisement are crammed together. If this was your advertisement, do you think there would be a revenue impact? Absolutely.
48+
49+
These aren’t cosmetic issues. In each case, **visual bugs are blocking revenue**.
50+
51+
Why do these visual bugs occur? Don’t they do functional testing? They do, but it’s not enough.
52+
53+
Many believe that functional tests are enough to catch visual bugs, but that is not true. Functional tests validate only the functional behavior of the app.
54+
55+
Visual bugs are rendering issues. And rendering validation is not what functional testing tools are designed to catch.
56+
57+
**Example 2:- Different visual bugs on each case**
58+
59+
{% include
60+
components/figure.html
61+
url="/assets/images/post/visual-testing2.png"
62+
%}
63+
64+
In the preceding example each snapshot has rendered with different visual error.
65+
66+
## **How can Visual Testing help?**
67+
68+
69+
{% include
70+
components/figure.html
71+
url="/assets/images/post/visual-testing3.png"
72+
description="Visual aspects of the quality"
73+
%}
74+
75+
**Benefits of Visual Testing**
76+
77+
- Provide Confidence for visual aspects of the product that can’t be covered by lower level validations (Even by E2E)
78+
- Easy to cover cases like RTL changes or Theming if already have original tests
79+
- For some functional tests it is **faster to develop** Visual tests than functional
80+
- **Maintenance of the visual tests can be cheaper than functional tests** (All you need is just update baselines, you have no dependencies to test ids and html structure)
81+
<br>
82+
<br>
83+
84+
## **Why can’t functional tests cover visual issues?**
85+
86+
Functional test scripts can validate the size, position, and color scheme of visual elements. But if we follow this approach, then our test scripts will soon balloon in size due to checkpoint bloat.
87+
88+
Let’s look at an Instagram advertisement screen that’s properly rendered:
89+
90+
{% include
91+
components/figure.html
92+
url="/assets/images/post/visual-testing4.png"
93+
description="Advertisement screen that has properly rendered"
94+
%}
95+
96+
If we look at the advertisement, there are 21 visual elements, like various icons, text —this ignores iOS elements at the top like Wi-Fi signal and time, since those aren’t controlled by the Instagram app.
97+
98+
Consider that each element has to be validated with all these 5 checkpoints:
99+
100+
- Visible [true/false]
101+
- Upper-left x, y coordinates
102+
- Height
103+
- Width
104+
- Background color
105+
106+
That means we need the following number of assertions in the test script:
107+
108+
**21 visual elements x 5 assertions per element = 105 lines of assertion code**
109+
110+
Even with all this assertion code, you wouldn’t be able to detect all visual bugs. Such as whether a visual element can’t be accessed because it’s being covered up in the DOM as hidden mode.
111+
112+
For each combination of **OS/browser/font size/screen size/screen orientation**. You could end up with thousands of lines of assertion code to be added in the test script, which is not a best approach to be followed.
113+
114+
**Hence, we need visual testing to catch all the visual errors and we cannot rely on functional tests to catch visual errors.**
115+
116+
117+
## **What is Manual Visual Testing?**
118+
119+
Manual visual testing means comparing two screenshots manually, one from your known good baseline image, and another from the latest version of your app. For each pair of images, you have to invest a lot of time to ensure you’ve caught all issues. Especially if the page is long, or has a lot of visual elements, in that case it is very difficult to identify all the visual issues.
120+
121+
{% include
122+
components/figure.html
123+
url="/assets/images/post/visual-testing5.png"
124+
description="Manual Visual Identification of the elements"
125+
%}
126+
127+
**Challenges of manual Visual Testing:-**
128+
Imagine you need to test your app on:
129+
130+
- 5 operating systems: windows, MacOS, Android, iOS, and Chrome
131+
- 5 popular browsers: chrome, Firefox, Internet Explorer (Windows only), Microsoft Edge (Windows Only), and Safari (Mac only)
132+
- 2 screen orientations for mobile devices: portrait and landscape
133+
- 10 standard mobile device display resolutions and 18 standard desktop/laptop display resolutions from XGA to 4G
134+
135+
**1 Screen to test = 21 x (20+18) = 21 x 38 = 798 Unique Screen Configurations**
136+
137+
Let’s say if your app has 100 pages to test:
138+
139+
**798 Screen Configurations x 100 Screens in-app = 79,800 Screen Configurations to test**
140+
141+
Wouldn’t it be great if there was a way to automate this crazy-tedious process?
142+
143+
Well, yes there is… a process is in place to do the tedious process
144+
145+
146+
Here we are with the problem statement from Visual Testing:
147+
148+
**🚨The problem** - Visual bugs are blocking revenue and resulting in not retaining customers.
149+
150+
**🎯The goal** - Visual testing captures defects that other types of UI tests cannot [Functional, Manual & Regression].
151+
152+
**💡The solution** - **Automated Visual Testing is a solution** and **Playwright** is one of the good option used in Backbase [**Applitools** or **Percy** are the other automated tools are available for visual testing].
153+
<br>
154+
<br>
155+
156+
## **Automated Visual Testing using Playwright**
157+
158+
To address the preceding challenges, automated visual testing needs to be implemented in place of ‘function testing’/’manual visual testing’ to **achieve efficient and reliable results in visual testing**.
159+
160+
- **Playwright** is an open-source test automation framework that enables end-to-end testing for modern web-apps
161+
- It uses languages - JavaScript, TypeScript, Python, Java, and C#
162+
- It also supports Chromium, Firefox, and WebKit-based browsers and can also run tests against an emulated mobile browser
163+
- OS support - Windows, Linux, and macOS
164+
165+
166+
**Snapshot Comparison Workflow:**
167+
168+
{% include
169+
components/figure.html
170+
url="/assets/images/post/visual-testing6.png"
171+
%}
172+
173+
**Simple Visual Snapshot Comparison Tests in Playwright:**
174+
175+
{% include
176+
components/figure.html
177+
url="/assets/images/post/visual-testing7.png"
178+
%}
179+
180+
When the **toHaveScreenshot()** function executes, it performs the following:
181+
182+
183+
- It verifies if there is an existing screenshot file. If not present, it fails
184+
- It takes a new screenshot
185+
- It computes the difference between the two screenshots using the pixel match library
186+
- If there is any difference, take another screenshot
187+
- It computes the difference again
188+
- It writes an expected, actual, and diff file to the test-results folder
189+
190+
{% include
191+
components/figure.html
192+
url="/assets/images/post/visual-testing8.png"
193+
%}
194+
195+
196+
{% include
197+
components/figure.html
198+
url="/assets/images/post/visual-testing9.png"
199+
%}
200+
201+
## **Key benefits/take-aways from Visual Testing Approach**
202+
203+
- **Enhanced User Experience (UX):** Visual testing is crucial for a seamless and visually pleasing user experience, positively impacting satisfaction, reducing bounce rates, and reinforcing brand image.
204+
- **Efficiency Through Automation:** Automated visual testing accelerates the detection and resolution of visual discrepancies, enhancing efficiency and accuracy in software development.
205+
- **Cross-Platform Compatibility Assurance:** Visual testing ensures consistency across browsers and devices, expanding user reach and maintaining a uniform brand image.
206+
- **Cost-Effective and Time-Efficient:** Automation in visual testing leads to significant time and cost savings compared to manual methods, allowing teams to focus on complex development tasks.
207+
- **Integration with CI/CD:** Visual testing seamlessly integrates into CI/CD pipelines, supporting rapid, high-quality software delivery by validating visual aspects with each code change.
537 KB
Loading
118 KB
Loading
206 KB
Loading
803 KB
Loading
457 KB
Loading
195 KB
Loading
787 KB
Loading
146 KB
Loading

0 commit comments

Comments
 (0)