Learn about common localization bugs, the traditional challenges involved in finding them, and solutions that can make localization testing far easier.

What is Localization?

Localization is the process of customizing a software application that was originally designed for a domestic market so that it can be released in a specific foreign market.

How to Get Started with Localization

Localization testing usually involves substantial changes of the application’s UI, including the translation of all texts to the target language, replacement of icons and images, and many other culture, language, and country-specific adjustments, that affect the presentation of data (e.g., date and time formats, alphabetical sorting order, etc.). Due to the lack of in-house language expertise, localization usually involves in-house personnel as well as outside contractors, and localization service providers.

Before a software application is localized for the first time, it must undergo a process of Internationalization.

What is Internationalization?

Internationalization often involves an extensive development and re-engineering effort which goal is to allow the application to operate in localized environments and to correctly process and display localized data. In addition, locale-specific resources such as texts, images and documentation files, are isolated from the application code and placed in external resource files, so they can be easily replaced without requiring further development efforts.

Once an application is internationalized, the engineering effort required to localize it to a new language or culture is drastically reduced. However, the same is not true for UI localization testing.

The Challenge of UI Localization Testing

Every time an application is localized to a new language, the application changes, or the resources of a supported localization change, the localized UI must be thoroughly tested for localization and internationalization (LI) bugs.

Common Localization and Internationalization Bugs Most Testers can Catch

LI bugs which can be detected by testers that are not language experts include:

• Broken functionality – the execution environment, data or translated resources of a new locale, may uncover internationalization bugs can prevent the application from running or break some of its functionality.
• Untranslated text – text appearing in text fields or images of the localized UI is left untranslated. This indicates that certain resources were not translated or that the original text is hard-coded in the UI and not exported to the resource files.
• Text overlap / overflow – the translated text may require more space than available in its containing control, resulting with the text overflowing the bounds of the control and possibly overlapping or hiding other UI elements.
• Layout corruption – UI controls dynamically adjust their size and position to the expanded or contracted size of the localized text, icons or images, resulting with misaligned, overlapping, missing or redundant UI artifacts.
• Oversized windows and dialogs – multiple expanded texts and images can result with oversized tooltips, dialogs and windows. In extreme situations, expanded dialogs and windows may only be partially visible in low screen resolutions.
• Inadequate fonts – a control’s font cannot properly display some characters of the target language. This usually results with question marks or glyphs being displayed instead of the expected text.

Localization and Internationalization Bugs Requiring Language Expertise

Other common LI bugs which can only be detected with the help of a language expert include:

• Mistranslation – translated text that appears once in the resource files, may appear multiple times in different parts of the application. The context in which the text appears can vary its meaning and require a different translation.
• Wrong images and icons – images and icons were replaced with wrong or inappropriate graphics.
• Text truncation – the translated text may require more space than available in its containing control, resulting with a truncated string.
• Locale violations – wrong date, time, number and currency formats, punctuation, alphabetical sort order, etc.

Localization and Internationalization Bugs are Hard to Find

An unfortunate characteristic of LI bugs, is that they require a lot of effort to find. To uncover such bugs, a tester (assisted by a language expert) must carefully inspect each and every window, dialog, tooltip, menu item, and any other UI state of the application. Since most of these bugs are sensitive to the size and layout of the application, tests must be repeated on a variety of execution environments (e.g., different operating systems, web browsers, devices, etc.) and screen resolutions. Furthermore, if the application window is resizable, tests should also be repeated for various window sizes.

Why is UI Localization Testing Hard?

There are several other factors that contribute to the complexity of UI Localization testing:

• Lack of automation – most of the common LI bugs listed above are visual and cannot be effectively detected by traditional functional test automation tools. Manual inspection of the localized UI is slower than with a non-localized UI because it is  unreadable to the tester.
• Lack of in-house language expertise – since many of the common LI bugs can only be detected with the help of external language experts, which are usually not testers and are not familiar with the application under test, LI testing often requires an in-house tester to perform tests together with a language expert. In many cases, these experts work on multiple projects for multiple customers in parallel, and their occasional lack of availability can substantially delay test cycles and product releases. Similarly, delays can occur while waiting for the translation of changed resources, or while waiting for translation bugs to be fixed.
• Time constraints – localization projects usually begin at late stages of the development lifecycle, after the application UI has stabilized. In many cases, testers are left with little time to properly perform localization tests, and are under constant pressure to avoid delaying the product release.
• Bug severity – UI localization bugs such as missing or garbled text are often considered critical, and therefore must be fixed and verified before the product is released.

Due to these factors, maintaining multiple localized application versions and adding new ones, incurs a huge overhead on quality assurance teams.

Fortunately, there is a modern solution that can make localization testing significantly easier – Automated Visual Testing.

How to Automate Localization Testing with Visual Testing

Visual test automation tools can be applied to UI localization testing to eliminate unnecessary manual involvement of testers and language experts, and drastically shorten test cycles.

To understand this, let’s first understand what visual testing is, and then how to apply visual testing to localization testing.

What is Visual Testing?

Visual testing is the process of validating the visual aspects of an application’s User Interface (UI).

In addition to validating that the UI displays the correct content or data, visual testing focuses on validating the layout and appearance of each visual element of the UI and of the UI as a whole. Layout correctness means that each visual element of the UI is properly positioned on the screen, is of the right shape and size, and doesn’t overlap or hide other visual elements. Appearance correctness means that the visual elements are of the correct font, color, or image.

Visual Test Automation tools can automate most of the activities involved in visual testing. They can easily detect many common UI localization bugs such as text overlap or overflow, layout corruptions, oversized windows and dialogs, etc. All a tester needs to do is to drive the Application Under Test (AUT) through its various UI states and submit UI screenshots to the tool for visual validation.

For simple websites, this can be as easy as directing a web browser to a set of URLs. For more complex applications, some buttons or links should be clicked, or some forms should be filled in order to reach certain screens. Driving the AUT through its different UI states can be easily automated using a variety of open-source and commercial tools (e.g., Selenium, Cypress, etc.). If the tool is properly configured to rely on internal UI object identifiers, the same automation script/program can be used to drive the AUT in all of its localized versions.

So, how can we use this to simplify UI localization testing?

How Automated Visual Testing Simplifies UI Localization Testing

• Preparation – in order to provide translators with the context required to properly localize the application, screenshots of the application’s UI are often delivered along with the resource files to be localized. The process of manually collecting these screenshots is laborious, time consuming, and error prone. When a visual test automation tool is in place, updated screenshots of all UI states are always available and can be shared with translators with a click of a button. When an application changes, the tool can highlight only those screens (in the source language) that differ from the previous version so that only those screens are provided to translators. Some visual test automation tools also provide animated “playbacks” of tests showing the different screens, and the human activities leading from one screen to the next (e.g., clicks, mouse movements, keyboard strokes, etc.).  Such animated playbacks provide much more context than standalone screenshots and are more easily understood by translators, which are usually not familiar with the application being localized. Employing a visual test automation tool can substantially shorten the localization project’s preparation phase and assist in producing higher quality preliminary translations, which in turn can lead to fewer and shorter test cycles.

