Did you attend the Applitools workshop last week for You, Me, and Accessibility: Empathy and Human-Centered Design Thinking? If you missed it, don’t fret; the recording can be found on-demand and my recap of key learnings, Q&A, and poll results are right here!

Applitools workshops are designed to bring together talented people within software development teams to provide hands-on learning experiences. Folks shared with me after the workshop just how enjoyable learning about accessibility, empathy and human-centered design thinking is and discovered ways to share with their peers and product teams.

What we covered in this workshop

Human-centered design thinking

What it is and how we can use it!

Empathy sessions

What are they? Who are they for? The benefits they provide.

#A11y tools and resources

Manual and automated testing resources and much more!

Great products come from conversations, experiments, and learning. Human-centered design thinking is a wonderful process for problem solving. Here you can empathize, define, ideate, prototype, and test your solutions early and often! Empathy sessions fall right in line with the concepts of human-centered design thinking as an opportunity for exploratory testing of our users. 

We kicked things off with a base question of Web Content Accessibility Guidelines (WCAG) awareness. I am thrilled when I see a majority has knowledge of accessibility when it comes to digital content, and truly appreciate an opportunity to share with folks newer to the topic.

I spoke at length about common accessibility (often shortened to a11y) categories, where to consider them in the software development lifecycle (SDLC), and what the intersection of software and empathy looks like. We explored human-centered design thinking as a tool and demonstrated ways empathy drives innovation. Humans are emotional beings! There is value in proficiency in the technical side of software development as well as the human-centered side.

How does empathy drive innovation?

Empathy supercharges creativity and innovation by giving us insight into experiencing what someone else is thinking and feeling and allows us to more fully understand their motivations and anticipate their needs in ways the user may not be able to express themselves.

For the purpose of our workshop, we wanted to dig into what role folks play on their current product teams. To do this, we asked them! We went over what happens in the software development lifecycle and why it’s important to talk about how users are using technology. There we had opportunities to explore the different types of users who could potentially use our products or services. Then we discussed how those opportunities can be expanded upon by utilizing design thinking and in empathy sessions. 

What is human-centered design thinking?

Based on three principles:

1. Collaboration
2. Empathy
3. Experimentation

What happens in the software development lifecycle? We talk about the products and services that we want to make for our users. We make the products and services to the best of our ability. We test and ship those products and services to our users.

We wrapped up the workshop with some wonderful questions and answers that I wanted to also provide additional feedback and resources for. 

If you enjoyed this recap, be sure to follow me on social media for more content like it on LinkedIn and Twitter. You can also read more of my insight into empathy, software testing, and hot accessibility testing tools on medium!

The post You, Me, and Accessibility: Empathy and Human-Centered Design Thinking Webinar Recap appeared first on Automated Visual Testing | Applitools.

Learn how to get started with web accessibility testing with this list of the best paid, free and open source accessibility testing tools.

If you visit the Web Accessibility Evaluation Tools List, there are a whopping 167 tools to choose from! As someone who is just starting in the world of accessibility, how do you decide which tools to choose?

There are of course various factors to consider when choosing an accessibility tool, but in this blog post, I’ll share a few tools that I have found really useful when it comes to accessibility testing. If you tuned in to my talk on Shifting Accessibility Testing to the Left (or read my blog post), you would know that I like to group the accessibility testing tools in different areas. These areas are:

• Tools requiring human assistance
• Semi automated tools in the form of browser extensions
• Automated tools

Accessibility Testing Tools Requiring Human Assistance

Even though there’s a growing number of automated tools out there, accessibility testing still requires human assistance to make sure that the experience we are testing closely matches the one our users will have. The following tools are my go-to when it comes to manually testing for accessibility.

Keyboards

The first tool is my very own keyboard. Making sure that your website is keyboard friendly and compatible already makes it more accessible than many other websites.

To get started with keyboard compatibility testing, you need to know basic keystrokes such as TAB, Enter, Arrow keys (← ↑ → ↓), just to name a few, to make sure that you can still interact with the website as if you are using a mouse.

When it comes to testing with a keyboard, this can surface accessibility considerations such as:

• Are your elements focusable when the user tabs through it?
• Do you have a skip to the main content link which is only visible when tabbed through with a keyboard?
• When presented with a modal or a pop-up, can the users exit the modal and interact with what they were presented before?

Screen Readers

Using a screen reader can be overwhelming for people who don’t use it but screen readers are a must when it comes to testing for accessibility. Depending on the operating system that you are using, there is an available screen reader software for you to use such as VoiceOver, JAWS, NVDA and TalkBack. Spend some time familiarizing yourself on how to use a screen reader to make sure that your websites are accessible for these users.

Zoom/Magnification

