Unit 6 Study Guide

Unit 6: Testing, Ethics, Oversight, and Scaling
6a. Test and debug workflows and agents for accuracy and reliability.
How do you check whether a workflow or agent gives the right result?
Which problems should you look for first when a workflow fails or acts in a surprising way?
When two possible fixes exist, how do you decide which one is more reliable?
What evidence from the test results tells you that the workflow is ready to use?
Testing and debugging help you find whether an automation does what you intended. The unit materials on testing and debugging focus on checking the steps in the workflow, the output it produces, and the places where it may fail. A good test shows whether the automation is accurate and reliable. A debugging process is the work of finding the cause of a problem and correcting it, and students often get stuck when they change too many parts at once. To answer the first two questions, start by checking the trigger, the conditions, and the data passed between steps, because an error in any one of those can break the result. To answer the third question, choose the fix that matches the problem you observed, not the one that seems simplest without evidence.
You also need to compare test results over more than one run, because one correct result does not prove the automation is dependable. If a workflow works once but fails when the input changes, it is not yet reliable. A test case is one set of input and expected output used to check whether the automation behaves correctly. Use the test cases from the unit materials to see whether the workflow handles normal inputs, unusual inputs, and edge cases. For example, if a workflow sends a message after a form submission, you would test a normal submission, a missing field, and a changed value to see where the process breaks.
Can you see why this matters? If the workflow gives the wrong result only in one branch, the fix may belong in that branch, not in the whole system. That is why good debugging is careful and step by step. The evidence that the workflow is ready is not just that it runs, but that it produces the expected output across the cases you tested.
To review, see:
[6.1 Testing and Debugging Automations]
6b. Apply ethical, privacy, and governance principles to AI automations.
What risks to privacy and fairness should you check before using an automation?
Which data should you avoid sending into an AI step?
How do ethical rules change the way you design or approve an automation?
When the goal is fast results, what should you still protect, and why?
The unit materials on ethics and privacy ask you to think about how an automation affects people, data, and decision-making. Ethical principles are the rules that help you choose actions that are fair and responsible, and privacy means protecting personal information from unnecessary sharing or use. To apply these principles, you first check what data the automation uses, where it goes, and who can see it. If an AI step does not need personal data, do not include it. That is the simplest way to reduce risk. The materials also point you to governance, which means the rules and oversight used to make sure automations are used properly. Can you judge whether a process needs approval before it runs? If it handles sensitive information, the answer should be yes.
A common mistake is to focus only on whether the automation works and forget whether it should work that way. For example, an automation may be fast, but it is not appropriate if it shares more information than the task requires. The unit materials stress that you should think about consent, limited access, and responsible use before you launch. This is especially important when AI services are involved, because they may process data in ways users do not expect. So, when you design or review an automation, ask whether the data flow is necessary, whether the people affected would understand it, and whether the process follows the rules set for your work.
To review, see:
[6.2 Ethical and Privacy Considerations]
6c. Implement human oversight, approval steps, and error-handling mechanisms in automations.
Where should a person review or approve the output before the automation continues?
Which kinds of errors need a stop, a retry, or a handoff to a person?
How do approval steps reduce risk without stopping the whole process?
When the automation cannot finish correctly, what should happen next?
The unit materials on oversight and error handling show how to keep an automation from making unchecked decisions. Human oversight means a person reviews, confirms, or can stop the process at the right point, and an approval step is a built-in pause where a person must approve before the workflow continues. You add these steps when the cost of a mistake is high or when the output needs judgment. For example, if an AI step drafts a message, you can route it to a person before it is sent. This answers the first two questions: place review points after the step that creates the risky output, and use error handling where the process might fail or return a bad result.
The materials also emphasize error handling, which is the set of actions a workflow takes when something goes wrong. This can include stopping the process, sending an alert, retrying a step, or sending the task to a person for review. Students often think error handling only means fixing broken software, but it also means deciding what the workflow should do when the data is missing, the connection fails, or the output does not make sense. By contrast, approval steps are about control before action, while error handling is about response after a problem appears. If a workflow cannot continue safely, it should not guess. It should pause, notify the right person, or route the work for review.
To review, see:
[6.3 Adding Human Oversight and Error Handling]
6d. Develop strategies to monitor, refine, document, and scale automations over time.
How do you know when an automation needs updates after it is already in use?
What should you document so someone else can understand and maintain it later?
Which changes should you make first when a workflow starts to slow down or fail more often?
How do you decide whether an automation is ready to expand to more users or more tasks?
The unit materials on long-term use and scaling ask you to think beyond the first working version. A strong automation needs monitoring, which means checking its behavior over time so you can notice problems, and refinement, which means improving it after you see what actually happens in use. You should watch for repeated errors, changes in input, and places where the workflow no longer fits the real task. A common pain point is assuming that a workflow that worked once will always work the same way. It will not, because people, data, and tools change. So the first changes should focus on the parts that fail most often or create the greatest delay.
The materials also stress documentation, which is a clear record of what the automation does, how it works, and how to maintain it. Good documentation helps you or someone else update the workflow later without starting over. To answer the fourth question, think about scaling, which means making the automation work for more cases, more users, or more volume while keeping it dependable. You should only scale after the workflow is stable, documented, and monitored. For example, if one approval workflow works for a small team, you would not expand it until you know the steps are clear, the errors are handled, and the review process is consistent. That way, you can grow the automation without losing control.
To review, see:
[6.4 Planning for Long-Term Use and Scaling]
Unit 6 Vocabulary
This vocabulary list includes terms you will need to know to successfully complete the final exam.
approval step
debugging
documentation
error handling
ethical principles
governance
human oversight
monitoring
privacy
refinement
scaling
test case