• Testing localization changes – visual test automation tools work by comparing screenshots of an application against a set of previously approved “expected” screenshots called the baseline. After receiving the translated resources and integrating them with the application, a visual test of the updated localized application can be automatically executed using the previous localized version as a baseline. The tool will then report all screens that contain visual changes and will also highlight the exact changes in each of the changed screens. This report can then be inspected by testers and external language experts without having to manually interact with the localized application. By only focusing on the screens that changed, a huge amount of time and effort can be saved. As we showed above, most UI localization bugs are visual by nature and are therefore sensitive to the execution environment (browser, operating system, device, screen resolution, etc.). Since visual test automation tools automatically execute tests in all required execution environments, testing cycles can be drastically shortened.

• Testing new localizations – when localizing an application for a new language, no localized baseline is available to compare with. However, visual test automation tools can be configured to perform comparisons at the layout level, meaning that only layout inconsistencies (e.g., missing or overflowing text, UI elements appearing out of place, broken paragraphs or columns, etc.) are flagged as differences. By using layout comparison, a newly localized application can be automatically compared with its domestic version, to obtain a report indicating all layout inconsistencies, in all execution environments and screen resolutions.

• Incremental validation – when localization defects are addressed by translators and developers, the updated application must be tested again to make sure that all reported defects were fixed and that no new defects were introduced. By using the latest localized version as the baseline with which to compare the newly updated application, testers can easily identify the actual changes between the two versions, and quickly verify their validity, instead of manually testing the entire application.

• Regression testing – whenever changes are introduced to a localized application, regression testing must be performed to make sure that no localization bugs were introduced, even if no direct changes were made to the application’s localizable resources. For example, a UI control can be modified or replaced, the contents of a window may be repositioned, or some internal logic that affects the application’s output may change. It is practically impossible to manually perform these tests, especially with today’s Agile and continuous delivery practices, which dictate extremely short release cycles. Visual test automation tools can continuously verify that no unexpected UI changes occur in any of the localized versions of the application, after each and every change to the application.

• Collateral material – in additional to localizing the application itself, localized versions of its user manual, documentation and other marketing and sales collateral must be created. For this purpose, updated screenshots of the application must be obtained. As described above, a visual test automation tool can provide up-to-date screenshots of any part of the application in any execution environment. The immediate availability of these screenshots significantly reduces the chance of including out-of-date application images in collaterals and eliminates the manual effort involved in obtaining them after each application change.

Application localization is notoriously difficult and complex. Manually testing for UI localization bugs, during and between localization projects, is extremely time consuming, error-prone, and requires the involvement of external language experts.

Visual test automation tools are a modern breed of test automation tools that can effectively eliminate unnecessary manual involvement, drastically shorten the duration of localization projects, and increase the quality of localized applications.

Applitools Automated Visual Testing and Localization Testing

Applitools has pioneered the use of Visual AI to deliver the best visual testing in the industry. You can learn more about how Applitools can help you with localization testing, or to get started with Applitools today, request a demo or sign up for a free Applitools account.

Editor’s Note: Parts of this post were originally published in two parts in 2017/2018, and have since been updated for accuracy and completeness.

The post Getting Started with Localization Testing appeared first on Automated Visual Testing | Applitools.

Update: We have recently released a new, native Slack integration. For additional details please visit our step by step guide for Applitools & Slack integration.

One of the great things about Slack is the long list of integrations available. Whether it’s an integration as foundational as Google Drive, GitHub, or Zendesk — or as whimsical as Lunch Train — there are Slack integrations for a wide range of use cases.

Here’s an example of Slack’s GitHub integration:

With that backdrop, we’d like to show you how to integrate your Applitools Eyes visual UI test results into one of your Slack channels — something that our customers have frequently requested.

This step-by-step tutorial uses the Slack incoming webhooks API.

First, some background:

Slack provides APIs to users to create applications and to automate processes, such as sending automatic notifications based on human input, sending alerts on specified conditions, and more. The Slack API has been noted for its compatibility with many types of applications, frameworks, and services.

Once you build this tutorial, you’ll be able to view test results on any Slack client: your laptop, your phone. Or even via notifications on your Apple Watch, if you’re stuck in a meeting and don’t want to open your phone. You’ll be the first to know if your app has a visual glitch that you’ll need to fix.

With that, let’s dive into what you need to do  to bring Applitools into your Slack channel:

Step 1: Set up your Slack endpoint

1. Per Slack recommendations, create a “sandbox” account for Slack for your experiments before integrating it with your team Slack account: https://slack.com/create
2. Follow these instructions to see how you post your first “Hello world” message to your new Slack channel: https://api.slack.com/tutorials/slack-apps-hello-world
3. Copy and keep your webhook URL (always better to add this webhook URL to your environment variables, but I’ll leave it to you).

Step 2: Getting Applitools Eyes Test Results

1. Switch to whatever IDE you use to write automated test scripts that call the Applitools API, and open one of those scripts.
2. Towards the end of your test scripts, you should have a call to eyes.Close(). Here’s its documentation for our Java, JavaScript, C#, and Python SDKs. For scripts written in Java, it will look something like this:

   TestResults res = eyes.close(false);

3. This call returns a TestResults object. Additional information about Applitools TestResults can be found here.

Step 3: Connecting The Dots

The example below is in Java; however, you can figure out how to achieve this in any language you are using (with minor differences) as the TestResults object is accessible also in JavaScript, Python, Ruby, C#, and PHP. I’ve followed the instructions in this article to create the code below but feel free to customize it to your specific team needs.

1. Create class EyesSlack and add the following code in it:

View the code on Gist.

2. Now let’s see how we use this class in our tests:

View the code on Gist.

3. All you need to do now is run it to see your Applitools Eyes Test Results right in your Slack channel.

Here is an example of the screen message in Slack:

If you want to see my own experience putting together this blog post, check out this video:

Now that you tested it in your sandbox you are ready to merge into your team slack account – simply replace the webhook URL and you are good to go.

Looking for additional integrations with Applitools? Here are my favorites:

• JIRA and Applitools Integration
• Jenkins and Applitools Integration
• Azure DevOps and Applitools Integration
• GitHub and Applitools Integration
• TeamCity and Applitools Integration

The post Integrate test results into Slack [step-by-step tutorial] appeared first on Automated Visual Testing | Applitools.

Watch this in-depth session by Gil Tayar about how Test Engineers and QA pros can successfully collaborate with developers.

This webinar includes an extensive overview on test methodologies and types – especially for frontend testing – tips, tricks, and best practices on how to effectively test developer code, and how to decipher developer lingo.

The full webinar recording and Gil’s slide-deck are below.

“I will give a recipe that you can follow to ease your fear of the unknown: writing tests for developer code. At the end of this session, I guarantee that you will gain a deeper understanding of different kinds of tests, know how to decipher developer terminology, and learn how to write unit, integration, browser, and E2E tests.” — Gil Tayar. Sr. Architect & Evangelist

Testing is shifting left, moving closer to testing the code itself. But while managers dictate a shift to the left, developers and testers are confused as to how exactly to test the code.