Users who have low vision need to have a way to easily perceive, navigate and interact with the content that is presented to them. By using the zoom or magnification too that’s built into browsers, you can zoom in up to 200% (or more) and verify if the elements are displayed nicely and are still interactable.

Semi-Automated Accessibility Testing Tools in the Form of Browser Extensions

Browser extensions are a quick way to help you surface any accessibility issues that your websites might have. Most of the browser extensions are provided to you for free with additional features unlocked if you purchase their commercial version. The common thing with the extensions below is they all provide an easy way to check violations. All of the extensions, apart from ColorBlindly, also provide an easy to digest output so you can share with your teams a list of accessibility issues.

Axe DevTools and WAVE

Axe DevTools and WAVE are two extensions that you can install and integrate easily in your browser of choice. These accessibility extensions scan a specific web page and report any accessibility violations that it finds. These are great tools to get started with accessibility, especially if you are a beginner. They provide useful information such as the description of the accessibility violation, its impact, how to fix it and elements that are impacted.

Google Lighthouse

Google Lighthouse, which is already built into Google Chrome’s developer tools, provides an easy way to perform accessibility audits. It can also measure web performance apart from accessibility and can provide recommendations on how to fix the issues caught. Don’t get too fixated though with the Lighthouse accessibility scores as this is not a complete indication that your website is accessible.

ColorBlindly

ColorBlindly is an easy to use Chrome extension that can simulate different types of color blindness with just one click. This extension can help you verify if the color schemes of your website are accessible from a wide range of color blindness.

Automated Accessibility Testing Tools

Now, in order to shift accessibility testing as early as possible, apart from having early conversations with your team, leveraging automation is key so that you can focus on areas where accessibility testing is needed the most. What’s common with these tools is that you can easily integrate them as part of your continuous integration pipelines and it can provide a safety net so your team can be confident in making changes or introducing new features.

Axe CLI

Command line lovers, this tool is for you! Axe CLI is a command line tool which provides a way to perform accessibility audits straight from your command line. This is particularly useful if you want to quickly scan various pages from your command line.

The scan can be configurable in the sense that you can disable certain accessibility rules, include or exclude certain elements and modify the accessibility report. 

If you’re looking for a quick tool that you can easily integrate as part of your pipelines, give Axe CLI a try.

Cypress and cypress-axe

Good news for Cypress users! Did you know that you can easily integrate accessibility tests just by installing a plugin called cypress-axe? Cypress-axe uses the axe-core library and lets you audit pages or components straight from your Cypress tests. I have discussed this in more detail in my course Test Automation for Accessibility so if you’re interested to find out how the plugin works, check out this course from Test Automation University.

Similarly, if you’re using other testing frameworks, you’re also in luck because axe-core can be integrated with other frameworks or testing libraries. Whether you are using Playwright, WebdriverIO, Selenium or others, axe-core has a library for you which can be found here: projects that use axe-core.

Applitools Contrast Advisor

Did you know that Applitools also supports accessibility testing? If you’re already using Applitools for visual testing, then you can also try their Contrast Advisor tool which can detect contrast violations using artificial intelligence. With Contrast Advisor, it can easily integrate into your existing workflow and pipelines already so no additional coding setup is needed. You can also validate the contrast of images and native applications easily with this tool.

Wrap Up

The tools above are by no means a complete list, but should help you get started when it comes to accessibility testing. Regardless of what tools you choose, you should have the same goal and that is to catch as many accessibility issues as possible before giving it to your real users. 

By using a combination of these tools as early as possible, along with other accessibility testing strategies, you can ensure that your user experience is inclusive. The above tools should not be a replacement for accessibility testing with real users but should complement it instead.

How Can I Help?

Accessibility doesn’t start and end with tools. It requires a change of culture and wider buy-ins to make sure that everyone is on the same page. If you or anyone from your team requires specific consultation help with regards to accessibility, I’m happy to have an introductory chat to help you nurture accessibility within your team. You can contact me via Twitter @mcruzdrake or via my personal blog at mariedrake.com.

The post Top 10 Accessibility Testing Tools for Websites appeared first on Automated Visual Testing | Applitools.

In this detailed guide, learn everything you need to know about what regression testing is, along with best practices and examples. Learn how you can apply regression testing in your own organization and much more.

While regression testing is practiced in almost every organization, each team may have its own procedures and approaches. This article is a starter kit for organizations seeking a solid start to their regression testing strategy. It also assists teams in delving deeper into the missing links in their current regression testing technique in order to evolve their test strategy.

What is Regression Testing?

Regression testing is a type of software testing that verifies an application continues to work as intended after any code revisions, updates, or optimizations. As the application continues to evolve by adding new features, the team must perform regression testing to evaluate that the existing features work as expected and that there are no bugs introduced with the new feature(s). 

