Quality Assurance and Testing Technology Case Studies
Industrial5 Case StudiesUpdated Sep 2026
Quality assurance in industrial settings rarely fails inside the test lab. It fails on the line, in the historian, on a network segment nobody documented, or in a model someone trusted because it was fast. The five cases below come from stamping, fittings, packaging, metalworks, and cable assembly operations. Each turns on a decision made with incomplete evidence while production kept running. Read them as working notes rather than templates. Pay attention to who was waiting for an answer, what the team could actually measure, and which constraints they could not negotiate away.
Case Study 1
Vision station rejects climb after weekend release
Marrow Creek Stamping Works, a mid-sized maker of stamped brackets and housings for agricultural equipment, running three press lines on two shifts.
The situation
The release went out on a Saturday, which the plant had done for years without trouble. By the second shift on Monday, the automated vision station on press line two was rejecting about 9 percent of brackets, up from a steady 1.5 percent before the change. The rejects clustered in the first hour after each tool change, and the inspection queue backed up behind the station until the operators began pulling parts by hand. Dmitri, the controls engineer on call, could see the station's throughput had dropped by almost a third. Nobody could say yet whether the problem sat in the camera firmware, the new recipe template, or the middleware that pushed part records to the line database.
The challenge
The plant manager, Renata, had two commitments that pulled in opposite directions. A major customer's shipment was due at the end of the week, and the bracket order could not slip. At the same time, a bad part that reached assembly would trigger a field return, and the customer had already flagged this part family in its supplier review. Halting line two entirely would cost roughly 400 brackets an hour. The team had about ninety minutes before the day's first truck was loaded.
Analysis
Before anyone touched the release, Dmitri and Renata agreed on what the recovery had to protect. The objective was not zero rejects, since no one could reach that quickly. It was a defect escape rate that stayed inside the customer's agreed limit while output recovered. Teams grounded in Quality Assurance and Testing Technology usually start by sorting evidence into what is recorded and what is inferred. The station logs gave timestamps for every rejected part, the camera image archive held samples from before and after the change, and the middleware audit trail showed which recipe version each shift had loaded. Missing was a direct comparison of old and new recipes on identical parts.
The constraints shaped every option. Pulling the camera firmware back would have meant a full validation run that the quality group could not finish before the truck left, and the controls team had no tested rollback for the recipe database. Stopping the line cost about 400 brackets an hour. Slowing it to a manual sort kept output near half speed but put operators in front of parts they could not judge reliably. Stakeholders were uneven: the customer quality contact wanted a written containment plan, the operators wanted clear instructions rather than rumors, and the finance lead wanted the cost of rework tracked separately from scrap.
- Contain Hold suspect parts and freeze the recipe to a known good version.
- Diagnose Reproduce the fault on a spare unit using archived images.
- Restore Return line two to rate under the agreed escape limit.
- Prevent Replay archived images before every recipe release.
Actions taken
- Dmitri froze the recipe template to the last known good version and routed line two's inspection results to a second, read-only logger so the evidence stayed intact while the fix was tested.
- Renata set a containment rule that every part made in the first ninety minutes after a tool change got full manual inspection, and the customer contact received the written plan that afternoon.
- The controls group reproduced the fault on a spare station using archived images from before and after the change, and confirmed the cause before any firmware was altered on the live unit.
- Once the cause proved to be a threshold default in the new template, the team added a pre-release check that replays archived images through the recipe and blocks deployment when reject rates drift.
Results
Line two returned to full rate by the end of the shift, and the escape rate stayed inside the customer limit with no suspect parts shipped. Containment added about 1,100 labor minutes of manual sorting and rework, which the finance lead tracked apart from scrap. Reject rates settled near the old baseline. The pre-release replay check caught a similar threshold drift in a later release before it reached production, and the customer accepted the written review without a site visit. The main lesson was that the rollback path had been assumed, not tested.
Questions for discussion
- Which evidence would have let the team rule out the camera firmware earlier, and how should that evidence be preserved during a live incident?
- Which parts of the rollback path should have been tested before the release, and who should own that test?
- How should a plant weigh a known escape risk against a certain loss of output when the customer review is already open?
Case Study 2
Three yield reports that disagreed by two points
Quellin Forge Group, a producer of machined steel fittings with three plants and one central reporting team.
The situation
The monthly yield review had been running on three numbers for most of the year, and no one in the room trusted all of them. The plant historian reported first pass yield for the forging cells at one level, the enterprise resource system reported scrap at another, and the quality dashboard that fed the board showed a third figure that differed by a few points on most weeks. Each report had an owner, and each owner could explain their own method. Sofia, the quality director, needed one figure she could defend. Ahmed, who led the analytics group, suspected the gap came from how returned castings were counted, but he had not yet shown it.
The challenge
The board meeting was in the third week of the quarter, and the capital request for a second heat treatment line depended on the yield story. If the figures were wrong, the case would weaken and plant managers would stop trusting central reports. Ahmed's team had a limited window: two weeks of raw extracts, no direct access to the historian's source tables, and a reporting freeze that the finance group enforced at quarter close. They had to learn what each number meant before choosing one.
Analysis
The goal was narrower than fixing every report. Sofia needed a yield figure that matched the physical count of castings on the floor, with a written definition that the plants accepted. Evidence was the first thing the team sorted. Good reconciliation work usually starts by tracing each figure to its source rows before comparing totals. Ahmed's group pulled the lineage for each report and found that the historian counted a casting once at the cell, the ERP counted it again when it returned for rework, and the dashboard counted returns only when they were closed. None of the three was simply wrong.
Constraints narrowed the fix. The finance group would not reopen closed quarters, so any correction had to be presented as a method note with a restated comparison alongside the original figures. The historian was owned by the plant controls team, which allowed read access but no schema changes. Plant managers had built local habits around their own numbers, and a change in the board figure would reach their bonus conversations. Sofia wanted a single definition that could be reproduced by anyone with the extracts. Ahmed proposed adding a reconciliation table that showed each plant's count at every hand-off point, which made the disagreement visible.
Actions taken
- Ahmed traced each of the three reports to its source rows and wrote the lineage on one page, so every plant manager could see which rule produced which figure.
- The team agreed a single yield definition that counted each casting once at final inspection, with rework tracked as a separate, reconciled measure rather than folded into the headline.
- Validation rules were added at each hand-off so that a casting missing a cell record, or present twice in the same week, raised an alert before the weekly pack was built.
- Monitoring focused on the gap itself: a daily check flagged any plant whose reconciled count moved more than one point from the prior week, with the owner named on the alert.
Results
The restated figure differed from the dashboard by a little under two points, and the gap was almost entirely returned castings counted on different dates. The board received the corrected method note with both series shown, and the capital request went forward on the restated yield. In the following quarter, the reconciliation check caught a double-loaded batch at one plant within the first day, before it reached the pack. Plant managers still disputed the bonus effects, and that talk moved to finance. Two of the three reports now share a source table.
Questions for discussion
- Which of the three reported figures would you have chosen as the starting point, and what evidence would have changed that choice?
- How should a team decide when a finance freeze should delay a correction, and when the correction should go out anyway with a note?
- What would a reconciliation check need to measure to catch a problem that all three systems agree on?
Case Study 3
Overnight traffic from a packaging engineering workstation
Teague Harbor Converting, a maker of folding cartons and flexible pouches running four converting lines on a shared controls network.
The situation
The alert came from the network monitoring tool after two in the morning, when an engineering workstation on the controls network began sending outbound traffic to an address the plant had never seen. The machine was used only to load recipes into the sealing and printing controllers. Marisol, the night controls technician, found it running slowly, with an unfamiliar remote session tool and a log-in from a service account that had been disabled months earlier. She disconnected the network cable before anyone had decided what that meant. Nobody knew whether the account had been reused, whether the workstation had been used as a stepping stone, or whether the outbound traffic was a misconfigured backup job.
The challenge
Business objectives were the first constraint. The converter had two customers with food-contact packaging and a brand audit scheduled for next month. A changed print parameter or an altered recipe could produce packaging that passed inspection but carried a labeling error, which would be a recall matter. Line leaders wanted the lines running, and the plant had no spare controllers for a clean rebuild. Management had to decide within the shift whether to halt the sealing line, and the security lead had only partial visibility into the controls network.
Analysis
The scoping work came first and it asked which controllers the workstation could reach and which recipes it had touched in the last ninety days. The firewall logs recorded the outbound session, the event log showed a disabled service account authenticating at the odd hour, and the recipe server kept version history for each controller. Missing were memory captures from the machine before it was disconnected, and a list of every credential stored on it. Experienced responders know that a disconnected host is not a clean host, so the plan began with logs and backups rather than the device itself.
Constraints shaped the response more than the threat did. The sealing controllers could not be taken offline without a supervised restart, and the vendor's support contract covered only remote assistance during business hours. Pulling the disk for forensic imaging would have taken recipe control down for at least a shift, while leaving it on might let an attacker keep a foothold. The security lead captured powered memory through a documented procedure, imaged the disk, and rebuilt from a known clean image. Stakeholders included the quality manager, who needed to know if any recipe had changed, and the customer account team, which would have to explain any delay in shipments.
Actions taken
- Marisol kept the workstation powered and documented each step in the shift log, including the time, the account used, and who handled the machine.
- Access to the controls network was narrowed to two named accounts, and the disabled service account was locked at the directory and removed from every engineering machine.
- The team froze recipe changes on the sealing and printing controllers, then compared each loaded recipe against its last signed version before the line was released to run.
- The vendor was engaged for remote review under a written scope, and the incident record was shared with the customer quality contact under the existing supplier agreement.
Results
The memory capture showed a short-lived remote session that had reached the workstation through a stale vendor account and then stopped before touching any controller. Recipe comparison found no altered parameters on the sealing line, but the printing controller had one unsigned version that the team could not explain, and it was rolled back under supervision. Line one restarted by the end of the shift with a restricted account list, and the customer quality contact received a written summary the next morning. The team's written lesson was that the vendor account should never have outlived its project.
Questions for discussion
- Was disconnecting the workstation the right first move, given what the team knew at that hour, and what would a different first move have cost?
- How should a plant decide which accounts count as stale, and who should own the review of vendor access?
- When a memory capture cannot fully rule out an attacker's foothold, what evidence should be enough to restart a line that makes food-contact packaging?
Case Study 4
Edge inference versus central service for line cameras
Corvane Metalworks, a maker of machined aluminum housings with two plants and about 40 inspection cameras across its lines.
The situation
Corvane had moved its inspection to a central model service early in the program because it was the fastest way to get a working classifier onto the lines. That worked while volumes were small. As the second plant added cameras, the uploads began to queue, and the average round trip from camera to decision rose to about 1.8 seconds. The lines run at a pace that needs a decision within 600 milliseconds, so the rejected parts were being diverted late and inspectors were pulling them off conveyors by hand. Teodor, the platform engineer, noted that a link outage at the smaller plant stopped inspection outright.
The challenge
Corvane's board had approved a budget for a second plant's expansion with a stated cost per inspected part, and cloud charges were already above the approved figure. Any redesign had to keep images for ninety days for customer quality reviews. Security mattered as well, since unreleased part geometry could not leave the plant network under the customer's supplier rules, and current uploads were already under review. The team had two quarters to choose a design, and the cost of getting it wrong was another year of diverted parts.
Analysis
The options were clear enough to compare once the requirements were written down. Option one kept the central model but added a regional cache and a local fallback classifier. Option two moved inference onto a small edge device beside each camera, with models pushed from the central service and images kept inside the plant. Option three ran the full model on a single on-premises server per plant, with batch uploads to the central service for audit. The team had good evidence on current latency from the camera logs and a short benchmark of the edge device, but little data on link failures under load.
Teams grounded in Quality Assurance and Testing Technology score each option against workload first, then against floor failure modes. Edge inference wins on latency and keeps images inside the plant, but it means updating models on dozens of devices and proving each one behaves the same. The on-premises server is simpler to patch, yet it needs a capacity plan for the busiest shift and a maintained spare. Teodor preferred the edge option for reliability, the cost lead wanted the lowest monthly figure, and the customer's quality group wanted every image traceable to a model version. The plant engineering lead wanted nothing on the floor she could not service herself.
- 1Camera captureFrames leave the sensor at fixed intervals on each line.
- 2Edge inferenceLocal model returns a decision inside the line's time budget.
- 3Plant gatewayBatches images for audit and forwards only released geometry.
- 4Central registryHolds model versions, thresholds, and signed device approvals.
- 5Quality recordStores the image, the model version, and the final disposition.
Actions taken
- Teodor built a test harness that replayed two weeks of recorded camera frames through each candidate, measuring latency at the 95th percentile and the disagreement rate against the current classifier.
- The team ran a six-week pilot on one line with edge devices, keeping the old path live so inspectors could compare decisions and override either system without penalty.
- A written model registry recorded each version, its training images, its threshold, and the device group it was approved for, and no device accepted an update without a signed entry.
- Rollout moved one device group at a time, with an automatic rollback when the override rate on that group rose above the pilot level for two consecutive shifts.
Results
The edge option met the latency target with room to spare, and the disagreement rate with the old classifier stayed within the agreed band on the pilot line. Images stayed inside the plant, which satisfied the supplier rules without a separate review. Monthly cloud charges fell by about 60 percent once most uploads stopped, though the edge devices added hardware and maintenance hours that the cost lead had not fully priced. Two device groups had to be rolled back after a firmware fault, and each rollback took under an hour because the registry named the last good version.
Questions for discussion
- Which constraint would have to change before the on-premises server became the better choice for this group of plants?
- How should the team price the maintenance hours of distributed hardware when the cost case is built on monthly charges?
- What evidence about link failures would have been worth collecting before the pilot, and how long would it have taken?
Case Study 5
Automated lot release promises half the inspection labor
Dunmore Ridge Cable Assemblies, a maker of wire harnesses for vehicle and appliance customers, with one plant and four incoming inspection stations.
The situation
Dunmore Ridge takes connectors and terminals from about thirty suppliers, and incoming inspection is the slowest step before parts reach the harness line. A vendor proposed a model that scores a photograph of each incoming lot and releases it to stock when the score clears a threshold. The pitch promised roughly half the inspection labor and a faster path to the line. Hannah, the incoming quality supervisor, was not persuaded by the demonstration, which had used parts from the two largest suppliers under the same lighting. Her team's own lots varied in plating finish, tray color, and photo angle, and nobody had measured performance on smaller suppliers.
The challenge
The purchasing group wanted the vendor contract signed before supplier renewals in the third month, and the labor target was tied to the decision. A missed crimp defect could reach a vehicle harness, and a wrongly rejected lot could stall a line and strain a supplier relationship. The customer's quality agreement required documented human review for safety-related connectors, and the vendor could not yet say which part families fell in that group. Hannah had to define what evidence would justify any automatic release.
Analysis
Labor reduction was the stated goal, but the real objective was a disposition error rate the customer would accept. Hannah's team began by splitting the problem into two measures that the vendor's report had blended. The first was the false accept rate on lots that contained a real defect. The second was the false reject rate by supplier, which determined whether the tool would penalize small suppliers. Evidence was thin. The vendor's accuracy figure came from a test set dominated by two suppliers, and the plant's own sampling records covered only the last few lots per supplier. Hannah ruled out any threshold drawn from the vendor's numbers alone.
Human oversight works best as a designed part of the process rather than a fallback. Here that meant a reviewer sampling a fixed share of auto-released lots each week, with the sample drawn at random across suppliers so the review would catch bias as well as drift. The incoming dock had two inspectors on the day shift and one at night, and the vendor's integration could not hold a lot in quarantine without a manual release step. Stakeholders had different stakes. Purchasing wanted the savings, suppliers wanted fair treatment, and the customer's auditors wanted to see a record of every safety-related disposition made by a person.
- Before any releaseAgree metrics, build the stratified test set, and set limits.
- First week liveAutomatic release limited to suppliers with a clean history.
- Each week afterRandom sample reviewed; pause release on any disagreement above limit.
- After first monthCompare false accepts and rejects by supplier before expansion.
- Each quarterCustomer sign-off required before any safety-related family moves.
Actions taken
- Hannah and the vendor agreed on evaluation metrics before any threshold was set: false accepts on defective lots, false rejects by supplier, and reviewer override rate, each with a written limit.
- A stratified test set was built from lots of every active supplier, under the plant's own lighting and tray colors, and the model was scored on it before any live release.
- Automatic release was limited to lots from suppliers with a clean history, and every safety-related part family stayed under full manual disposition until the customer approved a change.
- A weekly review sampled released lots at random across suppliers, and any reviewer disagreement above the agreed limit paused automatic release for that supplier until the cause was found.
Results
The pilot covered three supplier groups over a full quarter of lots. The model cut manual inspection time on low-risk families by roughly a third, but it falsely accepted two lots with subtle crimp defects during the first month, both caught by the weekly sample before they reached a harness. Its false reject rate was about four times higher for one smaller supplier whose plating finish differed from the training set, and the team retrained with that supplier's lots before expanding. Automatic release now covers fewer part families, and the efficiency gain is smaller than the pitch.
Questions for discussion
- Which of the three metrics should carry the most weight in the decision to expand, and why might the vendor's report have hidden it?
- How large should the weekly review sample be before its results can be trusted for a supplier with only a few lots?
- What would have to happen for the team to restore automatic release on the safety-related families, and who should decide that?
Learning Resources
Industrial CASE STUDIES
China, India, United States, Indonesia, Pakistan, Nigeria, Brazil, Bangladesh, Russia, Japan, Mexico, Philippines, Vietnam, Egypt, Turkey, Germany, United Kingdom, France, Italy, Canada, South Korea, Australia, Spain.