Software Engineering: Integration Testing for Reliability


Software Engineering: Integration Testing for Reliability

To ensure the reliability and stability of our integration products, all development projects have gone through different types of functional and non-functional testing which includes performance testing, usability testing, security testing, regression testing, and stress testing, which are crucial to software engineering.

By Charlie Wu, Software Engineer

In a fast-paced retail environment that processes a large number of daily transactions, it is critical for retailers to have an efficient and reliable point of sale payment system to perform credit card transactions. A fast and error-free integration can not only prevent retailers from money loss in transactions but also improve shoppers’ experience and earn their trust and loyalty. Is it possible to develop complex but fault-free and high-quality payment integration software? With good design, diligent engineering and effective testing methods, the answer is yes.

Over the years, New West Technologies has developed a variety of payment integration software for various merchant services providers like OpenEdge, Cayan, Vantiv (Now Worldpay), and CardConnect to work with Microsoft Dynamics RMS, D365, and Retail Management Hero. To ensure the reliability and stability of our payment integration products, all development projects have gone through different types of functional and non-functional testing which includes performance testing, usability testing, security testing, regression testing, and stress testing. Compatibility testing is also a focus of the software development cycle to make certain the software runs smoothly on different platforms.

Although software products have passed several levels of testing and have been installed and performing well in other production environments, there are occasionally situations where software fails to behave as expected on the customer’s point of sale system. Software failures that are caused by abnormalities in the production POS environment are sometimes difficult to troubleshoot for service technicians and developers. Because these errors occur randomly and cannot be consistently and repeatedly reproduced, it is hard to pinpoint the problem and resolve the issue. In this situation, developers should attempt to reproduce the errors and fix them by replicating the customer’s environment in an internal test environment.

Software defects are often caused by faulty design and human error during software development. That is why software testing is an integral part of the development cycle. Unlike hardware which could age, break, rust or deform over time, software does not suffer from wear and tear but it does break, not because of physical faults but due to changes in complexity. In fact, it is normal to see software failure rates increase when there are new features added or upgrades are made. The error rates decrease after the bugs are detected and fixed, and the software achieves a high level of stability.

Although software reliability can increase over time, changes in the user environment or third-party components that a program runs and depends on could cause the software to behave erratically after it is deployed. The unpredictability of the end user’s production environment is the most challenging part of software reliability assurance. Unforeseen differences in the deployment environment could make even a well-designed program break down abruptly. For example, installing a Windows update or a new anti-virus program on a POS system could potentially make another application become unresponsive and unstable in performance. Sometimes an error in the RMS POS environment is an application failure due to an access violation of the RMS session variables. RMS session variables are static variables in the memory shared and used by different third-party RMS add-ons during runtime. If designed improperly, the RMS add-ons can attempt to write to the session variables at the same time causing memory violation exceptions in the POS system.

To minimize and prevent software failures due to environmental changes, developers would collect data from the environment that the application runs on, analyze the data for any trends or patterns of failures during runtime, and study different scenarios and workflows that may trigger exceptions in the production environment. Predictive analytics or future failure predictions can help developers better design a software product and avoid unexpected issues raised in the production environments. For instance, in the case of session variable conflicts in the RMS POS, an analytics tool can be created to explore the session variables and data used by other RMS add-ons on the POS system. The collected data of third-party programs on the system enable developers to allocate resources properly during design and implementation to ensure reliability and compatibility with other software.

In summary, software failures are mostly caused by human errors. Because humans are sometimes unreliable, that doesn’t mean the software cannot be reliable. With careful design and good engineering as well as adequate testing methods along with future failure predictions, software reliability and stability can be achieved and the end-users can enjoy their experience with the software on which they rely.

If you are interested in learning more about New West Technologies’ payment and other software integrations, contact our sales team.

***

Charlie Wu has been a Software Engineer and Developer for over ten years and has Computer Science and Computer Engineering degrees from Portland State University. In addition to developing software for retailers, Charlie enjoys building robots and other digital devices using STM32 and Arduino micro-controllers.