And while the backend world has established code-testing methodologies, we are still trying to figure out how to test frontend code, while ensuring effective testing procedures and processes.

This means testers need to step in and work with the frontend developers, but with an understanding of the frameworks by which frontend code is tested, the various kinds of testing that can be performed on frontend code, and which tools can be used for this.

In this hands-on session, Gil Tayar will demystify the frontend testing process, and guide us on how to work effectively with developers. He discusses various test methodologies, and how they fit together in a coherent way. Gil also includes sample code that you can use as a template in your own project — all in order to provide you with the knowledge and tools to approach and test developer code.

Topics include:

• Get familiar with different types of tests
• Understand developer terminology around frontend testing
• Learn how to write unit tests, integration tests, and browser and E2E tests
• Get acquainted with the tools of the trade – for testers and for developers

Gil’s full slide deck:

Full webinar recording:

Additional reading and recommended links:

• Github repo for this presentation: https://github.com/giltayar/collaborating-with-developers 
• Test Automation University – a leading educational initiative, lead by Angie Jones, offering free test automation courses by industry leaders
• Confident React: Kent C. Dodds Talks about Frontend Testing– webinar with expert Kent C. Dodds
• How Testers Can Speak the Language of Front-end Developers — post by Gil Tayar
• Building an Effective Front-end Testing Discipline – webinar with Expert Kevin Lamping
• Visual UI Testing at the Speed of Unit Testing, with new SDKs for Cypress and Storybook – webinar by Gil Tayar
• Selenium IDE: The Next Generation – webinar by Simon Stewart
• How to Visually Test React Components Using Our Storybook SDK – post by Gil Tayar
• Start visually testing your app today – with a free Applitools account. Click here to open it!

— HAPPY TESTING —

The post Collaborating with Developers: How-to Guide for QA Pros & Test Engineers appeared first on Automated Visual Testing | Applitools.

No frontend project can survive without an effective testing strategy. Why?

Because frontend projects can be as complex as backend projects — but users still expect a flawless experience. And if those users complain to your management… it’s just bad.

So, more and more frontend developers are realizing that they need to bake automated testing into their development process.

But questions remain:

• What testing should you do beyond unit testing?
• How can you find the time to both code and build/run/maintain automated tests?
• How do you maintain tests when requirements and features are constantly changing — and you’re pushing new code into production daily?
• How do you convince your boss that testing isn’t a waste of time?

We want to help you out of this.

Please join us at State of Frontend Testing, a free online event where frontend testing experts share how to quickly build high-quality web and mobile apps in 2019. We’ll cover the testing strategies, tools and frameworks you should be using in 2019.

Who’s presenting?

• Kent C. Dodds, JavaScript engineer at PayPal and creator of TestingJavaScript.com
• Gleb Bahmutov, JavaScript expert and software quality fanatic. VP of Engineering at Cypress.
• Shai Reznik, Founder of HiRez.io – Entertaining Angular + Testing Courses and TestAngular.com.
• James Evans, Software QA developer and Microsoft MVP.
•  Kevin Lamping, Front-end Engineer & Tester. Webdriver Fan.
• Rotem Mizrachi-Meidan, Mobile Infrastructure Engineer at Wix.
• Gil Tayar, Senior Architect at Applitools and creator of Applitools Ultrafast Grid
• Tracy Lee, co-founder, ThisDot Labs

Not a bad group, right?

State of Frontend Testing will stream live on Tuesday, December 18th at 10 am PST / 1 pm EST / 6 pm UK. This is a free, online event open to all developers.

Register here to see the event details and join the livestream.

We hope to see you on the 18th!

What will you do upgrade your frontend testing in 2019?

The post How to upgrade your Frontend Testing in 2019 appeared first on Automated Visual Testing | Applitools.

Listen to Gil Tayar’s webinar on the new Applitools SDKs for Cypress and Storybook, which enable developers to test the visual appearance of their apps across all responsive web platforms, including React, Vue, and Angular.  

Developers want their tests to run fast. In an increasingly agile world, waiting ten minutes or more for test results is a huge no-no. A new generation of browser automation tools recognize that need-for-speed and enable frontend developers to quickly automate their browser tests.

But those tests also need to check the application’s visual elements. Does the login page look okay? Does it look good in Firefox? What about mobile browsers, in 768px width? And does it still look good in 455px with a device pixel ratio of 2? These are just a few of the questions developers ask when building responsive web applications.

To check the visual quality of your application, across all browsers and in all those responsive widths, would necessitate a humongous grid of browsers, and an unreasonable amount of time. Far more than the two to five minutes usually available for a developer’s tests.

Applitools’ new SDKs for Cypress and Storybook enable you to do just that: write a set of visual regression tests that run through your pages and components, and have the pages and components render in Applitools Ultrafast Grid, in parallel, on a large set of browsers and widths, and return the result in less than a minute.

One minute. That’s quicker than most functional test suites, and approaching the time required for unit testing.

Listen to Applitools Architect Gil Tayar, as he discusses the new generation of visual UI testing tools. Tools that move the burden of the visual work to cloud, and enable you to check what was till now impossible to check locally: the visual appearance of your application across multiple responsive platforms.

Source code, slides, and video

You can find companion code for Gil’s talk on this GitHub repo.

We also have detailed, step-by-step tutorials on how to use Applitools with Cypress, Storybook + React, Storybook + Vue, and Storybook + Angular.

Here’s Gil’s slide deck:

And here’s the full webinar recording:

Check out these resources, and if you have any questions, please contact us or set up a demo.

How are you going to start visually testing with Cypress or Storybook?

The post Visual UI Testing at the Speed of Unit Testing, with new SDKs for Cypress and Storybook appeared first on Automated Visual Testing | Applitools.

A few weeks back, Applitools made the trip just up the road from our headquarters to take part in DevOps World | Jenkins World San Francisco. The event is an international event that provides opportunities to learn, explore, network and help shape the future of DevOps and CI with Jenkins. It’s always an exciting and energizing event and this year proved no different as we were able to network and engage with leading minds in the world of software development.

While we were there, James Lamberti, our Chief Marketing Officer, had the honor of sitting down with Jayne Groll, CEO of the DevOps Institute, to talk shop and explore some of the ways Applitools has changed how organizations are able to use visual testing to deliver better UI/UX for their customers. Here are some of the highlights of that conversation. 

Understanding Applitools and How It Fits into Digital Transformations

Jayne’s first question led James to discuss the basics of what the Applitools Visual AI tool is – and how it aligned perfectly with the theme of the event.

“Applitools exists to make sure the user interface is visually perfect on every device, operating system, and screen, whether mobile and desktop,” said Lamberti. “The theme [of DevOps World] this year is transform. And essentially, the issue or the problem that we solve for pretty much everyone in this room is digital transformation.”

While “digital transformation” at times is viewed as an industry buzzword, it is inarguable that businesses of all sizes and verticals are using digital as a means of fundamentally transforming their businesses, in part by building applications to streamline customer interactions. So when it comes to the user interface a customer-facing app, there is truly no brand spared from the impact of what a broken UI can do.