In this post, we will discuss various techniques for Regression Testing, and which to use depending on your team’s way of working. 

However, before we jump onto the how part, let us understand why having a regression test suite is essential.

Why Do We Need Regression Testing?

A software application gets directly modified due to new enhancements (functional, performance or even improved security), tweaks or changes to existing features, bug fixes, and updates. It is also indirectly affected by the third-party services it consumes to provide features through its interface. 

Changes in the application’s source code, both planned and unintended, demand verification. Additionally, the impact of modifications to external services used by the application should be verified.

Teams must ensure that the modified component of the application functions as expected and that the change had no adverse effect on the other sections of the application. 

A comprehensive regression testing technique aids the team in identifying regression issues, which are subsequently corrected and retested to ensure that the original faults are not present. 

Regression Testing Example

Let us quickly understand with the help of an example – Login functionality. 

• A user can log into an app using either their username and password or their Gmail account via Google integration.
• A new feature, LinkedIn integration, is added to enable users to log into the app using their LinkedIn account.
• While it is vital to verify that LinkedIn login functions as expected, it is equally necessary to verify that other login methods continue to function (Form login and Google integration).

Smoke vs Sanity vs Regression Testing

People commonly use the terms smoke, sanity, and regression interchangeably in testing, which is misleading. These terms differ not only in terms of the application’s scope, but also in terms of when they are carried out. 

What is Smoke Testing?

Smoke testing is done at the outset of a fresh build. The main goal is to see if the build is good enough to start testing. Some examples include being able to launch the site by simply hitting in the URL, or being able to run the app after installing a new executable.

What is Sanity Testing?

Sanity testing is surface level testing on newly deployed environments. For instance, the features are broadly tested on staging environments before passing it on to User Acceptance Testing. Another example could be verifying that the fonts have correctly loaded on the web page, expected components are interactive and overall things appear to be in order without a detailed investigation.

How is Regression Testing Different from Smoke and Sanity Testing?

Regression testing has more depth where the potentially impacted areas are thoroughly tested on the environment where new changes have been introduced.

Existing stable features are rigorously tested on a regular basis to ensure their accuracy in the face of purposeful and unintended changes. 

Regression Testing Approaches

The techniques can be grouped into the following categories:

Partial Regression Testing

As the name suggests, partial regression testing is an approach where a subset of the entire regression suite is selected and executed as part of regression testing.

This subset selection results from a combination of several logical criteria as follows:

• The cases derived from identifying the potentially affected feature(s) due to the change(s)
• Business-critical cases
• Most commonly used paths

Partial regression testing works excellently when the team successfully identifies the impacted areas and the corresponding test cases through proven ways like the Requirement Traceability Matrix (RTM henceforth) or any other form of metadata approved by the team.

The following situations are more conducive to partial regression testing:

• The project has a solid test automation framework in place, with a large number of Unit, API, Integration tests, and Acceptance tests in proportion as per the test pyramid.
• Changes to the source code are always being tracked and communicated within the cross-functional team.
• Short-term projects tight on budget and time.
• The same team members have been working on the project for a long period.

While this method is effective, it is possible to overlook issues if:

• The impacted regions aren’t identified appropriately.
• The changes aren’t conveyed to the entire team.
• The team doesn’t religiously follow the process of documenting test scenarios or test cases.

Complete Regression Testing

In many cases, reasons like significant software updates, changes to the tech stack demand the team to perform comprehensive regression testing to uncover new problems or problems introduced due to the changes.

In this approach, the whole test suite is run to uncover issues every time new code is committed, or, at some agreed time intervals.

This is a significantly time-consuming approach compared to the other techniques and should ideally be adopted only when the situation demands.

To keep the feedback cycle faster, one must embrace automated testing to enable productive complete regression testing in their teams.

Which Regression Technique to Use?

Irrespective of the technique adopted, I always suggest that teams prioritize the most business-critical cases and the common use cases performed by end-users when it comes to execution. 

Remember, the main goal of regression testing is to ensure that the end-user is not impacted due to an unavailable/incorrect feature, which could affect business outcomes in many ways.

Best Practises for Regression Testing

To achieve better testing coverage of your application, plan your regression testing with a combination of technology and business scenarios. Apply the practices across the Test Pyramid. 

Leverage the Power of Visual Representation

Arranging the information in the form of a matrix enables the team to quickly identify the potentially impacted areas. 

• The RTM shown in the diagram below, any changes made to REQ1 UC 1.3 will let us know that we have to test the test cases 1.1.2, 1.1.4 and 1.1.7.
• Also, since test case 1.1.2 is also related to UC 1.2, we would immediately test that for any regression issues. 
• Of course, the RTM should be up-to-date at all times for the technique to work correctly for the team.
  
  (Image Source)
  

