This article walks through the fundamentals of FAT, how it differs from other testing phases, and how to prepare your system and your customer for a smooth buy-off.

Background

Before we dive into the topic of Factory Acceptance Testing, I want to outline an example of the Project Process DMC follows. After thousands of projects, DMC has found that a phased approach is the best way to make a system production-ready.

• Requirements & Specifications – DMC works collaboratively with the client to determine system requirements. This phase often culminates in a “System Functional Review.”
• Preliminary Design – DMC defines a Preliminary Design as a ~20% complete design, where the high-level architecture has been mapped out and identified risks have been evaluated to the point where a plan is in place. This phase often culminates in a “Preliminary Design Review.”
• Comprehensive Design – DMC defines a Comprehensive Design as an ~80% complete design, with the remaining tasks to be finalized during the Development & Fabrication phases. (i.e., what nuts and bolts will be used to mount the hardware). This phase often culminates in a “Critical Design Review.”
• Development – The software development portion of the implementation phase, where any custom software is created and tested.
• Fabrication – The hardware build portion of the implementation phase, where any hardware is assembled into a complete system.
• Factory Acceptance Testing – The point in the project process where DMC validates the system prior to shipping it to the client site.
• Site Acceptance Testing – The final validation testing performed after the system arrives at the client site.
• Training & Support – After delivery and acceptance, DMC can provide training on using or extending the system, as well as support for troubleshooting and future improvements.

Learn more about DMC’s Project Management that makes this flow happen.

Project Specific Customizations

At DMC, we understand that not all projects are the same, so the Project Phases are customized on an individual project level.

• If a customer already has a well-defined Requirement & Specification document, we can jump straight into the Design phases.
• For small projects, we might combine “Requirement & Specification, Preliminary Design, and Comprehensive Design” into a single “Design” phase.
• For software-only projects, we remove the Fabrication phase and may combine “Factory Acceptance Testing and Site Acceptance Testing” into a single “Testing” phase.

Now that we have a better understanding of DMC’s typical project process, let’s talk about how we can prepare for a successful Factory Acceptance Testing phase.

FAT vs. SAT vs. ATP: What’s the Difference?

Before we dive into any details, let’s define terms that will be used in this blog.

Factory Acceptance Testing (FAT)

FAT is testing at the fabrication location to verify that the system meets the agreed-upon requirements before shipment. FAT focuses on testing that can be performed without the systems or hardware only available at the customer’s facility.

Site Acceptance Testing (SAT)

SAT is a test conducted after the system has been installed at the customer’s facility and is the first opportunity to test with systems or hardware only available at the site. SAT will often repeat tests performed during FAT to ensure the system wasn’t damaged during transport.

Acceptance Test Plan (ATP)

The ATP is the test plan used to execute FAT or SAT. It defines what is tested, how it is tested, and what constitutes a pass or fail. A well-written ATP is essential for efficient execution and clear customer sign-off.

What Does a Successful FAT Look Like?

FAT is successful when all parties are in agreement that the system meets its requirements and is ready for shipment to its final location.

How Do We Ensure FAT Is Successful?

Preparation is critical to ensuring that FAT is an efficient and productive use of time. We will dive a little deeper into how we can maximize testing prior to FAT, define participation and roles during FAT, and how to develop the ATP.

What Testing Should Occur Before FAT?

FAT should not be the first time testing occurs during the project process. Systems and code should be tested as they are developed. Testing strategy is a huge topic and will not be discussed further in this blog.

Who Participates During FAT?

At DMC, customer involvement during the FAT process is highly encouraged. At the end of the day, the customer will own and operate the system, so DMC strives to include the customer in as many aspects of our project process as possible. Some benefits of customer involvement during FAT are:

• A chance to make tweaks to the system without major cost or schedule impacts to the project.
• An opportunity to receive hands-on training with the team that developed the system.
• Provides an opportunity to identify gaps or misunderstandings in requirements.

Regardless of whether or not the customer attends FAT, they should be involved in developing the ATP. Ideally, either DMC or the client would write the acceptance test plan, while the other reviews and approves.

Typically, the customer should be responsible for writing the acceptance test plan to ensure complete test coverage and feel comfortable accepting the system at the end of the day. However, DMC engineers are experts and will often develop the ATP.

How Do You Develop an ATP?

Each item in an ATP should be clear, repeatable, and objective. In order to achieve this goal, each test should have the following core elements at a minimum:

