Skip to content

SOP for Testing WordPress Plugin Updates

Jump to bottom
Victor Zazulla edited this page Mar 10, 2025 · 13 revisions

Purpose

The purpose of this document is to outline the standard operating procedure (SOP) for testing updates to the SaaSPress WordPress plugin. The goal is to ensure that updates are thoroughly tested for functionality, compatibility with other plugins and themes, and stability before being released to end users. This process will also guarantee that all changes, including new features and bug fixes, are correctly integrated without causing regressions.

Scope

This SOP applies to testing updates for the SaaSPress plugin, covering the following areas:

  • The update process itself (manual or automated).
  • Post-update performance and behavior of the plugin.
  • Compatibility with common WordPress themes and plugins.
  • Integrity of plugin settings, data, and user configurations.
  • Rollback procedures in case of errors during the update.

Responsibility

The following roles and responsibilities are assigned to ensure a smooth testing process:

  • Developer: Implements changes and prepares the update, including necessary code fixes and improvements.
  • Tester: Executes the testing procedures, verifies the functionality of the updated plugin, and reports any issues or anomalies found during the testing phase.
  • Project Manager: Reviews the findings from testing, addresses critical issues, and approves the release of the update.

Tools Required

To perform the update testing for the SaaSPress plugin, the following tools are necessary:

  • WordPress Staging Site: A local or hosted staging environment to test the update without affecting the live site.
  • SaaSPress Plugin Versions: Both the previous (e.g., version 1.0.0) and the new version (e.g., version 1.1.0) of the SaaSPress plugin.
  • GitHub Repository Access: Ensure access to the plugin’s GitHub repository to verify updates and confirm the update process.

Procedure

1. Preparation

Before initiating the update process, the following steps must be taken to set up the testing environment:

Set up a Clean WordPress Staging Site

  • Install the latest stable version of WordPress.
  • Ensure that common plugins (e.g., Yoast SEO, WooCommerce) are installed for compatibility testing.
  • Activate a default theme (e.g., Twenty Twenty-Four) to avoid conflicts with custom themes.

Install Previous Plugin Version

  • Install the last stable version of the SaaSPress plugin (e.g., 1.0.0) to serve as the base for comparison.

Backup Database and Files

  • Always back up the WordPress database and files before proceeding with any update.

2. Simulate the Update Process

The update process can be tested manually or automatically. This section outlines both methods:

Manual Update (Via GitHub)

  1. Download the new version of the plugin from the GitHub repository or the release page.
  2. Upload the new version using the WordPress admin dashboard under Plugins > Add New > Upload Plugin, or replace the plugin files manually via FTP.
  3. Activate the plugin and check for any errors or warnings during the activation process.

Automated Update (via Plugin Update Checker)

  1. Verify that the SaaSPress plugin is properly configured to check for updates through the Plugin Update Checker.
  2. Trigger the update process via the WordPress dashboard, ensuring the plugin pulls the correct version from GitHub.

3. Functional Testing

After the update is successfully applied, functional testing ensures that the plugin behaves as expected.

Core Feature Verification

  • Test the main functionality of SaaSPress, such as custom admin menus or settings pages, and ensure they load correctly and function as expected.
  • Test if any specific features, such as analytics tracking or user management, are still working without errors.

New Features and Fixes

  • Ensure that any new features listed in the changelog (e.g., new admin panel options or improved performance) are functioning correctly.
  • Check that any reported bugs or issues from the previous version (e.g., broken functionality) have been resolved.

Error Handling

  • Test for PHP errors or warnings by enabling WP_DEBUG (define('WP_DEBUG', true); in wp-config.php).
  • Check if any deprecated functions are used and that they do not interfere with the plugin's operation.

4. Compatibility Testing

It is crucial to test the updated version of the plugin for compatibility with common WordPress plugins and themes:

Test Plugin Compatibility

  • Activate common plugins (e.g., WooCommerce, Elementor, Yoast SEO) and verify that the SaaSPress plugin works alongside them without errors.

Test Theme Compatibility

  • Switch to popular themes (e.g., Twenty Twenty-Three, Astra) and ensure that the SaaSPress plugin does not cause layout issues or conflicts with the theme’s CSS or JavaScript.

5. Database and Settings Integrity

Ensuring that the plugin does not corrupt or alter data during the update is crucial:

Preservation of Settings

  • Verify that all previous settings and configurations remain intact after the update. Ensure that custom options added by the user are not lost.

Database Upgrade Routines

  • Check that any database upgrade routines (e.g., new tables or options) have been applied correctly. This can be checked using a plugin such as WP DB Manager or by reviewing the database structure directly.

Data Integrity

  • Ensure that no data is lost during the update process, particularly user-related data or plugin-specific data stored in the database.

6. Performance Check

Performance testing ensures that the plugin update does not negatively impact the site's speed or resource usage.

