The target date is almost always important and firm. In managing website design and development projects for over half of my career, I have become very familiar with timelines that clients desire, especially tight timelines. As an agency, we’re always doing our best to hit and exceed client goals, but there are times when it’s a bad idea to rush your website project.

A website design and development project typically takes 12 weeks (or more) from initiation to completion. There are various phases throughout a project life cycle that are critical in ensuring a performant and secure website that delivers what the client is expecting. When you rush a website project to hit a particular goal date, you risk a lot.

Discovery is so important.

Rushing a website project typically means starting the development phase ASAP. This is a huge mistake.

The discovery phase of a project provides time for the Engineering Team to explore requirements with the client, research and plan. Planning is crucial to a successful project. We typically dedicate one to two weeks for the discovery phase a project.

The first week involves discovery calls with the client to gather information and requirements, as well as reviewing the scope and researching. The second week involves defining a development path, planning tasks and outlining a project plan for the client to review. Without a solid plan, you risk issues with development, confusion around client expectations, and ultimately not hitting the rushed timeline. Take time for discovery and planning, even when there is a hard deliverable date.

Processes (like code reviews) are in place for a reason.

Tight timelines on website projects usually force Project Managers and Engineers to look at the project life cycle, processes, etc., and see where they can cut corners in order to hit a date. Again, this is a huge mistake. Would you purchase a house that was built with steps skipped and corners cut? Of course, you would not. Why would you do that with your website?

The project life cycle is what it is. You have to plan, build, review the quality and prep in order to be successful with a website project. Similarly, the development phase standard processes are in place for a reason, and chances are they are well-thought through to make certain that the product produced for the client is successful. Cutting corners, like skipping code reviews, is not an option.

For example, we ensure every of line of code written at WebDevStudios follows the WordPress coding standards as well as our own internal standards, and we wouldn’t want our name on a product that wasn’t superb. We have a code review process in place that allows a Lead Engineer time to review the code and test features.

Every project timeline that we set, or agree to, guarantees that we allow time for this step. It’s important to verify the development work being done meets standards. Processes are meant to be followed even with tight timelines, and if there isn’t time to do things like plan or review code, then the timeline should shift to account for these key steps.

Quality assurance and testing cannot be eliminated in order to hit a target launch date.

It may sound crazy, but I have managed a few projects where the client wanted to wave the quality assurance and user experience testing in order to get a site launched for an important target date. If at all possible, please avoid this.

QA and UAT are extremely important. The QA phase gives the Engineering Team an opportunity to discover any design issues and development errors, while cross browser testing on a variety of devices. Additionally, it’s important to take time to run performance testing on the clients hosting environment before deploying to production. Without these quality assurance tests, you risk running into bugs post-production that can be costly.

We understand that project timelines are important. Consider the target date no different than a goal. When discussing the goals and target dates, be flexible. The Project Manager will always provide the best project timeline that works toward the goal, and if it doesn’t quite hit it that target date, they will have a valid reason why. Avoid rushing your next website project if possible, and I assure you, it will be more successful!

The post Why It’s a Bad Idea to Rush Your Website Project appeared first on WebDevStudios.

QA and UAT are review processes that are done during a web development project to ensure design and functionality requirements are met prior to a production release.

When you spend weeks, or even months, on a project only to wind up with a handful of QA issues (that you should have caught the first time around), it is easy to feel discouraged. You can receive QA feedback for scenarios you did not even think about the first time around. The person performing QA isn’t intending to discourage the developers. QA and UAT are intended to find the obvious issues, and the most nit-picky annoying ones that no one thought to test.

The goal of QA and UAT is to break the site… the code.

Self-QA

A major part of the QA process during development is doing it yourself. Remember that you, as the developer, are responsible for being the first set of eyes reviewing your code. Unfortunately, you can code a feature for so long that you become blind to obvious issues.

Slow down. We do have deadlines to meet, but a quick break from your code can really help. Taking a lunch break, stepping away from the screen for a few minutes, or even working on another task for a bit can get you refreshed for self-QA. You’ll be able to see the little things you can clean up, fix, or completely change for clarity, because you’ve taken a quick break from your code.

Another method of self-QA is to take the feedback you received at the end of your last project and apply it to new code. Do you consistently receive the same feedback on issues when a formal QA is done? If so, keep track of that feedback and include it as part of your initial development.

Peer Review

When you need a second pair of eyes, use your peers. If you’re building a large feature, using a new skill set, or just want some additional feedback on a task before turning it in for final review, grab a peer to review your code. If you’re working with a team, lean on them to make your code better and expect them to do the same with you. We should all have the same goal, produce the best possible product by writing the best possible code. 

Here at WebDevStudios, we have a system in place for our peer reviews. A developer will work on a feature and pass it to a senior developer for the initial round of code review. If everything passes their checklist, they pass it onto the a lead developer for final review and scrutiny.

A senior or lead developer may not have all the skills to get your code up to par. This industry changes so rapidly that no single developer can truly know everything. If you see code that a senior or lead developer can improve upon, let them know; and hope that you work in an environment, like WebDevStudios, that encourages knowledge sharing.

Formal QA and UAT

Once self-QA and peer review has been completed on individual tasks within a project, it’s time to do a full project QA and UAT review. This process will most likely be unique to your company or team structure. The general process is that an individual, or team of developers, reviews the entire site to perform visual and functional QA.

