Slow is Smooth and Smooth is Fast

Code Coverage as a Quality Gate

noreply@blogger.com (Unknown) — Sat, 08 Feb 2025 13:49:00 +0000

In software development, code coverage is one of those terms that really seems important. As software developers, we certainly make it important from time to time. What code coverage means to you, how you achieve it, and the value placed upon that number likely says more about you than the number itself.

The conversation around code coverage should always be based on the outcome needed (i.e. higher quality code) and not the number itself. Code coverage should be a signal of the system and never a hard line.

What is code coverage?

"is a percentage measure of the degree to which the source code of a program is executed when a particular test suite is run."
- Wikipedia

Meaning, the code was executed, not that it was correct.

Teams with emphasis on code coverage value itself may ship high quality code but how they arrive at that number is not generally sustainable and will be based more on ceremony than striving for the outcome of quality code.

Teams treat code coverage as a signal, and not the value, will likely have a higher and more sustainable approach to code quality based on the practices they employ.

The difference is the team culture.

Examples

A team that has a declared a code quality gate (e.g. 80%) generally follows this downward spiral

It's a new project, and they want to do it "right"
PR branches will have tests, however, branches that pass code coverage may still bring the main branch down just enough to fail the build for quality, even when the new code has near 100% coverage

The side effect of this is that it introduces chaos, and suspicion, as the new changes worked fine in isolation but fail as part of the whole, requiring additional effort, often orthogonal to the task at hand, in order to bring the code quality number for the main branch as a whole back up just enough to pass

Delivery pressure dips code quality below the threshold of 80%, so a new, lower threshold is set
Work is paused to focus on getting code coverage number back above the threshold - often not even valuable work
Rinse and repeat

This is not a healthy team cycle and is not sustainable as the code base complexity grows as it leads to an "exception based" or "yeah, but" style of delivery.

A team that understands quality is more than a number will generally

Write test for the important things
Treats tests as production code
PR branches will have tests
Observes signals in the system, including code coverage percentage. Other signals might be

bug backlog
number of incidents
quality of the tests, i.e. ease of change

Observes the system as a whole to see where improvements needed, pausing work to improve overall throughput, and quality of the system
Rinse and repeat

This is a sustainable team environment that takes a more end-to-end view of quality and not just a number. The difference is the team culture and how they understand the why of it all.

Configuration Management with Azure App Configuration

noreply@blogger.com (Unknown) — Thu, 06 Feb 2025 22:22:00 +0000

For a variety of reasons, you might find yourself changing configuration (settings, connection strings, credentials, etc.) and then having to touch all the applications that consume that configuration. Once that happens, we can start looking at lifting out and centralizing that configuration somewhere else. Microsoft refers to this as the External Configuration Store pattern.

Move configuration information out of the application deployment package to a centralized location. This can provide opportunities for easier management and control of configuration data, and for sharing configuration data across applications and application instances. — Microsoft Architecture Center: External Configuration Store

Using Azure App Configuration as the system of record for configuration can help manage, version and audit that configuration. Other software/services exist (i.e. Vault, Consul) but as most of the services we are building today leverage Azure PaaS Azure App Configuration is a good fit.

There are three patterns we’ve used when building applications and managing their configuration.

Manually configure per environment
Configuration on Deploy
Configuration on Startup

Manually Configure per Environment

We are including this here for completeness but the only acceptable use for manually applying application configuration is prototyping or a VERY small footprint. There is very little traceability here when changes are made, why they were made, and they are less likely to be reproducible.

Configuration on Startup

Using the configuration on startup pattern, the service only has context of an identity, configuration key sets (labels, tags, name filters, etc.) and the configuration endpoint. The service authenticates to the configuration endpoint on startup, retrieves its configuration, and applies before continuing with its boot process.

Pros

Applying of configuration is “IN YO FACE”
Changing configuration doesn’t require restart/redeploy

Cons

Applying of configuration is “IN YO FACE”
Authenticating with DefaultAzureCredential is often very slow, which is lag for developer feedback loop

Configuration on Deploy

Using the “Config on Deploy” pattern, the configuration for the service is applied when the service is deployed. The service then loads configuration by conventional means (local.appsettings.json, appSettings.json, environment variables, etc.).

Pros

Configuration is more of Operational concern and less of Development Concern
Leverages traditional IConfiguration, IOption, and related programming models
Better traceability for how to resolve configuration
Managed Identity is not required for configuration (but still worthwhile!)

