The company supported AI adoption. Developers were already using AI in their daily work, including development tasks.
Most of the QA team was not.
I was using it personally, and I had started preparing an internal presentation to introduce practical AI use cases for QA. My first topics were not autonomous testing, generated automation frameworks, or promises that everyone would become dramatically faster.
I wanted to begin with two ordinary problems:
- Documentation was not always consistent.
- Bug reports sometimes arrived without all the information another person needed.
The presentation was never completed or rolled out, so I cannot claim that it changed the team or produced measurable results. But preparing it forced me to answer a management question that is becoming increasingly important:
How should a QA Manager introduce AI when the organization is ready for it, but the team has not yet made it part of its daily work?
My conclusion was that adoption should not begin with the tool.
It should begin with better work.
The Adoption Gap Is Not a Performance Verdict
When one discipline adopts AI faster than another, it is easy to turn the difference into a judgment.
Developers are using it, so why is QA behind?
That question may sound reasonable, but it can lead a manager toward the wrong action. Telling everyone to “use AI more” creates an activity target without defining the outcome. People may generate more test cases, longer documents, or more polished reports without improving coverage, clarity, or release confidence.
The fact that most QA engineers were not using AI did not mean they were resistant, less technical, or less capable. Their daily workflows, available examples, perceived risks, and reasons to change were different.
A manager’s responsibility is not to shame a team into adopting a tool. It is to create a safe and useful path from the current way of working to a better one.
That requires a clear answer to three questions:
- Which recurring problem are we trying to solve?
- Where can AI help without becoming the source of truth?
- What must the QA engineer still verify and own?
If those answers are missing, adoption is premature.
Start With a Visible Workflow Problem
I chose documentation and bug reporting because the problems were already visible.
Some reports contained strong evidence but were difficult to scan. Others described the symptom but omitted the environment, build, expected behaviour, or a useful reproduction detail. Different people naturally wrote in different styles, which made consistency difficult.
The team already knew this friction existed. That made it a better adoption candidate than a dramatic use case with unclear value: testers create defects regularly, and several disciplines depend on that information.
AI could help organize information that the tester had already collected.
For example, a QA engineer might provide:
- The environment and build.
- Reproduction steps.
- Expected and observed behaviour.
- Device or account conditions.
- A screenshot or video reference.
- Notes from an exploratory session.
An approved AI assistant could help arrange that material into the team’s bug template, point out that a required field was empty, or rewrite an unclear sentence.
That is a useful role because it improves the transfer of knowledge without deciding what actually happened.
Standardize the Output Before Adding AI
AI cannot create consistency if the team has never agreed on what a good result looks like.
Before introducing an assistant into bug reporting, the manager should define the minimum standard with the people who use the report. QA should understand what developers need to investigate efficiently. Development should understand what QA can reasonably collect. Product or design may need particular context for user-facing problems.
A practical bug standard may require:
- A concise title describing the observed failure.
- The environment, build, device, or platform.
- Preconditions that materially affect reproduction.
- Clear reproduction steps.
- Expected and observed behaviour.
- Relevant evidence such as an image, video, log reference, or account state.
- An initial impact assessment that remains open to discussion.
Once that standard exists, AI has a bounded task: help the engineer express supplied information in the agreed format.
Without the standard, the tool may produce a confident-looking report that is still unhelpful. The formatting can appear professional while essential context remains absent.
This is why AI adoption in QA is partly a process-design problem. The manager must first make good work visible. Only then can a tool help people produce it more consistently.
AI Can Structure Evidence; It Cannot Create It
The most important boundary in my planned presentation was evidence.
An AI assistant can help rewrite reproduction steps. It cannot claim that those steps reproduce the problem unless a person has actually verified them.
It can summarize notes associated with a video. It cannot replace watching the video and confirming that the summary matches what occurred.
It can identify that the environment field is missing. It cannot choose an environment based on what seems likely.
It can suggest that a symptom may relate to a known system. It cannot turn that hypothesis into a confirmed root cause.
The final report remains the QA engineer’s responsibility.
That means the engineer must confirm:
- Every step reflects an action that was performed.
- The expected behaviour matches the current product decision.
- The observed behaviour is described accurately.
- The attached evidence belongs to the reported condition.
- No unsupported cause or severity has been added.
- Sensitive information has not been exposed.
This review is not an administrative formality. It is the professional act that converts generated language into trustworthy QA communication.
Privacy Is a Management Responsibility
Responsible adoption also depends on which tools the organization approves and what information can be shared with them.
Bug reports may include unreleased features, user information, internal URLs, account identifiers, logs, screenshots, videos, or business rules. A manager should never assume that a generally available AI tool is an acceptable destination for that data.
Before asking a team to use AI, leadership needs clear rules:
- Which tools are approved?
- What data may be entered?
- Which information must be removed or generalized?
- How long is data retained?
- Who can access the output?
- What review is required before generated content enters the tracking system?
If the organization cannot answer those questions, the initial exercises should use synthetic examples rather than real product data.
Teach With Examples, Not a Mandate
If I were completing that presentation now, I would show a controlled before-and-after example using synthetic notes: a device, build, symptom, incomplete steps, and an evidence reference.
The review would not ask only whether the second version sounded better. It would ask:
- Did the tool preserve every verified fact?
- Did it add anything that was not provided?
- Which required fields remain missing?
- Is the report easier for another person to investigate?
- What must the tester correct before submitting it?
That exercise teaches the real skill: evaluating generated output.
I would also provide a small set of approved prompts or templates. Not because one prompt should control everyone’s work, but because a safe example reduces the effort and uncertainty of starting.
People learn new tools at different speeds. A manager can maintain one quality standard without requiring one identical workflow.
Do Not Measure Adoption by Output Volume
AI makes it easy to create more.
A tester can generate dozens of scenarios and pages of documentation. That output can look productive while making the information that matters harder to find.
A QA Manager should evaluate whether the work is more useful, not simply larger.
For documentation and defects, I would look for:
- Accuracy.
- Completeness.
- Clear separation between evidence and hypothesis.
- Relevance to the reader.
- Traceability to the tested condition.
- Appropriate handling of confidential information.
- Evidence that the engineer reviewed the final result.
This changes the coaching conversation. Instead of asking, “How much did you use AI?” the manager asks, “How did the tool improve this work, and how did you verify the result?”
The Manager’s Role Is to Develop Judgment
AI does not reduce the need for QA leadership. It changes where leadership effort is most valuable.
Managers need to help engineers decide:
- Which information matters.
- Which source is trustworthy.
- Which tasks are safe to assist.
- Which outputs require deeper review.
- When a generated answer should be rejected.
- When ambiguity requires a conversation instead of another prompt.
Technical knowledge still matters. A manager must recognize when polished language is hiding weak reasoning. Engineers must also feel comfortable saying that a tool did not help or that they need guidance on a data boundary.
The objective is not universal enthusiasm. It is responsible competence.
What I Learned From an Initiative I Did Not Finish
I began preparing the presentation, but I did not complete or roll out the initiative. I do not know how quickly the team would have adopted the workflow or which parts would have needed to change after real use.
The value of the experience is in the design questions it surfaced.
I learned that “AI for QA” was too broad to be a useful starting point. Documentation and bug reporting were narrower. The team already understood the underlying problem, the expected output could be defined, and human verification could remain explicit.
I also learned that adoption planning reveals process weaknesses. If the team cannot define the minimum content of a useful defect, AI is not the first problem to solve. If data-handling rules are unclear, a manager should resolve that uncertainty before encouraging experimentation.
An unfinished initiative can still improve a leader’s framework—as long as it is presented honestly as preparation, not proof.
A Seven-Step Framework for QA Managers
Based on that preparation and my broader QA leadership experience, this is the sequence I would use:
1. Identify one recurring problem
Choose a workflow the team recognizes, not a use case selected only because the technology can perform it.
2. Define the quality standard
Agree on what a useful document, bug report, test analysis, or other output must contain.
3. Establish tool and data boundaries
Use approved tools and make confidentiality, retention, and review expectations explicit.
4. Build a synthetic example
Demonstrate the workflow without exposing real product information.
5. Teach verification
Show how to find invented facts, missing context, weak reasoning, and differences between evidence and hypothesis.
6. Run a limited pilot
Apply the workflow to a small, low-risk area and collect feedback before expanding it.
7. Evaluate usefulness, not usage
Assess accuracy, clarity, investigation value, and professional judgment—not prompt counts or generated volume.
This framework does not guarantee adoption. It creates the conditions for the team to evaluate AI based on the quality of the work it supports.
Better Work Is the Goal
The question for a QA Manager is not whether every engineer uses AI.
The question is whether the team can use it where it adds value, reject it where it does not, and remain accountable for the result.
For the presentation I started, documentation and bug reporting were practical entry points because they addressed problems the team already experienced. AI could help structure the information. The tester would still own the evidence, the accuracy, and the final decision to submit it.
Tools will continue to change. The manager’s responsibility remains more stable: define good work, protect the team and the product, develop professional judgment, and make improvement possible without pretending that adoption itself is the outcome.
AI should help QA engineers communicate what they know more clearly.
It should never allow them—or their managers—to stop asking whether it is true.