With the explosion of cloud technologies software development, testing, tools, and applications face a new set of challenges. One such challenge is determining if a non-native cloud application can be converted to work within and take advantage of a cloud. Such a migration brings about the potential for high reward yet increases scalability demands for development and testing in this new domain.
The viability of applications developed before the proliferation of cloud computing must be evaluated before migrating them into the cloud. Cloud environments offer pathways for increased product reach. This expanded reach comes with the expectation that non-native cloud applications will scale according to the potential for greater demand.
This paper demonstrates an approach for testing non-native cloud applications at cloud scale. Specifically, we will cover test design considerations, tooling, lessons learned, and key takeaways as we have worked to overcome these challenges.
Applying Continuous Integration principles and practices to embedded software is often frustrating and full of challenges unique to working alongside, on top of, and within a hardware-centric ecosphere. One such challenge overcoming a purely development environment mindset and attempting to test a customer experience before the product is in its final revisions.
This proposal covers three key concepts core to employing Continuous Integration in Embedded Software:
In order to test the physical product in an automated system then some accessibility exceptions must be made, but, to the smallest extent tolerable. When considering how to test a product then the ideal approach is to utilize methods available to end-users and abstract them so that the appearance of automation is simple and coherent for engineering to consume in day-to-day development. The number of physical configurations that a product could potentially be in often times far exceeds the number of prototypes available for testing. So, a method needs to be available that allow engineers to quickly and easily reconfigure an instrument without anxiety that they are potentially making a breaking change to automation.