Visual QA and functional UAT processes may be completely separate from one another. Comparing a page in the browser to the mock-up, and running through a specific set of functionality, like new user registration, are two entirely different things. It is critical to perform both QA visual review and functional UAT.

As a freelancer or company, you also need to define your own pass/fail scenarios on visual QA. Do you want to strive for absolute pixel perfection, or is it okay for the placement of something to be off by two pixels? Will it be important to the client to take the time to take screenshots, write up a task, have it assigned out, worked on, and finally reviewed?

What isn’t subjective, though, is whether or not a thing actually works. This is where a strong-handed UAT comes into play. Before you can have a solid UAT process, you need to have a solid process for documenting how something should work. This can be either with user stories defined by the client in the project plan itself, or documentation written as the project progresses. If user stories are in place from the beginning, that means each developer knows exactly what they need to do in order to complete their work. Providing user stories can be a major cornerstone along the QA and UAT process.

Client QA

Once an internal formal QA and UAT is completed, it’s time to hand off the completed project/site to the client so they can run through their review and testing process. Each client is unique and will have their own QA and UAT review processes to ensure their site is functioning as expected, per the proposal, prior to a production release.

Clients are typically able to find bugs when they run their QA. Clients have very specific ideas about how things should look, function, and how they should be able to interact with elements on the site. Certain features or functionality may not have been conveyed in static mock-ups. For example, the way images or links hover, or how unique sets of content resize for small screens. This is where user stories can help to eliminate some of that disconnect between static mock-ups, and a fully functioning website. When clients find bugs or issues based on expected functionality, we consider this a learning experience. We have the opportunity to improve our processes so that we can improve on assumptions for the next project.

Conclusion

There are so many methodologies around what we do and how to do it more efficiently – whether it’s making sure your code is as clean as possible, or that your functions do just one thing. These are hallmarks of being a solid developer. But, if you’re writing clean, smart code and testing it in different scenarios, you’ll wind up with fewer issues in the various stages of QA down the line.

QA is not a single process run at the end of a project. In reality, QA happens at several points along the way, starting with the developer working on the task and performing self-QA, peer reviews with senior and lead developers, onto the person running internal QA, and finally in the client’s hands. The earlier an issue is caught, the better it is for everyone along the path of review. It’s so important to be able to reflect on your previous projects and apply the knowledge you’ve learned at the earliest stage possible.

What are your methods for QA-ing your work on a site from start to finish? Do you have suggestions or tips on how others could possibly benefit from your own workflows? If so, share them in the comments and let us know!

The post The Importance of QA and UAT appeared first on WebDevStudios.

Project Initiation

Once we have a signed proposal/contract, our Client Strategist is ready to start project initiation. In this phase, we schedule various project discovery sessions to get a detailed understanding of general project goals, design requirements, and website data details. The goal of the discovery sessions is to get as much information in order to outline a detailed project plan. The project plan specifies the project design and development requirements.

Design Phase

A majority of clients that we work with desire a refreshed design for their website. We work directly with the client to get an understanding of design requirements and turn those into Figma mock-ups. We typically go through two to three rounds in the design phase: initial, revised versions, and finalized mock-ups. Our design team ensures that we provide the latest web design elements, while considering responsiveness and accessibility.

Data Migration

If you are migrating from another content management system, or want a fresh WordPress install, your website will require data migration. The data migration phase typically starts by providing WDS access to your database, or your database files. With access to your database, our development team pulls together a data mapping document, writes a data migration script, and starts the import process. Once we complete the initial import into our development environment, we do a quality assurance review against the data mapping document to ensure all content imported correctly. Our development team will be working with your actual data during the development process to ensure the launch process goes seamless.

Active Development

Once we have the final approved designs and project plan, our development team is ready to start programming your website. In this phase, we will create all page templates using the coding standards that we have put in place here at WDS. Our team will code custom features and functionality based on your project requirements using custom code and plugins. Additionally, throughout the development phase, our lead developers perform code reviews on all features to ensure proper sanitization, caching, and security are in place.

Quality Assurance (QA) / User Acceptance Testing (UAT) Review

Once all development tasks are complete, our development team performs cross browser and device testing to ensure responsiveness and accessibility is in place. We run your new custom theme through our WDS theme check plugin. Our development team also runs a query monitor and report to ensure that the site is performant prior to launch.

Launch

Each new website/project that we work on has a unique launch plan. Typically, the following steps are taken during this phase to move the site from our development environment to your staging and production environment.

• Our development lead will set up staging and production environments on your host and set up deployments.
• We will then request a content freeze in order to start the final data migration process.
• Once the site has been moved over to your environment and a quality assurance test has been completed, you will be ready to switch the domain DNS/cpanel.
• And… your new WordPress website is now live for your company and users!

Support

WDS likes to guarantee our development work by providing a 30-day support phase post project completion. We use this time to squash any minor bugs or issues that came up during launch and make certain that your company is happy with your new website. We also offer extended or ongoing support and maintenance options for our clients.

Overall, WDS has set the standard for projects and project life cycles. We ensure that we provide quality WordPress websites based on our clients’ goals and requirements.

The post Project Life Cycle of a New WordPress Website appeared first on WebDevStudios.