Cons

Applying of configuration is a pipeline activity
Changing configuration requires re-deploy

How to Publish Configuration?

Most configuration is published either from the system, or application, pipelines themselves. For example, a system level resource like an Azure Blob storage location will be created (using Azure Bicep via pipeline) and its key will be published, along with a naming convention for retrieval, to Azure Application Configuration. An application level resource, like an Azure Function, can also publish (again using Bicep via a pipeline) to Azure App Configuration.

How to Consume Configuration?

Consumers of configuration, such as pipelines or services, will read Azure Application Configuration, using the agreed naming conventions, and then apply that configuration using either the Configure on Startup or Configure on Deploy patterns.

What about Local Development?

AZ CLI PUSH/PULL config

Possible Additional Improvements

Strongly typed configuration via Option. Today, we use _configuration["config_key"] frequently. This is likely fine for small, less complex components. However, we have some that might benefit from strongly typing the configuration. Aides in understanding, traceability and refactoring.
Validate configuration as early as possible, not on first access. ie. When the service starts, we could validate that we have all the configuration required for the service to run instead of waiting for methods to be called.

Falling into Functional

noreply@blogger.com (Unknown) — Thu, 06 Feb 2025 21:43:00 +0000

Picked up a copy of Domain Modeling made Functional - Scott Wlaschin over the Christmas break for a couple of reasons:

An interest in domain driven design
An interest in modeling business domains using F#

The first ~60 pages of this book should be required reading for any team, including stakeholders, as a primer for vision of a "how to" when it comes to modeling the business. Think it will really help get some alignment quickly with a few short.

The expressiveness of F# is impressive - especially when it comes to eliminating 'primitive types' and building that vocabulary.

I love the idea of domain driven design. I know what it looks like when its healthy and know what it looks like when it's more of a cargo cult. This book cut through most of the cheese with a "just do it" approach that avoids a lot of the pitfalls that tend to derail.

Recommended.

Software Delivery Bottlenecks - Deployment

noreply@blogger.com (Unknown) — Tue, 03 Apr 2012 02:29:00 +0000

Seems that the business waits on software developers, who have waited on system administrators, who have waited on infrastructure engineers to produce the ecosystem required for today's software applications, while waiting on the business to produce the contracts, by which the business can legally operate.

Looking at the most simplistic example of the macro tasks involved in a software project we have:

develop software
runtime environment(s)
deploy software

If we assume an admissibly arbitrary cost of 1, for our tasks, and fundamentally all tasks being equal, then we can create a simple formula to help describe the bottleneck in our software delivery process.

We do have to account for things we do many times or iterations. For instance, we will deploy software through more than 1 environment. While the software hasn't changed, but we still have the overhead of the deployment cost.

Example

assumed cost of 1 arbitrary unit
multiplier N, where N is equal to the number of iterations, which will be 5.
multiplier E, where E is equal to the number of environments, which will be 4 (Development, QA, Staging, and Production)

The Cost of Doing Business

develop software (1 * N) = (1 * 5) = 5
provision hardware (1 * E) = (1 * 4) = 4
deploy software ((1 * E) * N) = ((1 * 4) * 5) = (4 * 5) = 20

Of course, this is a very simplistic view, contrived to drive the point home that deploying software can have a very high overall cost of a software delivery. Deployment is an area of the overall software delivery process that can bring an almost immediate value in economy of scale as the number of servers, and number of environments, increases.

Automate those things that have a high rate of repeatability. Don't be surprised, removing one bottleneck will typically force another bottleneck into the light and we address those one at a time.

People, Process, and Automation.

Lather, Rinse, Repeat.

Guys Weekend - The Potato Gun

noreply@blogger.com (Unknown) — Sat, 08 Sep 2007 02:38:00 +0000

Every once and a while my Dad, my Brother and I get together just to goof off outside the scope of normal family visits. A chance to just relax, swap stories, brainstorm how to change the world, and act well, like kids.

My Brother owns a house overlooking Lake Travis in Jonestown, TX [northwest of Austin], he's got the nice boat, a great entertainment center, you know...all the toys. What he's lacking is a good guest bed and some food on the shelves [bachelor], but that can all be remedied. Dad usually arrives on his motorcycle [from Conroe] at the crack of dawn and I'll roll in around noon [from Dallas].