Alternatively, many test case management tools now have started providing inbuilt support to build a regression test suite with the help of appropriate tags and modules. These tools also let you systematically track and identify patterns in the regression test execution to dig into more related areas.

I have seen teams being most effective when they have automated most of their regression suite, and the non-automatable tests organised and represented in a meaningful way that allows quick filtering and meaningful information.

Test Data

We should leverage the power of automation to create test data instantly across different test environments. We need to ascertain that the updated feature is evaluated against both old and new data. 

Ex: A new field added to a user profile, for example, should work consistently for both existing and newly formed accounts.

Production Data

Production test data plays a vital role in identifying issues that might have been missed during the initial delivery.

In cases where possible, replicate the production environment to identify edge cases and add those scenarios to the regression test suite.

Using production data isn’t always viable, and it can lead to non-compliance issues. Teams frequently conceal / mask sensitive information from production data and use the information to fulfil the requirement for on-the-ground scenario analysis.

Test Environments

If you have multiple environments, we should verify that the application works as intended in each of the environments.

Obtaining a Fresh Outlook

Every time a new person joined the team when the development was already in progress, they asked meaningful questions about the long-forgotten stable features. I also prefer young guns to be part of my regression team to get a raw and holistic testing perspective.

Automate

Automate the regression test suite! If you have the budget, great, or else, create supporting mechanisms to utilise the team’s idle time to implement automated tests.

Simply automating the business-critical scenarios or the most used workflows is a good enough start. Initiate this activity and work incrementally.

Either tag/annotate your automated scenarios as per the feature or segregate them into appropriate folders so that you’d be able to run particular automated regression scenarios.

Sequential execution won’t scale with a rising number of test environments and permutations, despite the fact that automated test execution is faster. As a result, concurrent test execution in various settings is required to meet scalability requirements. Selenium Grid and other cloud solutions like Applitools Ultrafast Test Cloud enable you to execute automated tests in parallel across different configurations.

In addition to adhering to best practises when creating the test automation framework, these tests must run at a high pace and in parallel to provide faster feedback.

Choose What Works for You

Always! One cannot ignore the business limitations and the client demands to meet the delivery. Based on your context, adopt the most suitable regression testing techniques.

Plan for Regression Testing in Sprints

I have seen it take a long time to automate a regression backlog. To keep making progress on this activity, while estimating the Sprint tasks, always account for regression testing efforts explicitly, or you might be increasing your technical debt in the form of uncovered bugs.

Communicate within the Cross-Functional Team

Changes are not always directly related to client needs, nor are they always conveyed. Internally, the development team continually optimises the code for reusability, performance, and other factors. Ensure that these source-code modifications are documented/tracked in a ticket so that the team can perform regression testing accordingly.

Regression Testing at Scale

An enterprise product results from multiple teams’ contributions across geographies. While the teams will independently conduct regression testing for their part, it mustn’t be done only in silos. The teams must also set up cadence structures/processes to test all integrational regression scenarios.

Crowdsourced Testing

Crowdsourced testing can help find brand new flaws in the programme, such as functionality, usability, and localization concerns, thereby improving the product’s quality.

Plan for Non-Functional Regression Testing

Non-functional elements like performance, security, accessibility, and usability must all be examined as part of your regression testing plan, in addition to functionality.

Benchmarking test execution results from past sessions and comparing them to test execution results after the most recent modifications is a simple but effective technique for detecting performance, accessibility, and other degradations.

Due to substantial faults in non-functional areas, applications with the best functionality have either been unable to see production through or have been shelved despite launching successfully.

In a similar vein, application security and accessibility issues have cost businesses millions of dollars in addition to a tarnished reputation.

The Need for an Automated Regression Test Suite

Regardless of your application architecture or development methodology, the importance of automating the regression tests can never fade away. Be it a small-scale application or an enterprise product, having automated tests will save you time, people’s energy and money in the longer run.

Let’s understand some reasons to automate the regression test suite:

Fast Feedback

Automated software verification is exponentially faster than humans. Automated continuous testing in the CI-CD pipeline is a powerful approach to identifying regression bugs as close to its introduction because of the increased speed and frequency at which it operates.

Equally important is to look at the test results from each automated suite execution and take meaningful steps to get the product and the test suite progressively better.

Timely identification of issues will avoid defect leakage in the most significant parts of the application and later stages of testing.

Consequently, the slight left shift always profits the organisation in many ways apart from cost.

Automated Test Data Creation

Before getting to the actual testing, the testing teams spend a significant amount of time generating test data. Automation aids not only in the execution of tests but also in the rapid generation of large amounts of test data. The functional testing team may leverage data generated by scripts (SQL, APIs), allowing them to focus on testing rather than worrying about the data.

