comment 0

Quality Assurance vs Quality Control vs Testing

While the terms quality assurance and quality control are often used interchangeably, there are differences between the two disciplines. Likewise, quality control and testing are sometimes used interchangeably, though the terms are not exactly the same thing.


The Definitions

Quality assurance is a process designed to ensure a system meets its objectives. Quality assurance tries to design processes that deliver the consistent and correct results every time. It includes verifying processes already outlined are followed. QA tends to be pro-active. Per one Dilbert strip, QA involves telling people how to do their jobs so that they do it right.

Quality control refers to the activities to evaluate whether produced items and services meet standards. It tends to focus on defects in specific deliverables, checking performance or dimensions against pre-determined standards. QC is, by definition, reactive, because it finds imperfect products after the mistake is made.

Testing is the process of trying to find defects. Testing procedures need to be documented so that they are followed consistently by everyone who receives them. The test plans need to call out the right hardware, software and supporting information needed to follow the same test every time. And they need to be kept up to date as industry standards change, hardware evolves and the software behind many automated testing systems changes. Even things like where you store information on test results and test scripts need to be documented.


Quality Assurance vs Quality Control vs Testing in IT

QA in IT ensures your process is defined and appropriate. What is the scope of the project? Do we have a formal test plan? QA is the full software development lifecycle.

QC tries to identify defects in the product. The classic case is the database of bugs found during software testing.  One definition of QC was always executing the program, while QA may involve theoretical or administrative reviews. In the case of QC in IT, you have to run the software to find the ways it doesn’t deliver results appropriately, errors out, or literally locks up.

In IT, testing is running your software and hardware tests. And QC is specifically the software testing life cycle. Test plans should specific the IT architecture and hardware used for testing. After all, putting something on the wrong test bed is going to cause it to get very different errors than if the right one were used.


Does Automation in Software Testing Eliminate the Need for IEs in IT?

Quality automation engineers take it one step further and write the code that runs automated tests per various test cases and generates a report of defects.  However, you cannot assume this automation of testing is always accurate or complete.

In one instance, an engineer demonstrated his automated test script to replace manual testing that was going on, and we watched a number of error messages pop up. And because the script was only looking for errors like access control limit notices during the automated test, the dozens of popups generated weren’t recorded as errors by the script. And if the quality automation engineer isn’t clearly told what constitutes a success, you could get events like a report being generated counted as a pass when the report itself doesn’t show all the data or contains other errors.

In summary, no, automation doesn’t eliminate the need to apply quality assurance and quality control to any aspect of IT even if one can automate many tasks.

comment 0

IE Lessons from Dr. Jordan Peterson’s Advice

While Dr. Jordan B. Peterson’s advice is widely applicable in a variety of areas, there are snippets that are particularly in line with industrial engineering principles.

  • Make at least one thing better every single place you go.

One way of describing the goal of industrial engineering is “better and better”. The definition of better itself is variable, whether you want it cheaper, faster, using less, or an improved design.


  • Tell the truth.

You cannot solve a problem if it is against the rules or culture to admit it in the first place. You cannot fix something if you aren’t allowed to share solutions or talk to those with the most knowledge about the issue.


  • Assume that the person you are listening to might know something you need to know. Listen to them hard enough so that they will share it with you.


One way to look at this is to give people your whole attention, because the little details and passing mentions may be the most important information … and it is what you’ll miss if you give them half your attention.

Another variation of this is how often people do surveys or solicit feedback only to skim over it, analyze it in aggregate and use intermediaries for what seems like the sake of efficiency.

Early in my career, a manager listened to my advice on solving a problem based on heavy theoretical reading. He replied, “If you want to find the solution, start with the people who are dealing with the problem.”

On one occasion, the seals were falling off a PCB board’s air ducts. I went down to the manufacturing shop, talked to a production head, and he put together a test of wash processes and adhesives on the seals. A line operator assembled the combinations of seals and adhesives on junk boards, we ran the lots through wash cycles, and we found the fatal combination. It took two hours. I returned to work in time for an engineering meeting, where I stood up to discuss the results. Most present had only started to consider how it might be testing. Asking the person with the most direct experience with the process resulted in an answer.

Many assemblers knew short term work-arounds that could be turned into permanent design solutions or had recommendations based on years of experience building, fixing and deconstructing the product. After several years in product development and production support, I was surprised to later find that many engineers were reluctant to talk to those on the shop floor … or even asked me to join in the meeting for my shop floor experience so they didn’t have to talk to the people doing the hard work.

  • Imagine who you could be, and then aim single-mindedly at that.

Burning platform, anyone?


  • Work as hard as you possibly can on at least one thing and see what happens.


Define progress for the moment – faster, leaner, simpler, more efficient. Then apply a fitting continuous process improvement methodology toward that goal. Re-evaluate and sustain the gain. Remember that you can shift the focus after you achieve a goal.


  • Nothing well done is insignificant.

