Missing Data

Oftentimes, our clients wish to migrate the data from their current site to their new site. At the beginning of the life cycle of the project, we conduct a data discovery phase. We examine the data on your current site and complete a data mapping document which is handed off to our clients for final review and approval. Sometimes, it is not desired that all data be brought over. Other times, it is, but the data mapping document should outline explicitly what will be brought over.

Then, development kicks off and data is often not something that comes to our clients’ minds when we are demoing the brand new frontend of their site site. Once the site is handed off for QA review, the initial elation of actually having the site subsides, and the realization that a few key pieces of content are missing hits. Is it possible that something is missing in our scripts? Yes, that’s what the QA process is for—to identify any issues. More often than not, however, the data was not included in the data mapping document originally.

To avoid this typical website project problem, we encourage our clients to closely review the data mapping document before signing off. As a slightly less technical individual, I understand how daunting of a task it is to review that. So, I encourage our clients to ask questions, as many as you need, to fully understand what exactly you are agreeing to have migrated.

Image Issues

Another issue that comes up frequently is image sizing. When you review mock-ups, you are looking at a static image. Although we all like mobile responsive sites, it can be confusing when content management comes up.

Images don’t just shrink or expand based on the size of a screen; they respond and scale accordingly. Oftentimes, the images that our clients are using on their current sites do not match the recommended sizes for the modules we have built for their new site.

As this is an issue that frequently comes up, we recommend asking as many questions around this subject matter as early as the design phase of the project. This way you have ample time to prepare the appropriate graphics.

We have a few tips, though, to help you handle this challenge.

• Keep your graphics center-focused. Here’s why: graphics that have text or important details that run to the edges of the image can be problematic. As the image responds to the size of the screen, the edges will cut off. This is our number-one issue reported by clients. By selecting a graphic where the key content is towards the center, you will ensure that on all screens the graphic looks stellar.
• Let your site handle the call-to-actions. We create text fields and buttons for information that you are trying to convey. If you add text to a graphic, it can interfere with the elements of the block, as the site responds to different screen sizes. Let your images be just that, an image.

QA Phase

Another issue that often comes up during website projects, is around the QA phase. This is the first time our clients really get their hands on their sites. There’s that excitement again! But this can quickly turn into a potential issue if the QA phase is not used to report bugs and issues, but rather, used to create new requests and suggest nice-to-haves.

I like to think of a website projects as building a house. You wouldn’t think about installing a shiny new chandelier without first checking that the electrical outlets work properly. Similarly, it is surely fun to think about impressive future features, and we encourage you documenting those requests, but it is important to use the QA phase to thoroughly test your site specifically for the purpose of uncovering any bugs or issues.

Redirects

So now you are at the point where your site is about to launch. Everybody has been working towards this exciting, yet nerve-wracking, moment in your project. Then another issue may creep up, maybe a few links on the old site have been forgotten about, which will result in pages displaying a 404 error on your new site.

This issue is totally avoidable, if redirects are discussed early on. We can assist in setting up 301 redirects for those pesky old links. Remember, you know your current site better than we do, and it is helpful when you raise this topic and point those out to us.

I can pretty much guarantee that you will ride the roller coaster from the moment you begin discovery for your website till the site is live. Will website project problems come up? Yes, they will. That’s the nature of the beast, but these tips will help you feel the rush of the ride instead of any sinking feelings.

Looking for a partner to ride the roller coaster with you for your upcoming website project? Contact us!

The post Website Project Problems You Might Encounter appeared first on WebDevStudios.

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.

In the beginning, there was man

Okay, so maybe not THAT far back.

In the beginning, there were mockups

That’s better.

We’re all familiar with the concept of mockups. We (or one of our more-talented designers with awesome skills) provide a PSD mockup of one, or several, pages to the client. It’s a representation of what the website will look like, and the client is free to pick at and scrutinize the smallest (and largest) details of said mockup. “Move this over a pixel!” or “Bump the font size one point up!” may sound like simple changes, but what if you’ve got ten different PSDs and the client wants to see the change reflected in all of them? Well, I’ll tell you what: you get a lot of wasted time.

To me, that just doesn’t fly. I’m all about efficiency when I work. I sit down, I get in the zone, and I start working away with as few distractions as possible. But the mundanity of updating several mockups for a simple change just to sate the client just lacks appeal.

