- Posted on: 2020-01-09
This is Part 2 of our 2-blog post series. Part 1 defined Unit Tests and Integration Tests, below we define Automated Tests and Endurance Tests.
3. An automated test means running the test the same way an operator would normal do it, except that the test is launched and monitored automatically (unattended). The goal of automated testing is to do more testing (and retesting) without spending man hours in the process. Various tools are available to help drive automation. For example, Jenkins is a popular, open source, Continuous Integration (CI) tool you can use to automate your testing in an agile development process.
Synovus typically uses a subset of the complete test plan, with real hardware where possible, as a reliable validation of the code.
4. An endurance test is an extension of an automated test. While the other tests are typically performed before, and after, each build (ideally before and after each commit). Endurance tests typically run 24/7 and are restarted either every week or every month. Their main purpose is to catch issues that will results in bugs after an extended period of time, so that your ATS can be trusted for the 28-day environmental test. As this step tends to be overlooked, it is the test manager’s responsibility to make sure that a good, test driven, approach to development is taken up-time maximized so the ATS can be relied upon when running a long, critical test.
Where to start: We recommend test managers go with an iterative approach. In designing a test plan, we initially aim for ~60% coverage of the total envisaged testing and work towards that coverage. It is generally unrealistic, and cost prohibitive, to aim for 100% coverage initially. Then, as bugs are found, we iterate to increase the test coverage. For example, a new bug could be reproduced by creating a newUnit Test, then continue running that new test case forever to ensure that bug doesn’t creep back into the code.
A side benefit of all this work is that by running endurance tests 24/7 automatically with a DUT, you will also catch less frequent problems of synchronization or timing issues, un-wanted behaviors of the DUT that may otherwise be detected in your customers’ hands.
Conclusion: This blog has focused on how to automate testing of your LabVIEW. If you don’t have the time or available skill set to do this in house, we and other developers have the expertise, and the tools in place to help you succeed faster, and at a lower cost. Look up an Alliance Partner in your area.
Learn more about Symplify™ or request a demo.