Testing features like pagination, infinite scroll, tabular representation, performance of the app are few examples where rapid test data generation helps the team with instant test data. 

Banking and insurance are regulated sectors with several complex operations and subtleties. To exercise and address the data models and flows, a variety of test data is required. The ability to automate test data management has shown to be a critical component of successful testing.

Address Scalability

The automated test suite’s parallel execution answers the need for faster feedback and does it rapidly. Teams can generate test results across a variety of environments, browsers, devices, and operating systems with the right infrastructure and the prerequisite of having built a scalable automated test suite.

The Applitools Ultrafast Test Cloud is the next step forward in cross-browser testing. You run your functional and visual tests once locally using Ultrafast Grid (part of the Ultrafast Test Cloud), and the grid instantaneously generates all screens across whatever combination of browsers, devices, and viewports you choose. 

Use the Human Brain and Technology to Their Full Potential

Repetitive tasks are handled efficiently and consistently through automation. It does not make errors in the same way that people do.

It also allows humans to concentrate their ingenuity on exploratory testing, which machines cannot accomplish. You can deploy new features with a reduced time-to-market thanks to automation.

Maintenance of the Regression Test Suite

Now, let’s complete the cycle by ensuring that the corresponding test cases (manual and automated) are also modified immediately with every modification and change request to any existing part of the application. These modified test cases should now be part of the regression suite.

Failing to adjust the test cases would create chaos in the teams involved. The circus might result in incorrect testing of the underlying application and introduce unintended features and rollbacks. 

Maintaining the regression test suite consists of adding new tests, modifying existing tests, and deleting irrelevant tests. These changes should be reflected in the manual and automated test suites.

Regression Testing Tools

There aren’t separate testing tools categorised as “regression testing tools.” The teams use the same testing tools; however, many test automation tools are utilised to automate the regression test suite. 

Depending on the project type, the following regression testing tools may be used in a combination of the above techniques mentioned in the previous section:

API Heavy Applications

APIs are the foundation of modern software development, especially as more and more teams abandon monolithic programmes in favour of a microservices-based strategy.

• Contract-driven testing is gaining popularity, and rightly so because it avoids regression issues being committed to the repository in the first place as opposed to identifying them later in the process during the testing phase. Understand more about pacts/contracts here. 
• Specmatic is an excellent open-source solution that uses the contracts available in OpenAPI spec format, and turns them into executable specifications which can be used by the provider and consumer in parallel. It also allows you to check the contract for backward compatibility via CI.
• Testing APIs is comparatively faster than verifying the functionality of the user interface. Hence, for faster & accurate feedback flowing across the groups, adopt automated API & API Workflow testing using open-source solutions like REST-Assured, Postman, etc.   

UI Heavy Applications

UI accuracy is unquestionably vital for a successful business because it directly impacts end users.

Even when utilizing the most extraordinary development processes and frontend technology, testing the UI is one of the most significant bottlenecks in a release.

Applitools is a pioneer in AI-powered automated visual regression testing. Their solution allows you to integrate Visual Testing with functional and regression UI automation and in turn get increased test coverage, quick feedback, and seamless scaling by using the Applitools Ultrafast Grid – all while writing less code. You can try out their solutions by signing up for a free account and going through the tutorials available here.

Support & Maintenance Portfolio

Teams responsible for testing legacy applications often experience the need to explore the application before blindly getting started with the regression test suite.

Utilizing the results from your exploratory testing sessions to populate and validate your impact analysis documents and RTMs proves beneficial in making necessary modifications to the regression test suite.

Exploratory testing tools are incredibly valuable and can assist you in achieving your goal for the session, whether it’s to explore a component of the app, detect flaws, or determine the relationship between features.

Non-Functional Testing

Each of the following topics is a specialised field in and of itself, and it is impossible to cover them all in one blog post. This list, on the other hand, will undoubtedly get you thinking in that direction.

Performance Testing

• Performance issues can occur at any tier of the software stack, including the operating system, network, disc, web, application, and database layer.
• Open source regression testing tools such as Apache JMeter, Gatling, Locust, Taurus, and others help detect performance issues such as concurrency, throughput, peak load, performance bottlenecks, and so on throughout the software stack.
• Application performance monitoring (APM) tools are also used by development teams to link coding practises to app performance throughout development.
  

Security Testing

• Zed Attack Proxy (ZAP), Wfuzz, Wapiti, W3af, SQLMap, SonarQube, Nogotofail, Iron Wasp, Grabber, and Arachni are open source security testing tools that help with assessing security conditions such as Authentication, Authorization, Availability, Confidentiality, Integrity, and Non-repudiation. 
• To reap the benefits of both methodologies, organisations combine static application security testing (SAST) with dynamic application security testing (DAST).
  

