Introduction to Generative AI for Software Testing practice questions

Classical machine learning is a data-driven approach that needs data preparation, feature selection and model training.

Both classical machine learning and deep learning learn from data, so the difference is feature handling. In classical machine learning, people prepare the data and select the features the model trains on. Deep learning's neural networks learn features automatically. Rules written by experts are symbolic AI, and using a pre-trained model directly is the generative AI advantage.

1. Note that both approaches learn from data.
2. Ask who decides the features: people or the model.
3. People selecting features means classical machine learning.
4. Eliminate the descriptions of symbolic AI and generative AI.

Exam tip: Classical ML: humans prepare data and pick features; deep learning finds the features itself.

Deep learning uses neural networks to learn features automatically from large, complex data such as images, but often still needs human involvement.

Two facts combine here. First, deep learning does not need people to define features: the neural network learns them from the screenshots. Second, that does not remove people from the project, because training data must be annotated and results validated. The tempting options either bring back manual feature design (classical machine learning), drop training altogether (which applies only to using an already pre-trained generative model), or require rules (symbolic AI).

1. Identify the approach: the team trains its own deep learning model.
2. Recall that deep learning learns features automatically.
3. Recall that human annotation, tuning and validation are still needed in practice.
4. Reject options that describe classical ML, symbolic AI or using a pre-trained model.

Exam tip: Deep learning automates feature finding, not the whole project: labelling and validation remain human work.

Generative AI uses pre-trained models that can be applied directly to test tasks.

Symbolic AI needs rules to be written, and classical machine learning and deep learning need data and a training phase before they are useful. Generative AI's pre-trained models skip that phase and can be applied to a test task immediately, although this brings risks such as hallucinations. Repeatability and traceable rules are not properties of LLMs.

1. Recall what each other type of AI needs before use: rules or training.
2. Recall that LLMs arrive pre-trained.
3. Reject claims of repeatable output, since LLMs are non-deterministic.
4. Reject explicit rules, which belong to symbolic AI.

Exam tip: GenAI's edge: pre-trained, so no training phase before applying it to a test task.

The key advantage of generative AI is that pre-trained models can be applied directly without an additional training phase.

Three constraints decide. With no labelled history and no time to train, both machine learning options fail: classical machine learning needs labelled data and feature selection, and deep learning needs a large labelled dataset and training. Symbolic rules need no data, but varied wording makes keyword rules brittle. A pre-trained LLM handles natural-language variation and can be used immediately, with a human reviewing its output because plausible output is not always correct.

1. List the constraints: no labelled data, start now, varied wording.
2. Eliminate approaches that need labelled data and training.
3. Eliminate rules that cannot handle varied wording.
4. Choose the pre-trained model and keep a human review step.

Exam tip: No training data and no time to train: use a pre-trained LLM, and review its output.

Tokenization breaks text into smaller units called tokens.

An LLM first tokenizes its input: it splits the text into tokens that may be characters, sub-words or words. Embeddings then convert each token into a vector, the context window limits how many tokens can be considered, and inference predicts the next token. Each distractor is a real step in the same pipeline, just not tokenization.

1. Place tokenization at the start of the processing pipeline.
2. Recall that tokens vary in size from a character to a word.
3. Match the other options to embeddings, context window and inference.

Exam tip: Tokenization = text into tokens; embeddings = tokens into vectors.

Tokens can be as small as a character or as large as a sub-word or word, so token count depends on the text's structure, not only its word count.

Token count, not word count, is what consumes the context window. Everyday English words are often single tokens, but identifiers, hex addresses and symbols are rare in training text, so the tokenizer splits them into many sub-word or character tokens. That is why logs and code can use far more of the context window than their length in words suggests.

1. Note that the word counts are equal, so words are not the unit that differs.
2. Recall that tokens can be characters, sub-words or words.
3. Ask which text contains rare strings that cannot be single tokens.
4. Conclude that rare strings split into many tokens.

Exam tip: Logs and code cost more tokens per word than plain prose: measure tokens, not words.