• Test Procedure: Step-by-step instructions
• Acceptance Criteria: Objective pass/fail conditions
• Observed Results: What actually occurred
• Result Files: Logs, screenshots, or data files as evidence

Depending on your specific requirements, you can also consider tracking the Test Type, Test Operator, Test Date, and the approval status of Individual Results. If you’re looking for more information on why you might need an ATP, check out this blog.

Does the Order of ATP Execution Matter?

The order of individual ATP items is crucial for reducing the amount of time spent troubleshooting and debugging the system. The highest system-level impact should come first, followed by more narrowly scoped items. This narrows down potential causes of issues, reducing the overall time spent troubleshooting and debugging the system.

As you test systems and subsystems, start with the simplest components and add more complex capabilities sequentially.

A high-level concept for ATP Execution Order is as follows:

Conclusion

Factory Acceptance Testing is more than a checkbox. By involving the customer early, planning FAT thoughtfully, and executing against a clear, well-structured ATP, teams can streamline buy-off, minimize rework, and set the project up for long-term success.

The post Factory Acceptance Testing 101: Preparing for Customer Buy-Off appeared first on DMC, Inc..

• The fixture is finally working. The measurements are stable. The limits are all set.
• The PLC handshakes don’t fault out. Operators are trained, and parts are flowing.

Everyone celebrates because they should. Getting a new EOLT station deployed is hard work. But then something predictable happens: All the long-term improvement ideas, especially around data management, get pushed to “Phase 2.”

“We’ll come back to the data piece later.”

“Let’s get production stabilized first.”

“We’ll handle reporting in the next budget cycle.”

Except… “later” almost never comes. Once the line is running and hitting daily takt numbers, the momentum shifts to the next urgent project. The data pipeline, how results are stored, validated, structured, analyzed, or even found later, quietly fades into the background.

Meanwhile, the EOLT system is generating an enormous amount of valuable information. Every single test run produces signals that could help improve capability, reduce escapes, diagnose warranty returns, or drive Six Sigma improvements. But unless someone deliberately builds a usable data pipeline, those insights disappear into a pile of CSV files, neglected SQL tables, or are not collected at all.

This blog is about that forgotten half of EOL testing, and what you can do to finally unlock the value that’s already sitting in your factory.

Why EOL Data Is So Important, and So Underutilized

There’s often a huge gap between what leaders think is happening with EOLT data and what’s actually happening on the ground. The expectations typically sound like this:

“We’ve been keeping our test data stored somewhere.”

“It can be accessed by Quality whenever required.”

“We’ll be using this data for SPC once we stabilize production.”

“There’s another project that will be following this one to create dashboards.”

“This data has been cleaned and sorted already.”

In theory, the data is being scrubbed, validated, indexed, archived, and correlated with part numbers, revisions, and operators. And ultimately, used to improve the business. But the reality is usually very different. In most factories, this is what actually happens:

• Data is saved in inconsistent formats by different test stations and engineers.
• Pass/Fail Limits are not version-controlled.
• SQL tables live on a local PC with no backups.
• CSV files pile up in folders named “temp,” “new,” or “old system”.
• Dashboards and data portals never get built.
• Phase 2 never gets funded.

And even when data is stored, it’s often impossible to use:

• Test records include missing or mismatched fields.
• Metadata (revision, operator, equipment ID) is missing.
• Time stamps are inconsistent or incorrect.
• No one knows how to open a *.TDMS file.
• Data is unvalidated, unstructured, and untrustworthy.

Engineers want to use EOL test data, but the pipeline isn’t there. The result, EOLT data becomes “digital exhaust” instead of actionable insight.

What’s most concerning isn’t the volume of information generated, but the value it represents. Every EOLT run provides a window into the capabilities of your process, the state of your design, and the variance in your manufacturing operation. Essentially, it’s the best way for you to keep an eye on the quality of your manufacturing process.

However, without a defined path to capture, structure, and analyze this data, its value is lost, leaving critical insights on the production floor.

What You Could Be Doing with Your EOL Test Data

Your End-of-Line tester should do more than just tell you whether a part passed or failed. When that data is captured, organized, and connected across teams, it can become a powerful tool for improving quality, reducing waste, speeding up production, and making better engineering decisions.

A few of the highest-value ways to use EOL test data include:

