The PeepSo plugin family is about to grow… and it’s going to grow big! The 1.7.0 release is massive. This release consists of 132 developer tasks, added a pile of new features, improvements, bug fixes, and a whole host of cool stuff. But most of them will be gathered under: New [GROUPS] GroupSo Plugin on our changelog.
The first commit to the Groups plugin repository was made on May 18th, 2016, which means that we started work on the Groups plugin while we were still building PeepSo 1.6.0, 1.6.1, 1.6.2 and 1.6.3.
Once lead developer Matt Jaworski had the architecture in place for Groups though we focused solely on the plugin itself. We wanted to get it out quick without compromising on code quality. We made sure that nothing breaks, that upgrades work and that everything does exactly what it’s supposed to.
The Development Process and Quality Assurance 2.0
Some of you might have read one of my early blog posts about our development process. I wrote that post almost exactly a year ago. Here’s an update that explains exactly how we make sure PeepSo works.
The planning stage. We look at the backlog and user requests, and ask ourselves what should go into the next version of PeepSo. Usually Merav gives us a general direction like: ‘Groups’, then lets me run wild(!) with it. So far it’s worked pretty great 🙂 Once the decisions are made we go to the next stage…
Matt is responsible for the grand design. He makes all the architectural decisions and he’s done an outstanding job. When the architecture is in place, tasks are given to the team members. If they’re too big to be handled in one ticket, Matt breaks them down into smaller tasks and delegates them. Once a task is done it goes to the next stage…
Code Quality Control
Completed tasks are passed to a Peer Review column on our board. A developer who didn’t work on the task reviews the code to make sure it meets our standards, and tests it. If the code passes, the task goes to Lead Code Review where Matt takes another look and either gives his stamp of approval or sends the task back to the original developer for correction. If all is well, the task finally reaches my desk.
The PM Quality Control
I can be very picky, especially when it comes to the design. If something’s out of alignment by as much as one pixel my CDO (it’s like OCD but in the correct alphabetical order) steps in. I can’t sleep until it’s fixed. Nothing leaves my desk until it’s perfect. Only then does it reach our beloved Webdriver team.
The Webdriver Quality Control
Webdriver is automated testing. It’s a series of scripts that automatically click around a site and check whether features do what they’re supposed to. In my blogpost a year ago, I said that we run 400 tests for PeepSo and its plugins. A lot has happened in a year. When I’m writing this we run 1,254 test cases for PeepSo and its plugins, there will be more when Groups plugin is out. We have a dedicated server running those tests and the whole test suite takes about 18h to execute them all.
Here’s an example:
We have an automated test that checks whether users can create groups when the setting is enabled in the backend. We also have an automated test that checks whether users can’t create groups if that setting is disabled.
We also have a test to check whether admins can create groups if the setting is enabled… and a test to check whether admins can create groups if the setting is disabled.
Those tests cover every possible scenario. There’s a great tweet about QA:
QA Engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers. Orders a sfdeljknesv.
— Bill Sempf (@sempf) September 23, 2014
Bugs Do Happen
The result of that borderline insane quality control is that we rarely receive bug reports, and only around 5 percent of the reports we do receive are valid PeepSo bugs created by a problem with our coding. The other reports are usually a server misconfiguration, a third party plugin issue or a theme problem that overwrote the PeepSo styles, making some parts of our plugin look a bit off. We once underwent a period of three weeks with no bug reports at all from users. I mean none. Version 1.7.0 will contain just five bug fixes reported by users. That’s five reported bugs since the release of 1.6.3 on September 5th.
If a user does find a bug, it’s put through our regular task procedure. Bugs end up as test cases to ensure they never happen again.
The Final Word
I’ve heard some people say:
“It’s just a WordPress plugin. You’re putting way too much effort into the quality. Who cares?!”
We all do. I will never put my name to something that’s half done. Thanks to our nutty high standards we can focus on development and not on fixing bugs. That saves us all time. If a user finds a bug, they get frustrated, send a bug report, and we have to patch it up. Some bugs might be too complex for a patch so we might have to create a workaround because the current architecture doesn’t support it. It’s a mess.
We’d rather do things properly the first time. That’s our approach and we’ll stick to it.
Oh, right… I almost forgot… Groups should be out around the end of October 2016 🙂