![\"1](\"https:\/\/applitools.com\/wp-content\/uploads\/2019\/10\/1-x59cvjb_mojtouxmkbihsq.jpeg\")
<\/p>\nMyopia means nearsightedness. If you write functional tests, you likely suffer from functional test myopia. You focus on your expected outcome and your test coverage. But you miss the big picture.<\/p>\n
We all know the joke about one night with a guy on his knees under a streetlamp. As he\u2019s fumbling around, a passerby notices him.<\/p>\n
\u201cSir,\u201d says the passerby, \u201cWhat are you doing down there?\u201d<\/p>\n
\u201cI\u2019m looking for my wallet,\u201d replies the guy.<\/p>\n
\u201cWhere did you lose it?\u201d asks the passerby.<\/p>\n
\u201cDown there, I think,\u201d says the guy, pointing to a place down the darkened street.<\/p>\n
\u201cWhy are you looking here, then?\u201d wonders the passerby.<\/p>\n
\u201cAh,\u201d says the guy, \u201cI can see here.\u201d<\/p>\n
<\/p>\n
Source: http:\/\/first-the-trousers.com\/hello-world\/<\/a><\/p>\n This is the case for functional testing<\/a> of your web app. You test what you expect to see. But your functional tests can\u2019t see beyond their code to the daylight of the rendered browser.<\/p>\n Let me start by asking you – what goals do you set for your web app testing?<\/p>\n Have you ever wondered, if you\u2019re building a web app, why do you bother using a browser to test the app? If you\u2019re testing whether the app responds correctly to inputs and selectors, why not test using curl<\/a>\u00a0or a text-based browser like Browsh<\/a>?<\/p>\n I\u2019m being ironic. You know that the browser renders your app, and you want to make sure your app renders correctly.<\/p>\n But think about it: a text-based browser that converts web pages into something out of Minecraft will still pass a functional test — even if those pages are not rendered properly. That shows how limited traditional functional testing tools are.<\/p>\n I ask this question not to trip you up, but to help clarify your expectations.<\/p>\n In my experience, functional testers look for proper functionality for proper data input, handling data input exception cases, handling workflow exceptions, and handling server exceptions.<\/p>\n Whatever your goals, when you test your applications, you expect to see the application behave as expected when handling both normal and exception cases. You hope to cover as much of the app code as possible, and you want to validate that the app works as designed.<\/p>\n Functional testing myopia results from the code-based nature of functional testing. \u00a0To drive web app activity, most engineers use appropriate technology, such as Selenium WebDriver<\/a>. Selenium suits this need quite well. Other tools, like Cypress<\/a>, can drive the application.<\/p>\n Similarly, a code-based tool evaluates the application response in HTML. TestNG<\/a>, JUnit<\/a>, Cypress, or some other tool inspects the DOM<\/a>\u00a0for an exact or relative locator<\/a>\u00a0that matches the coder\u2019s intended response and validates that:<\/p>\n Potentially, a functional test might validate the entire DOM for the response page resulting from a given test action. Practically, only the expected response gets checked.<\/p>\n Just like the person on his or her knees under the streetlamp, functional testing validates the conditions the test can check. \u00a0And, herein lies myopia. Even if the code could validate the entire DOM response, the code cannot validate the rendered page. Functional testing tests pre-rendered code.<\/p>\n The difference between functional test and user experience explains functional test myopia. Our best web browser automation code only checks for a tiny portion of page attributes and does not match the full visual experience that a human user has.<\/p>\n Alone, functional tests miss things like:<\/p>\n Can you tell whether your application appears the way your customers expected or the way your designers intended? How do you validate app rendering?<\/p>\n Many app developers leaned on manual testing for validation purposes. One of my good friends has made a career as a manual QA tester. His job – run an app through its paces as a real user might, and validate the app behavior.<\/p>\n Manual testing can uncover visual bugs missed by functional test myopia. But manual testing suffers from three downsides:<\/p>\n Test engineers who consider automation for rendered applications seek the automation equivalent of manual testers.\u00a0They seek a tool that can inspect the visual output and make judgments on whether or not the rendered page matches expectations. They seek a visual testing<\/a> strategy that can help speed the testing process and validate visual behavior through visual test automation.<\/p>\n Conversely, test engineers don\u2019t want a bot that doesn\u2019t care if web pages are rendered Minecraft-style by Browsh.<\/p>\n Source: https:\/\/pxhere.com\/en\/photo\/536919<\/a><\/p>\n Given the number of visual development<\/em>\u00a0tools available, one might think that visual testing<\/em> tools match the development tools in scope and availability. Unfortunately, no. While one can develop a single app to run on mobile native and desktop browsers, from screen sizes ranging from five-inch LCD to 4K display, the two most commonly-used visual testing technologies remain pixel diffing and DOM diffing. And they both have issues.<\/p>\n DOM diff comparisons don\u2019t actually compare the visual output. DOM diffs:<\/p>\n Pixel diffing uses pixel comparisons to determine whether or not page content has changed. But pixel rendering can vary with the browser version, operating system, and graphics cards. Screen anti-aliasing settings and image rendering algorithms can result in pixel differences. While pixel diffs can identify valid visual differences they can also identify insignificant visual differences that a real user could not distinguish. As a result, pixel diffs suffer from false positives – reported differences that require you to investigate only to conclude they\u2019re not different. In other words, a waste of time.<\/p>\n Over the past decade, visual testing advanced from stand-alone tools to integrated visual testing tools. Some of these tools can be obtained through open source. Others are commercial tools that leverage new technologies.<\/p>\n The most promising approach uses computer vision technology – visual AI, the technology underlying Applitools Eyes – to distinguish visual changes between versions of a rendered page. Visual AI uses the same computer vision technology found in self-driving car development to replace pixel diffing.<\/p>\n Source: https:\/\/www.teslarati.com\/wp-content\/uploads\/2017\/07\/Traffic-light-computer-vision-lvl5.jpg<\/a><\/p>\n However, instead of comparing pixels, Visual AI perceives distinct visual elements — buttons, text fields, etc. — and can compare their presentation as a human might see them. As a result, Visual AI more closely \u201csees\u201d a web page with the same richness that a human user does. For this reason, Visual AI provides a much higher level of accuracy in test validation.<\/p>\n Here\u2019s an example of Visual AI in action:<\/p>\n As a Visual AI tool, Applitools Eyes has been used by a large number of companies to add visual test automation to their web app testing. As a result, these companies have not only expanded beyond functional test myopia, but they now have the ability to rapidly accept or reject visual changes in their applications with visual validation workflow.<\/p>\n Whether you code web apps or write test automation code, you want to find and fix issues as early as possible. Visual validation tools let you bring visual testing into your development process so that you can automate behavior and rendering testing earlier in your development process. \u00a0You can use visual validation to see what you\u2019re doing and what your customers will experience.<\/p>\n Don\u2019t get stuck in functional test myopia.<\/p>\n Get a free Applitools account<\/a>.<\/p>\nWhat Are Your Goals For Web App Testing?<\/h2>\n
![\"\"](\"https:\/\/applitools.com\/wp-content\/uploads\/2019\/10\/giphy.gif\")
<\/p>\nWhy Functional Test Automation can fail<\/h2>\n
\n
\n
![\"pasted](\"https:\/\/applitools.com\/wp-content\/uploads\/2019\/10\/pasted-image-0-11.png\")
<\/p>\nHow Do You Know Your App Renders Correctly?<\/h2>\n
\n
![\"pasted](\"https:\/\/applitools.com\/wp-content\/uploads\/2019\/10\/pasted-image-0-12.png\")
<\/p>\nLegacy Visual Testing Technologies<\/h2>\n
\n
AI and visual Testing<\/h2>\n
![\"pasted](\"https:\/\/applitools.com\/wp-content\/uploads\/2019\/10\/pasted-image-0-13.jpg\")
<\/p>\n![\"pasted](\"https:\/\/applitools.com\/wp-content\/uploads\/2019\/10\/pasted-image-0-9.png\")
<\/p>\nBroaden Your Vision<\/h2>\n
For More Information<\/h2>\n