When to use TestStand

[joshxdr]

For simple test flows, what TestStand does is fairly easy to implement with a custom software framework. Is there a rule of thumb as to what kind of application makes sense to use TestStand? I have studied TestStand for about 20 hours now, and I have found it difficult to learn. I don't want to add an extremely complex, single-purpose software tool to my test flow if I can accomplish the same thing with my existing general-purpose tools (LabVIEW in my case).

At one point I had assumed that TestStand was to enable sequential programming to LabVIEW, but I have since learned this can't be the reason. It is not hard to build a command interpreter with LabVIEW that interprets a text file, and can handle data logging, variables, conditional branching, etc. Is TestStand just for users who lack the programming sophistication to build this kind of application themselves?

[Teds]

What do you mean by?

At one point I had assumed that TestStand was to enable sequential programming to LabVIEW, but I have since learned this can't be the reason.

I wouldn't rule out TestStand, yet as you only gave it 20+ hours.    What exactly were you trying to accomplish with TestStand?

Thanks,

PH

[j_osh_o]

LabVIEW can be a bad solution for a sequential type of operation (like executing the steps of a test flow) if you only use a long string of vis. A test flow is a long list of events that happen one after another, and it needs to very flexible and configurable. If you just chain together a bunch of VIs, you would get a LabVIEW program 30 screens wide. This is very bad. When I was a LabVIEW n00b I assumed that TestStand had been invented to solve this problem.

I was able to make a solution using LabVIEW to implement test flows without using TestStand at all. I didn't really need to use LabVIEW, I could have used C or any other language. This program was for test set "A". This program works by using a state machine that loads a list of commands from a text file into a queue and executes the commands in order.

I have another test set (platform "B") that I am updating with new software. I am not sure whether to re-use my old state machine code, or to try TestStand. At this point I am very disappointed with TestStand. It is very difficult to learn. It has aspects like "models" and "callbacks" that add complexity but are not useful for my application. The default user interface and data log format do not fit my needs, so I would need to replace the stock data logging and user interface elements with my own.

So my question to people that use TestStand is, what is the advantage to using this tool vs spinning your own solution? What is supposed to be the core value of TestStand? What is the advantage of spending 100 hours learning TestStand and spinning my own custom interface vs creating my own test flow sequencer?

[RaviShrigiri]

TestStand is a test management software.

Few advantages of using TestStand :

Support multiple language - LV,CVI,C#,C++ ( your drivers can be in any of these languages)

It allows you to stored data to Dbase,Print reports.

Connectivity with source control software

Connectivity with switching executive,Requirements gateway,etc

Forums available for discussion.

Some of the problems you may face when using your own solution :

Testing of the solution

Maintainence of the solution ( flexibility)

Training on the solution ( assuming there are other people involved who will also use this solution)

Did you try the examples of TestStand?

[Rodéric]

IMO, TestStand brings very usefull frameworks that you can customize to suit your needs. those frameworks are robust and tested!

If you want to do what you need in LabVIEW you will have to build your framework from scratch and it may contain bugs, plus you will create something that already exists and its called TestStand. 

but when it comes to the field, you end up with the technology your customer is more familliar with...

[.aCe.]

I would also like to add that by having a text file interpreter in LabVIEW you are effectively restricting yourselves to one thread. You can of course write your interpreter to generate parallel threads which then makes the interpreter complex as you will need to address synchronisation, thread safety and other complications that come with it. There are always situations where you need to monitor something in the background even in simple testing scenarios, I find.

[Rodéric]

You can always do what TestStand does in LabVIEW or whatever programming language but it might take a lot of effort. I built a system with 2 batch of 16 UUT in parallel I whish I could have used TestStand...

[joshxdr]

Thanks to everyone who commented on this thread. The general impression I get is that TestStand is good if you start from zero, and you have a complicated production test with with multiple UUTs that benefits from multithreading.

I have only a single UUT, I don't require any kind of multithreading. I have already created a command interpreter, GUI, and data logger for another project. So in my case I can modify what I already have to suit the new application. So I get the impression that TestStand is not the answer for me.

There are some parts of the design of TestStand that I am not keen on. There are things hidden behind the scenes, like models and entry points. There are also "preconditions" and "postconditions" in the flow that are difficult to see, so it is hard to tell at first glance what the flow is doing. TestStand seems to be trying to be all things to all people, so it is chock full of features, and is very complex. A lot of the commenters seem to really like it, so maybe I will revist this tool in the future if I have a requirement for multiple UUTs.

[Teds]

Not always.  I wrote an operator interface we use for functional testing of about 50+ CCA.  All tests are run using Single Pass and are selected automatically when the barcode is scanned on the CCA.  One of the things we liked was the user permissions: Operator, Technician, etc.... was already setup in TestStand. Additionally, the database functionality is already done.  We have to switch databases from a local access configuration to a networked Microsoft SQL implementation, and it was a matter of changing a couple files.   I don't know how long that would take to do in LabVIEW.

The thing I wish was made easier was the reporting, it is still a challenge for me to go through and figure out exactly what is going on.

Plus the thing I like best is that you can FOCUS on writing code to test your product and NOT have to worry about debugging the operator interface code provided by TestStand.

PH

[joshxdr]

I think some readers of this post have misunderstood my question. Every tool has its place. Just because you have a hammer does not mean every problem in the world is a nail. TestStand is a tool like any other tool. What situations are the best for applying TestStand as part of your solution?