Blog

A universal test system software architecture

Are you developing test sequences using NI TestStand? If so, beware that a lot more goes into a full test architecture than test sequences. In our experiences, test developers often focus solely on the test sequences and code modules, leaving items like file management, hardware abstraction, operator interfaces, and result processing all but forgotten until you run into a problem. Unfortunately, these items often take longer to develop, and require more in-depth TestStand knowledge than the test sequences themselves.

The Material Review Board (MRB) usually consists of a meeting of personnel from Quality, Materials, Purchasing and Manufacturing engineering. The purpose of an MRB is to review rejected material for disposition. Disposition decisions are often made based on schedule requirements, material cost, availability of alternatives, or analysis of the defect. The MRB material of interest is Printed Circuit Board Assemblies (PCBAs).

(Me too!)

What is an interface?

An interface is the set of methods, messages, or VIs (think connector panes) that we use to pass data in and out of a software module. Simply put, what are the inputs and outputs, and how do they get in and out? A software module could be a class, a library, or simply a repository of VIs (in descending order of author preference).

Why are interfaces useful?

In the previous installment, we built a very simple program which consisted of a single actor and a single message.  In this part we will create an application that is a bit more complex.  This example consists of two actors: a DAQ actor which can read an analog voltage and a User Interface actor which provides a graphical user interface to display the data.  Let’s get started!

Scrum is powerful because it takes a large amount of work--for which estimating the total effort needed for completion is very difficult--and breaks it up into several 2-4 week long well-defined sprints. At the end of each sprint, the team delivers tested, documented, working code that the customer can immediately interact with and use to inject feedback into the next sprint cycle. Before the code is handed off, the team holds two meetings: the sprint review meeting and the sprint retrospective meeting.

Sprint planning meetings are held before the start of each sprint and are attended by product owner, scrum master and the entire development team. During the meeting the product owner describes the goal of the upcoming sprint and prioritizes the backlog of user stories based on that goal. The sprint goal is a concise description of what the sprint team plans to achieve in the upcoming sprint.

Agile software development methodologies are built to account for change.  As such, it is not necessary that the customer creates a detailed list of requirements before the start of the project or that the developers perfectly predict how long each requirement will take to implement.  Agile solves the problem by helping us make decisions based on the information we currently have. We create user stories for features that we can currently define and epic stories for feature sets that we need later but are not yet able to define in detail.

Effective scrum requires its participants to play certain roles and Bloomy’s scrum process is closely based on industry-standard scrum practices. A Bloomy scrum team consists of two to four Bloomy developers and one member of the customer’s team.  The customer’s team member acts as the product owner, while the Bloomy team includes at least one scrum master and one developer.  Both Bloomy and customer stakeholders provide support throughout the process but do not play a direct role in the scrum.

At Bloomy we use the agile scrum process to deliver the highest business value to our customers in the shortest amount of time.  Scrum allows us to deliver working software to our customers at the conclusion of each two week sprint so that they can interact with the software and provide feedback for the next iteration.  Ceremonies that encourage open and honest communication are central to the scrum framework and help to expose assumptions early by frequently incorporating customer feedback.