Testing Generative AI: A Simple Checklist Before Your Team Uses It

The team tests the AI with one question, gets a clear answer, and all team members feel comfortable using the tool. But, the next day, the tool returns a wrong date and skips an important step. One correct answer is not enough to understand the whole situation, and the team needs testing to be done before the build of the feature into the workflow.

Gen AI testing involves assessing both the answer provided by the tool and the context of the task itself. Are all the correct facts used in the text? Is the draft presented properly in the app? Does the worker understand what he/she needs to check? An AI test, or simply eval, is a planned check of these results.

It describes a straightforward plan for a test. Consider a company applying AI to create reminders to customers from confirmed bookings. They are just for example purposes rather than for claims of use by a Digitonix customer. There is no need for understanding of complex mathematics or modeling to understand the guidance provided. Begin with a clear task, right questions, and people who will check the results.

Write down the allowed task

Define the feature under test. Our product creates a draft reminder based on a confirmed booking. It neither alters the booking nor provides a new service in response to it. Such limits help define the test. Without being able to describe the task clearly, reaching agreement as to which answer is useful and which behavior is incorrect would prove difficult.

List the important facts and actions. Date is to be taken from the current booking. Message should remain in the draft until an employee looks through it. The system should not say that a message has been sent, when it has only created the text. This will link the answer provided by the AI with practice in the business environment, and not consider correct wording as the sole goal.

Make a small set of test examples

The examples should look natural and real. An example of booking that contains wrong time, changed name, and an out-of-scope question should be made. Use safe made-up or approved examples for the test set. They should show the problem without revealing real customers’ private details. A small note should be added to each example to explain its relevance.

Do not only take the simplest examples during the demo. The use of typical mistakes and interruptions is necessary too. Long note, unclear wording, or obsolete record can be a sign of error that cannot be revealed using a perfect example. It is also good to have some examples which are not used for developing the program. Otherwise, the team will practice the same questions and believe that they test the program correctly.

Decide what a useful result looks like

Each example should be provided with information that should be included in the answer and statements that should not be used. There is no need to make up one certain sentence. Two versions can be different in wording, but they can still be useful. Absence of a date, but, can be a real mistake.

Use clear rules for the reviews. A draft reminder needs to contain the correct visit with its confirmed date. It should not suggest a made-up moment when there is no information about the date of appointment. It should be easy to read and give clear step in the reviewing process. Give a few examples which could help the reviewers form an opinion. It will be more consistent than judging based on convincing sound.

Check facts against trusted sources

The reviewer should have the choice of confirmation of the fact. Show useful appointment or policy from the source where it can be used. The sentence that sounds confident should not be considered as proof alone. If there is no such data or it is not clear, the tool should show this situation or ask for extra information.

Record errors according to their type. A wrong date is different than a confusing phrase. False claims about a policy are different from an unneeded lengthy answer. These categories will help in the team’s decision about which issue needs fixing. The overall number alone won’t show the type of error that is important for the business, especially if the answer might prompt a customer to act on it.

Test the app as well as the text

An answer might be right but the application process faulty. The draft might come up along with the wrong booking. The save button might be confusing. An employee might think the message was sent, when in fact it was just generated. Test the entire path from entering the information to reviewing it, with its support for a next action by the customer.

If the feature does its actions by using some tools, then judge the result itself. Just saying that the job was done does not imply the record has been updated. According to Anthropic's guidelines on checking AI systems, when an agent uses tools, one must check the whole process and not only the final answer. Apply the same method to the actions and records of your own system. Refer to Anthropic's guidelines on AI tests to find more. See Anthropic's guide to AI evaluations for related information.

Include cases with missing answers

Sometimes there will be no answer to the request as there will be no data for that or the user will ask about something the company does not provide. It is not good for the feature to invent some information in these cases. Define the next step – to ask the question or forward it to the right person.

Make sure that the explanation about the limit is clear and helpful. An overly technical message about the error will confuse the employee. A vague denial will make them uncertain about their next steps. A good example of failure wording will let the person know what is known, what is not known, and the path that is supported by the system and will help them achieve their goal.

Check access and private information

Test the account and record access rules. The user should not get information that they are not allowed to view from the AI response. Test the old URL, the changed role, and the request for the other restricted record through the approved project process. The application needs to enforce its access policies beyond just disabling the control on the interface.

