Building a software test and regression plan
By Darryl Koivisto and Deepak Shankar, Mirabilis Design
Embedded.com (07/20/09, 07:54:00 PM EDT)
Coming up with a Test Plan is the hardest job in a product company. Engineers like to develop cool products; marketing likes to tout the list of features; and QA/Test lingers in the background with little investment and a very tiny place in the schedule. Productivity is only as great as the quality of your product.
This article discusses our experience at Mirabilis Design in developing a comprehensive test and support plan. The complexity of the software required that we split the testing into sections- Graphical User Interface, feature library, Documentation, Web Links, Simulator or analytics and Database. This allowed some of the tests to be be fully automated while others require visual inspections.
The purpose of the test plan is to maximize the product quality, test the largest number of operating scenarios, ensure that models are upward compatible and identify incorrect operations.
In addition, the Test Plan is designed to address several unique features. In the case of our software these were mixed domains simulation and hierarchical considerations for memory, virtual connection, and virtual machine operations. In our discussion of the plan we came up with we will describe these aspects of software testing:
Embedded.com (07/20/09, 07:54:00 PM EDT)
Coming up with a Test Plan is the hardest job in a product company. Engineers like to develop cool products; marketing likes to tout the list of features; and QA/Test lingers in the background with little investment and a very tiny place in the schedule. Productivity is only as great as the quality of your product.
This article discusses our experience at Mirabilis Design in developing a comprehensive test and support plan. The complexity of the software required that we split the testing into sections- Graphical User Interface, feature library, Documentation, Web Links, Simulator or analytics and Database. This allowed some of the tests to be be fully automated while others require visual inspections.
The purpose of the test plan is to maximize the product quality, test the largest number of operating scenarios, ensure that models are upward compatible and identify incorrect operations.
In addition, the Test Plan is designed to address several unique features. In the case of our software these were mixed domains simulation and hierarchical considerations for memory, virtual connection, and virtual machine operations. In our discussion of the plan we came up with we will describe these aspects of software testing:
- Background, Scope, Defects and Failures, Compatibility, Input Combinations and Preconditions, Static vs. Dynamic Testing, Software Verification and Validation, Software Testing Team, Software Quality Assurance (SQA)
- Concept of Baseline Functionality
- Baseline Libraries
- New Libraries Based on Baseline Functionality
- Regression Testing
- Other Specific Block Issues to be Addressed
To read the full article, click here
Related Semiconductor IP
- nQrux® Root of Trust IP
- AXI to UCIe Bridge IP
- UCIe 2.x Controller IP
- SWI3S (SoundWire I3S Interface) Peripheral Controller Core IP
- OpenTitan-based RISC-V Secure Element
Related Articles
- Introduction to and Regression Test for OCP SystemC Channel Models
- Developing a test plan to make your design HDMI 1.4 compliant
- Design clock controllers for hierarchical test
- Use test data to diagnose failed memory
Latest Articles
- A Secure dToF LiDAR SoC with Dual-Domain Fingerprinting and Event-Driven AFE Circuit Achieving Sensor-Level Attack Resilience
- ZTA-Q: an Open-source RISC-V Platform for Accurate Quantized CNN Inference
- Automated Pre-Silicon Verification of High-Speed DDR5 and LPDDR5/6 Memory Controllers: Closed-Loop Timing, Mode Register, and PHY Synchronization in UVM
- U-Sonic: An Open-Source 8-Channel Ultrasound Transmit IP in a 130 nm RISC-V SoC
- S-ALSA: Co-Design of Adiabatic Logic-based Sensing and Balanced Bit-Cells for Secure and Energy-Efficient MRAM