LoanPro Development Cycle
- Bug Fixes
- Bug Reported
- Bug Verified
- Cause Identified
- Code Fix Made
- Code Fix Verified
- Fix Added to Master Code Repository
- Fix Goes Live at Next Release
- New Features (Including Custom Programming Jobs)
- New Feature Proposed
- Feature Evaluated
- Priority Assigned
- Feature Specification Document Written
- Development Cycle Assigned
- Feature Developed
- Feature Verified
- Feature-Related Bugs Fixed
- Feature Added to Master Code Repository
- Feature Documentation
- Feature Goes Live at Release
- Feature Tested Post Release
Customers who have reported bugs or had new features approved for development often wonder what happens next and how much time will take to complete the project. This article will go over the development process for LoanPro to explain what goes into fixing a bug and developing a new feature.
A software bug is an issue with the software. Some function in the software functions in an unexpected way, or doesn't function at all. The diagram below shows the basic process of fixing a LoanPro bug.
A bug can be reported in a number of ways. If the bug is found by our team, a bug report is created directly within the task-tracking system we use. If a bug is found by a customer, they can report it in one of the following ways:
- Directly on our website at https://loanpro.io/support - Here you can enter all the relevant information about the bug including: location in the software, description, and steps to reproduce the bug.
- Email - You can report a software bug by sending an email to firstname.lastname@example.org.
- Phone - You can call our support line (800-559-4776) to report bugs.
Once a bug is reported, our quality assurance team will try to reproduce the bug to verify that there is an issue with our software. It may be that the reported bug is specific to a single tenant, server, or the computer that it was found on. Because if this, verifying the bug can be difficult.
If the bug is only happening on some computers, it is usually an issue with the browser, the specific version of the browser, a browser plugin or extension, or the network settings for the computer where the bug is observed.
If the bug is only happening at one location, usually the issue is the network settings for the location's network.
If the bug is happening sometimes, but not all the time, it usually means the bug is confined to a single LoanPro server.
If the bug is only observed inside one company account, it is usually specific to that single account.
If the bug is observable in all accounts, on all computers, all the time, it almost certainly an issue with LoanPro.
Once the bug can be reproduced, if it is determined that LoanPro may be the source of the bug, it is passed on to LoanPro's developers. The cause of the bug is identified. Usually this is the most time-consuming part of the process.
Code Fix Made
Once the cause of the bug has been identified, usually making the code or configuration change needed to fix the bug is fairly simple. A fix will be made by LoanPro development, and added to our beta site for testing.
Code Fix Verified
Once the code fix has been applied to our beta site, it is tested thoroughly by our QA team. This includes testing the fix using different approaches and configurations on multiple computers to ensure that it is really fixed. If the issue persists, the bug will be sent back to the development team for further fixing.
Fix Added to Master Code Repository
The LoanPro master code repository is the location of the code that will be pushed to production for use by customers during the next release cycle. Bug fixes will be pushed here in preparation for release to LoanPro clients.
Fix Goes Live at Next Release
LoanPro only releases code during its formal release cycles. This ensure that customers can take time to prepare for new features or code that may require changes to their processes or API integrations. This also helps LoanPro to test and push complete, known changes during each release, to avoid pushing incomplete code or features. Because if this, it may take some time between the reporting of a bug and the introduction of the fix to the actual production environment, where it can be seen by customers.
New Features (Including Custom Programming Jobs)
LoanPro regularly adds new features. Most of these features are proposed by customers, while others are proposed by our internal team. Others are needed to meet legal, security and/or industry regulations. The diagram below shows the basic process for new-feature development in LoanPro:
New Feature Proposed
If a feature is proposed by our team, a basic description is created directly within the task-tracking system we use. Customers can propose a new feature in one of the following ways:
- The preferred method is to propose the new feature through our website at https://www.simnang.com/loanpro/assets/pages/requests.html?feature=true. Here, customers are asked where the feature should be located in the software, what problem the feature will solve, and to describe the feature. It is preferable to have written information about a proposed feature to start with because it ensures that LoanPro has a record of what is important to the customer. Starting out with a written description also helps to move the task through the process more quickly.
- Email - A feature can also be proposed through email. It should be clear that the email is a new feature proposal. This will make sure it is routed to the correct personnel. The proposal should contain a description of the feature and the business case for which it will be used.
- Phone - The least-effective way to propose a new feature is to call support and describe it to a representative over the phone. The rep will be responsible to interpret what you say and convert that to a feature proposal. This method usually results in a feature that is not quite what was requested.
Custom Programming Note: You may need a feature badly enough that you will propose the feature as custom programming instead. Custom programming has the advantage that it is more likely the feature will be created, the timeline for creation will be accelerated, and communication about the feature will be more frequent. The disadvantage is that you will pay for part or all of the feature depending on the evaluation of its appeal to other customers. Custom programming requests should be made through the LoanPro website at https://loanpro.io/support.
Once a new feature is proposed, it will be evaluated by the LoanPro team to decide whether it should be developed. If the feature is being developed as part of a custom-programming job, the evaluation will be accompanied by a written quote that will include price and timeline. If a custom-programming feature will not be developed, a written rejection will be issued. If the feature is not associated with a custom programming job, there is no guarantee that any communication about the decision to develop the feature will be issued.
If LoanPro decides to develop the feature, the feature will be assigned a development priority. This could be a very low priority (we will develop the feature someday) all the way up to including the feature in the next available development cycle. Custom-programming jobs are more likely to get a high priority. Usually, we have already decided on all the tasks that we will try to complete for the next one or two development cycles. Because of this, even if a new feature is assigned a high priority, it will be several months before it is released.
Feature Specification Document Written
For the large majority of new features, a document is written describing the feature, the use case for the feature, the scope of development for the feature, and other specifics. This document servers as a common-ground description of the feature that can be understood by both project management and the development team. Depending on the size and scope of the feature, this document may take some time to write and get approved. If the feature is associated with a custom-programming job, usually this document is approved by the customer requesting the feature.
Development Cycle Assigned
Once the specification document is complete, the development cycle during which the feature will be developed, is decided upon. This does not guarantee that the feature will be developed during that development cycle, but it does mean that it will be assigned to one or more developers with the goal to develop it during that time. This also means that the final day of the assigned development cycle will be the tentative release date for the feature. For custom-programming features, this date is usually communicated to the requesting customer. For other proposed features, this date will most likely not be communicated unless asked for, and our support team may not have access to development information for the feature.
During the assigned development cycle, the feature will be developed. Features are usually completed during their assigned development cycle, but may not be, depending on issues with other development tasks, or underestimating the time the feature would take to develop.
Once the feature is completed, it will be pushed to the LoanPro beta site for testing. The Quality Assurance team will test the feature to make sure it functions correctly. Incomplete features or new-feature bugs will be reported back to the development team so issues can be fixed.
Feature-Related Bugs Fixed
Fixing feature-related bugs works similarly to fixing any software bugs, except that they are typically fixed in the same release cycle during which the feature was developed.
Feature Added to Master Code Repository
Once the feature development is complete, the feature code is added to the master code repository. This is the code that will be pushed live during the next software release.
Documentation is written on how to use new features. This documentation is included in the articles system at https://loanpro.helpdoc.io The most vital information about the new feature and a link to articles describing its use are included in the notes for the software release. For custom-programming jobs, a special communication is usually made to the requesting customer.
Feature Goes Live at Release
When the software release occurs, the feature will be live and available for use. Depending on your company's user roles, a change of access may be required before users in your company can see/use the new feature.
Feature Tested Post Release
On the release date and for a few days afterwords, the LoanPro Quality Assurance team will continue to test to the new feature to ensure that it works in the production environment.