Front-end Developers represent the creative arm of the development world. Their code is closest to the users, and often the most scrutinized. They are usually artists, or connoisseurs, in user experience and engagement. And because they tend to be more creative, the “boring” tasks, such as functional testing, bug fixing, and reporting, are not considered the best part of the job.
That is mainly because testing has been presented in a “do your homework” kind of way. Actually, functional testing can enable the front-end developer to execute faster on new and awesome features, and spend less time fixing bugs. This is the dreamland of focusing on steps forward, not backward. Simply put: front-end developers without functional testing equals a lot of bad weekends.
Bad releases don’t just disrupt the lives of the QA and DevOps teams. They ripple their way back to all the developers responsible for creating the release. Have you ever had a weekend-release destroy your time off? It probably is more common than any of us care to admit.
We Value Your Call; Please Hold the Line While We Pass it to QA
And the bad news for FEDs like you is that there are more and more bug-hunters like me out there. I love finding bugs in applications. I do not do it for the purpose of sticking it to a dev team, but because if I’m using a product, it probably means I’m a fan. And if I am a fan I want to make it better. So if I find a bug, I tend to just look up the developers on LinkedIn and let them know.
On the other end, however, is the developer, possibly raging with annoyance, and I am always surprised when the response to my submissions is: “thank you, I will pass it to QA”. The time waste seems phenomenal. Can’t this complex (and unnecessary) feedback loop be avoided?
Bugs go to QA for validation, then to a ticket in backlog, then to prioritization, and finally back to the developer who created it. This can all be avoided. But the crazy thing is that in this loop it usually never reaches the front-end developers when they are cleaver about avoiding bugs by looking for functionality down the road that will overt it.
Coding – the Boring Kind…
I get it, because I have the exact same behavior. I hate backtracking. It is like pulling teeth to re-read my emails or blog posts even (if you find a typo, don’t tell me), much less my code. But I also know that addressing the problem head-on, means less work later. But that is still not very exciting.
The real problem is not that the front-end developer doesn’t care. It is that many functional testing tools require you to do even more coding, the boring kind, and you have to think about the things to test in advance.
So you essentially have to write your code, then write a way to test the same code, it’s just like re-reading an email before you send it, in the same compressed time window. I think this is the definition of burnout. To make things worse, most testing tools test functionality through the front-end, but not the front-end itself, which causes the visual cases being missed, and you get a bug anyway.
That is why it’s important to find a testing tool that allows you to test without any additional steps. And really test what you created, the front-end, not just business logic. It’s not a unicorn, trust me: those tools do exist.
Perceptual Diff to the Rescue!
First off, it might not be as complex as it seems. Because modern test automation frameworks such as Selenium have JavaScript bindings, they allow the front-end developer to implement their tests using their existing dev tools and programming language. Not need to learn a new tool, or add another application to work in.
Next, the tool should do a lot of the work for you. It should know the pages added or removed from your application, and have a baseline of the ones that already existed – and approved. And it should allow you to test without thinking in advance what the tests would be.
The way to do this is leveraging perceptual diff. All you need to do with this approach is review the differences that pop-up, accept them if they are correct, and address them immediately in code if they are not. This takes 1/10, if not less, of the time originally needed to create detailed testing scripts, and it means a whole needless procedure avoided by your QA (faster releases makes friends), and more importantly: happy customers enjoying your bug-free apps.
No More Facepalms!
Testing allows you to fix and release features faster, without additional effort in creating tests or writing more code. Smart testing is all about bypassing – at the FED-level – bugs that might have been created in new versions, overlooked in previous versions, or even help you address that awesome feature that you have been itching to write but keeps getting pushed on the roadmap.
Functional testing can mean no more wasted weekends and no more facepalms while creating Selenium testing scripts. Build your app, run your tests, review the exceptions, and move on to your next wicked feature, with fewer – a lot fewer – disruptions down the road.
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.
