Readysell Development Methodology

Overview

Readysell, as all software, has some bugs in it. We try to keep the number of bugs as low as reasonably possible by adhering to a number of defined practices, however we are always balancing quality with how quickly and efficiently we can delivery new functionality and this can lead to the occasional bug in the software.

These tried and tested software development practices are used by many software developers facing similar challenges. We believe we have the right mix of speed and efficiency of delivery and stability, but are always happy to hear your feedback.

Planning

Readysell develops software using an agile methodology. New features are developed in "sprints" - time-boxed periods of development after which we release a new version of the software. At the beginning of each sprint we prioritise a list of work items based on the following factors:

• Feature Requests: Features requested and logged in the Readysell Feature Requests forum
• Change Requests: Paid change requests from customers who have been provided with and accepted a proposal
• Customer Contact: We get the chance to meet customers and hear their successes and challenges via telephone, email, at user group meetings and trade shows
• Technical Support: Our support team provides clear insights into the issues that are challenging for customers, and which are generating the most requests to support
• Advisory Groups: Our advisory groups provides insights into real-world customer issues and strategic direction for the group
• Evaluator Feedback: When someone new tries Readysell, we want to know what they liked and disliked and often reach out to them for more detail
• Automated Metrics: Readysell automatically collects performance, reliability and usage metrics about Readysell on your system and uses this to target areas for improvement
• Product Strategy: Our long-term strategic vision for the product

Feature Requests

Suggestions for new features that might improve Readysell are encouraged. Readysell may at its discretion accept or reject suggestions. If accepted, those suggestions will be included in some future release of Readysell. We do not make our roadmaps public, and as such, the release date of new features and improvements will not normally be published in advance. Support work is our priority above development, we may hold off development of any feature for a long period of time for a number of reasons. As a result we only announce new features when they are actually released.

Feature suggestions should be submitted on a support ticket. Comments and votes can be submitted at the Readysell Feature Suggestions Forum. The most popular suggestions are reviewed for inclusion by our product managers on a regular basis. If you submit a feature suggestion via one of our regular support channels, we will ask you to submit it at the feedback forum. This will ensure that we have a good idea about the demand for the feature and that you are progressively updated on the status.

Change Requests

If you want a new feature and are willing to pay for it, rather than submitting it to Readysell for including on the feature request forum, you can put in a change request as a ticket.

Custom features and reports required for your site are considered change requests. Readysell charges for such requests individually based on the Readysell Service Fee Policy. A quote must be accepted before work commenced.

Change requests should be submitted using the regular support channels above.

After you get any quote, you can still elect to ask us to add the request to our feature request forum if you decide to not go ahead with the quote.

While we try to be as accommodating as practical in respect to change requests. We may determine the request is not appropriate or may need to hold off development for a time due to other development priorities.

Issue Tracking

All customer-reported issues are tracked in our support system (see Readysell Support Policy for more details). If the issue is deemed to be caused by a bug in the Readysell software, that bug is logged in our internal bug-tracking system. This allows us to record all the required details about the bug and track it through development, testing and deployment.

Automated Testing

Readysell has some automated testing of key components to ensure that issues introduced by programming errors are picked up as early as possible in the process. We continue to invest in expanding our automated testing to improve test coverage.

Internal Testing

Once our developers have addressed a bug, the bug is handed over to our internal testers for testing. Our testers will follow pre-defined reproduction steps to determine the issue has been resolved. They will also perform exploratory regression testing to ensure that no new issues have been introduced as a result of fixing the addressed bug. The tester will go back to the developer if any issues are found with the bug fix, and once they are satisfied, will mark the bug as "Testing Passed" in our internal bug-trackign system.

Piloting

Once internal testing of the addressed bugs in a new version is completed, that version is deployed to a small set of volunteer customers who provide direct feedback and telemetry to ensure that the update does not cause new issues in a production environment.

Staged Rollout

After a short period of piloting (typically 1 or 2 days), we commence staged rollout of the new version to customers. Customers are placed into deployment "rings" that dictate this rollout. If you would like to know which ring you are part of and/or change rings, please contact Readysell support.

See also

• Software bug at Wikipedia