• Catch process drift before it becomes a problem – By tracking key measurements over time, teams can spot trends, shifts, or out-of-control conditions before they lead to scrap, rework, or customer escapes.
• Understand whether your process is truly capable – Capability studies help show whether your process is consistently meeting specifications—not just passing tests, but doing so with enough margin and stability to build confidence.
• Make better decisions with trusted measurements – If the measurement system is not repeatable or reliable, the data can point teams in the wrong direction. Connecting MSA data with production results helps prove that the numbers can actually be trusted.
• Enhance testing boundaries and eliminate false failures – Information from previous EOL results can help a team improve their testing parameters, strengthen their weak spots, and ensure they don’t reject good items. It also helps to establish an audit trail for parameter changes.
• Reduce cycle time by removing low-value tests – Not every test adds equal value. By looking at fail rates, test duration, and correlation to real defects, teams can identify tests that may be redundant, rarely useful, or candidates for consolidation.
• Connect factory results to warranty and field issues – When EOL records are linked to returned parts or field failures, teams can identify early warning signs present during production. This can reduce warranty costs and help engineering improve future designs.
• Give each team the information they actually need – Operators, quality engineers, line leads, and product engineers all need different views of the same data. Role-specific dashboards and alerts help make sure the right people see the right information at the right time.
• Limits, set-ups, and software releases – It would be far more valuable if all EOL data could be tied to the specific test limits, set-ups, and software releases actually used during testing.

EOL test data is not just output data. When effectively utilized, it serves as a tool for process improvement, helping teams to enhance quality, minimize variations, reduce cycle times, and make sound product decisions.

The Reality: EOL Data Only Works If the Pipeline Works

Even the best measurements, fixtures, instrumentation, and limits won’t produce value if the data pipeline behind them isn’t healthy. And this is where most organizations quietly struggle.

An EOL test system is constantly generating signals: currents, voltages, timings, displacements, communication messages, temperatures, pressures, waveforms, vision metrics, operator interactions, PLC handshakes… the list goes on. But unless all of that information moves through a clean, reliable, structured pipeline, it becomes impossible to trust, access, or analyze later.

Most companies assume the pipeline will “take care of itself.” In practice, it does not. It requires planning, effort, and maintenance. Experience helps.

What a Healthy EOL Data Pipeline Requires

A robust pipeline needs several well‑defined components working together:

1. Reliable Data Capture – Every test must record the same fields, in the same format, with the same metadata. No missing values. No mystery columns. No different units for the same measurement.

2. Standardized, Versioned Test Records – Measurements, limits, station configurations, fixture revisions, and software versions must all be captured and traceable. When a number shifts, you need to know whether the product changed or the test changed.

3. Automated Reporting and Alerts – Data and analysis are worthless if no one sees it. A good pipeline pushes insights out automatically; it never waits for someone to “go pull the numbers.”

4. Clean, Structured Storage – Data needs to live somewhere durable and queryable (SQL, Azure, AWS, SystemLink, etc.). Not on a local PC. Not in a trove of CSVs on a network share. Not in arbitrary Excel files named “latest_results_FINAL2.xlsx.”

5. Full Traceability – Every record should connect back to the basics. Without this, you can’t trust the results: Serial number, Product revision, Limit set ID, Station ID, Operator, Test sequence version, Part configuration, Time and date, Equipment calibration status, etc.

6. Automated Data Validation – Bad records should be flagged at the moment of ingestion, not discovered months later during a recall analysis.

7. Easy Access for Those Who Need It – SPC needs Quality. Throughput/FPY needs manufacturing. Distributions/histograms need engineering. CAN logs need controls. Yield trends need leadership. Varied needs from varied perspectives, but they all point back to the same source.

Why Most Factories Don’t Get This Right

The underlying issue is simple: making the tester work gets all the attention, making the data pipeline work gets whatever scraps are left.

And typically, that means:

• Data “storage” is whatever the test automation vendor has implemented.
• Organizational structures evolve organically over the years and engineers’ careers.
• Important metadata is missing because it wasn’t captured from day one.
• EOL software revisions shift quietly without updating version fields.
• MES/ERP integrations never happen.
• Dashboards get deprioritized because “production is up.”

As products change, limits evolve, stations age, and operators come and go, the data slowly becomes inconsistent and disconnected. The further you go without a structured approach, the harder it becomes to fix the past, and the less likely the data will be trusted for meaningful decisions.

When the Pipeline Fails, Everything Downstream Fails

Without trust in the data, there’s no way to perform SPC analysis, capability study, limit adjustment, detect drift, troubleshoot warranty claims, shorten cycles, increase yield, or influence future design generations. Or, put differently: poor-quality data feeds make your cutting-edge EOL tester worthless – just a fancy go/no-go light.