So, what do we do? Instead of telling the client to shove it or to tell them to imagine the shifted pixel or font size, maybe we should just get out of the habit of providing full-blown, full-page, or sometimes several-page mockups.

It’s a Small, Small, Small, Small World

What blog post about modular design would be complete without referencing this article by Daniel Mall about the grace and ease of element collages. Of course, that post and line of thinking may not have even come to fruition without Samantha Warren’s article about Style Tiles in 2012.

These two heroes of the design process got us thinking outside of the mock and in a more focused way. Not only have they introduced processes by which we can give the proper amount of attention to detail necessary, but they’ve also increased our productivity by cutting down the amount of time we spend (waste?) on creating full-blown mockups for clients. In this game, saving time means saving money and I think we’re all on board with that.

This does mean, however, a radical shift in the way we present our ideas to the client. I fully understand that some clients may be a bit apprehensive to accept element collages over a full-page mockup. After all, the latter is something they’re used to. It’s a comfort food. It’s what they know and it’s what they expect, and if it’s not done just right they’re going to be left with a bad taste in their mouths.

On the flip side of that argument, though, the clients who come to us for a project aren’t the experts in design and development. After all, that’s why they’re coming to us. I’m not going to write a letter to Sony or Microsoft and give them my personal feedback on how to improve the features or looks of the PS4 or Xbox One. I’m just a consumer and they’re the pros; they’ve done all of the testing to ensure that the final product I receive is the best it possibly can be (for the most part).

By the same token, shouldn’t we be taking that kind of responsibility with our work? If we know that something new is on the horizon, or even here already, shouldn’t we be the ones presenting those new ideas to our clients? We should be on the front lines of innovation and education! They trust our knowledge and our skills enough to hire us, so they’re going to trust us enough to at least listen to the new processes and workflows that we’re ready to propose.

Yes, it could be a bit of a shock to the senses for client to receive an element collage instead of a full-page mockup. They would see all of the elements of a website, but they may not actually make sense as far as placement, positioning, or even structure. Again, though, that’s where we come in; it’s OUR job to explain what they’re seeing on the screen in a way that they will understand to ensure they’re not confused or freaked out at receiving what appears to be a bunch of random elements crammed together. We’ll have to explain to them that these are the elements that will make up their website and that these styles and elements will be used throughout the site to retain uniformity, cleanliness, and ease of use.

Taking The First Big Small Step

Think of it this way: if you make a list of things to do over the weekend, you’re going to want to be as granular as possible. If your weekend task is to clean the house, your checklist is going to be a lot longer than “Clean the house.” You’re going to separate your tasks into smaller, more specific tasks. You’ve got to vacuum the living room, sweep and mop the floor in the kitchen, clean the toilet, clean the tub, etc. You’re going to make sure you nail every item on that list, and you’re going to know you’ve completed everything you set out to do once you’ve crossed off every one of those tasks, otherwise you’re going to forget to dust the ceiling fans or clean that weird crevice between the fridge and the wall.

This is the way we need to work as designers. We shouldn’t take a mockup for a single post or the home page and begin a task called “Create Home Page Template.” We need to break that down because without doing so our focus would be all over the place. We’ll go from looking at the header and navigation to the sidebar, over to the content then down to the footer, back up to the header because we may have missed something the first time around, and so on and so on.

With a full-page mockup, we can also get lost in the sections or individual elements because, now that we have a thing which LOOKS like a webpage, we’re also looking at it as a webpage instead of handful of separate elements. With element collages, though, that kind of foresight is built right in from the very beginning. We take a look at the collage and see JUST the header. We see what a widget in the sidebar should look like. We see what buttons and links should look like. We’re seeing everything for what it is: a single piece of the puzzle rather than looking at the entire puzzle and trying to pick out the pieces we feel hold the most importance.

In addition to the specificity with which we’re able to see our elements, we also get to eliminate a major headache from our design process–pixel perfection. I know that phrase probably sent shivers down your spine, but please just bear with me for a moment. PSD mockups are not perfect, okay? They’re never perfect. They’re never going to be perfect. Maybe you want fifteen pixels of space below a widget, but for whatever reason you accidentally leave an extra five or ten pixels below a single widget in the mockup. Should that actually be fifteen pixels, or should it be twenty-five pixels? Why do some posts have ten pixels beneath them and others have thirteen? What does it all mean?!

