It’s easy to say that I test everything before it leaves the shop. I’m the programmer, after all. But with complex platforms like WordPress, where drop-in components, widgets, and themes may all come from different vendors, it’s easy to lose track of who’s responsible for testing what.
Testing for me, at its heart, boils down to the following process:
If you want a big, fancy way of labeling this process, it’s called unit testing. You take the smallest bits of the project, test each one individually. You put together those bits in a group, and you see if that group works. You put all the groups together in the final product, and you see if the whole thing works. This common-sense way of doing things applies to practically every part of your life, too: running out of flour, fixing a lamp, or changing your oil.
Is it broken or missing? Then fix it!
Testing is an important part of software development, and sometimes (as a single developer) it’s hard to separate development and testing as two discrete groups of tasks.
(It’s important to note that I’m not talking about usability testing — that is, the process where you put an unfinished product in front of actual or potential users to see how they respond. This is important too, but what I’m discussing here is in the context of fixing bugs, not determining how well a feature works.)
With larger website projects, testing becomes more complicated, because I am no longer the only actor working in the chart. For example, 48 developers maintain WordPress’ core software, and have spent an estimated 52 years of combined effort. They allow everyone to test pre-release versions of WordPress, and report bugs that they fix.
This isn’t to say that WordPress is consistently and totally flawless. There are, on average, between 3,500 and 4,000 issues in the WordPress bug database (called Trac) at any given time.
You wouldn’t be wrong to think it’s a bad idea to willfully include flawed software in a client project. Realistically speaking, and mostly from a budget standpoint, it’s just not practical for smaller businesses to maintain their own developer team that produces flawless code every day. (That’s why most small businesses hire freelancers in the first place.) And looking at the broader picture, since software is developed by human beings, and human beings make mistakes, I’d argue the likelihood of error-free code goes down as the number of lines of code increases.
So what can we do? We do the best we can with what we have. I personally test the code that I write, and I personally verify that it meets the customer’s criteria before showing the customer. Does that mean I do this perfectly a hundred percent of the time? No, of course not. Do I fix things when a customer finds a problem? Of course I do.
For larger projects, there’s an element of trust required. You trust that the WordPress folks have done their level best to release a product that’s stable and reliable. I tend to favor using components like WordPress, jQuery, and Bootstrap — all projects with lots of contributors and with solid track records of releasing capable, performant software. I also appreciate, and seek out, customers that trust me with this responsibility too.
Even with a perfect test environment, priorities change. Having a testing procedure that doesn’t lock you into a particular way of doing things down the road is important for quickly implementing new features, and updating old ones. I’m lucky — I’m one person, so the same guy that makes the updates also tests them. Running software through a mechanical test program or a script is valuable when you’re calculating actuarial tables, but if you’re just adding some social media buttons to your sidebar, a complete audit and regression test of hundreds (if not thousands) of lines of code that eventually result in that button being output on the page — all the way down to Apache — is probably overkill.
My development process is specifically designed to ease testing. I often test sites in a staging environment that is as similar as possible (if not identical) to the production environment. The idea is to get the staging site as close as possible to the finished product prior to launch. Along with a solid, well-tested software stack as a foundation, a complete list of requirements to check against and active client participation, the testing process usually goes very smoothly.
When development is complete, we don’t bolt for the door, either. Most projects have an ample maintenance warranty period where you can call me up when something looks weird, and I’ll fix it for you. Most of the time, provided I’m not on vacation or without internet access, I’ll take care of it within a day or two.