Accessibility Testing

1. Use Applitools Contrast Advisor to identify contrast violations as part of your test automation execution. This solution works for native Android apps, native iOS apps, all Web Browsers including mobile-web, PDF documents and images.
2. Screen readers – VoiceOver, NVDA, JAWS, Talkback, etc.
3. WAT (Web accessibility toolbar) – WAVE, Colour Contrast Analyser, etc.

Summary

A well-thought-out regression testing plan will aid your team in achieving your QA and software development goals, whether the architecture is monolithic or microservices-based, and whether the application is new or old. You can learn about how Applitools can help with functional and visual regression testing here.

Editor’s Note: This post was originally published in January 2022, and has since been updated for completeness and accuracy.

The post What is Regression Testing? Definition, Tutorial & Examples appeared first on Automated Visual Testing | Applitools.

15% of the world’s population live with a form of disability. That’s equivalent to about one billion people. As we now live in a digital era where everything can be accessed online, we need to make sure that the features we provide are accessible to everyone, including those with disabilities. Accessibility testing is definitely not something new – it’s something that we’ve been trying to do for many years now. Yet until now, the number of inaccessible websites that we encounter are still very high.

The Accessibility Problem

Speaking with different individuals, it seems that there’s still a lack of buy-in from various teams to prioritise designing, developing and testing for accessibility. We’ve all heard about the infamous Domino’s accessibility case. There are regulations out there that state that organisations must have a responsibility to make sure that their products are accessible by people with disabilities. However, based on WebAIM’s accessibility research called the WebAIM Million, where they analysed the homepages of the top one million websites every year, they stated that “Users with disabilities would expect to encounter detectable errors on 1 in every 17 home page elements with which they engage.” From their research, they approximately found 51 million distinct accessibility errors. While the results for 2021 are slightly better than previous years, a significant chunk of work still needs to be done to make sure that the web is accessible for everyone.

There are a lot of available tools out there that can help us with accessibility testing. Giridhar Rajkumar has previously blogged what are some of the accessibility testing tools we can use to help us with testing (Accessibility Testing: Everything You Need To Know). However, the statistics above show that there’s still a lot of work to be done. In this blog post, I’ll explain why designing for inclusivity wins, why we need to talk about accessibility a lot, what we can do to create a culture of inclusivity and how to shift accessibility testing to the left.

Designing for Inclusivity

When we design for inclusivity, everyone wins. Let’s look at an image below to explain this concept.

Basically what we have here is we have a baseball game and a fence separating the people watching it and to also stop people running to the baseball field. Not everyone can see through the fence unless you are tall enough. This represents inequality. To remedy this, on the first image, we can give everyone a box to stand on even if they don’t need a box to emphasise equality. Some people will be able to watch along just fine but others won’t.

The second image shows that some people who are not tall enough can ask for additional boxes so they can watch the game. However, this is bad equity because someone needs to be there to hand out boxes physically which can be seen as an extra business overhead.

In order to not increase business overhead, we can just make the fence see through like in the last image. It still keeps people from stepping into the baseball field and at the same time, everyone can watch the game without anyone handing them boxes. Everyone wins if you think about being inclusive. Rather than seeing this as a cost overhead, it’s now become a revenue generator because everyone, whether you’re tall or small, in a wheelchair or not, can enjoy the game.  

Talking About Accessibility

So why is it that so many teams still think accessibility is a nice to have feature rather than having it embedded right from the beginning? I think the answer is we don’t talk about accessibility a lot. It’s not because our teams can’t code accessible websites, but because there is a missed education around the importance of accessibility which then leads to no consideration at all for accessibility. By educating our teams the benefits of having accessible products, we can get them to understand why we need to include it in the first place. 

We need to educate our teams that accessible products are easier to use and it increases user satisfaction. The more users a business can reach, the better it is for the business since it will have financial benefits. Accessibility is also linked to higher SEO ranking and better quality code. It avoids lawsuits and legal complications and encourages independence amongst all our users.

Creating A Culture Of Inclusivity

There’s all kinds of areas where we can bring value and make things more accessible but it starts from creating a culture first of inclusivity. This book that I read by Regine Gilbert called Inclusive Design for a Digital World, which I highly recommend to everyone, explains how it takes a whole village to make accessible products. It’s not only up to us, it’s up to everyone. 

Accessibility tools are here to help us and it can provide value but if there is no change in mindset and culture, then shifting accessibility testing to the left will be difficult since you’ll get resistance from the business to prioritise it. 

Shifting Accessibility Testing to the Left

