Front End UI Testing Process
Recently, we were engaged to develop and test UI elements for an existing site. Sounds easy doesn’t it? Unfortunately, reality is often the opposite of how we dream it to be.
Let’s not kid ourselves. Front End UI Testing is hard because it is still very much labour intensive. Unlike writing functional tests that can help automate testing, Front End UI testing often requires having the Front End Developer (us), and the client (if applicable) to work in tandem, and test UI elements at drastically different viewports, and on multiple devices!
We came up with a testing process during a recent client work engagement to tackle this issue.
What, and who are we testing for?
Before starting on any engagement, we would need to define the scope of the project. Similar to baking a cake, there needs to be a target or an objective to work towards.
This helps by making sure the client, and us developers are on the same page, and that we would know what browsers we are building and testing for.
Imagine the horror when you are told you need to test for all browsers available!
For this project, the client needed the website to be supported on major browsers including IE 9–11 due to audiences from certain countries where IE is dominant.
Tools of the Trade
Browsers
Our two browser tools for inspecting, and testing code were Chrome Dev Tools, and IE Developer Tools.
Devices
Having actual devices to test would be most ideal, as emulators will never be as accurate as using the real device. However, not everyone keeps a stash of devices around or have easy access to numerous devices. For this project, we had to emulate IE 9–11 on Virtual Box, which surprisingly worked pretty well. We used this tutorial to get our Macs set up with IE 9–11 on Virtual Box.
Task Runners
We use Grunt to build our project. This includes pre-compiling our SCSS files into CSS, adding vendor prefixes, and minification. This frees out our time to focus on testing.
Bug Tracking
For bug tracking, we used the mac screenshot tool (⌘⇧4. Command-Shift-4), and JIRA for assigning, and managing tickets.
Communication
For communication, we had daily sync ups and used Slack regardless of if we worked offsite or onsite.
Services
And the ever so useful caniuse.com to check for cross browser compatibility. This is an essential tool that any Front End Developer needs.
Testing Process
As we were building the UI elements as well, our testing process was a little different. It felt more like a design sprint, and went like this:
Building the UI element & Browser Test
Building the UI element was perhaps the easiest part of the testing process, the more difficult bit was actually deciding what CSS feature to use; should we go for display: flex, or use floats instead? A lot of time was spent on making decisions on the structure of the element, and the CSS features that accompanied it.
We used a lot of caniuse.com to help with this decision process. As we built UI elements, we quickly learnt that by casting our net wide and going for the CSS feature that covers the most number of browsers, it would speed up development as we would only need to inject browser specific CSS to ‘fix’ them on older browsers.
At the browser test, we would test the UI element on different browsers as required by the project. If the element works on IE 10 or 11, we would give it a ‘Pass’ as it meant it would work on the modern browsers, and we would only have to fix it on IE9.
Our mantra was that if it works in IE9, it ‘should’ work on all modern browsers
Describing & Squishing bugs
We used JIRA to keep track of existing bugs, and with the ever so helpful Mac screenshot tool to take image snippets of the bug.
Any fool can write code that a computer can understand. Good programmers write code that humans can understand. — Martin Fowler
We followed a strict naming convention when creating tickets.
[Project Name][Page Name] — [Brief Description of Bug]
[Detailed Description of Bug and Screenshot]
Below’s a real bug from the client’s site, that we have since fixed 😄
[Marketing][Book a Tour] — Input labels overlap input fields in IE9
Input labels overlap the input fields in IE 9, see attached screenshot.
This naming convention meant it would be easy for us Developers to know what the bug is, without having to go too much into the specifics of the bug.
If a bug ticket was opened by a client, we could easily consult them face-to-face if we were on-site, and check via Slack if we were off-site. This way, they could show us how to replicate the bug, and we would be able to tackle it easily.
Instead of having a bunch of bugs crawling up to us, we were able to quickly deal with them with minimal technical debt.
Summing up
Testing is a critical and necessary, yet often overlooked and under-appreciated process in front end development. It should be accounted, and budgeted for during the planning phase in any project, as to avoid running over the timelines.
Knowing what to test for is also essential, as it sets the scope of the testing process, and shapes the boundaries of testing that the developers would need to keep to.
Through testing, communication and close collaboration, you are able to avoid most bugs, and avoid getting the dreaded client calls asking why an essential feature on their site isn’t working, and have the confidence that the site you have helped built is fully tested and working.
Minitheory is a digital design studio based in sunny Singapore with a particular focus on UI and UX design. We make software simple, based on how people think and behave.