In short, it means that full-blown PSD mockups are dumb and that we should move on from them. We’re wasting our time counting pixels in mockups, and the client is wasting time doing the same thing and then following up with questions about why the spacing is different in the browser than in the mockup. We know what we’re doing here. We’ve established that. So rather than worrying about the space created in Photoshop, which may be off a few pixels here and there, why not worry about the space of the elements where it actually matters most–in the browser.

If we’ve moved on to element collages, the client and team will already know what each element should look like and this is where the worrying should stop. Once the element collage is given the okay, we should be on our way to creating beauty in the browser where these items come to life and things like spacing, interactivity, and usability are much more tangible.

I Thought This Was About QA?

If you’re still with me, you may be wondering where the talk of actual QA comes into the game. I’m about to give you a Shyamalan twist–we’ve been QA’ing the entire time!

I know that right now you’re shouting loudly at your screen, “But I thought the QA process began with a really cool spreadsheet to track all of the potential bugs and issues!” and I just want to tell you to relax because you’re gonna freak out your neighbors and pets. Don’t start acting like a crazy person now; we’re almost done!

It is true that my formal QA process begins with a spreadsheet where I can track the woes of a project. That’s the formal QA process, though. We can really be QA’ing the entire length of the project, and with a modular design process like element collages we’re going to be that much closer to a clean, complete deliverable once the project wraps up.

Think back to my example about your house cleaning list. If you don’t track every task meticulously, then you run the risk of missing something. The same goes for the design process. If we get a blanket task of “Create Single Post Template,” then there is a huge chance that we can overlook some smaller element on that page. So, why not start small instead of big? Why not create fifteen or twenty tasks for a page template? A task for the sharing elements; a task for comments; a task for pagination…and so on and so forth. If you’re focused on these smaller items, then these smaller items are going to receive more of your attention. You’re going to be locked into making the pagination kick as much tail as it possibly can rather than it becoming an afterthought which can absolutely happen at times.

When you’re working in as granular a process as is possible, then you’re going to be the first one to scrutinize the items you’re designing and developing long before they even make it to the QA table. This means that, once we get to the QA process, we’re going to spend less time fixing bugs. In turn, this means that we can eventually eliminate a lot of time from the project that may have otherwise been spent on cleanup and fixes which, finally, means a faster turnaround and a cleaner overall presentation for the client.

We live in a world built for weirdos. Phones are getting larger and tablets are getting smaller. Screen dimensions are ever-changing and we can now access from our watches, refrigerators, and televisions. Everything around us is constantly changing and the way we access our information is perhaps changing the most rapidly of all. Why, then, should our design process be stuck in the mud, unshifting and unrelenting in a world that continues to grow and move around it? Clients and consumers didn’t clamor for smart watches or a million different sizes of telephones–the experts made it so and the public responded. It’s time for us, as the experts in web design, to do the same.

The post Getting Small with Modular Design as QA appeared first on WebDevStudios.

Wrong.

WRONG WRONG WRONG.

Just because you think you’re done with a site doesn’t mean that you’re actually done with the site. I’m pretty sure Confucius said that. And what that means, basically, is that once you’ve pushed your “final” code and crossed off that final to-do there are still one million things left for you to do. Yes, you think everything looks good in whatever browser you’ve been working in, but have you considered other browsers and their thoughts? Their feelings? The way they handle your pseudo elements, or the way they display an SVG font as a craggly mess? You didn’t think about that, did you?

GOD, YOU’RE SO INSENSITIVE!

But we can help with that insensitivity.  That lack of a second-thought you give to the way your favorite browser works on another operating system, and the way your least-favorite browser mangles all of the delicate beauty you’ve painfully crafted over the last six weeks.

Around these parts, it used to be that I would complete a site and proudly watch as it entered the QA process.  I would smile along with any other designers with whom I had worked on the project, a little smug in our belief that the entire QA process would be totally fruitless for the QA’er.  How could they find anything wrong with something so wonderful?  We’ve made their job so easy!  Soon, there wouldn’t even be a need for a QA’er to QA anything what with all of the certified gold we were churning out.