Monitor Load Times

  • Use performance tools like Query Monitor to measure any significant changes in page load times. Compare load times before and after the update to ensure there are no regressions.

Database Queries

  • Monitor database queries to check for any excessive queries or slow-running operations. Excessive queries can indicate issues with the update that need to be addressed.

Resource Usage

  • Analyze the server's CPU and memory usage using server-side tools or the Query Monitor plugin to ensure the plugin update does not cause any spikes in resource consumption.

Test with Heavy Traffic

  • If possible, simulate a high-traffic environment to ensure that the plugin remains stable and performs well under load. This can be done using tools like Load Impact or BlazeMeter.

7. Rollback Test

Rollback testing is essential in case an issue arises during the update, allowing you to revert to the previous plugin version safely.

Deactivation and Reinstallation

  • To test the rollback process, deactivate the updated plugin and reinstall the previous version (e.g., 1.0.0).

Verify Functionality

  • After reinstalling the older version, verify that the site continues to function correctly, with all settings and data intact.

Check for Data Integrity

  • Ensure that no data or settings were lost during the update, and confirm that the previous version of the plugin operates as expected.

Test with Multiple Rollbacks

  • It’s a good practice to test the rollback process multiple times (i.e., update to the new version, then revert back to the older version) to ensure that the rollback procedure is foolproof.

Using git checkout to Revert to Previous Versions

  • If you need to perform a manual rollback using Git, the git checkout <commit_hash> command can be used. This command allows you to check out a specific commit, which corresponds to the previous version of the plugin.

    • Example usage: 
      git checkout <commit_hash>
      Replace <commit_hash> with the specific commit hash of the previous version. This will revert the files to the state they were in at that commit.

  • After running git checkout, you’ll need to push the changes to the repository to ensure the rollback is reflected in the remote repository.

    • Example usage: 
      git push origin HEAD
      This command pushes the changes (the reverted version) to the remote repository on the current branch.

  • If you're working on a separate branch, you may need to push to that specific branch:

    • Example usage: 
      git push origin <branch_name>
      Replace <branch_name> with the name of the branch you're working on (main).

  • After pushing, it's important to test again to ensure the rollback is complete and that the older version is functioning properly.

Additional Git Commands

  • If you're not sure about the commit history or need to see past commits, you can use the following command to view the commit logs:

    git log

    This will display the commit history, where you can find the specific commit hash to use with git checkout.

  • If you made any changes to the working directory and want to discard them before the rollback, use:

    git reset --hard

    This will reset your working directory to the latest commit and discard any uncommitted changes.

8. Documentation and Reporting

Keeping detailed logs and reports is crucial for transparency and tracking of the testing process.

Test Log

Record each test performed in a structured format. The log should include the date, tester's name, plugin version, and any issues encountered.

Example log format:

Date: [Insert Date]
Tester: [Name]
Plugin: [Plugin Name]
From Version: [e.g., 1.0.0]
To Version: [e.g., 1.1.0]
Issues Found: [List issues or "None"]
Status: [Pass/Fail]

Report Critical Issues

If critical issues are identified during testing, they should be reported immediately to the development team with detailed logs and any relevant screenshots or videos. The development team will assess the issues and work on resolutions.

Test Results Summary

Summarize the test results in a final report, listing all successful tests, any issues found, and actions taken. The report should be easy to understand and contain enough detail to allow for quick decision-making.

Acceptance Criteria

To approve the update for release, the following criteria must be met:

  • Error-Free Update: No errors or warnings should occur during the update process, including installation, activation, and deactivation phases.
  • Feature Functionality: All features, both existing and new, must work as expected without any functional errors.
  • Compatibility: The updated plugin should be fully compatible with common WordPress plugins and themes.
  • Data Integrity: User settings, plugin configurations, and database entries must remain intact, with no data loss.
  • Performance: The plugin should not negatively affect site performance.

Contingency Plan

In the event that critical issues are identified during testing, the following contingency plan should be followed:

  1. Rollback to Previous Version: Immediately revert to the previous stable version of the plugin.
  2. Report Issues: Detailed logs, including screenshots, error messages, and any other relevant data, should be reported to the development team.
  3. Retesting After Fixes: After the development team has fixed the issues, retest the update process.
  4. Version Increment and Release: If all tests pass, the version number will be incremented, and the update will be released to the public.

Approval

After the update has passed all tests and contingency plans have been implemented (if necessary), the release will be approved by the following stakeholders:

  • Tester: Sign-off on the successful completion of all tests.
  • Project Manager: Review the results, verify that all criteria have been met, and approve the release.

Sign-off:

  • Tester: ___________________
  • Project Manager: ___________________
  • Date Completed: [Insert Date]

Revision History

  • Version 1.1, Last updated: March 10, 2025
  • Author: SaaSPress

Clone this wiki locally