Prior to arriving, my Dad forwarded the following video of a 'potato cannon' to us. It was to become our inspiration for the trip. I've linked to it below in case your interested.

Once we saw the video [you can stop after a couple minutes, you'll get the point] the inner child in us was raring to go! We bought all the necessary components from the local True Value hardware store and the requisite 10lbs of potato's and a can of 'Aquanet'. Less than an hour [and a few beers] later, we had built the toy d' jour and it was awesome. You can see some of the pictures below and hopefully Dad will rip the video he took off his camera and get it to us so that we can see it.

This contraption literally shot a potato a hundred yards down the side of Jason's property!

Now, we realized that we were doing something dangerous [and quite possibly illegal] so we rationalized who would go first. We couldn't let Jason go first, he as the only one of us with any medical training [over 10 years as a paramedic], if anything went wrong we'd need him. They wouldn't let me go first because I've got a wife and two kids. That left Dad. Dad was barely able to contain himself just waiting for us to quit fooling around and give him the damn thing..

Of course, after all that deliberating [inebriating], Jason goes and sticks his face right up to the combustion chamber just as I am testing the 'spark' for what we thought would be a misfire. Well, the picture can be found in the group below! The irony is that we've grown up with guns our entire lives and gun safety has always been a priority.

Guys Weekend 2007 - The Potato Cannon

We enjoyed ourselves so much that we are going to each make one, with a little different design and definitely with a personal touch. Jason has already got his Halo design worked out.

We also spent a lot of time rocking the hilltop on Guitar Hero 2! I've got to get this, it is still the best game I've played in a long time. I still can't believe they've yet to release the wireless controller for the XBox 360! What kind of sick joke is that? Anyway, that's what I'm holding out for. Anyway, Dad won the cards with an all in late in the evening.

I had to cap off the weekend with a hangover and a burning desire to get back to my family [two sick kids] so called in on Sunday. Dad, Jason [and crew] still took Luscious out on the lake on Monday. I've yet to hear how that went.

Till next time..

Sea of Technology

noreply@blogger.com (Unknown) — Thu, 06 Sep 2007 02:46:00 +0000

I'm overdue for a rambling post, so here you go...

Just saw this article: InfoQ - Interview: Dino Chiesa on Microsoft's SOA Strategy (from BizTalk Server Team blog).

Of particular interest is the Microsoft ESB Guidance and the eBook ‘SOA in the Real World’. By the very nature of BizTalk, much of the work we do falls into the ‘service oriented’ design category.

However, BizTalk does not an SOA (or ESB) make. BizTalk can certainly be a core platform for delivering service oriented solutions and it certainly can be a key component for building a service bus.

This isn't a dive into how to develop service oriented solutions with BizTalk, or how to build an ESB with BizTalk. Its mainly about what skills you need to develop in order to swim in a sea of technology.

One thing that continues to be evident that it is not really possible to be just a 'BizTalk' developer without having a good grasp on at least the Microsoft technology stack.

The breadth of the technologies I've had to keep up with just seems to overwhelm compared to back when I was either just the 'UI Guy' (C++, Win32, MFC, a good understanding of the message pump and subclassing windows controls) or a 'Server Guy' (C++, Win32, STL and UI technologies be damned).

This is the short list:

.NET Framework - BizTalk is built on .NET and without a good understanding of .NET you won't be able to fully leverage the extensibility of BizTalk.
Sql Server - who doesn't need to store data? Who hasn't done this badly? A badly implemented data tier (including data access logic) can quickly become one of the most insidious of bottlenecks.
Xml - this is a technology stack unto itself. A working knowledge of Xml, Xml Schema, XPath and Xslt is pretty much required.
SOAP, WS-* - Pay attention to WS-BasicProfile and WS-Security. The rest are worth a look if your situation calls for it. Be wary about your interoperability story if you have heterogeneous clients consuming your services.
.NET Web Services (a.k.a. ASMX) - if you have any services in production, they are likely of the ASMX flavor. The initial service workhorse. Getting at least a passing familiarity of tcp/ip and http protocols really helps to understand what's going on at the 'wire'.
Windows Communication Foundation (WCF) - the WCF adapter is baked into the BizTalk 2006 R2 release. If your writing services today, WCF is the 'foundation' your likely starting with. Understanding the WCF programming model is key.
Windows Workflow - likely successor to the BizTalk orchestration engine. Actually, Tomas Restrepo has a good post that will make you go hmmmm... check out 'The Future of BizTalk/WCF/WF'. I've not realized the full potential for WF yet...but I know I want some of the IDE features with BizTalk! This is an area to keep an eye on for growth.
Debugging - learning what to do when it hits the fan, and it will hit the fan. Its a just a matter of time and it won't always be nice enough to occur in a development environment. Oh, no siree, it will wait to occur until your businesses critical time of the year/month/week/day, and it will hurt and you will have to fix it.

And lets not forget the plethora of bits that sit above these on the stack: Enterprise Library, the aforementioned Microsoft ESB Guidance, Testing, Source Control (e.g. TFS or Subversion), Security, the list goes on.

Oh yeah...that's why they pay us. Ok, then. Well, where do you start? Check out the following resources:

It starts with code. code. code. Build it. Analyze it. Learn from it. Rinse and Repeat.

Well, I've rambled enough for one night.

Test Process Template

noreply@blogger.com (Unknown) — Sat, 25 Aug 2007 18:01:00 +0000

No matter what type of testing you might be doing, it helps to have as part of your process a list of scripted steps to follow. Once identified, the list of steps will help make sure that you have consistency between test runs, and if automated, helps to get you back into a position to test again as soon as possible.

The following template is one that I've used for several years with success. What really helps get the extra mileage out of it is if you automate all, or most, of it using whatever scripting technologies work for you. My current personal favorite is NANT as the execution engine and then a suite of VBScript, or even .BAT files, that actually execute each specific step.

NANT's foreach construct makes it very easy to loop over a server list, getting consistent results across the board.

PRE-Test

Initialize Repository
1. Create folder(s) that will be repository for information from this test run. This will probably be something like a test label plus a run number. If your doing a lot of different types of testing, then it will make sense to have more meaningful labels. Otherwise, 'TESTRUN1', will likely work just fine. The important take away is that you need a friendly way to refer back to all the data that you will be collecting.
Capture Configuration
1. Copy all configuration files to the repository. The purpose of capturing the configuration is that you may need to correlate test results back to a specific configuration that was in effect during a particular test run. Examples of configuration files are: machine.config, web.config, app.config, .INI files. Consider exporting any registry settings to .REG files. If your using non .NET applications and services, then look for those files as well. Apache and WebSphere are two very file centric server applications.
2. Clear, or delete, any log files. Make sure that any event notification received should be from this particular test run.
Start Services
1. Identify the order that the services need to be started. Start services in preparation of the test run. These services are anything that your application needs to function: IIS, BizTalk, ERP or WMS services.
Start Monitoring
1. Make sure that your monitoring scripts fire up as well and that you are collecting data from the run. Unless your specifically measuring startup activity, you may wish to discard, or ignore, the 'warm up' period of your application.

Test

Begin any test scripts that will be driving the load for your applications. This could be automated testing such as SilkPerformer, LoadRunner, LoadGen, or even Windows Task Scheduler.

POST-Test

Stop Services
1. Most likely, if there is an order that the services needed to be started in, then you will want to reverse that order for shutdown. Many times you will need to stop services in order to execute the data collection.
Data Collection
1. Copy all log files to the test repository (e.g. application and server's such as IIS)
2. Copy all Windows event logs to the repository
3. Copy all performance (Perfmon) logs to the repository
Clean up
1. You probably have lots of 'data bits' floating around the test environment. Examples of this might be files in folder locations, MSMQ messages, rows in databases queues, etc.
2. Reset your data tier to a known good state. If your data lends itself to just flipping a status bit to get back to a known good state, then execute the SQL to do this. If not, then you will want to restore to your applications 'golden' backup.

Last Hope

noreply@blogger.com (Unknown) — Thu, 26 Jul 2007 02:07:00 +0000

Found a link to a cheeseball submission to gamedev.net from way, way, way back in the day. A screen shot is below. You can download the game here.

I can't tell you how absolutely amazed I was that it ran on my PC today!

Consider when it was written (2000), what the OS was (Windows 98) and what your technology stack looked like (Visual Studio 6, C++ and DirectX 7). Just think about that for a minute. No...not the fact that its some amazingly crafted piece of code (its not, but thanks anyway) that has withstood the test of time.

Think about the commitment Microsoft has put into the various levels of the application stack to make sure that future versions are backwards compatible.

That's really quite something.

It got me thinking...will the solutions I'm delivering today, be able to run, much less deliver value 3, 5, or 10 years from now? Its 2007. Do you know where your code is?

By the way, my current rig at home is running Windows Vista Home Premium with whatever version of DirectX ships with it. I don't make any claims it will work on your system, nor will I be held liable for making work (think I have the source though).

Another thing...my home development rig back then was a P400 with 128MB RAM. Woot!

Mary Kay ART Strategy

noreply@blogger.com (Unknown) — Thu, 19 Apr 2007 04:38:00 +0000

Project Dragon Application Readiness Testing

Supply Chain Systems

Strategy

The Mary Kay strategy for application readiness testing (ART) is to create an environment which will be similar to the production environment for purposes of executing tests. In addition to the necessary hardware and software components expected of a production environment, the ART environment also has available tools that are essential to the testing process, such as load generation and issue resolution.

Prior to implementing any new systems, or critical components, in a production environment it is expected that they will first be observed in the ART environment. The observations of the systems under test allow for the development of profiles for each application that will be used for planning future environments. These profiles consist of resource requirements for the systems under test such as network (bandwidth and utilization), storage and servers.

Having the environment available allows Mary Kay to test performance, stability and configuration of the different infrastructure, applications, and systems that make up the Mary Kay Supply Chain. Beyond having the hardware and software resources available is only part of the equation. To complement the environment, Mary Kay has identified personnel resources that are subject matter experts in areas such as application, hardware, network and platform architectures, all of whom are can be made available to help facilitate testing and just as importantly, analyzing the results.

Test Areas

There are key focal areas that have been defined for volume testing prior to the Project Dragon go-live.

J.D. Edwards and DSI

First and foremost is the Mary Kay enterprise resource planning system, J.D. Edwards and its new warehousing functionality that will be leveraged in all international supply chain deployments. This area was chosen for the following reasons:

Mary Kay is deploying a completely new version of JDE internationally, on an updated solution stack.
The JDE Advance Warehouse modules are new functionality to both this version of JDE and to the Mary Kay supply chain.
Mary Kay has made custom modifications to both JDE and DSI applications which need to be validated under load.
The RF traffic generated by DSI from the China remote facility to the Shanghai data center needs to be tested to be within defined user requirements for response time.

Business Process

Mary Kay will be developing both telnet and web based scripts to drive load against core functional areas as defined by the Mary Kay business team.

Distribution
Procurement
Shop Floor Control
Sales Order

Application Integration

Both BizTalk and DSI are planning to use the same inbound services ^¹ for JDE. Identifying the capacity of the planned hardware resources is required to identify if and when scale out of the JDE inbound architecture will be needed.

Enterprise Application Integration

Application and partner integration are critical to the success of the Mary Kay supply chain. These areas have undergone both architectural and platform upgrades, as well as new development, for the Dragon implementation.

BizTalk Server 2006

A key area for test around the Mary Kay BizTalk implementation is the throughput performance of the direct bound architecture and validating the capacity of the planned hardware resources. In addition, Mary Kay has introduced new transport protocol that has yet to be tested under load.

3PL Web Services

Mary Kay has implemented a service oriented messaging gateway for integrating with third party logistic vendors. This architecture needs to be tested to validate that it will meet production capacities.

Supply Chain Services

Mary Kay has implemented several key services that provide support for internal processes which need to be tested under production loads.

Workload Models

A workload model represents the execution of automated scripts which drive a determined amount of load against one, or more systems based upon certain characteristics. Mary Kay has organized the suite of tests into several individual workloads. Each workload has the ability to be executed independently, or concurrently, with other workloads.

Executing all workloads ultimately makes up the “Day in the Life Of” workload which best models the daily processes and volumes of the Mary Kay supply chain.

Distribution
Procurement
Shop Floor Control
Sales Order
Region to Region Integration
3PL Integration

Applications

J. D. Edwards

J.D. Edwards 8.11 SP1
8.96_D1 Tools
IBM Java Runtime
IBM Web Sphere 6.0.2.13
Apache 2.0.47
Microsoft Windows Server 2003 Standard SP1 x86
Microsoft Sql Server 2005 Enterprise Edition x64 SP1
Microsoft Sql Server 2005 JDBC driver

Data Systems International (DSI)

DSI dcLink 5.0
Microsoft Windows Server 2003 Standard SP1 x86
Microsoft Sql Server 2005 Enterprise Edition x64 SP1

BizTalk Server

Microsoft BizTalk Server 2006
Microsoft Windows Server 2003 Standard SP1 x86
Microsoft Sql Server 2005 Enterprise Edition x64 SP1
Microsoft Enterprise Library 2.0
Microsoft .NET 2.0

3PL Services Tier

Microsoft Windows Server 2003 Standard SP1 x86
Microsoft Sql Server 2005 Enterprise Edition x64 SP1
Microsoft Enterprise Library 2.0
Microsoft .NET 2.0

Tools

Borland Silk Performer 2006

www.borland.com

Silk Performer is the tool that allows for creation of scripts that can be executed to emulate a number of users interacting with one, or more systems. Mary Kay has a license for up to 2500 concurrent virtual users (VU) and an unlimited number of development clients.

Shunra VE 5.0

www.shunra.com

Shunra is a network appliance that allows Mary Kay to simulate real world network conditions right in the lab, by introducing constraints such as available bandwidth, latency, packet loss and jitter. Using a device such as Shunra, Mary Kay will be able to accurately model production networks in China, such as the network between the remote facilities and the data center or the region to region networks such as Dallas to China, and the impact these networks will have on performance.

Identify AppSight for Microsoft Windows/.NET

www.identify.com

The AppSight application provides Mary Kay with the ability to quickly identify performance bottlenecks and assists with issue resolution.

1 All inbound transactions to JDE use the Xml Call object architecture

ART Testing

noreply@blogger.com (Unknown) — Thu, 19 Apr 2007 03:04:00 +0000

Wow...its hard to believe that I've been sequestered away in a small room with our Application Readiness Team (ART) for almost 8 weeks now!

I am currently responsible for the go-live readiness of our J.D. Edwards global implementation of standardized business processes ("Project Starburst"). In a nutshell, our business and technology teams have defined core business processes that will be executed in 4 regional data centers. We've significantly customized J.D. Edwards, DSI (RF scanning) and Integration. I need to know how these processes will execute to understand areas that will need to be tuned (code) or whether or not scale up/out is required and be able to present the results to my management team.

I hear you 'agilists' out there cringing...why wait until the middle of the implementation to discover the answer to these questions? That, my friends, is another story...

For now, this is just a follow up to a previous post: Mary Kay Labs and don't forget to check out Mary Kay ART Strategy.

Somehow I continue to get sucked into engagements like this...at Mary Kay, this is my 4th such engagement for Supply Chain. Hmm....again, another story...

To catch you up...

We have built a complete testing environment at Mary Kay to support activities such as this; the result of the hard work of several people (thanks, girls and guys!). This includes enough hardware to deploy our applications to production-size hardware. I won't bore you with the hardware specifications, but I can if you like! :) Just drop me a line...

We have a total of 37 scripts to date emulating a total of ~50 users (virtual) across 5 functional
areas for everything but integration. Thats a special beast unto itself...fortunately, we've had a lot of experience in this area!

Each script has had a specific data set staged for its execution. We have created enough data to support these 'day in the life of' activities. Each script was used to stage data for downstream activities, so the data was created using the application, not any 'tricks' (although we have a few of those).

Each script is written to stand alone and also to be scaled up as necessary. For example, I can have a single virtual user processing 100 'iterations' of Inbound Receive Case, or two users processing 50 'iterations', or 100 simultaneous users processing 1 iteration of Inbound Receive Case, all without changing the script or the data set.

This attention to detail when creating scripts is not required if you are have very fixed requirements. However, if you want to be able to scale up as necessary. e.g. lets scale up the number of users across each functional area until we find a breaking point (application or infrastructure) then it pays off in script re-usability.

Also, we have a number of administrative and configuration based scripts that aren't actually used during the load test. For example, we are running with a copy of our staging environments data. Our staging environment was configured by humans and not all of our finished good products have the same consistent configurations (e.g. unit of measure conversions, standard case sizes, expiration dates, etc..). When testing, your always better off with known data than unknown. So, we have a script that will go out and configure a particular part type (component, finished good) a particular way for consistency (again, using the application NOT direct manipulation). This is an asset from this engagement that can be handed back to the business team to assist with their daily tasks.

Oh, there is lots more where this came from but my brain has sufficiently cycled down for the night....see ya!