Bad UI Can Keep Your Business Grounded

A real-world example James highlighted how a broken UI can fundamentally affect your business, and its bottom line, was his recent experience trying to book a flight via his mobile device. When it was time to finalize the transaction, the checkout button was unclickable – ending the purchase journey right then and there. As James pointed out, this sort of break in the user experience will cause your customer to switch on a dime to another company – and this is exactly the type of issue that can be prevented by partnering with Applitools.

Exciting Developments on the Horizon 

Finally, Jayne and James touched on some of the exciting news coming out of Applitools – namely our newest product, the world’s first UI version control system.

“Essentially, we have integrated with GitHub and, for the first time ever, you can actually tie your code commits into GitHub directly to changs to the UI. This means that, for the first time, you can correlate code changes to UI changes, and tracking the history of how your UI evolves over time,” said James. “And so now, if there’s a UI issue, you can tie it back to what code commit caused that issue.”

For instance, if you see that an application stopped meeting its business goals a month ago — say, transactions declined, or user engagement slipped — you can look at the visual changes that were made to your app’s UI around that time, in order to discern if the application might be to blame. Furthermore, you know what changes to undo in your code to get your UI back to its previous state.

It sounds simple concept — and it is. What’s shocking, to us anyway, is that no one has built this fundamental capability for DevOps teams. It’s a crucial piece of application management – and one we are excited to bring to our customers. We think having the ability to have the visual UI tied to its code is transformative for how we approach some of the challenges around digital transformation.

Watch the full interview discussion with Jayne Groll at Jenkins World:

If you weren’t able to connect with us at DevOps World | Jenkins World, reach out or sign up for a free Applitools account.

=====

FULL TRANSCRIPT:

Jayne: Hi everyone. I’m Jayne Groll, CEO of the DevOps Institute here at DevOps World | Jenkins World in San Francisco. And I’m really excited to be joined by James Lamberti of the Applitools. Welcome.

James: Thank you. Great for you to have us. I appreciate you doing what you’re doing here. It’s exciting.

Jayne: It’s really exciting, right? I don’t know if anybody can hear the buzz in the background but the energy is really palpable.

James: It definitely is.

Jayne: Yeah, interesting. So James, tell us a little bit about Applitools and kind of what you’re expecting out of DevOps World during the next couple of days.

James: Yeah, sure. So Applitools, for those who aren’t familiar, we essentially exist to make sure the UI is visually perfect on every device, operating system, screen, mobile, desktop and so that’s what we do. And so, we actually are pretty unique entity here at Jenkins World this year. And, you know, what do we want out of it? I mean, the theme this year is transformed, as you know. And essentially, the issue or the problem that we solve for pretty much everyone in this room is digital transformation. So, we tie in really nicely in, you know, what digital transformation, I know it’s an industry buzzword, but really what that means, in a practical sense, is, you know, the UI for most brands in the world typically exists now in 500 to 1000 variations at this very moment in time. I mean, you think about your…or just our everyday lives constantly coming across broken UI and there is no brand spared. The largest brands in the world routinely have broken UI and it’s…you know, that’s really what we’re here to transform as we can get beyond this now. We built technology at Applitools that essentially solves for that problem and ensures a visually perfect world, as the t-shirt says.

Jayne: But you know the UI is really the user experience, right?

James: Yeah.

Jayne: So, you know, the influence of the interface and how the user perceives that often shapes the perception of the product, right? So, what’s your experience? What are users really looking for in terms of their UI experience?

James: Oh, I mean, I think, fundamentally, they want it to work. I mean, honestly, like you get…we’re to a point where this transformation and the number of iterations of the UI is so overwhelming, R&D and Dev teams simply can’t get up. I know in some sense of they’ve given up and honestly, customers see that. Now, the problem with that approach is that a customer can switch on a dime. I mean, I won’t name brands right now, but I was just trying to book an airline ticket and I literally had a responsive design issue on my mobile device. I could not check out. The button…that it passed the functional tests, right, from a test automation discussion. I was clicking the button to try to buy the ticket and it literally was not working, and I needed to get it done. I just switched to another airline. So, implications are pretty clear. You can have a UI issue or a bug that just looks bad for the brand, like doesn’t cast a great impression but more importantly, you can literally break the customer experience to the point where they just switch on the dime.

So, you know, we’re in a world and a situation where we can’t just give up any more and there’s no need to give up. Like you can actually solve for this problem through visual AI, which is what we do. We’ve actually created a technology that in real time, at scale, inspects the UI, spots the difference between what should be and what is, alerts the R&D team either pre-production [inaudible 00:03:42] monitoring and allows them to fix it. And so, it’s been a huge step forward for the industry and really completes that test automation chain, if you will, right? Because the UI…the reason the UI is such a problem is it exists outside a lot of the automation frameworks we’ve built up, right? And so, we no longer have to suffer this way.

Jayne: And I think that’s awesome. And I think the example that you gave really shows that it also can affect the bottom line.

James: Oh, absolutely.

Jayne: And so, it’s not just pretty, right? It’s not superfluous. It actually does have a strong influence on…

James: Huge influence.

Jayne: …brand recognition and everything that’s associated with that, which is fantastic. So, we’re here at DevOps World, so do you guys have any announcements that you want to, kind of, sneak peek us with?

James: Yeah. I know, so I think, probably the most exciting thing, and we just announced it a couple days ago, is the world’s first UI version control system. And so, let me explain what that means. Essentially, we have integrated with GitHub and we are…for the first time ever, you can actually tie your merge, right, your branch, your fork, your merge into your GitHub Repo to the UI directly, so you’re seamlessly linking the UI to that particular code merge, and tracking that history, you know, forever. And so now, you’re in a situation where if there’s a UI issue, you can tie it back to what merge caused that issue.

Jayne: Oh, that’s awesome.

James: And you have a history of, “Okay, we made these changes, who made these changes? Why do we make these changes? What exactly did the UI look like before these changes and what branch or fork was, you know, the one we need to fall back to?” And so, that’s just, I mean, it’s actually a really extraordinary…in simple concept. But for us to have the visual tied to that code build is transformative for how we deal with this problem I was just describing around digital transformation. So, that’s a big announcement and it’s really, really exciting.

Jayne: That’s extremely exciting and again, sometimes we don’t think of the UI as part of the Repo and being able to tie that together and trackback makes a lot of sense.

James: Exactly.

Jayne: So, thank you for spending some time.

James: You’re welcome.

Jayne: Really looking forward to the rest of the conference.

James: Yeah, absolutely.

Jayne: We’ve just kicked off a little while ago and really wish you a lot of luck with your great announcement. Thanks.

James: Thank you very much. Thank you, DevOps.com.

The post How to improve Customer Experience with Visual AI and Applitools appeared first on Automated Visual Testing | Applitools.

Test Automation thought leaders gathered for a round-table discussion about the upcoming trends, best practices, tools, and ideas that will shape your Dev/Test environment in 2019.

Joe Colantonio hosted this all-star expert panel, including: Angie Jones, Dave Haeffner, and Gil Tayar – as they shared their thoughts and insights on the hottest topics in test automation and software quality, including:

• Shift left: how to get developers involved and invested in the testing process
• Selenium IDE: ghosts of the past, present, and future
• Avoiding common pitfalls: how to be successful with test automation
• Never bet against it: JavaScript’s role in test automation
• New automation frameworks Cypress and Puppeteer: the good, the bad and the ugly
• Keep calm and record-and-playback

Listen to the recording:

Slide Deck:

— HAPPY TESTING — 

The post Test Automation in 2019: Glimpse of the Near Future From the Experts Who Shape It appeared first on Automated Visual Testing | Applitools.

For years, front-end developers have dealt with the pain of browser-based bugs and the difficulty of testing hundreds of scenarios. They’re itching for help with front-end testing, but have struggled to find a solution that scales past a few simple tests. They have the skills to write test automation, just not the support.

Now, more than ever, is the time to team up front-end developers with QA teams. So much functionality has shifted to the front-end that past practices will no longer work. We need to focus on solid solutions that have been proven in the workforce.

In this session — hosted by Kevin Lamping, Front-end Engineer and Consultant — you’ll learn how you can build a Front-end Testing Discipline using cutting-edge tools and techniques, along with patterns to follow in organizations at various levels.

Here are some of the talking points Kevin covers in this session:

• Gain an understanding of front-end developer’s pains and needs
• Get acquainted with the best tools available, and how to get your front-end team to use them
• Learn how to pair front-end developers with QA testers in order to greatly improve test workflow
• Learn how to provide results that team members can look at and feel confident about
• Bonus: little-known tips testers should use in order to better work and communicate with front-end developers

Kevins’ slide deck:

Watch the full recording here:

Advanced Materials: 

Online Tutorials: Check out Kevin’s website and tutorials here. Reminder: get 20% off on Kevin’s tutorials and online classes by applying the code applitools2018.

Recommended Reading: How Testers Can Speak the Language of Front-end Developers — post by Gil Tayar

— HAPPY TESTING — 

The post Building an Effective Front-end Testing Discipline: on-demand webinar w/ Expert Kevin Lamping appeared first on Automated Visual Testing | Applitools.

Why is Jira so hard to use for bug tracking? This seems to be a continual refrain heard on the web: “Jira isn’t suited for Agile development”. “Jira is complex and bloated”. “People cram too much information into Jira”. Another common complaint is that Jira tickets are simply unmanageable.

Organizing JIRA tickets pic.twitter.com/2YeDNc7tcf

— Mike Herchel (@mikeherchel) October 2, 2017

But, love it or hate it, Atlassian Jira is very popular for bug tracking and can be found within many software development organizations worldwide. If your workplace is one of the many that uses Jira, you might want to consider using Applitools Eyes to make your visual user interface (UI) testing easier.

First, some background: Applitools Eyes lets you automate visual UI testing of your web and mobile application front end. Using Applitools Eyes ensures that your application’s UI is displayed consistently and accurately across any device, browser, or viewport. Atlassian Jira manages your development workflow, task tracking, issue management, and reporting.

Integrating Applitools Eyes and Jira will save you time, especially if your visual tests detect many defects. Manually logging visual defects may take a lot of time: grab a screenshot, draw a circle around the defect, write some text explaining what the problem is, create a Jira ticket, attach a screenshot, then have a follow-up call with a developer because they didn’t understand your write-up. This may easily add three to five minutes just to report and explain one software bug.

Three to five minutes per bug? What a time sink…

There’s a better way: integrate Applitools Eyes with Jira. Doing this lets you directly report issues to your engineering team, and track those issues to resolution. Highlight a region, write a quick comment, tag your teammate responsible for investigating, and you’re done. A bug report with screenshots with highlights of all visual differences, along with your comments, filed in Jira and your teammate is notified. Total time: about thirty seconds to file a bug.

With the manual tasks of reporting and tracking out of the way, testing teams can focus on increasing test coverage (and leaving the office at a reasonable time). This post explains how to quickly report issues and defects captured by Applitools Eyes to a Jira project.

Configuring Applitools

First, open the Applitools Eyes Admin panel and locate your team. Find the Jira section on the page and click the checkbox to enable the integration. In the text box, type the URL of your Jira server. Next, specify the Project ID (PID) and the ID of the relevant issue type for the target project. If your project uses additional Jira fields, type the field name into the text box and press the Add button. In the drop-down menu, select a field type. Alternatively, you can type the name of a custom field into the text box. After you provide all the relevant configuration information, save it.

Applitools Eyes Jira Integration in Action

Now that you have configured the Applitools Eyes Jira integration, we will show you how to use it. In this example, we will simulate a defect in an existing web application (Gmail), and then use the integration to create a new Jira issue. The test inspects Gmail’s More button and detects a typo. When a test detects an issue, click the Create New Jira Issue button. This opens a new browser tab that displays the Jira Create Issue form. In the form, each field you specified during the configuration process contains the relevant Applitools Eyes test information. You can edit the information in the form and populate any empty fields. When you are ready to create the issue, click the Create button.

After you save the detected defect, Jira creates an issue that includes the name of the test, the batch in which it was running, the step description, the time when Applitools Eyes encountered the issue, the execution environment in which it was running, and any custom properties you defined for the test. The issue includes a link that lets you view all the defects in the Applitools Test Manager. This allows you to examine the recorded visual validation in context and compare captured screenshots with the test’s baseline images.

You can add existing visual regression test results that were not linked to a Jira project using the Link to Jira issue dialog box. The dialog box lets you enter an issues Applitools ID and add it to Jira. After you add an issue from Applitools to Jira, click the View in Jira button from an issue region or the Collaboration View to view the defect in Jira. You can also use the dialog box to link to a different Jira issue, or you can just delete the link.

Find visual UI bugs before your customers do

In this post, we explained how our Applitools Eyes and Jira integration can boost your team’s productivity. Integrating Jira with Applitools will help you streamline communication with your engineering team, which will allow for more efficient management and tracking of issues. As a result, your software development team will ship better quality software in less time.

But productivity is only part of the picture. It’s absolutely critical that you don’t let visual user interface bugs escape into production. When this happens, your customers will lose trust in your software and brand.

Even worse, you can have a visual bug that blocks customers from buying, such as this glitch on the Southwest Airline’s website. See how the text is overlapping the Continue button? Because of this, the Continue button doesn’t work, and customers can’t book a flight.

From a business perspective, this bug is disastrous since it is blocking revenue generation and is actively driving customers to competitors. It’s these kinds of revenue-killing production bugs that software QA and development teams need to be able to report and act on quickly, and 

So, once you’ve integrated Applitools and Jira, what will you do with all the time you’ve saved?

If you are a Jira user and want to read more about Applitools’ visual UI testing and Application Visual Management (AVM) solutions, check out the resources section on the Applitools website. To get started with Applitools, request a demo, or sign up for a free Applitools account.

The post How to Make Jira Easier to Use with Integrated Visual UI Bug Tracking appeared first on Automated Visual Testing | Applitools.