In order to shift accessibility testing to the left, we need to make sure that accessibility is part of every stage of the development lifecycle and even as far left as possible from the planning stages. Rather than reacting to it right at the end, proactively discuss it as early as possible and get buy-in right from the start. Get your project managers involved and your leadership team onboarded so they know that it’s a priority and educate them that if it’s left out right at the end, it can be time consuming to fix the accessibility issues and exponentially expensive. 

Shifting accessibility is not just about automation. It’s also about having these conversations earlier on the cycle and trying to influence everyone in your team and the business so that everyone is on the same page.

Apart from early conversations and using automation to catch basic accessibility issues, the following are some of the example activities that you can do to shift left:

• Sit with your UX and Design team and test the design mock-ups. Verify if the general layout is clear and the colours use high contrast.
• Participate in planning sessions and contribute what scenarios need to be taken into consideration. This is where adopting different personas can help.
• Plan ahead on how it should be used by keyboards and screen readers and share that knowledge to your team.
• Participate in code reviews if you can. Semantic tags have built-in accessibility features so make sure that these are used appropriately.
• Try pair testing to catch more accessibility issues earlier on. 
• Integrate automated tests as part of your continuous integration pipelines so you can provide faster feedback to your team.

When accessibility is embedded right from the start, user experience will improve and be simplified and barriers for people with disabilities will be removed.

More Resources

Accessibility can be overwhelming, there are tons of resources out there with lots of information. The Web Content Accessibility Guidelines contain a lot of valuable information but it can be daunting to absorb all that information especially if this is your first time. 

So, what can you do? Start talking to your teams about accessibility! Find your allies and get that buy-in from the business by explaining the benefits. Remember that it needs a shift in culture and mindset. Once you have that support, if your website is live already, it’s a good idea to first see how accessible it is. Have an accessibility audit performed so you can see where the issues are. Start with a single page and acknowledge that it will take time. You won’t solve all the issues at once but that is ok. Every small accessibility fix that you and your team introduce will make it better for someone out there.

If you want to know more about testing for accessibility, check out this free course from Test Automation University – Test Automation for Accessibility.

The post Shifting Accessibility Testing to the Left appeared first on Automated Visual Testing | Applitools.

Often times, when we’re talking about tools to help us with testing, specifically automation tools, we hear a lot of preaching about not misusing these tools.

For example, people often ask how to use Selenium WebDriver – which is a browser automation tool – to do API testing. This clearly isn’t the right tool for the job.

While I most certainly agree that using the wrong tool for the job is not really efficient, I can also appreciate creative uses of tools for other means.

People “misuse” tools every day to meet their needs and end up realizing that while this specific tool was not designed for a particular use case, it actually works extremely well!

For example, here is a clothes hanger. It is obviously designed to hang clothing.

But necessity is the mother of innovation. So when you lock yourself out of your car, this tool all of a sudden has a new use!

Coca-cola was actually created as a medicine but after the manufacturing company was purchased, they began selling Coca-cola as a soft drink.

As if that wasn’t enough of a repurpose, coke can also be used to clean corrosion from batteries! (I should probably stop drinking this ?)

So as we see, misusing a tool isn’t always bad. Some tools can be used for more than their intended purpose.

As engineers, most of us are curious and creative. This is a recipe for innovation!

Visual Testing

I’m working with automated visual testing a lot these days. It’s an approach that uses UI snapshots to allow you to verify that your application looks the way it’s supposed to.

Applitools does this by taking a screenshot of your application when you first write your test, and then comparing that screenshot with how the UI looks during regression runs. It is intended to find cosmetic bugs that could negatively impact your customer’s experience. It’s designed to find visual bugs that otherwise cannot be discovered by functional testing tools that query the DOM.

Take a look at a few examples of visual bugs:

While Applitools is second to none in finding cosmetic issues that may be costly for companies, I began to wonder how I could misuse this tool for good. I explored some of the hard problems in test automation to see if I can utilize the Applitools Eyes API to solve those as well!

Increase Coverage

Let’s look at a common e-commerce scenario where I want to test the flow of buying this nice dress. I select the color, size, and quantity. Then I add it to the cart and head over to the cart to verify.

And here’s the code to test this scenario:

Looking at the shopping cart, we’ve only verified that it contains the Tokyo Talkies dress. And that verification is by name. There’s a LOT more on this screen that is going unverified. And not just the look and feel, but the color, size, quantity, price, buttons, etc.

Sure, we can write more assertions, but this starts getting really long. We have doubled the size of the test here and this is just a subset of the all the checks we could possibly do.

What if I used visual testing to not only make sure the app looks good, but to also increase my coverage?

On line 10 here, I added a visual assertion. This covers everything I’ve thought about and even the stuff that I didn’t. And I’m now back to 11 lines here – so less code and more coverage!

Localization Testing