Don’t denigrate small process improvement projects or modest gain in an area. We worship big projects, major wins, ignoring the fact that small, incremental progress can achieve the same or more and with less risk.

This same mentality is why politicians prefer big infrastructure projects over maintaining what’s already been built. Filling potholes and preventative maintenance aren’t as sexy as a new highway or overseeing a major equipment upgrade.


  • Remember that what you do not yet know is more important than what you already know.


It is the problems you don’t know about that are about to explode, hopefully not literally. It is the root causes you don’t realize are affecting your process that have the greatest impact on your quality.


  • Be precise in your speech.
  • Do not hide unwanted things in the fog.

I put these two together because of the tendency to use heavy jargon, whether it is in the hope of seeming more educated and thus justify one’s stance or in the misguided belief that if you rename something, the seriousness of it is reduced. The end result in both cases is confusion as to the issue involved unless you’re up to date on the jargon and often misunderstandings as to the severity of the issue. And sometimes people use the euphemisms and jargon fitting for a Dilbert comic to try to hide the severity of a problem.


  • Notice that opportunity lurks where responsibility has been abdicated.

Need ideas for a process improvement project? Look at the things others have given up on but really wish was solved.


comment 0

How the IoT Could Affect Industrial Engineering

The Internet of Things is moving from the realm of theory to real world application. This is in some ways the extension of facility monitoring systems that many IEs have worked with to the broader world, while it extends the network to everything else in the facility from back office equipment reporting energy usage to your finished product continuing to send data to your organization after shipment. Here are a few ways IoT could affect industrial engineering.

  • IEs working in industrial automation will need better training in data mining and analysis of data flooding in from the IoT whether detailed reporting from everything contributing to the assembly line.
  • Potential faults and impending failures make manufacturing management much more proactive.
  • If shipped product is able to send data back to manufacturers to diagnose failures, failure analysis becomes a real time skillset and requires stronger customer service skills.
  • If products can report failures to manufacturers the same way computers can send failure reports to Microsoft or Apple, there will be far more data to mine for understanding the root causes of any type of failure.
  • User experience is revolutionized by the amount of information IEs in this field get regarding how systems are actually used.
  • Just as managers need to learn how to use business intelligence software, IEs will need to learn how to use software developed to summarize IoT data and control increasingly self-sufficient factories.
  • Total Predictive Maintenance will become standard and include far more data points and equipment. For example, you’ll need to plan on replacing sensors monitoring everything as well as the equipment itself.
  • Programming and information security become more important to the average industrial engineer.
  • Smart automation will expand from the biggest or newest factories to many more manufacturers.

What would you add to this list?

IE Lessons Learned from Dilbert, Part Two

The Dilbert comic strip has mocked nearly every aspect of corporate America for decades. Among those targets includes process improvement methodologies and management fads. And, funny enough, there are lessons we can learn from the good-natured criticisms.


“I Assure You That This Program Has a Totally Different Name”


5S, TQM, Lean, Six Sigma and other process improvement methodologies share elements with at least one other. Lean, I think, originates from the Toyota Production System. Supply chain management is a rebranding of inventory control and lead time reduction. Six Sigma is an extension of Total Quality Management. Continuous Process Improvement in various forms comes from Deming’s PDCA. Adding another one or two steps is literally a minor change. The new name is used to sell a new set of consulting services, while those who are not IEs think that it is unrelated to the prior skillsets. I sat in one interview where the interviewer asked me if I was familiar with CPI. I had to ask for clarification, since the financial term was my first thought. I said yes, Six Sigma, and my degree by definition includes lean principles. They likely struck me off the list then, because my prior training didn’t seem relevant to the new buzzword.


“My Company Is Moving to JIT.” “So Your Success Depends on Us Keeping Promises? Sympathies.”


This is a synopsis of a March 14, 2003 comic strip. And it surprises me that some people don’t realize the great risk a just in time system creates. When you’re reliant on the other person to meet schedule and quality requirements, you’re at the mercy of their performance. Having some inventory on hand to fill in the gaps if they are late shouldn’t be seen as a sin, even if you have alternate sources of products and services, since your backup plans may take longer than you expect. You don’t have to hoard inventory unless that is literally the only way to acquire it (farm harvests, for example), but having margin is always wise.


“Less of What?”


The February 13, 2011 Dilbert comic strip features the pointy haired boss saying less is more. However, he rules out less meetings and less micromanagement, instead clarifying he only means less money. In general, we need to recognize that lean should include less of all sorts of waste and shouldn’t automatically come with the assumption that you can cut funding. Ironically, process improvement methods can become inefficient in their own right, when you’re chasing asymptotic limits of improvement. Switching to a different methodology like from Lean to Six Sigma or Six Sigma to 5S improves the odds you’ve find new, low cost improvements to make in the organization and process flow.