To better understand the Applitools Storybook SDK for Angular, here is a tutorial on how to build a small AngularJS application from scratch, adding some Storybook stories, and then finally performing visual regression testing using the Applitools SDK to generate snapshots for us to view and analyze.
You can find the source code for this article on GitHub by following this link storybook-angular-applitools repo.
I’m pleased to announce that Applitools has released Root Cause Analysis, or RCA for short. This new offering allows you to instantly pinpoint the root cause of visual bugs in your front-end code. I’d like to explain why RCA matters to you, and how it’ll help you in your work.
Well, maybe RCA doesn’t find THE root cause. After all, all software bugs are created by people, as the Dilbert cartoon above points out.
But when you’re fixing visual bugs in your web apps, you need a bit more information than what Dilbert is presenting above.
What we’ve seen in our experience is that, when you find a bug in your front-end UI, you need to answer the question: what has changed?
I regularly use Jenkins CI and GitHub to help our customers integrate Applitools into their continuous integration workflow. Even though I’m pretty familiar with both tools, there’s one thing that drives me nuts.
Here’s the problem:
I can’t see Jenkins build status in my GitHub repo pull request. Below is a screenshot of a typical GitHub pull request. As you can see, there’s no indication of my Jenkins build status.
This forces me to leave GitHub and go to Jenkins every time I merge, just so I can check the build status.
Doing this once is no big deal. But after doing this for a hundred pull requests, I feel like pulling my hair out. (And that would just look weird.)
There’s a new claim to the throne of functional test automation tools: Cypress.io. Is Cypress fast? Yes. Is Cypress interactive? Yep. Is Cypress reliable? You bet. And best of all… it’s cool!
But is Cypress an alternative to Selenium WebDriver? Does Selenium, the current king of web automation and testing frameworks, cringe in fear for its position, or is it smiling benevolently at the supposed usurper, knowing full well that, well, it’s just a kid!
Is Cypress better than Selenium WebDriver? I get asked this a lot. And frankly, the easiest path of a “this vs that” article is to try and find out which is “best”. But I will not take that path. Instead, I will try and explain how is Cypress different from Selenium WebDriver.
React is, first and foremost, a library for creating reusable components. But until React Storybook came along, reusability of components between applications was very limited. While a library of common components could be created, it was very difficult to use, as there was no useful way of documenting it.
Yes, documenting the common components via a Readme file is possible, even useful. But a component is, in its essence, something visual. A Readme file just doesn’t cut it, neither for a developer and definitely not for a designer that wants to browse a library of shared components and choose the one that fits their purpose.
This limited the usefulness of React’s component reusability.
And then React Storybook came along. React Storybook has changed the way many companies approach React by allowing them to create a library of components that can be visually browsed so as to be able to pick and choose the component they want:
Some questions I get asked a lot from customers are: Can I automate visual testing of videos? What are some techniques for automated video testing? What software testing tools should I use to test video?
They’re asking because manual video testing can consume a lot of time — hours, if not days. It can be a bottleneck in your testing efforts and slow down release cycles.
My answer: you CAN and should automate video testing! In this post, I’d like to show you how.
You know what’s crazy about software?
It’s the fact that, for many businesses, applications are a big revenue driver — maybe even the ONLY revenue driver. But we have no system of record to manage the development of our application user interfaces.
Let me explain.
Suppose your company’s revenue drops off. You learn that over the past quarter, revenue coming from mobile app has declined significantly.
Take a guess: how long have we been dealing with software bugs?
It’s not 30 years, around the time Windows was first released.
It’s not 48 years, the start of the Unix epoch.
It’s actually much longer. 71 years and 2 days, to be exact. Here’s why.
Back on September 9, 1947, Grace Hopper, a Harvard computer scientist, was running tests on a calculator and found calculation errors. She did some investigation and found a moth that had landed between two solenoid contacts, shorting out an electromechanical relay. Apparently, the bug had been attracted by the warmth of the machine.
We now commemorate this occasion every September 9, Tester’s Day.
As you can see in her logbook entry below, dated September 9, the actual offending month was taped to the page. So not only is the first known example of a software bug, it’s probably the most tangible example of one as well.
Applitools’ Angie Jones up for Test Automation Expert of the Year in Tricentis’ 2018 Testing Heroes Awards.
First thing’s first – we’d like to formally welcome Angie Jones to the Applitools team as our Senior Developer Advocate! Exciting things are certain to come with her on board so stay tuned for more news soon.
In the meantime – we are thrilled to see Angie on the shortlist for the Tricentis 2018 Testing Heroes Awards. The annual Testing Heroes Awards (#TestingHeroes2018) recognize the outstanding individual contributions within the software testing community, and awards Tester of the Year, Test Manager of the Year, The Explorer, The Performer, The Automator and The Risk-o-Meter. Nominations are closed and voting for the finalists is now open.
The other day, I was supposed to meet a colleague for drinks at the local bar. He was a bit late, as he got delayed at work. When he arrived at the bar, after a drink or two, he asked if I could take a look at the problem he had. “Sure, why not,” I said.
First, some background: we’re both in the testing business. I am a software developer at Applitools where I develop visual UI testing software tools based on artificial intelligence algorithms. My friend is a test automation engineer working on automated testing in a web SaaS company. One of his responsibilities is to make sure new versions don’t have any unexpected bugs. Read more…
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.
Until the late 1960s, no one thought computers needed a user interface (UI), and the UIs that did exist were expensive and primitive. At the time, these UIs were being used by the military for air defense systems, were built as academic research projects, or were used as props in science fiction movies.
All organizations that build software realize that testing is an integral part of the software development process. Like many important tasks and processes, it is not fun. When we are assigned testing tasks, we regard them as an unwanted burden.
Many people think of GitHub as a niche website that hosts open-source projects. In June 2018, that niche website with a mere 28 million users got more media attention than Apple’s Worldwide Developer Conference (WWDC). Somehow, a site that provides free services was so valuable that Microsoft acquired them for $7.5 billion US dollars.
The QA team is the last frontier before your customers get their hands on your latest product version. Assuming your testing team has already completed smoke testing, integration tests, functional tests, end-to-end tests, acceptance tests and performance tests (not necessarily in that order) there’s still one piece of the puzzle: visual UI testing of your app front end.
The way many companies visually test their applications using image comparison tools. Some of these are free and some are paid. But in either case, these tools are not always reliable and often deliver false-positives (false alarms) that only frustrate both frontend developers and testers, and ultimately making you ship software late.
As a genre, fantasy is often looked down upon by fans and writers of science fiction. There are some who argue that the worlds created by JRR Tolkien were influenced by the events of the early twentieth century. No matter how you interpret his works, one of the central themes of The Hobbit and The Lord of the Rings that remains timeless is that if you come into possession of and use something powerful, like an all-powerful magic ring, you should be prepared for the harm it can cause.
Before we get too carried away with Tolkien references, this post is about visual UI testing, not hobbits. Similar to Tolkien’s central theme, the goal of this post is to inform you that any time you use visual UI testing, you should consider the broader issues it involves. Specifically, this post explores the reasons why developers who use visual testing need to think about more than simply testing the parts of a web app that they can see. It’s the things you cannot see that will trip you up, not the things you can see. Many of these unseen page elements have very little to do with the application itself or its underlying code, but are caused by the display technologies that are used to present the application to users.
This post explains how the hardware and software technologies that are designed to make displayed content look better will cause your visual tests to fail. We also offer Applitools Eyes as a solution that can help you avoid these problems and their consequences.
Every morning, just before we leave our house, my seven-year-old daughter and I love to spend a few minutes playing the spot-it game located on the last page of our local newspaper. She always spots all the differences before me, and it makes her day knowing that she won. (Plus it makes my day seeing her glow, knowing that her day started on the right foot.)
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.
In the days before web applications, programmers wrote applications for a specific platform and used that platform’s native development environment and user interface controls. Before the application’s final release, a tester would check that the application was ready. Some testers wrote elaborate documents that described complicated scenarios they performed on the software manually. Other, more adventurous testers used fancy tools that were the quality assurance version of Microsoft’s Word and Excel macro recorders. A tester would record a series of actions on the software under test. These steps were recorded in a high-level language in which the tester could edit the code and add test conditions that would verify that the actual results of the test matched the expected results. Each time a test was run, a report was generated that showed which conditions had been passed or failed.
It’s not often that software testing makes the news, but when it does, it’s usually because something within the test automation has gone spectacularly wrong. At 8:05 AM on January 13, 2018, the Hawaii Emergency Management Agency sent out a false missile alert. While there is much that is still unclear regarding exactly what happened, most reports agree that an internal test was treated as a real event. According to The Washington Post, part of the problem may have been caused by a human operator who chose the “Missile alert” instead of the “Test missile alert” from an application menu.
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.
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.
It is probably safe to assume that any developers reading this article are already testing their applications. At the bare minimum, you’re testing the feature you’re working on as you develop it and checking that it works with any existing code. Many of you are probably using some form of automated functional testing as well. These types of testing are certainly important and they help to ensure that your applications work as expected, but adding visual testing into the mix will improve your testing significantly.
Today, users access applications in a variety of ways, including wearables, smartphones, tablets, laptops, desktop PCs and an increasing range of smart devices. Now, developers need to account for the ways in which these new and diverse technologies change how their software is presented to and perceived by their users. The typical forms of testing we’ve relied upon for so long simply can’t detect the problems that may exist on every possible device. This is why developers now need to test the visual aspects of their applications. In recent years, developers have started using visual testing methods, tools, and frameworks to meet these new challenges.
In this post, we make the case that it’s wise to use visual testing. Even if you, your team, or your organization are old hands at automated functional testing, we’ll explain why you should add visual testing into your existing infrastructure. We also offer advice about available tools, frameworks and solutions that will help you get started. Whether you’re a novice developer or a seasoned veteran, the information presented in this post will help you deliver the best experience for your users.
At an industry event recently I had the opportunity to listen to a keynote by Janet Gregory, co-author of “Agile Testing” and “More Agile Testing”. During the talk, Janet asked the audience to pair up. One person stood facing the stage and projected slides, the other to face away. The person facing the slides was to tell their partner what they saw. They had 5 minutes to describe in every detail what was going on in the picture. The person facing away was told to visualize it. To try to remember and visualize every detail spoken to them.
When the clock ticked down and the five minutes were up. Janet asked the folks facing away from the image if they thought they had a good visualization of the image. Of course they did, they’d just heard 5 minutes worth of words detailing it.
Then she asked everyone to look at the image.
Traditional software products render essentially the same on any device. Microsoft Office, for example, looks the same on every personal computer. Imagine taking Microsoft Word exactly as it runs on your desktop, and viewing it on a iPhone4. Either the menus and buttons will appear tiny, or else you’ll only see a corner of the screen, and need to use extensive scrollbars. Either way, the application becomes essential unusable.
Many years ago, I heard a senior executive at one of my companies make a statement that changed the way I would think about things for a long time. The statement was so common sense that I wish I had thought about it on my own. He said that regardless of the benefits of being an executive, regardless of the financial freedom he had experienced, the most important thing that becoming an executive gave him was TIME.
He stated that years earlier he would put a lot of hours into his work, only to find that when he left work, he had so many things to take care of: yard work, maintenance around the house, vehicle maintenance, remodeling and repairs, cleaning, and keeping things up to date.
The agile development movement is making testers shift their tests to the left. From a practical perspective, this means that the testers are getting closer to the frontend developers, and the testers’ automated tests need to be integrated with the developers’ tests (I discussed this in considerable length here, if you’re interested).
This is interesting. The shift-left movement now ties together the tester’s tests and the developer’s tests. This begs the question — should the tests be written in the same language?
I will try to convince you that answering yes to that question has many benefits to both sides.
In a previous blog post of mine “Embracing Agility: A Practical Approach for Software Testers”, I discussed how an agile team changes the role of the software tester. Instead of being a gatekeeper that tests the product after it is developed, the software tester is part of the development process.
I also described how the shift-left movement enables the software tester to concentrate on the more interesting tests, and leave the boring tests (“this form field can only accept email addresses”) to the software developer. But those interesting tests, at least the ones we decided to automate, need to be written, and written quickly.
In this blog post I will discuss a technique whereby you can use visual UI testing to make writing those tests much easier. Read more…
While everyone knows that printed newspaper sales are dwindling, the interesting story is in online subscriptions, which are exploding. Electronic Medical Records (EMR) are becoming the new normal, eliminating lookup, replacement and a whole lot of printing. The Plain Old Telephone system (POTS), which phone poles and a separate physical wire into the house are falling into disrepair but anyone under 30 is unlikely to notice because they do not have a physical landline phone.
The digital transformation is in full swing and the consequences are everywhere.
Can software testers help smooth digital transformations with visual UI testing?
I think so.Read more…