I worked on a localized product and automating the tests was really tough. We originally only supported the English version of the product; but after the product was internationalized, we synched into the localized Strings that development used for the product so we were at least able to assert on the text we needed.

However, not all languages are written left to right. Some are right to left, like Arabic. How could I verify this without visual testing?

Netflix internationalized their product and quickly saw UI issues. Their product assumed English string lengths, line heights, and graphic symbols. They translated the product into 26 languages – which is essentially 26 different versions of the product that need to be maintained and regression-tested.

And good localization also accounts for cultural variances and includes things like icon and image replacements. All of these are highly visual – which makes it a good case for visual testing.

Using Applitools, writing the test for different locales is not too bad, especially since you don’t need to deal with the translated context in the assertions. And the visual tests will verify the sites of each locale.

Looking at the English-translated version of this website, I can see a few bugs here.

• The Spanish logo is being used
• The image overlay is still in Spanish
• The video captions are also still in Spanish

Trying to verify everything on this page programmatically without visual testing would be painful and can easily miss some of these localization issues.

Cross-Platform Testing

I’m sure anyone who has had to write test automation to work on multiple platforms would agree with me that this is not fun at all! In fact, this is quite the chore. And yet, our applications are expected o work on so many different configurations. Multiple browsers, multiple phones, tablets, you name it!

For example, here’s a web view and a mobile view of the Doordash application.

There are quite a few differences, such as:

• On the web view, the address is on the top row to the right of the menu, but on mobile it’s on the 2nd row and centered
• The site title exists on the web view but is not on the mobile view at all – only the logo
• The search field exists on the web view but only the search icon on the mobile view
• And the shopping cart shows the quantity on the web view but not on the mobile view

Because of these differences, we either need to write totally different framework code for the various configurations, or include conditional logic for every place where the app differs. Like I said, painful!

But the worse part of it all is that the return on investment is really low. I hardly find any cross-platform bugs using this approach. And it’s not because they don’t exist. It’s because most cross-platform bugs are visual bugs!

The viewport size changes, and all of a sudden, your app looks goofy! ?

So what if instead of just using visual testing to make sure my app looks nice, I bended this technology a bit to execute my cross-platform tests more efficiently?

Like instead of a functional grid that executes my tests step by step across all of the devices I specify, what about a visual grid that allows me to write my test only once, without the conditional viewport logic? Then executes my test and blasts the application’s state across all of my supported devices, browsers, and viewports in parallel so that I can find the visual bugs? ?

That’s pretty powerful and yes, we can use visual testing to do this too!

Accessibility Testing

There’s a lot of talk about accessibility testing lately. It’s one of those important things that often gets missed by development teams.

You may have heard of the recent Supreme Court case where a blind man sued a pizza franchise because their site was not accessible.

This is not a game. We have to take this seriously. Can visual testing help with this at all?

Yep, what if we used visual testing to be able to detect accessibility violations like the contrast between colors, the font sizes, etc? This could make a nice complement to other accessibility tools that are analyzing from the DOM.

A/B Testing

A/B testing is a nightmare for test automation, and sometimes impossible. It’s where you have two variations of your product as an experiment to see which one performs better with your users.

Let’s say Variation B did much better than Variation A. We’d assume that’s because our users really liked Variation B. But what if Variation A had a serious bug that prevented many users from converting?

The problem is that many teams don’t automate tests for both variations because it’s throw away code, and you’re not entirely sure which variation you’ll get each time the test runs.

Instead of writing a bunch of conditionals and trying to maintain the locators for both variations, what if we used visual testing instead? Could that make things easier to automate?

Indeed! Applitools supports A/B testing by allowing you to save multiple baseline images for your app’s variations.

I could write one test and instead of coding all the differences between the two variations, I could simply do the visual check and provide it with photos of both variations.

Dark Mode

All the cool apps are now providing a dark mode option. But how do you write automated tests for this? It’s kind of an A/B type of scenario where the app can be in either variation. But the content is the same. So that makes it relatively easy to write the code but then we miss stuff.

For example, when Slack first offered dark mode, I noticed that I couldn’t see any code samples.

As much as I work with visual testing, it didn’t dawn on me that I could use visual testing for this until Richard Bradshaw pointed it out to me. In hindsight, DUH of course this can be tackled by visual testing. But in the moment, it wasn’t apparent to me because visual tools don’t advertise this as a use case.

Which brings me back to my original point…

Misuse Your Tools!

Most creators make a solution for a specific problem. They aren’t thinking of ALL of our use cases. So, I encourage you to not just explore your products, but explore your toolset and don’t be afraid to misuse (but not abuse) your tools where it makes sense.

The post The Many Uses of Visual Testing appeared first on Automated Visual Testing | Applitools.