The DevOps movement details a fundamental shift of who is responsible for software testing, and how testing is carried out. Functional testing has become not only the responsibility of the QA team but also the developers.
As the QA team now focuses on automation of tests, creating testing infrastructure, and empowering the organization to fast track bug repairs, developers, and especially front-end developers, are in charge of delivering the app to QA with quality gates in place.
This post details the 7 steps front-end developers should adopt to prepare themselves for functional testing.
If you a front-end developer and are shaking your head at the idea of taking on functional testing in addition to everything else you are already doing – we get it. You are busy focusing on your code, implementing new functionality and creating apps in a multi-everything environment. To take on new responsibilities is just going to slow everything down, isn’t it?
Well, no.
With the introduction of new testing methods, such as perceptual diffs for visual testing, and new ways to build browser grids without spending time on infrastructure (which is totally boring), functional testing is a much easier pill to swallow, and it’s benefits outweigh any time you spend on it.
So while you might be taking on new responsibilities, you are also increasing release frequency, and decreasing time spent on bugs and regression cycles – since you ship to QA a working product, tested and fully-functional.
You, the mighty FED, are the first line of defense for preventing bugs, which come back to haunt you anyway. When you integrate functional testing into your schedule, you are fast tracking new features because you know better than anyone how tests should run on features you just wrote, which means faster turnaround on releases, and ability to get more in on a release. When done wrong, these things waste more time – your time – a lot more than the addition of functional testing will take from you.
So now that I cleared the apprehension, here are 7 things you, the front-end developer, need to consider with functional testing:
(1) Make sure you have a testing lab.
You do not want to test on your local machine, as this will take the machine away from you. And managing any infrastructure is just a waste of your time. It should be a matter of adding your scripts to a test suite, pressing a “go” button, and when it is done, reviewing the results.
All organizations should have a testing lab, either in the cloud or locally. Ask your QA Automation team for access to the lab, and methods for using it. Or you can leverage cloud-based testing tools like SauceLabs, Browser Stack, or Rainforest QA who provided the infrastructure for you.
(2) Pseudo your tests as you code.
Timing is important and being on top of your test cases is critical. With functional testing you should create your test case when you create a feature. The definition of “feature” can be subjective I know, but it usually relates to a ticket, or backlog item.While features are not tied to one function, they are (should be) clear to you. You wrote it!
There are a few elements you need to note as you write the feature. What are the page objects related to this new feature? And what are the pages (URLS) associated with it? It’s best to have a note-taking app open and jot down in pseudo the details of the test. You will not get the test written at this point, and 70% of this ritual is just so you remember what test cases you need to write. When it comes time to, you can then pound them out.
(3) Segregate your tests into two types: user flows, and visual testing.
The challenge with test automation tools like Selenium is that sometimes you need to know in advance what to test. Channel your telepathy skills. But even if you predict all tests, you can quickly spiral into a never-ending test case if you are not disciplined.
You do not always need to test every detail for some functionality, but for others you do. It relates to your specific application, and what is most important to test in each release. For example new text in a title is not as critical as a new payment button and purchase flow. User flow tests should be more complex, and work on page objects and interactions with those objects. The entire test can be multi-page, and needs to emulate user actions.
While visual testing is very simple to script, all it does is load a page, then snapshot that page. After you have the snapshots you will use a tool like Applitools Eyes to compare the screenshots in order to identify changes in the application from previous builds. It tests everything visually, so you don’t need to predict the test in advance – it alerts you on major changes from previous release.
So for each test know what type of test it is (OK you got me, there is a use case for using both tests together).
(4) Run regression tests.
I know I know, you are thinking, “I’m just testing what is new”. But what is new can very easily break what is old. True, before a release QA will run regression tests, but if there is a problem during their run, guess what, it’s back in your lap anyway. And if that test is run on a weekend, you might be getting a call in the middle of the night. So, hey, it’s a lot easier to just run the tests.
There is a trick in your back pocket if you can get the team on board: Continuous Integration (CI) tools, such as Jenkins, that can run the regression tests for you. Instead of “running tests”, you are releasing to staging.
Someone else will write the regression tests, and it should only be a matter of introducing your new scripts into the suite, which includes the regression tests and hitting the “run” button.
(5) Leverage tools specifically for Front-End functionality testing, such as “Wait” Extensions for AJAX applications, Protractor for Angular Applications, and Capybara for Ruby on Rails application.
There is so much available from the community, but you do need to be careful when you select open source tools. Pay attention to the committers devotion to the project, as many have come and gone, such as WaitForCondition.
(6) Version, share, and plan your testing suite.
Almost all dev teams suffer from script sprawl. Scripts are coming from everywhere, and there is little time to prune old scripts and manage the suite. However, it is important. It should not be just the front-end developers’ job, but everyone should be aware.
Usually, QA will regularly review scripts. Your job, now that you are adding scripts, is to provide visibility into the tests you created, and ideas on what might be prune-able. There are advanced ways to do this automatically, but that is for another time. Without doing so, eventually failed scripts (caused by removed functionality, for example) will wreak havoc on test runs.
(7) Be open-minded.
There will be some storming and norming that goes on in the process of taking on functional testing. But the dust will settle, and once you are in a groove, you will forget it’s even a new process.
It’s coming. Application quality is a responsibility moving closer and closer to those who built the application. Front-End developers will be an integral part of the testing process. But the good news is there are tools and processes that limit its impact. And eventually, make it hugely beneficial.
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.