And that’s a waste of capability and money. The moment you treat the EOL data pipeline like a business-critical process, test results transform from something that needs to be stored to something that can be learned from.

Why Companies Don’t Fix This, and Why They Should

1. EOL data projects are important, but rarely feel urgent

Most companies understand that better EOL data would help, but it often loses to more visible priorities like getting the line running, hitting takt time, passing audits, and shipping product. The problem is that once production stabilizes, “Phase 2” data improvements are easy to forget. By then, months or years of valuable production history may already be missing, inconsistent, or unusable.

2. Ownership is often unclear

EOL data usually sits between multiple groups: Quality, Manufacturing, Test Engineering, IT, MES vendors, and sometimes the system integrator. Because no single team clearly owns the data’s structure, quality, and usability, everyone assumes someone else is handling it. The result is fragmented data that may exist somewhere, but is not trusted or useful enough to drive real decisions.

3. Fixing the data pipeline is often one of the highest-ROI improvements available

Improving an EOL data pipeline usually costs far less than buying a new test system, but it can unlock major value: higher yield, lower scrap, better traceability, smarter test limits, shorter cycle times, and stronger warranty/root-cause analysis. When capital budgets are tight, this can be one of the smartest ways to get more performance out of the equipment a factory already has.

Conclusion: Stop Letting EOL Test Data Go to Waste

You don’t need a new tester to get new value. If your End‑of‑Line station is running but your data isn’t structured, trusted, or visible, you’re leaving yield, quality, and warranty savings on the table.

The fastest ROI today comes from transforming your EOL results into a clean, reliable pipeline that feeds SPC, capability, dashboards, and decision makers. It’s affordable; it doesn’t disrupt production, and it works with the equipment you already own—making it a smart move in tight capital years.

Maximize impact, treat the EOL data pipeline like a business process: capture consistently, validate automatically, store centrally, version limits/configurations, and surface insights to the right people. When you do, your tester stops being a pass/fail gate and becomes a continuous improvement engine.

Ready to explore our solutions? DMC specializes in modernizing EOL data without ripping and replacing hardware:

• Stand up a standardized results schema (with limit/config/software versioning)
• Build ingestion + validation pipelines from your existing testers
• Create SPC, capability, FPY, and spec margin dashboards
• Automate daily/weekly reports and alerts for quality and engineering
• Connect to MES/ERP and warranty/returns for closed‑loop learning

DMC’s Test & Measurement team routinely works in the latest test technology to help our clients uncover the value hidden in EOL test data. From NI software to Microsoft SQL Server, Ignition, Grafana and more, DMC can help you turn test data into a business intelligence asset.

The post End-of-Line Test: What to Do with All that Data? appeared first on DMC, Inc..

That’s why early engagement with a test system integration partner matters. Whether you operate in the automotive, aerospace, energy, semiconductor, medical devices, or consumer electronics, involving the right partner early can reshape your project’s trajectory, reducing costs, enabling innovation, and accelerating delivery.

Early Input Leads to Smarter Test Strategy

Engaging a system integrator like DMC early in the project lifecycle helps teams make better decisions sooner. During the exploratory phase, DMC provides critical insight into test requirements and system architecture, informing on project scope, uncovering cost-saving opportunities, and aligning test capabilities with production and program goals.

In one recent project, early discussions led to the decision to split a complex end-of-line test process across multiple stations. This modular approach allowed the customer to better utilize their most expensive asset (high-power battery cycling equipment) by moving test processes that do not require high power to lower-power, lower-cost stations. The result was a more efficient test flow and significant capital savings.

In another case, DMC’s Test and Measurement team proposed a high-power multiplexing system that reduced the number of test assets needed to meet production rates. By automating these connections with well-designed software, the team effectively shared the high-power, high-cost equipment across multiple test stations, saving the client over a million dollars.

And in a third example, a DMC customer initially requested a bed-of-nails test system for a printed circuit board assembly (PCBA). After initial discussions, DMC engineers learned that the test’s purpose was a basic functional checkout prior to further assembly. All required tests could be performed through the already-installed PCBA connectors. DMC eliminated the need for an expensive bed-of-nails fixture and replaced the device-under-test (DUT) connection with a cable harness terminated in custom-designed, high mating-cycle, pogo-pin style connectors. This simple change, along with a reduction in DAQ system precision and accuracy requirements, cut hardware costs by 50 percent.

Phase 1 Exploratory Projects Reduce Risk and Clarify Direction

A Phase 1 exploratory project gives you a low-risk way to validate assumptions before committing to major capital or locking in system requirements. These engagements are typically short, fixed-cost engineering efforts focused on answering the right questions early, when changes are still inexpensive.