As front end developers, our job is to present visual information that looks good and gives users cues to help them understand content quickly. Even a static, text-only web page is more than a collection of words. The page has a title that appears at the top. The title may be bold or in a large font size. In the body of the text, words are grouped into sentences that end with periods, and related sentences are grouped into paragraphs. Certain words in a sentence may be emphasized with bolding, underlining, or italics. These examples barely scratch the surface of the many, minute details of visual web page design.

These components may seem basic and unimportant, but for many people, accessing and reading text on a web page is difficult. For example, individuals with visual impairments often struggle to read the text. When we think of visual impairment, most of us automatically picture a person who is blind, but there are many other types of visual impairment to consider, including color blindness, low vision, sight problems caused by degenerative disorders, etc. The range of disabilities and handicaps our users may have extends far beyond the visual category to include hearing, cognitive, motor, and other types of issues. Therefore, making sure your website or application is accessible rises to the utmost importance. 

Since front end developers handle the visual presentation and functionality of web pages and applications, we need to be aware of and address the accessibility issues that exist for those who have disabilities and handicaps. While we all have a moral imperative to do our best to make websites and applications accessible, front end developers in many countries also have a legal obligation to do so.

This post will define what accessibility means and will discuss what kinds of issues front end developers need to be conscious of in terms of providing accessibility. We’ll also review some of the available methods, tools, and resources to address these issues.

What Is Web Accessibility and Why Do You Need to Be Involved?

The World Wide Web was created for the purpose of sharing research amongst atomic physicists at CERN. As the web grew, the World Wide Web Consortium (WC3) was created to govern it. The WC3’s mission states that the web was created to enable human communication to benefit all people, no matter where they live or what physical and/or mental abilities they may have.

Web accessibility ensures that people with physical and non-physical disabilities have equal access to the web. It helps people with impaired auditory, cognitive, neurological, physical, speech, or visual functions perceive, understand, navigate, interact with, and contribute to the internet. To help web developers and designers make their pages and applications accessible, the WC3 launched the Web Accessibility Initiative (WAI), which provides guidelines for making the web available to people with disabilities. Providing accessibility also helps other groups, such as users of mobile technologies, older people, people who have temporary disabilities (e.g., someone who is recovering from an injury caused by a physical accident), and people in certain locations and countries with limited bandwidth.

Beyond our basic obligation to help our fellow human beings, there are also practical reasons for providing equal accessibility. No matter what type of organization we work for, be it commercial, non-profit, governmental, etc., we need to accommodate all users and customers. If we understand what our users need and provide methods to meet those needs, any person, no matter their physical or other limitations, can buy our products and use our services.

As the reach of the internet spreads to individuals with limited income and to less developed countries, we risk losing huge numbers of potential customers if we don’t make our products accessible to them. According to the World Health Organization (WHO), one out of seven people of the world’s population is disabled or handicapped in some capacity. So, if we fail to meet this population’s needs, we’re missing out on approximately one billion potential consumers.

In some countries, front end developers are also legally required to provide accessibility. Many governments around the world have adopted the WC3’s Web Content Accessibility Guidelines (WCAG) 2.0. WCAG 2.0 provides guidelines for implementing solutions, but it isn’t tied to any specific technologies. The UN and local initiatives have also used WCAG 2.0 as the basis for their accessibility legislation. Countries that currently have laws governing web accessibility include Australia, Brazil, Israel, the United Kingdom, the United States, and the member states of the European Union.

How to Provide Web Accessibility

Since we have a limited amount of space in this post, we’ll concentrate on vision and cognitive impairments for our specific examples of how to provide web accessibility.

One of the simplest ways to accommodate these users is to provide good page semantics. Semantics are the elements and structure of a page that give it meaning to a human reader. A page’s semantics are created by applying the correct HTML elements in the right sequence (e.g., using page headings H1 and H2 in the correct order). You can also differentiate between different types of content by using bulleted and numbered lists. Page semantics matter because assisted reading technologies, such as screen readers, use them to process the page and read it aloud to people with visual impairments.

Page semantics are also important for helping individuals with cognitive disorders. For example, people who have dyslexia can see words and pictures, but they have difficulty extracting meaning from the raw, visual input because of difficulties with processing contextual information like letters and word order.

There are a variety of ways to make information accessible for users with disabilities and handicaps. To help people with low vision and dyslexia, you can use a high-contrast color palette. You can achieve this contrast by using a dark color like black as the background color and a bright color like white or yellow for the foreground text.

Front End Development and Accessibility

As front end developers, we have the power to make equal accessibility a reality. There are a number of tools you can use to build and test web accessibility. We discuss some of the best tools below.

ARIA

The Angular, React, and Vue frameworks all provide support for the Accessible Rich Internet Applications (ARIA) toolkit. 

ARIA is a WIA platform that standardizes how developers can build web-accessible applications and present content for people with disabilities. It provides the required functionality for assistive technologies (e.g., means to control input devices for people with limited/impaired motor functions and screen readers for people who have visual impairments).

ARIA can be used as an indicator of the state of a web component to a screen reader or an input device. In a web application, components indicate their current state visually. If the state of the component changes, the object’s presentation changes. For example, a checkbox indicates the values are true by displaying a checkmark, and false by leaving the box blank. To support assistive technologies, additional semantic information is required so that the component’s state can be presented to the user.

To provide this information, you can add the ARIA-checked label to the component. If the page is read by a screen reader, it will use a label to inform the user if the box is checked or not. If the page is being used by a person with limited mobility, component state changes can be indicated via haptic feedback.

Ally.js

While ARIA can help you identify components and provide state information to users, it doesn’t have any built-in support for navigating web pages. In this context, navigating a page refers to two things: moving between page components and indicating the order in which they should be used. For example, if a website requires a user to change their password, it will ask them to type a password into one text box, retype it into a second text box, and then press the submit button. After each step is completed, visual cues in the application tell the user what to do next and where to place the required input. For a user who is unable to use conventional input devices, it’s difficult to enter the information in the correct location and navigate to the next component in the correct order.

Ally.js is a library that enables users with restricted mobility and limited vision to navigate web pages. It does this by providing an accessibility tree that shows the structure of the page and indicates any objects and components that have semantic significance. The accessibility tree defines a web page’s Sequential Navigation Focus Order, which is a list that determines the sequence in which components are accessed via an input device.

Test Automation

There are many available tools for testing web accessibility, but testing often involves boring and repetitive tasks. So, there are many tools and frameworks for automating functional, regression, and visual testing. Testing accessibility can be done by using the same methods and tools. The best tool for the job is the aXe platform, which is an open-source project that provides assertions for accessibility testing and integrates with a large range of testing and CI systems.

Conclusion: Committing to Making the Web Accessible to All

We all agree that everybody, no matter what mental or physical restrictions they may have, should have equal access to the web. There are clear moral, economic, and legal reasons to make the web accessible, and there are also guidelines, techniques, and technologies available that can help front end developers actually make it happen.

