Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Five Best Practices to Ensure Stellar Website Introduction

DZone's Guide to

Five Best Practices to Ensure Stellar Website Introduction

In this article, we look at what you as a web developer can do to ensure that your team's new application gets off on the right foot.

· Web Dev Zone
Free Resource

Learn how to build modern digital experience apps with Crafter CMS. Download this eBook now. Brought to you in partnership with Crafter Software

This article is featured in the new DZone Guide to Web Development. Get your free copy for more insightful articles, industry statistics, and more!

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, 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 a competitive edge.

Embrace Quality Activities (as Part of Development)

We’re increasingly observing the fallacy of the separation between dev 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 developer's 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 dev, 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 to web dev 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.

Focus Vigilantly

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 rightsolution 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 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. 

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 dev 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 clientside 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 frameworks to assets in production.

  • It’s valuable: Not only do coders know (and take pride) of 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 perspectives, 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. Formore advanced reading, please refer to Earn Kinsbruner’s ebook, 10 Test Automation Frameworks for Cross-Browser Testing –A Comparison Guide for 2017.

This article is featured in the new DZone Guide to Web Development. Get your free copy for more insightful articles, industry statistics, and more!

Crafter is a modern CMS platform for building modern websites and content-rich digital experiences. Download this eBook now. Brought to you in partnership with Crafter Software.

Topics:
web dev ,web application testing ,agile web development team

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}