Engineering quality in software

The diagram above is a conceptual framework of the actors and stages involved in LLM based testing. Lets delve into a little bit more detail and the challenges involved. The continuous arrows denote technical challenges and the dashed arrows denote social/ human challenges.

Preparation

involves configuring the models, such as parameters-setting, fine-tuning models for improved performance within the context of the specific test task in hand, and handling the data use for training and testing.

Configuration

The challenge here is understanding the interactions between different configurations and programming languages, including parameter tuning and the selection of different models, and their impact on outcomes e.g. LLMs can perform well when used to test software in some languages but not well in others.

Fine-tuning

Incorrect fine-tuning can harm model performance and cause catastrophic forgetting i.e. the model loses previously acquired knowledge. Moreover, high quality and relevant data as well as access to specialized hardware and cloud infrastructure - needed for fine-tuning may not be readily available.

Data issues

With no visibility into the data used to train commercial LLMs, it won't be possible to realistically evaluate the model's performance on unseen data. Also, there is a risk that the code generated by LLMs could breach proprietary rights.

Interaction

For a model that has been configured and ready-to-go, there is a strong correlation between how a prompt is phrased and the effectiveness of the LLM output.

Prompt Engineering

refers to the process of guiding the gen-AI systems to produce the desired output. The challenge lies in systematically designing prompts that guide the model towards useful, valid and in-context outputs. There are potential solutions such as in-context learning i.e. enhancing prompt accuracy by including representative examples directly within the input, in-memory programming i.e. feeding the previous LLM output back to it, self-refinement i.e. prompting the LLM to enhance the relevance and clarity of the prompt.

Context

refers to the information provided to the model to perform a specific task. The challenge is how to provide a broader base of relevant testing knowledge to enhance the LLM performance. It is not as straight forward as one would think since increasing the context is sometimes counterproductive. The question of how much context is enough - and which context is effective - remains largely open. There is also a need for LLMs to be robust under real-world constraints, where ideal inputs cannot always be guaranteed.

Retrieval Augmented Generation (RAG)

One challenge is cases where the retrieval context exceeds the model's processing capacity. Another challenge is RAG's dependence on the quality and relevance of the data used as input.

Validation

is evaluating how the LLMs perform.

Hallucinations

result in flawed code or inexact outputs/ calculations. Though hallucinations can be harnessed to extend the creative boundaries of testing by offering edge cases that the test engineer may have overlooked, uncontrolled hallucinations require effective migration strategies.

Metrics

Current metrics often produce misleading evaluations by failing to capture functional equivalence between syntactically distinct and semantically correct code segments.

Social Challenges

are the factors (beyond technical) coming in the way of adopting LLMs.

Trust

When a test fails, it can be hard to decipher whether it is due to a genuine bug or because of a model failure. Another factor undermining trust is that LLMs often struggle to perform well with complex or specific scenarios requiring advanced reasoning or semantic understanding.

Adoption

i.e integration of LLMs into software processes faces the challenges of performance, cost, privacy and usability. Though LLMs have demonstrated potential, their application is often time-consuming, resource-inefficent (frequent API calls, too many iterations in getting to a satisfactory output) and require a lot of manual post-processing. Running LLMs locally or fine-tuning them require expensive and specialized hardware, and LLMs-as-a-service can also be costly or limited by data regulations policies. Using LLMs via external services raises risks of data leakage and unclear usage policies, particularly in regulated sectors that handle sensitive data. Finally, existing development workflows don't lend themselves to be easily co-opted into being integrated with LLMs

Education

The responsible and effective use of LLMs in software testing require proper education and training programs which are not included in the current learning roadmaps.

To conclude

Although LLM's adoption can yield substantial cost and resource savings, these benefits must be weighed against the additional effort required for complementary activities - such as prompt engineering and fine-tuning, necessary to ensure high test quality. Challenges related to automation, reliability of LLM output, social aspects, and education need to be still carefully addressed.