Let me like myself sometimes
Let me be narcissistic sometimes
I’m not like this all the time

– Everyone Everywhere, “I Feel Fine by Everyone Everywhere“

It is in those moments where I now realize how gravely I overestimated our aforementioned gold and how deeply I underestimated the QA prowess of one Lisa Sabin-Wilson.  You don’t know true shame until you’ve passed off a site for QA and see it come back with three dozen new to-dos.  Well, until you look at the to-dos and realize how easily these QA issues could have been fixed.  You can tell yourself whatever you need to tell yourself to try and feel better about it – you’ve been looking at it for so long that it’s easy to miss the little things.  Right?  That’s a real thing, right?  What it comes down to, though, is that you’ve overlooked some pretty obvious and easy things and being called out on those via the QA process is like a punch to the head, heart and ego.

I want to smash things
I want a coffee
I want to punch myself repeatedly

– Everyone Everywhere, “I Feel Exhausted“

It didn’t take long for me to realize that I needed to change the way I was doing things so the resulting product would have a much easier and simpler QA process once it left my hands.  Damn it, I’d QA the site myself before I even handed it off to someone else!  As a Front-End Lead at WebDevStudios, that came as part of the job so my rallying cry to myself is more of a way to pump myself up than me shaking the foundation of QA itself.  But hey, if you can’t be proud of the work you’re doing and get yourself excited to do it, then what’s the point of doing anything?  Why even get out of bed?  Why even wake up, ya damn bum?

So, what’s the big secret?  How do I QA sites before I pass them off for a final review, ensuring that all of the little things have been sewn up?

Spreadsheets.

Yep.  Spreadsheets.

I didn’t know what would be the best way to organize my QA thoughts.  I broke out a pen and paper and scrawled chicken scratch into shoddy columns, making notes of which browser rendered something too weird to accept.  Even then, though, you can miss things because you’re still working against your own brain and memory.  Work-as-you-go QA still allows for things to be left behind.

My first step in the QA process is to visit the WordPress dashboard.  I look at the sidebar and begin making a list of all of the various post types.  Posts and Pages, of course, but then any other custom post types that may have been registered.  We’re not just listing the post types, though – we want to be as granular as possible.  Post archives, single posts, post type-specific sidebars, etc.

What about taxonomies?  Categories, tags, custom taxonomies – you’re going to want to make sure you’re looking at those, too.  Sure, maybe you’re using a single archive template file to power all of your archive pages, but don’t be so sure that something weird won’t crop up on a custom taxonomy page just because your category archive page looks terrific.  Expect the unexpected, and then go fix it.

And for the love of God, don’t forget the search results or 404 pages.

When all is said and done, I wind up with something like this:

While I walk through the QA process, browser-by-browser, I eventually wind up with something like this:

It’s the most wonderful time of the year, isn’t it?

As you can see, I block cells out with green if they’re good to go and red if they’re bad to go.  In addition to the red menace, I’ll add a number with a corresponding note that falls below.  This way, I can organize my thoughts and add individual, granular tasks into Basecamp so I can help track the process a bit more.  Plus, rather than fixing everything immediately as I see it, this allows me to see if there are any trends across browsers (this is why you see numbers repeating across columns).  If something is breaking in all but one or two browsers, then maybe it’s something I’m doing wrong and not something the browsers are doing wrong.

Since implementing this method for myself, I really feel that the quality of my QA’ing has increased exponentially.  Now, instead of just running through the site and telling myself I’ve checked off all of the possible pages, page templates, post type archives, etc., I can sit confidently knowing that – yes, I DID check that post type out or no, I did NOT remember to check a specific page template.  At this point, I’ll add it to my spreadsheet and start the process on that single item once again.  Maybe you’re telling yourself that, in the final stages of QA, you’d rather just check the items you may have forgotten without opening up the spreadsheet again.  But what’s the point of that?  If you’re writing everything down and making notes of everything you’re seeing, you can rest assured that you have absolutely, positively, 100% checked everything that you had needed to check.

I’m not saying that this is the best way or the only way to QA.  Everyone works differently and what works best for one person may not work as well for the next.  For me, though, being able to block out each portion of the site and make a visual mark of the work I’ve done QA’ing it has been hugely beneficial.

The post How to QA WordPress Websites Like a Pro! appeared first on WebDevStudios.