During Phase 1, DMC works with your team to:

• Clarify test requirements and production constraints
• Evaluate multiple system architectures and test strategies
• Identify cost, schedule, and scalability tradeoffs
• Define a clear path from prototype to production

In one example, a one-week engineering sprint helped a client define requirements and lay out two test system concepts: an initial system to support early builds and a scalable production system for higher volumes. This early clarity informed capital planning, aligned stakeholders, and prevented costly redesigns later in the program.

Phase 1 projects are intentionally flexible. You can move forward with full implementation, adjust scope, or pivot entirely based on what’s learned. Regardless of the outcome, you gain a clearer understanding of risks, costs, and long-term implications. Early collaboration sets the stage for smarter decisions. Clients can choose to proceed with full implementation or pivot based on feedback from their integration partner, setting the foundation for a test system that meets today’s needs without limiting future growth.

Broad Expertise and Strategic Insight Across Industries

While some examples stem from battery testing or electronics, the same principles apply across industries. DMC’s engineers bring experience from hundreds of test system deployments across major industries and relationships with suppliers of emerging test and measurement technologies.

By engaging early, you gain access to lessons learned across platforms and applications, including:

• Selecting the right instrumentation and switching topology
• Designing scalable software architectures built for change
• Integrating safety-rated systems and compliance considerations
• Consideration of emerging test and measurement technologies

The cross-industry perspective of a test system integration partner can help you avoid common pitfalls and build systems that are cost-effective, flexible, and ready to evolve.

Conclusion: Don’t Wait, Engage Early

If your team is planning a new test system or preparing for a major upgrade, don’t wait until specifications are locked or problems surface on the production floor. Early engagement with a test system integration partner gives you better options, clearer tradeoffs, and fewer surprises.

Whether it’s a short exploratory project or just an initial conversation, involving DMC early can help reduce risk, control costs, and design a test strategy that scales with your program. The difference between a good system and a great one often comes down to decisions made at the very beginning.

The post It’s Never Too Early to Engage With Your Test System Integration Partners appeared first on DMC, Inc..

This article describes why developing a comprehensive Acceptance Test Plan (and then rigorously applying it) is important to overall project success.

Benefits of an Acceptance Test Plan

An Acceptance Test Plan provides many significant benefits to the project process.

Improves System Quality

Perhaps the most obvious benefit of an Acceptance Test Plan is that it provides a systematic, trackable, structured, and unified approach to performing system verification and validation.

Saves Calendar Time

Save time by parallelizing the work of fully defining test cases up front (as the Acceptance Test Plan is formulated), instead of doing this in-line (thus on critical project path) during actual commissioning activities. This minimizes total calendar time required for testing activities.

Reduces Engineering Time Spent on Testing

Writing a good Acceptance Test Plan takes time, but performing those tests takes even MORE time. Developing a complete Acceptance Test Plan in advance allows the full team to review and refine the plan prior to starting commissioning. This facilitates consensus agreement on what to test how it should be tested. This makes commissioning time more focused and productive.

The Plan Gets Utilized Twice for a Dual Benefit

The Acceptance Test Plan can be applied both during the upfront development level or “simulated” testing phases, and during final commissioning of the completed system. Thus, many of the benefits of an effective test plan get magnified. Although some aspects of the Acceptance Test plan won’t apply to the preliminary testing stage, there is still a significant ROI across the subsequent stages.

Guides and Supports System Development

Good test plans inherently flush out any ambiguities, gaps, or misunderstandings relating to system requirements. Applying these corrections sooner saves time and money.

Establishes Clearly Defined Milestones for Completion

Define successful completion of the project, or at least the current phase. A good Acceptance Test Plan avoids ambiguity or discrepancies on what it means for the system to be “working the way it needs to work.” Under the guidance of a good Acceptance Test Plan, all members of the team (both Client personnel and DMC) are striving towards a mutually understood goal.

Characteristics of a Good Acceptance Test Plan 

As a point of reference to everyone involved in the project, DMC suggests that a good Acceptance Test Plan should exhibit the following characteristics:

• Once it’s successfully executed, the Client is confident that the new system is properly doing its job, and that it will meet business needs.
• The Acceptance Test Plan should clearly define all test cases needed to accomplish the above goal. Each such case should:
  • Define the relevant input parameters and setup (both hardware and software) that need to be in place to start the test.
  • Define the process to execute that test case in clear, concrete, and actionable terms. This makes testing activities repeatable and self-documenting. Later, someone can look back and see a pass/fail result and exactly how it was created.
  • Define the expected results and/or pass-fail criteria for that test in clear, unambiguous, quantifiable terms. Tests should be broken down to a level where the answer to “Did it do what it was supposed to do” is a very clear YES or NO answer. 
    • Bad: The Configuration GUI screen operates as expected.
    • Good: When the “Save As” button is pressed, the operator is prompted with a “Browse” dialog, allowing them to select a file path and file name.  
    • Good: When “OK” is pressed on this Browse dialog, the program saves the parameter file in an INI format in the specified file path location with the specified file name. The parameter file shall contain all previously entered parameter values.

Return on Upfront Time Investment 

The following questions commonly arise when considering Acceptance Test Plan development:

Is it worth it to spend this time to define how the system needs to be tested, and exactly how each test will be conducted?  

Aren’t we smart enough to figure this out as we go along?

When developing complex, customized, and mission-critical systems, omitting rigorous system testing from the project process is NOT an option. Doing so may detract from the quality of the final system and risk unacceptable failures and issues.

It is true that defining the full process for each test case is no small task and will take some time. It’s critical to keep in mind that, to perform any commissioning tests, the work to define tests must still be completed at some point. 

We have two options for when to figure out these details:

• During acceptance testing – In this case, all work happens in-line with actual commissioning/testing activities. It is on the project critical path and adds time to overall project schedule.
• Before acceptance testing/commissioning – Include this information in a pre-defined Acceptance Test Plan. In this case, all time happens in PARALLEL to other critical path development activities, and IN ADVANCE OF actual commissioning activities. This effort is parallelized, off the critical path, and has limited impact on overall project schedule.

Another time-saving benefit is that, once documented in an Acceptance Test Plan, tests can be reliably repeated. If something fails once (which is going to happen many times in a complex system), having a good Acceptance Test Plan means that, after making corrective modifications to the system, any person will be able to conduct the same test in the same way it was originally done.  

Moreover, this can be done without needing to re-formulate the steps and without requiring that the exact same people conduct the test. An Acceptance Test Plan adds structure, documentation, and repeatability to the test process.

Who Should Write the Acceptance Test Plan? 

The generation of the Acceptance Test Plan should be a collaborative effort among all team members. Certain team members know specific aspects of the system better than others, and all members of the team are invested and share responsibility in making sure the system works properly and meets Client needs.

DMC suggests that the Client team is best suited to have primary responsibility for creating the Acceptance Test Plan.

Why is this the case?

The Acceptance Test Plan will be the primary way for the Client to exercise “quality assurance” over the new system and make sure it does the job it needs to do. When push comes to shove, “the job it needs to do” is a matter of the Client’s business needs. Thus, the definition of how to check if the system is doing its job (i.e., the Acceptance Test Plan) is most meaningful if it comes from the relevant stakeholders and end users on the Client’s team.

Additionally, having client stakeholders develop test cases creates a system of “checks and balances.” A supporting purpose of an Acceptance Test Plan is to verify that the developers correctly interpreted each requirement. For example, if DMC writes a test case about a particular requirement, it’s inherently based our interpretation of the requirement, which will naturally align with how we implemented that requirement. The system is likely to pass that test case, whether our requirement interpretation is accurate.

Therefore, it’s generally not best practice for developers to create the final test cases for their code. Test cases are often driven by those who are the “end users” of the given system. Having Client stakeholders develop test cases creates a system of “checks and balances” and enables the Client to act in an oversight capacity for system quality assurance.

Requirements Vs. Test Cases

A common view on test strategies is that testing should consist of going through the original requirements document and checking that each requirement is satisfied. This makes sense because a good Acceptance Test Plan should essentially be a set of test cases that provide 100% coverage of the system requirements. However, the requirements document is not an Acceptance Test Plan. There is a fundamental difference between a requirement (a statement of what a system shall be capable of) and a test case (a statement of conditions to establish, steps to follow, and criteria to evaluate to determine if a system is meeting a requirement). Yet there is a close correlation between requirements and test cases.

DMC recommends that one should reference the system requirements documentation while drafting the Acceptance Test Plan. We should be translating and expanding each requirement into a test case (or multiple test cases) that effectively checks whether the system is meeting that requirement. If we do this for each system requirement, we end up with a good Acceptance Test Plan that has 100% coverage of the requirements. 

The post Deciding If Your Project Needs an Acceptance Test Plan appeared first on DMC, Inc..