People have been creating websites for the longest time. Some may say “HTML is HTML”. Well, not
exactly: websites are now rendered on many different types of devices, browsers, form factors etc. New technologies enable HTML5 to offer content and services according to the user’s context (location, time etc.). At the same time, web development cycles accelerate and sprints are shrinking as organizations adopt agile practices. This article will offer best practices to improve team efficiency and deliver high quality products, while maintaining velocity and competitive edge.
EMBRACE QUALITY ACTIVITIES (AS PART OF WEB DEVELOPMENT)
We’re increasingly observing the fallacy of the separation between web development and quality activities. Defects are often found late, anytime between mid-sprint and production. Developers then spend expensive hours undoing code to correct the issue, creating more QA work, increasing risk, and eventually jeopardizing the app’s success.
The way to address this expensive cycle is to expand the “definition of done” to include some level of code verification. In other words, developers need to run a few tests pre-commit and post-commit to get fast feedback. This is the best, cheapest, and safest time to find a defect: the code is still fresh in the developers’ head, it won’t take long to fix, and there’s no added risk by undoing code that was built on top of this recent code. A high quality
website is the end goal of the entire team, regardless if you are part of the web development, design, test, or ops team.
It’s not to say traditional QA activities would all move into the hands of developers. Load testing, for example, may not be suitable for a development environment, but the more agile the quality activities can realistically be, the better.
To make this change, a few things need to happen:
- Small scale test activities need to be automated and provide rapid value: if a developer committed code, some tests need to be run to provide fast feedback. That process needs to be automated.
- Developers can adopt developer-oriented tests and tools: for example, unit tests with XCTest/Espresso, getting network performance insight using HAR files, or conducting single user performance tests.
- Developers need to learn and see the value delivered, otherwise they won’t do it.
- Taking advantage of the test automation pyramid and implementing more API tests at the expense of UI tests is a way to reduce testing time while practicing agile testing. Another modern approach for web development and testing is to leverage headless browsers for unit testing (i.e. Google’s puppeteer project).
- Don’t underestimate the importance of accessibility for your website. This is becoming a big deal for many reasons, including site SEO, adoption, and compliance. Testing for site accessibility is quite hard to automate on mobile devices compared to the more mature web testing tools. However, the complexity of doing so shouldn’t be an excuse not to do it at all.
Assuming we agree that developers pick some quality activities, the question becomes, “What’s relevant and vital for developers to work on?” Their time is expensive. One area where they should not be working is in a lab (maintaining emulators, browsers, or devices). The effort to maintain a lab can become very time consuming very quickly: the lab needs updates, care, and attention. A proper lab should provide all the means for coverage, automation, fast reporting, etc. The developer should only need to describe the user flows that are important to test (matching
the code they are developing now) and which devices and browsers to test those on. Everything else should be automated.
FAIL FAST, FAIL EARLY
In the spirit of agility, developers will realize that testing (and failing) early beats failing later. As mentioned earlier, it does require investment: (stable) tests need to be written alongside the code, and it will take some time for those to run and create a perspective for the quality of the code committed. However, the investment is well worth it. Knowing within an hour (or less) about a new defect is much better than knowing about it weeks or months later. Even iterating a few times, failing until the right solution is found, is better.
ADOPT COVERAGE APPROACH (INCLUDE MOBILE) AND PRIORITIZE
One of the things to remember is that the website will most likely be rendered on all kinds of devices, browsers, and form factors. The common approach to handle all of these variations is to adopt a responsive web design approach: one line of code serves many screens, but that’s not easy either. With the same code, one needs to offer the right rendering for different device combinations and manage network connectivity to optimize the experience for small and large screens.
The same thinking should be applied to quality activities: they need to consider a prioritized set of browsers, devices, user flows, and environments in which the user is likely to experience. The lab should support all of these so the developer can very easily create test scripts to exercise the code in as many scenarios as possible. The top browsers developers should currently consider in their testing are listed in the table on the top right.
SHIFT LEFT, SHIFT RIGHT: QUALITY ACROSS THE LIFECYCLE
Last but not least is the realization that app quality is something that needs to be a point of focus throughout the life stages of the app: from design to production. Truly agile web development teams are driving the application behavior in production. There are several reasons/motivations to do so, to name a few:
- With the proliferation of client-side capabilities, the client side has an increasingly bigger role in real time incidents, and developers are being called to assist. If they are being called anyway, they might as well own the experience and fix incidents quickly
- It’s easy to do: with a proper test automation capability, it is very easy to apply the same or similar test framework to assets in production.
- It’s valuable: Not only do coders know (and take pride) or their code in production, but they can also benchmark the new build performance against production and improve accordingly
Modern websites are developed and displayed very differently compared to ones developed years ago. Technology (such as HTML5) and processes (agile) present new opportunities to deliver new functionality earlier and at higher quality and functionality to the market. With that comes the challenge of reducing defects in production, which risks the end user experience. With proper measures, tools, and perspective, developers can extend their area of responsibility to embed quality activities into their daily activities in a way that not only doesn’t slow them down, but allows them to develop faster, find defects early, and fix them without undoing code and design.
99 total views, 0 views today