ISQI CT-GENAI - Questions & Answers

Classical machine learning is characterized by a data-driven workflow in which people prepare data, select relevant variables, and often design features before training a model. The model learns statistical relationships from examples, but the quality of the result depends strongly on the representation supplied to the algorithm. That makes feature engineering, data cleaning, labeling, splitting, and evaluation central activities in this approach. This workflow also makes evaluation and feature choice visible to testers and analysts.

A rule-based system belongs more naturally to symbolic AI, where behavior is encoded through explicit rules rather than learned from data. Neural networks with many hidden layers describe deep learning, where the model performs more of the representation learning internally. Text generation from very large corpora describes generative AI and large language models. Classical machine learning can still be powerful for testing tasks such as classification, prediction, clustering, and prioritization, but it normally requires more explicit preparation of structured inputs than modern deep or generative models.

Embeddings give a language model a mathematical way to work with words, subwords, or other tokens. A token by itself is a discrete item, but a model cannot compare meaning or context directly from a plain symbol. An embedding maps that token into a vector space where related concepts can be positioned closer together and where grammar, meaning, and usage patterns can influence later processing. This is why embeddings are fundamental to search, retrieval, classification, and generation tasks built around language models.
Several nearby concepts can be confused with embeddings. The maximum amount of text a model can consider is the context window. Breaking text into smaller units is tokenization. Randomness and creativity are influenced by generation settings such as temperature. Embeddings are different because they provide the numerical representation used by the model after tokenization and before later layers reason over relationships. In testing work, embeddings also support semantic retrieval, such as finding requirements or standards that are conceptually similar even when they do not share exact wording.

Tokenization and context window are separate but connected ideas. Tokenization breaks input text into smaller units that the model can process, such as words, word fragments, punctuation, or other subword pieces. The context window is the maximum span of tokens the model can consider for a single interaction or generation step. A larger context window can help the model keep more of a long requirement, test log, defect history, or design note available while it produces an answer.

The misleading statements reverse or overstate those concepts. Expanding the context window normally increases computational work and memory demand; it does not generally make processing simpler or
faster. Converting tokens into high-dimensional vectors is the role of embeddings, not tokenization itself.
This distinction matters in test work because long artifacts can exceed the effective context a model handles well. A tester should know when to chunk content, summarize carefully, or use retrieval support rather than assuming all earlier details will remain equally influential throughout a long prompt.

An instruction-tuned language model starts from a broader foundation model and is further trained or refined so that it responds better to human instructions. The purpose is not merely to know language patterns, but to interpret requests, follow constraints, use requested formats, and align output with the intent expressed by the user or developer. This makes instruction tuning especially relevant for testing tasks where the prompt asks for structured test ideas, review comments, defect summaries, or automation snippets.

A general-purpose foundation model may be capable across many tasks but may not reliably follow precise directions without additional alignment. A reasoning-focused model emphasizes complex inference and multi-step problem solving, which is a different specialization. A broad generative model may create images, code, or text, but that describes generative capability rather than the instruction-following refinement. In practical use, testers still need clear prompts and review discipline, but an instruction-tuned model is designed to make prompt intent, task boundaries, and output requirements more controllable than a raw foundation model.

A task that combines screenshots with textual defect reports requires a model that can process more than one type of input. Multimodal language models, especially those with vision-language capability, are built to relate visual information to text. In a testing context, this can help compare a described expected behavior with visible user interface elements, layout, labels, states, or inconsistencies that may not be captured in a written report alone.

The other model categories do not match the problem as directly. Symbolic AI relies on explicit rules and is not naturally suited to interpreting varied screen content. Classical machine learning can classify data when trained on suitable features, but the scenario needs integrated interpretation of text and images rather than only structured defect categories. Reasoning-oriented language models may help analyze a report, but without visual understanding they cannot evaluate the screenshot evidence directly. The key capability is cross-modal grounding: the model must connect what is described in language with what appears in the interface so that potential visual defects can be identified and reviewed by testers.

The two needs call for different forms of AI support. A chatbot is well suited to rapid, ad-hoc exploration because it supports interactive dialogue. A new tester can ask clarifying questions, request examples, refine ideas, and explore requirements informally. That style is flexible and useful when the work is exploratory, one-off, or still being understood.

A repetitive continuous integration workflow needs a more structured LLM-powered testing application.
Such an application can be integrated into a pipeline, receive controlled inputs, enforce output formats, store configuration, run consistently on a schedule, and connect to test data management or automation systems. A plain chat interface is not enough for reliable daily regression support. Conversely, a full testing application is often too heavy for a tester who simply needs quick interactive help. The important distinction is between conversational assistance for human exploration and engineered workflow support for repeatable automated test activities. Matching the system style to the work reduces friction and improves governance.

The quoted prompt line defines how the model response should be structured and delivered. It specifies a CSV file format and names the expected columns. That is an output format requirement because it tells the model the shape, organization, and representation of the response rather than the business role, domain background, or task objective.

In a structured prompt, the role component defines the persona or viewpoint, such as acting as a test analyst. Context supplies background about the product, feature, requirement, risk, or test objective.
Instruction states the task to perform, such as generate test cases for a workflow. Constraints limit what the model may include or must avoid, such as coverage rules, scope exclusions, assumptions, or security boundaries. Output format is specifically about the response layout, fields, syntax, or artifact type. In test work this separation is practical: a clear format requirement makes generated test cases easier to review, import, compare, and reuse, while the other prompt components control purpose and scope.

A statement that treats constraints as the primary place for response format is inaccurate. In a six-part prompt structure, constraints describe restrictions, boundaries, policies, assumptions, exclusions, or quality rules that shape what the model may produce. The desired representation of the response, such as a markdown table, CSV, Gherkin syntax, or a particular set of columns, belongs to the output format component.

The other descriptions align with the normal role of prompt components. A role sets the persona or expertise the model should apply. Context gives background about the system under test, feature, requirement, or testing goal so the model can reason within the right situation. Instruction defines the actual work the model must perform and may include relevant task requirements. Keeping these components distinct helps testers diagnose poor outputs. If the response uses the wrong layout, the output format needs improvement. If the model misses scope or policy limits, constraints need improvement. If the model misunderstands the system, context or instruction needs refinement.

Prompt chaining fits a complex activity that benefits from several smaller, reviewable steps. Instead of asking the model to produce a full test plan summary in one large response, the tester can break the work into stages. One prompt may extract objectives and risks, another may organize coverage areas, another may summarize progress, and a final prompt may combine checked intermediate results into the requested summary. The output of each stage becomes controlled input for the next stage.

Few-shot prompting provides examples to guide a response pattern, which helps with style or format but does not by itself manage multi-step refinement. Meta prompting focuses on prompting about prompts or strategies for prompting. Zero-shot prompting asks for a result without examples. The scenario emphasizes iterative review, verification, and dependency between steps, so prompt chaining is the strongest fit. It also supports testing discipline because intermediate artifacts can be inspected before they influence later output, reducing the risk that a hidden error spreads through a large generated result.