One might say quality control of PSD to HTML conversions is like playing the Game of Difference. But isn't there more than meets the eye?
“Code gathers, and now my watch begins. I shall not end until 5 p.m. I shall take no excuses, hold no errors, father no bugs. I shall wear no nerd t-shirts and win no prizes. I shall live and die at my desk. I am the click in the browsers. I am the watcher on the monitors. I am the fire that burns against the glitches, the light that brings the adjustments, the horn that wakes the developers, the shield that guards the realm of pixel perfection. I pledge my life and honor to the Quality Control, for this test and all tests to come.”
The Quality Controller Oath
One might say controlling quality of PSD to HTML conversions is like playing the Game of Difference, which is about, well, finding differences. In this case, the difference between a non-interactive image and an interactive website. But how do you make sure these two are identical when at their very core, as the statement above suggests, they are most likely not?
Boisterously saying, by weaving the digital soul out of code, a developer breaths life into a design. You cannot really compare a non-responding entity to a responding entity. Finding visual differences between them is important, of course, there is value in making sure they look as close to identical as possible. But being a good Quality Control Engineer is more than spotting visual differences.
It’s about inventiveness
Some may say that “browser checking is the heart of the Quality Control process”. Assuring the page displays and behaves similarly across browsers is as important as having it almost mirror the design. But the most important goal of a PSD to HTML Control Engineer is to ensure a perfectly functional, well-working website. Not an easy goal to meet; achieving it is much more than finding visual differences and tracking bugs. It is about contributing with ideas of reasonable adjustments and feature improvements. For that, you need to posses a very particular set of skills and traits.
Let’s look at the concept of an engineer. An engineer isn’t just a person who measures something (in this case, measuring conversion precision).
“Engineer” derives from ingeniare, which means “to contrive”; and from ingenium, which means “cleverness”.
Measuring with cleverness is the core of PSD to HTML Quality Control.
It’s about intuition and looking closely
Quality Control workflow is like peeling an onion
Think about the website Quality Control workflow as peeling an onion (and yes, sometimes crying can be part of it). You start with what seems to be the easy part; the outermost layer. Then you continue peeling off layer by layer, searching for functional bugs, before you get down to the deepest core: the code itself.
Let’s begin with outer layer of the website. Imagine you receive a website from a developer known for high quality deliverables. You have a good foundation to assume this page is going to be nicely cut. A first glimpse at the files confirms the high quality.
So, what do you do next?
Do you start comparing the site to the design with a light heart, assuming it’s won’t take much time since the code seems to be high quality?
You convince yourself that, even if the developer might be a god of code, this page has at least one bug. At least one adjustment that needs to be made. Only then you start testing the site. If you don’t think a bug is hiding somewhere, you won’t find it.
You have to WANT to find a bug.
Is there a particular procedure to finding bugs? Every Quality Control Engineer has their own workflow. But it helps to keep in mind that bugs can be divided into at least two categories: visual and functional.
Some visual bugs are immediately visible to the bare eyes. Others may require a special tool like X-Precise to reveal. Some requires intense focus to uncover. And then there are the plain lucky discoveries.
Bugs most often get caught during repeated cross-browser tests, when the site is looked at over and over again to make sure that the visual and functional experience is as expected and required.
It’s about patience
Once you understand that, you will not only look at the site closely, you will look at it over and over. And that is why you need to possess an endless amount of patience to be a successful PSD to HTML Quality Control Engineer. You’ll repeat the same process multiple times and more everyday.
You need to possess an endless amount of patience
And even after the laborious work of finding visual differences if finished… a Quality Control Engineer’s job is not done.
Because the second wave of bugs you are going to exterminate are functional; those that will break the overall layout of a website. These are the sneaky ones! To find them, you need at least basic knowledge of the mechanics that power the website. And you need intuition.
And the more breakpoints site has, the more grey hair you will grow.
It’s about precision
On your journey as a Quality Control Engineer in the world of web development you may encounter projects that aren’t coded with the greatest diligence.
Developers need to do their own tests before handing projects to Quality Control. The reason is simple: it saves time. For the developer. For the Quality Control Engineer. And most importantly, for the customer.
It usually does not require a lot of effort for a developer to, for example, perform a cross-browser check on their own. While doing so, many bugs can be spotted and fixed off-hand. It is in the developer’s best interest to do a sanity check of their own work. The less issues reported back, the faster a developer can move on to the next project, or spend time on tasks more fun than fixing buggy code!
When it comes to responsive sites, it is essential for a developer to perform tests on real phones and tablets. Emulators rarely do justice. But in an era of devices equipped with infinite versions of screen sizes and viewports, one has to take measures to minimize the chance of bugs slipping through.
Use your mouse as a surgeon uses their scalpel
Bugs characteristic to responsive sites are usually centered around breakpoints. If you want to spot errors while your initial testing takes place on desktop browsers, use your mouse as a surgeon uses their scalpel during viewport resizing. You have to do it slowly, with great precision, continuously scanning the site with a focused eye. Sometimes bugs delight themselves in hiding at the very exact viewports. One – yes, one – pixel can make a difference between the bug appearing or not. And when this is the case – OK, you can’t really blame a developer. Easy one to miss! But when you see that the site is falling apart, feel justified to release your blazing wrath… and politely ask the developer to have another look at their work.
It’s about trying to break things
It is crucial to familiarize yourself with the project requirements before you start testing. All expected functionality is listed and explained there. Once you know what kind of technology is used for a certain part of the site, you are not only going to know where to look, but how to look.
Testing sites is about trying to break them in the most creative ways
Testing sites is also about trying to break them – in the most creative ways. The more creative you are about finding new ways of breaking the site, the bigger the chance of triggering unexpected bugs. As we are not an omnipotent beings, and computer programs sometimes tend to act like they have a soul of their own, not even testers with the greatest knowledge can find all the bugs. And this is when luck comes to play its part. Just as during castle siege you may be victorious just because enemy commander slipped on the stairs (OK, it might not be that simple, but you get the point!), during website testing you may spot a bug only because you performed this crazy chain of actions no one would – potentially – ever repeat.
Therefore don’t let this always present, elusive, missing percent of Quality Control effectiveness bother you – some things will remain hidden before you, and you need to deal with it.
But, as stated above, that should not stop you from keeping yourself on your toes when it comes to finding the most perfidious ways of ruining this beautiful piece of code art the developer put on your plate.
It’s about being polite, but firm
Finding a fix or providing an adjustment to code can sometimes be a challenge for a developer. Even if he or she states it’s been done, on occasion, it may not be. Therefore it is not only very important to verify fixes, but also not to let yourself to get overwhelmed by the feeling of being stroppy. This job requires you hanging on to the details which may not be as significant to others as they are to you. You may think developers are going to hate you after you have reopened a task for the 10th time, because, well, a pixel is missing, or the breakpoint still needs some adjustments. Of course – common sense before vain perfection, but when you know you have a point – keep executing your requests. Be firm about this, but always polite.
It’s about multi-tasking and being well organised
There will be days when you may find yourself in a crossfire of tasks. When there are so many projects to be checked that is seems overwhelming. More than that, during the work day someone may ask for a help with a very urgent thing. This is when you need to suspend your focus on current stuff, put everything into the back of your mind for a while, and do what the situation requires to be done at that exact moment. Such days and such situations require not only prioritization, but also multitasking. The ability to switch between projects and conversations upon request. This kind of workflow (frequent context switching) isn’t for everyone.
What is quality control NOT about?
Before joining the ranks of XHTMLized I asked some of my developer friends about PSD to HTML Quality Control process. They would provide answers such as: “Well, they will give you a design – and they will give you a website. You have to make sure the latter looks exactly like the former. Easy job, man!”
So I asked myself: “Easy? Sounds more like boring.”
During my time at XHTMLized I was proved one thing for sure: they were wrong.
And, fortunately, so was I.
About the author
Related blog posts
In this article, I’ll show you how you can design your own Quality Assurance Scoring System based on the criteria we used in my previous article Code Quality Assurance Checklist: 8/20 Rule.
In PSD to HTML conversion, what defines front-end code as being of top quality? We follow 8/20 Rule here at XHTMLized – 8 areas consisting of 20 criteria the code has to pass in the code quality assurance process. What are those?