Tyche Softwares has a limited number of plugins to sell, but we are making sure these limited number of plugins are well supported, maintained and upgraded with the recent market needs. We have in all 15 plugins that are being regularly updated averagely every 15 days. To some, this may sound this is a very less number of plugins that are to be maintained, but the effort of each developer to release each plugin every 15 days takes some real dedication. And we also have happily included most of the highest voted features by the end users in our core plugins.
At Tyche Softwares, plugin development is not the only prowess that we focus on. We have a dedicated team for providing quick, top-quality support and we have a dedicated person who only focuses on testing the plugin updates. It is the team, as a whole, which drives & thrives the company.
Before we move forward, I would like to mention that I take care of all testing that happens in our company.
When a WordPress plugin is developed or an update is released, it needs to be tested. There are a number of dimensions of testing that needs to be considered before making the plugin live and available to the WordPress community. In this blog, we will be discussing the process that is followed at Tyche Softwares for testing.
In the previous post, we provided some details regarding test cases & our testing environment. We surely ask the developer to test their code first hand. But that does not involve integration testing. Once the basic test is run and passed by the developer, the plugin is then sent to me.
Having a focussed testing person is a must for any company who is providing WordPress plugins.
The tester prepares a document that we call Pre-Testing Sheet. This document has all the points that are to be released in the plugin. We majorly split these points into three:
- New features/Enhancements
- Tweaks
- Bug fixes
The Pre-Testing Sheet lists all the points that are to be released and lists the test cases that are to be tested for each point. An estimation is made & priority assigned for each point. The points are taken up for testing according to the priority of the point.
We also mention if the current behaviour of the plugin will be changed by any of the new features so that we can emphasise more on such points. Here is a gist of the ‘Pre-Testing document’:
Adding to it, there are some extra pointers that are included in the document like Make sure debug mode is always on, check the debug log for warnings thrown from the plugin, always check the plugin on a fresh install, test the plugin on localhost that is not connected to the Internet, etc.
We always test the plugin by replacing the release copy over the copy where live version is installed and setup, so that we know no settings are affected on the sites used by our existing users.
When an issue is caught in the plugin, it is recorded on our GitHub repository. All our plugins, free & paid, are uploaded on GitHub. (You can check the free ones here ;)) All the issues caught while testing is listed on GitHub. These issues are then fixed by the developer by committing the fixes to our GitHub repository. Each issue is assigned to the dedicated developer of the plugin. The issues are prioritised & fixed accordingly.
Again a cycle is run where the issues are fixed & tested by the developer and then handed over to me to re-test. When the plugin reaches to a satisfactory level where the new features or the issues fixed is working flawlessly, we go ahead with releasing the plugin.
Apart from testing our own plugins, I also spend my time in testing the beta version release of WooCommerce & WordPress as and when they are released, so that we are up to date with them. We are currently testing the WooCommerce v2.6 beta versions with all of our plugins, to make sure our plugins’ compatibility with WooCommerce is not affected by the WooCommerce update.
We have used many different approaches in the past to see which one works best for us. Methods like listing all the possible test cases for a plugin, then filtering them according to the different functionalities of the plugin, we also used WorkFlow method that would let us know which plugin update is at which level in a pipeline as shown below.
Currently, we think the Pre-Testing Sheet is working well for us. So we have kind of settled down on using that as our key testing document.
We are researching how we can include Automation testing in our plugins. So you will see us using Automation testing methodology in near future.
What is your take on testing in WordPress? Do you have a focus on testing your plugins? If yes, what do you do? If no, why not? We will be happy to know.
