Testing software is one of those topics that people often talk about, write about (books even), and evangelize during conferences, meet ups, and so on. And rightly so – testing is one of the most important aspects of building something that’s going to be used by others.

Sometimes though, I wonder if we don’t do more talking about testing than actual testing.

By that, I mean we all understand its importance and I’d venture to say that we’re relatively familiar with the tools that are available for testing, but the act of testing in and of itself is kind of a beast:

  • It requires that you install additional software on to your computer
  • It requires that you learn how to write tests using the above software
  • It introduces more code thus more time into a project which doesn’t always translate well for stake holders
  • …and more

In short, there’s a lot working against it. I get it. Even more so, we talk about all kinds of testing – anything from unit tests to beta tests to release candidates and so on. All of these are important and they all have their place, and testing in WordPress is no different.

That said, there’s at least one method of testing that I think is applicable but rarely employed when it comes to creating themes or plugins. It’s an intermediate step of testing that I would say fits between user testing and beta testing: Use case testing (perhaps there’s a better title for it, but that’s what I have for this post).

Use Case Testing in WordPress

First, I wanted to make sure I was clear in that this type of testing in WordPress is meant to be in addition to the usual steps. That is,

  • This comes after unit tests (with various types of data)
  • And this comes before – and perhaps even in between – beta tests

In short, this type of testing consists of using a spreadsheet to document all of the various use cases and features of a theme through which you work your way through when testing the project.

Testing in WordPress

An example spreadsheet of user testing in WordPress

As you can see in the screenshot above, I’ve got nine columns each of which correspond to a different aspect of any given feature:

  1. Feature Group (such as installation, default options, etc.)
  2. Feature Name
  3. The expected output
  4. The actual output that occurs
  5. Did it pass?
  6. Did it fail?
  7. Notes regarding this specific case
  8. When the issue was reported
  9. When (as in, which date or which build or which version) was the reported issue fixed

It’s pretty simple, isn’t it? On top of that, the methodology allows us to create separate sheets each time we’re performing a new iteration of tests. Ideally, we’ll have a collection of tabs along the bottom of the spreadsheet the first of which likely includes a lot of fails and the final sheet which includes nothing but passes.

Who Does This?

In terms of who should do this, I think there’s value in having both yourself and an objective – or as an objective as can be – third-party.

When you test it yourself, you see your work through the lens of how others will be experiencing. This is true, at least, to some degree. This helps not only expose the issues that others will solve, but it also helps you experience the frustration they’ll have when trying to get something to work.

And if you use someone else to help you that didn’t help build the project, then that’s all the better. Ideally, they should be someone technical enough to know how to navigate around whatever it is that you’re having the test, but they don’t have to be a programmer (especially because those types tend to share, you know “Here’s what the bug is and here’s how I would fix it.” As if the latter matters right now. :).

It’s Too Simple

Yes, it’s a simple way of testing work. It’s even a little tedious, but it’s worth it. It’s something that I’ve had done on numerous occasions with several different projects and I’ve never regretted it.

There’s likely more that could be added to this approach, but if you’re not doing something like this at the bare minimum, then I think it’s worth starting somewhere – even if it’s as simple a foundation as the screenshot above.


Join the conversation! 8 Comments

  1. Nice article. I’ve been using something similar to this method for many years. You’re right, it’s tedious, but it’s effective. BTW, this is the best practical book ever written on software testing (at least that I’m familar with)


  2. Did you ever hear of the term acceptance testing? Is this it?

    Automate tools like cucumber and such.

    • Did you ever hear of the term acceptance testing? Is this it?

      Yes, and essentially yes it is.

      Automate tools like cucumber and such.

      There are some things that automated tools are not great at catching across browsers (such as certain inconsistencies of features especially as it’s related to Ajax and some of the more advanced CSS3 queries, responsiveness, and so on).

      • True. Though there are projects like karma, phantoms and such that might be aiming to alleviate some of those issues.

        Haven’t used them much though.

        • Completely true.

          But I’m still hesitant to rely on software for acceptance until it can do a better job – or perhaps a more efficient job, is a better phrase – than an actual person.

          I think using both is fine, of course. But having a person (or people) doing QA has always yielded better results – at least in my experience.

  3. i want to test my theme in wordpress with lots of plugins and widgets..

    which is best automation testing tool for wordpress?

    can anybody tell me how can i tested with my theme using selenium?

    its urgent..please reply me soon..


Leave a Reply