Logs and generated drafts should also be reviewed. They may include some information that was copied from the input. It is necessary to have good evidence for the test team without leaking all the private conversation into the report. Use the proper testing environment and safe logs. The aim is to test the boundary and improve the system, not to reveal the real data of customers during the review.

Repeat important checks

The wording may be different in the generated drafts. Even an answer that was correct once may not be the same in another run. Select the proper amount of repetitions for the case and its consequences. Write down the decision and the result. One right run does not guarantee that the feature will behave the same way for everyone.

Be explicit about the test environment. Include feature version, settings, input data and request being sent. For a result change, they can always review these factors. It’s not necessary to build some fancy dashboard at first place. The log of what you tested and the result you observed is far more valuable than an assuring number without any context.

Use people and automated checks together

Some checks can be done automatically. It may be the presence of a required field or comparing dates with known values. On the other hand, there are tests that require a person's judgment like checking message quality and usefulness to do the task. Just pick the check that will help you answer your question. Don’t wait for a single checker to handle all the issues.

Allow time for review and set clear rules. If there are conflicting opinions, analyze the example and the rule, not the average out of the problem. A disagreement could show a fuzzy need. It should be decided by the responsible owner how it will be handled. Note down the reasoning so that future reviewers can learn from the experience of the team.

Set a release decision before launch

Choose which bugs make it impossible to release the app and which are acceptable provided there is a specific threshold. Poor customer record may be worse than a text that needs a shorter sentence. Define an owner for each bug that remains unsolved. Your team should know the person in charge of the first release and what evidence he expects.

Consider beginning with a finite group or a specific task, as needed. Pay attention to usage in the wild, and know how to stop the roll-out. Have a plan for falling back to allow users to complete their work if there is an issue with the AI features. The initial roll-out should be able to show both useful behavior and control limits and a response to issues rather than assume that testing eliminated any possibility of errors.

Retest after meaningful changes

Model, request, source file, or app update can impact the result. Check the boxes for those tests that should be redone after these have been changed. Make sure to keep the sample set in tune with the evolution of your business. The important condition for your first release might become not useful or require a different source file at a certain time.

Apply actual feedback to enhance the tests. If the staff detects any new failure, make a safe example of it and add it into the test as a check. Do not add new rules out of every temporary complaint if you do not understand the root cause. The test set should stay concentrated on results and help the team to make better decisions about releases.

How Digitonix can help

AI solutions and cloud and DevOps services offered by Digitonix can be considered right to discuss AI checks and release needs. Provide the allowed task, safe examples, important details, and the actions supported by the application. Request the test rules, failure cases, ownership, and justification for the initial release. Check what each proposed check will prove and where further reviewing is required.

Tests of applications created with the help of Python or Node.js should be developed according to the application and work environment. Explain through Digitonix the business result and the errors that should be considered. The proper test plan should allow you to judge the business result and manage the feature in the future.

Frequently asked questions

What is an AI eval?

It is a planned test of the output of an AI system. The test will depend on the task. It can be a check of facts, wording, access, or an actual action done by a certain tool. State what useful behavior would be and provide evidence of the output. The purpose is to inform a decision, not just give a score with no meaning.

Is one good answer enough to release a feature?

No. Use examples of both simple and complex cases. Cover issues such as missing data, alterations in records, and the important events involved in the answer. Replicate checks where there is variation in cases. It can be one helpful demo, but it cannot prove that the entire business process is sound and that the feature will process all requests in the future.

Can another AI model judge all the answers?

It may help in reviewing some cases, but it should not serve as the only judge for every answer. It is prone to errors. Review what it finds against set rules and also human judgment when required. The company will decide the results that matter and will decide ownership of complex decisions when an answer may lead to an action or reveal private data.

When should we run the tests again?

Re-test when any changes occur in the model, request, source information, application behavior, or access. Employ the new failures to enrich the sampling set. Document the version and context so that the tests can be compared with the past. Testing must continue as part of maintenance rather than a one-time activity where an older test result is used to check any future changes.

What should we bring to a testing discussion?

Specify the task to be done, sample data, known facts, sources, failures, and available actions. Include those with the authority to check the results and give permission for release. Provide the present state of the app and the change process. This will help in formulating an effective initial test plan with proper ownership and evidence rather than just a general request for correctness.