With the many tools we have at our disposal, creating accessible web pages and applications has never been easier. Accessibility support is baked into the major platforms via ARIA for front end developers. If you need extra functionality that isn’t provided by your framework of choice, you can use ally.js. You can even do automated testing with the aXe platform to test your applications for web accessibility. With empathy, understanding, and the proper tools, front end developers have the power and the responsibility to make the web accessible to all.

To learn more about Applitools’ visual UI testing and application visual management (AVM) solutions, check out the tutorials on the Applitools website. To get started with Applitools, request a demo, or sign up for a free Applitools account.

The post Making Your Website/Application Accessible: a Guide for Front End Developers appeared first on Automated Visual Testing | Applitools.

At some point while each of us were growing up, we wished that the adults in our lives would just disappear. They made our lives miserable with their arbitrary rules and restrictions, but they got to do all kinds of fun things. After all, how hard could it be to drive a car, and why did we need them to watch an R-rated movie or to cross the street?

Well, front end developers have a similar fantasy. Their wish is that one day, all back end developers will move out of their way and let them take control. Front end developers are responsible for the things people see and use. All the back end developers need to do is create REST APIs and HTTP endpoints that work and return well-formed JSON, and the front end developers do the rest.

One way you can get what you want in a timely manner is to go over to the dark side and become a full-stack developer, but where’s the fun in that? Well, there have been some interesting things happening in the world of cloud services, and soon, the tables may finally turn and put front end developers in the driver’s seat.

A new development that is benefiting front end developers is called serverless computing. Of course, the term “serverless computing” is deceptive. In this article, we take a look at the server behind the curtain, discuss the rise of serverless computing and what that means for front end development, and show you how you can get started.

What is Serverless Computing?

Serverless computing could just be a fad, and it might eventually join the long list of tech marketing buzzwords like Agile, virtualization, containers, DevOps, AI, machine learning, etc. In his article about serverless architecture, Mike Roberts defines serverless computing as applying to two different, but overlapping, models. These models are Backend as a Service (BaaS) and Functions as a Service (FaaS).

BaaS refers to third-party cloud services such as authentication, file storage, messaging, and data management. These services are accessible via an easy-to-use, web-based graphical user interface (GUI). Sometimes, they also have a command line interface (CLI) for building the services. The service also takes care of operational tasks such as maintenance, security, and scaling. Developers call these services directly from their client code via an HTTP endpoint and a rest API.

FaaS enables the developer to create a function that combines a number of exposed BaaS endpoints. These functions provide a container that can be deployed to provide specific backend services. The functions are triggered by an event such as a request sent from a client application.

In order to run the functions, FaaS services provide a compute platform and a gateway. The compute platform lets you write and deploy code that receives requests and performs the relevant tasks, such as user authentication, running queries against a database, and uploading files to storage. The gateway publishes the functions and provides an API proxy that receives requests from client applications, authenticates them, passes them to the compute platform for processing, and sends the response back to the client. In addition, all of the services provide a developer console, management tools, and various ways to analyze usage and performance.

Getting Started with Serverless Computing

One of the best places to start exploring serverless computing is Google’s Firebase service. 

Below, we provide examples of how to use Firebase for BaaS and FaaS. Please note that the examples are all written in JavaScript and ReactJS.

Creating a Project

Before exploring the BaaS and FaaS aspects of Firebase, you must create a project. Creating a project with Firebase is very straightforward. First, you open the Firebase console web page and follow the instructions. Once you create the project, Firebase generates a JSON object that contains all of the configuration information. Then, you copy the object and include it as part of the project. Here is a sample of the generated code:

BaaS Services

Firebase provides a range of BaaS services, but for the purposes of this post, we will just review the authentication and data management services.

Authentication

Even if you do not use any other service, there is no excuse for not using commercial authentication. The provider has done most of the leg work, so you do not need to reinvent the wheel.

Firebase gives you everything you need to create and manage users. More importantly, it lets you create the rules that control permissions and data access. On the client side, it provides the Firebase UI library, which abstracts away the annoyance of building and maintaining client-side authentication code. For React developers, there is a Firebase UI React library that provides additional wrappers. The libraries allow you to create an object that lists the relevant authentication methods, and they show you how to handle the authentication process.

const uiConfig = {
  signInOptions: [ firebase.auth.GoogleAuthProvider.PROVIDER_ID,
    firebase.auth.FacebookAuthProvider.PROVIDER_ID ]
};

All you need to do is embed the Firebase authentication component in your class object’s render method.

class Login extends React.Component {
  render() {
    return 
  }
}

Data Management

Firebase provides a cloud-based document database called Firestore. A document is a JSON object that stores data in key-value pairs. Like other popular document databases such as MongoDB and CouchBase, Firestore lets you create and manage collections (groups of related documents like customer and sales data). In the following example, a user creates a product that manages a collection of users, and locates a document with the information for a specific member.

firebase.firestore().collection("members")
.where("member", "==", "jonnygold").get().then((snapshot) => {})

FaaS Services: Cloud Functions

Cloud Functions allow developers to write code that responds to specific events. These events can be handled by any Firebase or GCP service. For example, they can be used to handle authentication and query data, send messages related to changes for specific data, manipulate files, or integrate with third-party services. In the following example, the function is triggered when a user updates their profile:

exports.updateUser = functions.firestore
  .document('users/{userId}')
  .onUpdate(event => {
    // Retrieves user document
    let newVal = event.data.data();
    // access relevant field
    let name = newValue.name;
});

The Serverless Framework

In addition to exploring serverless offerings from Firebase, Google Cloud Platform, Microsoft Azure, and Amazon Web Services, you should also check out the Serverless Framework. It was built to provide tools for deploying and operating serverless architectures. The framework is vendor agnostic. It supports all the major vendors, but is designed so that you won’t get locked into a single provider’s solution. In fact, you can start building your app on any of the supported platforms, such as AWS, and at a later stage migrate it to a different platform, such as GCP or Azure. Serverless provides a command line interface for creating and deploying applications, and lets you use the language your project uses to handle configuration and application management.

Conclusion: Onwards and Upwards

We only scratch the surface of the serverless computing revolution in this short post. There is currently a lot of marketing hype about serverless computing, but it is true that this development represents a significant change in how we build apps. It gives front end developers the power and opportunity to build what they want, when they want, and how they want.

Firebase is a good place to start, but all of the platforms more or less offer the same services, and they all offer a developer/free tier to get you started. So whatever your idea is, you now have the tools to make it a reality.

In addition, once you get started you may want to migrate your serverless application to a new platform. This is where the Serverless Framework comes in. It will help you build a serverless application that does not depend on a single vendor’s tools or infrastructure. It will let you deploy your serverless system without the vendor lock-in that typifies cloud vendors and platforms.

To learn more about Applitools’ visual UI testing and application visual management (AVM) solutions, check out the tutorials on the Applitools website. To get started with Applitools, request a demo, or sign up for a free Applitools account.

The post A Front End Developer’s Guide for Creating Serverless Applications appeared first on Automated Visual Testing | Applitools.

Have you ever asked yourself why all apps aren’t web apps? Well, this is actually already the case on desktops and most of the apps you use at home and/or at work. When it comes to productivity apps, Microsoft, Apple, and Google all have full-featured web apps that are just as capable as locally installed desktop applications. As long as you have good wired or wireless internet, you can do nearly all of your work in Chrome, Edge, or Safari. Apart from specific categories, such as graphics, video editing, software development, and high-end gaming, you can do nearly everything in a web browser.

Mobile, however, is a different story.

Whether you’re trying to tether a laptop or use a mobile device, using a native app is preferable to using a web app. Native desktop and mobile apps have access to device hardware (such as storage) and can work offline. When it comes to mobile, it doesn’t matter whether you use the mobile versions of Chrome (Android) or Safari (iOS)—they’re pale shadows of the desktop versions, and they aren’t worth the effort.

The good news is that things are starting to change, and a new generation of Progressive Web Apps (PWAs) are changing the status quo. They’re the missing piece that will allow any browser-based app to look, act, and respond like a native app. They work offline, are able to access native device hardware (e.g., camera, storage, network, etc.), and provide a user experience that’s indistinguishable from native applications.

At this point, Google and Microsoft are fully committed to supporting PWAs across their platforms and browsers. Apple hasn’t made an official commitment yet, but there’s evidence that both desktop and mobile Safari will offer partial or full PWA functionality in the near future.

In this post, we discuss how the mobile revolution and the rise of smartphones led to the creation of PWAs. We explain what PWAs are, describe their component parts, and provide instructions for how to build and test them.

The Rise and Fall of Web Apps

Until 2007, it seemed like the rise of web apps was unstoppable, but then the iPhone changed everything. Google quickly followed Apple’s example and launched Android. Both platforms came with a built-in browser that did a reasonable job of rendering web pages. Due to security and performance concerns, the browsers had limited access to a device’s hardware. Developers voted with their feet—they preferred writing mobile versions of their apps using each platform’s native SDK and distributing them via app stores.

During the rise of native apps on mobile devices, it appeared that web apps were becoming irrelevant at best, and obsolete at worst. Desktop browsers and web apps may have been overshadowed, but in this period, a number of new developments made the web browser the platform of choice for app development and delivery. Ironically, given that we think of Apple as the iPhone company, we forget that they were instrumental in creating the web standards that resulted in new and better web apps.

Following the launch of Safari on the Mac, Apple created the WebKit rendering engine. In 2008, Google adopted WebKit and started to implement the new web standards in their Chrome browser. Chrome enabled developers to deliver web apps that could access device hardware such as storage, camera, and location. Recently, Google has been adding these features to the latest versions of mobile Chrome on Android and Chrome OS. Alex Russell, a Google Chrome team member, coined the term Progressive Web App (PWA) to define these new developments.

What is a Progressive Web App?

On Google PWA homepage, a PWA is described as a web-based user experience that’s reliable, fast, and engaging. Highlighting these three qualities draws attention to the fact that many web apps are unreliable, slow, and not engaging, which has the potential to tar PWAs with the same brush.

When it comes to reliability, a web app is only as reliable as its network connection. A bad connection means that a web app will either load slowly or not load at all. So PWAs should load quickly and reliably even when network connectivity is uncertain. If network connection is lost during a session, you should be able to rely on the PWA to save data and any changes you made.

You could say that reliability and speed are two sides of the same coin. This is partly because they’re dependant on sending requests to and receiving responses from remote servers. It’s also because many front end frameworks that are used to create web applications perform less efficiently than similar native frameworks.

A PWA that’s reliable and fast will engage users and ensure that the PWA user experience feels as natural as using a native app. As far as the user is concerned, a PWA is no different from a native app, and it should provide a shortcut icon that allows launching from the home screen. PWAs are progressive because, no matter what limitations a browser has, they can be progressively enhanced to include any missing functionality.

In addition, PWAs must have the following characteristics: 

Discoverable

What use is writing a great app if no one can find it? And once you’ve found it, how do you install it? There are many sites that provide curated lists of available apps (e.g., PWA Rocks). In the near future, PWAs will also be available from app stores. 

To install a PWA, you must locate and download the relevant assets to your device. In order to find and install these assets, developers create an app manifest. The manifest is a JSON file that stores web application metadata and related information. This includes its name, links to assets (e.g., icons, images, video), the preferred URL to launch or open the web app, and configuration settings (orientation, full screen, etc.). The browser uses the information to provide support for device-native services and hardware.

Provide Offline Support

One of the biggest problems with using the mobile web is that it must be connected to the internet. In order to provide a completely app-like experience, a PWA must be available and work offline. PWAs provide offline support via service workers, which are scripts that a web browser runs separately from and in the background of a web page. The service worker sends requests and caches the responses. In other words, a service worker doesn’t just store application data in random access memory; instead, it persists this data to the device’s file system or the browser’s internal databases. In the event that the browser’s internet connection fails, it can continue to operate offline. Service workers can also provide support for push notifications and updates.

Secure

The HTTP protocol enables you to pass unencrypted data over an internet connection. Since the world is a dangerous place and PWAs will be used to handle sensitive personal and financial information, it’s better to be safe than sorry. PWAs ensure security by being served over HTTPS. While you technically can create a PWA and serve it via a non-secure HTTP, using HTTPS provides an extra layer of protection for sensitive user data.

Building and Testing Your First PWA

The first step for creating a PWA is writing a manifest file. Next, write a service worker for caching pages and handling offline data. The last step involves integrating the service worker into your application. This requires writing code that registers and downloads the service worker. For a detailed, step-by-step guide, see this tutorial from Google. If you want to convert an existing web app, see this guide from Chris Love. Another approach is to use an online service, such as the Manifold Online PWA Builder. 

As with any web or mobile application, it’s not enough to just write the code—you also need to test it before it’s released for users. A PWA is a web app, so its elements can be tested using existing manual and automated testing techniques. Additional tests will be required to measure online and offline performance and presentation. For a comprehensive list of PWA features and functionality, you should test, see Google’s PWA checklist. 

PWAs are also excellent for visual testing. For example, you can test your PWA using Applitools Eyes. Applitools Eyes allows you to define a visual baseline of your app. If a test run detects differences between the expected/baseline image and the actual image that’s detected in the test, the test is failed. Oftentimes, the difference doesn’t come from an issue or a defect but is instead caused by a newly introduced feature or cosmetic change. 

Conclusion: The Best Is Yet to Come

Over the last ten years, we’ve witnessed an impressive evolution of the mobile web. In that time, we’ve progressed from primitive, barely usable mobile browsers running on features and pre-iPhone smartphones to today’s highly capable mobile browsers that run on phones and tablets.  

PWAs are the next step in the evolution. They will blur the lines between mobile and native development. While developing and deploying mobile web apps may be easier, the issue of testing mobile apps becomes increasingly important. To ensure the best possible experience for your users, the case for using visual testing tools like Applitools Eyes has never been stronger.

To learn more about Applitools’ visual UI testing and application visual management (AVM) solutions, check out the tutorials on the Applitools website. To get started with Applitools, request a demo, or sign up for a free Applitools account.

The post Progressive Web Apps: Building Compelling Apps with the Latest Mobile Web Technology appeared first on Automated Visual Testing | Applitools.