1.4 AI 도입으로 인한 기존 품질 보증(QA) 체계의 붕괴

1. 소프트웨어 결정론의 해체와 테스트 오라클의 위기

소프트웨어 품질 보증(Quality Assurance, QA)의 근간은 입력에 따른 출력이 사전에 정의된 기대값과 일치하는지를 검증하는 결정론적 과정에 있다. 전통적인 소프트웨어 공학, 즉 소프트웨어 1.0 체계에서는 개발자가 명시적인 로직을 코드로 작성하며, 특정 입력값 x에 대해 시스템이 산출해야 하는 정답 y가 수학적으로나 논리적으로 명확히 정의된다. 이러한 체계에서 검증 메커니즘인 ’테스트 오라클(Test Oracle)’은 프로그램의 실행 결과가 옳은지 그른지를 판단할 수 있는 확고한 기준점이 되어 왔다. 그러나 인공지능(AI), 특히 대규모 언어 모델(LLM)과 머신러닝(ML) 시스템이 도입되면서 이러한 결정론적 검증 체계는 근본적인 붕괴 직면에 처하게 되었다.

전통적 소프트웨어에서 오라클은 “The Oracle Problem in Software Testing: A Survey“에서 정의한 바와 같이, 프로그램의 결과가 명세(Specification)와 일치하는지를 판별하는 장치이다. 하지만 AI 시스템은 인간이 로직을 직접 코딩하는 대신 방대한 데이터로부터 패턴을 학습하여 동작을 정의하는 데이터 중심(Data-driven) 방식이다. 이로 인해 “시스템이 올바른 시점에 올바른 일을 하고 있는가?“라는 근본적인 질문에 답하기 위한 오라클을 설계하는 것이 극도로 어려워지는 ’테스트 오라클 문제(Test Oracle Problem)’가 발생한다. AI는 인간이 수학적으로 정의할 수 없는 복잡한 문제를 해결하기 위해 도입되는데, 역설적으로 정답을 명확히 정의할 수 없기에 사용하는 도구임에도 불구하고 QA 과정에서는 다시 명확한 정답을 요구받는 모순에 빠지게 된다.

이러한 오라클의 부재는 단순한 기술적 불편함을 넘어 QA 프로세스 전체의 신뢰성을 무너뜨린다. 전통적인 QA 플랫폼들은 2006년경의 스크립트 기반 방법론에 머물러 있으며, 이는 현대의 민첩한 AI 기반 워크플로우와 근본적으로 호환되지 않는다. 개발팀이 클라우드 네이티브와 AI 가속 워크플로우로 이동하는 동안 테스팅 업계가 과거의 방법론에 고착됨으로써 발생하는 불일치는 조직의 엔지니어링 예산 30~50%를 소모하면서도 취약한 테스트 결과만을 양산하는 결과를 초래한다.

2. 테스트 오라클의 네 가지 유형과 AI 환경에서의 부적합성

테스트 오라클의 유형을 분석하면 왜 AI 시스템에서 기존 QA 체계가 작동하지 않는지 더욱 명확해진다. 오라클은 일반적으로 명시적, 파생적, 암시적, 인간 오라클의 네 가지로 분류된다. 아래 테이블은 각 오라클의 특성과 AI 도입 시 발생하는 한계점을 요약한 것이다.

전통적 소프트웨어는 ’코드 기반(Code-driven)’이기에 명시적 오라클을 통해 결과의 정확성을 수학적으로 증명할 수 있었다. 하지만 머신러닝 시스템은 데이터 패턴을 복제하여 동작을 상속받으므로, 인간이 사전에 정답 쌍을 모두 나열하는 ‘브루트 포스(Brute force)’ 방식의 오라클 구축이 불가능하다. 예를 들어 자율주행 시스템이나 이미지 인식 모델에서 조명, 시야각, 노이즈 등 무한한 환경 변수를 모두 고려한 명시적 오라클을 만드는 것은 물리적으로 불가능에 가깝다. 이러한 오라클 문제의 심화는 결국 ’정답지 없는 채점’이라는 QA의 근본적 모순을 낳는다.

3. 비결정성(Nondeterminism)과 플레이키 테스트의 확산

AI 모델, 특히 LLM의 가장 당혹스러운 기술적 특성은 동일한 입력에 대해 매번 다른 출력을 내놓을 수 있다는 비결정성(Nondeterminism)이다. 전통적인 회귀 테스트(Regression Testing) 체계는 “한 번 통과한 테스트는 코드가 변하지 않는 한 영원히 통과해야 한다“는 반복 가능성(Repeatability)의 원칙 위에 세워졌다. 그러나 AI 기반 소프트웨어에서는 이 원칙이 붕괴되며, ’플레이키 테스트(Flaky Test)’가 QA 현장을 점령하게 된다.

3.1 플레이키 테스트의 경제적 손실과 생산성 저하

플레이키 테스트란 코드 변경이 없음에도 불구하고 실행 시마다 성공과 실패를 무작위로 반복하는 불안정한 테스트를 말한다. “Flaky Tests: The Silent Productivity Killer“에 따르면, 일반적인 엔지니어링 조직은 플레이키 테스트로 인해 연간 430만 달러 이상의 손실을 보고 있다. 개발자의 59%가 매주 혹은 매일 플레이키 테스트 문제에 대응하고 있으며, 이는 단순한 시간 낭비를 넘어 테스트 스위트 전체에 대한 신뢰를 갉아먹는다.

이러한 플레이키 현상은 AI 모델의 확률적(Probabilistic) 특성에서 기인한다. 전통적 QA에서 테스트 실패는 곧 ’수정해야 할 결함’을 의미했지만, AI 테스팅에서는 실패가 단순한 ’확률적 변동’일 가능성이 높다. 이로 인해 개발자들은 테스트 실패 보고를 보아도 이를 무시하거나 “다시 돌리면 통과하겠지“라는 안일한 태도를 갖게 되며, 이는 결과적으로 운영 환경에 치명적인 버그가 유입되는 통로가 된다.

3.2 배포 속도와 조직 문화의 충돌

플레이키 테스트는 지속적 통합 및 배포(CI/CD) 파이프라인의 핵심인 자동화 게이트(Automated Gate)를 무력화한다. 테스트 결과가 불안정하면 배포를 진행할지 말지에 대한 의사결정을 자동화할 수 없기 때문이다. 조사 결과에 따르면 플레이키 테스트 문제를 해결한 팀은 매일 혹은 온디맨드 배포가 가능한 반면, 그렇지 못한 팀은 배포 주기가 2~3주로 지연되는 경향을 보인다. 이는 AI 기술을 통해 얻고자 했던 개발 가속화의 이점을 QA 단계의 병목 현상이 모두 상쇄해 버리는 꼴이다.

4. 시맨틱 정합성: ’정답’의 기준이 문자열에서 의미로 이동

기존 QA 체계의 붕괴를 가속화하는 또 다른 요인은 ’정답’의 정의가 변화했다는 점이다. 전통적인 단위 테스트(Unit Test)에서는 assert response == "Hello World"와 같은 엄격한 문자열 비교가 표준이었다. 하지만 AI 모델이 생성하는 답변은 문법적, 의미적으로는 동일하지만 표현 방식이 무수히 다양할 수 있다. “The End of Expected Result: Why Traditional QA Fails in the AI Era“에서 지적하듯, 사용자의 질문에 대해 “카드 한도 초과입니다“라고 답하든 “잔액이 부족하여 결제가 거부되었습니다“라고 답하든 두 답변 모두 사용자에게는 정답일 수 있다.

전통적인 문자열 기반 단언문(Assertion)은 이러한 유연성을 수용하지 못하고 ’가짜 실패(False Negative)’를 발생시킨다. 이를 해결하기 위해 시맨틱 유사성(Semantic Similarity)을 측정하는 방식이 제안되고 있으나, 이는 QA 프로세스에 새로운 복잡성을 부가한다. 정답 여부를 판별하기 위해 코사인 유사도(Cosine Similarity)와 같은 수학적 지표를 도입하고 일정 임계값(Threshold)을 설정해야 하는데, 이 임계값을 얼마로 설정할 것인가 자체가 또 다른 주관적 영역이기 때문이다.

5. 기존 자연어 평가 지표의 수학적 한계와 오용

AI 모델의 품질을 측정하기 위해 널리 사용되어 온 BLEU나 ROUGE 같은 지표들도 엔지니어링 관점의 QA 오라클로서는 심각한 한계를 드러낸다. 이러한 지표들은 텍스트의 실제 의미나 논리적 정합성을 평가하기보다는 단어의 겹침(Overlap)에 기반한 통계적 수치만을 제공하기 때문이다.

5.1 BLEU 및 ROUGE 스코어의 메커니즘 분석

BLEU(Bilingual Evaluation Understudy)는 주로 기계 번역의 품질을 측정하기 위해 개발되었으며, n-gram 정밀도(Precision)에 기반한다.
BLEU = BP \cdot \exp\left( \sum_{n=1}^{N} w_n \log p_n \right)
여기서 BP는 브레비티 페널티(Brevity Penalty)로, 모델이 생성한 문장이 참조 문장보다 짧을 경우 점수를 깎는 역할을 한다. 구체적으로 BP = \min(1, \exp(1 - r/c))로 계산되며, r은 참조 문장의 길이, c는 생성된 문장의 길이다. 이 수식은 모델이 짧고 간결하지만 핵심적인 답변을 내놓았을 때 오히려 낮은 점수를 부여하게 만드는 부작용을 낳는다.

반면 ROUGE(Recall-Oriented Understudy for Gisting Evaluation)는 요약 모델의 성능 측정을 위해 재현율(Recall)에 집중한다.
ROUGE\text{-}N = \frac{\sum_{S \in \{Reference\}} \sum_{gram_n \in S} Count_{match}(gram_n)}{\sum_{S \in \{Reference\}} \sum_{gram_n \in S} Count(gram_n)}
이러한 지표들의 공통적인 문제는 ’의미’를 이해하지 못한다는 것이다. 예를 들어 “나는 사과를 먹지 않았다“와 “나는 사과를 먹었다“는 단어 하나 차이로 의미가 정반대가 되지만, BLEU나 ROUGE 상에서는 매우 높은 점수를 기록하게 된다. 이는 정확성이 생명인 금융이나 의료 도메인의 소프트웨어 QA에서 이 지표들을 오라클로 사용할 수 없는 결정적인 이유가 된다.

5.2 BERTScore와 임베딩 기반 지표의 부상

전통적 지표의 한계를 극복하기 위해 제안된 BERTScore는 문맥적 임베딩(Contextual Embeddings) 간의 코사인 유사도를 계산하여 의미적 동등성을 평가하려 시도한다.
R_{BERT} = \frac{1}{\vert x \vert} \sum_{x_i \in x} \max_{y_j \in y} x_i^\top y_j
BERTScore는 단순 단어 매칭보다는 높은 인간 평가 일치도(약 59%)를 보이지만, 여전히 도메인 특화 지식이나 미세한 논리적 오류를 감지하는 데는 한계가 있다. 무엇보다 이러한 모든 점수 기반 지표들은 “통과(Pass)” 아니면 “실패(Fail)“라는 명확한 바이너리 판단을 내려야 하는 QA 파이프라인에서 ’어느 점수부터 합격인가’라는 모호한 기준을 강요함으로써 기존의 자동화 체계를 마비시킨다.

6. LLM-as-a-Judge: 평가의 자동화인가, 편향의 가속화인가?

최근 붕괴된 QA 체계를 보완하기 위해 고성능 AI 모델(GPT-4 등)을 평가자로 사용하는 ‘LLM-as-a-Judge’ 기법이 급부상하고 있다. 이는 인간의 주관적 평가를 대규모로 자동화할 수 있다는 기대를 불러일으켰으나, 실증적 연구 결과는 이 방식 역시 결정론적 오라클을 대체하기에는 여전히 불안정함을 보여준다.

6.1 LLM 판사의 구조적 편향성

“Beyond Consensus: Mitigating the agreeableness bias in LLM judge evaluations” 연구에 따르면, LLM 판사들은 강력한 ’긍정 편향(Agreeableness Bias)’을 보인다. 실험 결과, LLM은 정답인 출력을 올바르게 식별하는 능력(True Positive Rate)은 96% 이상으로 매우 높았으나, 틀린 출력을 오답으로 잡아내는 능력(True Negative Rate)은 25% 미만으로 참담한 수준이었다. 즉, 모델이 틀린 답을 내놓아도 AI 판사는 이를 ’정답’이라고 너그럽게 판단해 버리는 경향이 강하다는 것이다.

또한 다음과 같은 여러 가지 기술적 편향이 LLM 판사의 신뢰성을 저해한다.

이러한 편향성 때문에 “Order in the Evaluation Court: A Critical Analysis of NLG Evaluation Trends“와 같은 최신 논문들은 LLM 판사를 맹목적으로 신뢰하는 행위를 경고하고 있으며, 이는 결국 QA 프로세스에서 다시 인간의 개입을 요구하는 회귀 현상을 낳고 있다.

7. 코드 생성 AI와 유닛 테스트의 역설

개발자들의 생산성을 획기적으로 높여준 코파일럿(Copilot)과 같은 코드 생성 AI는 테스팅 영역에서 새로운 위협이 되고 있다. “Design choices made by LLM-based test generators prevent them from finding bugs” 연구에 따르면, AI가 생성한 테스트 케이스들은 종종 기존 코드의 ’버그가 포함된 동작’을 정답으로 간주하여 정당화하는 위험한 양상을 보인다.

AI 테스트 생성 도구들은 기존 구현을 관찰하여 테스트 오라클을 만드는데, 만약 원본 코드에 버그가 있다면 AI는 그 버그를 ’의도된 기능’으로 학습하여 테스트를 설계한다. 결과적으로 버그를 검출해야 할 테스트가 오히려 버그를 보호하는 방어막 역할을 하게 되는 것이다. 이는 “버그는 오직 실패하는 테스트 케이스를 통해서만 드러난다“는 소프트웨어 테스팅의 대원칙을 정면으로 위반한다. 상용화된 AI 테스트 생성 도구들이 높은 코드 커버리지(Code Coverage)를 달성했다고 광고하지만, 실제로는 버그를 찾아내는 ‘결함 검출 밀도’ 면에서는 인간이 작성한 테스트에 비해 현저히 떨어지는 이유가 여기에 있다.

8. 변형 테스트(Metamorphic Testing): 무너진 오라클의 대안적 접근

전통적 오라클이 부재한 AI 시스템에서 유일한 탈출구로 논의되는 기법이 변형 테스트(Metamorphic Testing, MT)이다. MT는 개별 입력에 대한 정답을 아는 대신, 여러 입력들 사이의 관계인 ’변형 관계(Metamorphic Relations, MR)’를 정의하여 시스템을 검증한다.

예를 들어 고양이 이미지를 판별하는 모델에서 원본 이미지(Source Input)를 90도 회전시킨 이미지(Follow-up Input)를 입력했을 때, 모델은 여전히 이를 ’고양이’로 분류해야 한다. 만약 회전시킨 이미지에서 분류 결과가 바뀐다면, 우리는 구체적인 정답 점수를 모르더라도 이 시스템에 결함이 있음을 확신할 수 있다.

MT의 핵심적인 가치는 다음과 같다.

1. 정답지 없는 검증: 특정 입력에 대한 완벽한 정답(Oracle)이 없어도 시스템의 논리적 일관성을 검증할 수 있다.
2. 자동화된 테스트 케이스 생성: 하나의 원본 테스트 케이스로부터 수많은 변형 테스트 케이스를 자동으로 생성할 수 있어 테스트 범위를 획기적으로 넓힌다.
3. 비결정성 완화: 확률적 모델에서도 “입력의 변화에 따른 출력의 변화 양상“은 일정한 규칙을 따라야 하므로, 비결정성 문제에 대응할 수 있는 강력한 도구가 된다.

하지만 MT 역시 변형 관계(MR)를 설계하는 과정에서 고도의 도메인 지식과 인간의 개입이 필요하다는 한계를 지닌다. 현재까지 MR을 완벽하게 자동 추출할 수 있는 상용 도구는 부재하며, 이는 QA 팀에게 새로운 형태의 고난도 업무를 부과하고 있다.

9. 실전 예제: AI 챗봇의 비결정성 대응을 위한 QA 전략의 변화

기존 QA 체계가 AI 도입으로 인해 어떻게 구체적으로 변화해야 하는지 실전 사례를 통해 살펴본다. 전통적인 비용 처리 시스템의 카테고리 분류 기능을 테스트한다고 가정하자.

9.1 과거의 결정론적 접근 (Software 1.0)

def test_expense_categorization():
    expense = "Starbucks Coffee"
    category = categorize_expense(expense)
    assert category == "Food & Dining"  # 단 하나의 정답만을 허용

이 테스트는 명확하고 빠르지만, AI 모델이 “Coffee Shops“나 “Restaurants & Cafes“라고 답변하는 순간 실패 처리된다.

9.2 현대의 확률적 접근 (Software 2.0)

AI 시대의 QA는 단일 성공 여부가 아닌 ’계약(Contract)’과 ’경계(Boundary)’를 테스트하는 방식으로 진화한다.

1. 구조적 계약 테스트: 응답이 유효한 JSON 형식인지, 필수 필드가 포함되어 있는지 검증한다.
2. 임계값 기반 검증: “Starbucks Coffee“에 대해 반환된 카테고리가 사전에 정의된 ’허용 리스트’에 포함되는지, 혹은 임베딩 유사도가 0.85 이상인지 확인한다.
3. 다중 샘플링 평가 (Multi-sample Evaluation): 동일한 테스트를 20번 실행하여 성공률(Success Rate)이 95% 이상인지를 측정한다.

이러한 변화는 QA의 역할이 ’정답 확인자’에서 ‘리스크 관리자’ 및 ’통계적 분석가’로 변모했음을 의미한다. 더 이상 “버그가 하나도 없다“는 선언은 불가능하며, “이 모델의 오류 발생 확률은 n\% 미만이며, 비즈니스 영향도는 수용 가능한 수준이다“라는 확률적 품질 보증이 표준이 된다.

10. 미래 전망: AI 네이티브 테스팅 플랫폼으로의 이행

결국 기존 QA 체계의 붕괴는 AI 네이티브(AI-native) 플랫폼으로의 완전한 전환을 요구한다. 전통적인 도구들이 10배의 생산성 향상과 95%의 유지보수 비용 절감을 약속하는 AI 기반 테스팅 도구들에 의해 대체되고 있다. 이러한 새로운 플랫폼들은 다음과 같은 특징을 갖는다.

• 자기 치유(Self-healing): UI 구조가 변경되어도 AI가 변경 사항을 감지하여 테스트 스크립트를 자동으로 수정한다.
• 자율 에이전트(Autonomous Agents): 인간이 시나리오를 작성하는 대신, AI 에이전트가 애플리케이션을 탐색하며 스스로 테스트 케이스를 생성하고 실행한다.
• 실시간 모니터링 및 피드백 루프: 운영 환경의 실제 데이터(Production Telemetry)를 CI/CD 파이프라인으로 피드백하여, 실제 사용자가 겪는 문제에 우선순위를 두고 테스트를 정렬한다.

조직적 측면에서도 QA와 개발의 경계가 무너지는 ‘시프트 레프트(Shift-left)’ 현상이 가속화되고 있다. 47%의 조직이 품질 확장성의 장벽으로 인력 부족을 꼽고 있는 상황에서, AI를 활용한 QA 자동화는 선택이 아닌 생존의 문제가 되었다. 테스터들은 이제 단순 반복 업무에서 벗어나 AI 모델의 편향성을 감시하고, 복잡한 비즈니스 시나리오에서 AI의 윤리성과 안전성을 평가하는 전략적 파트너로 진화해야 한다.

11. 결론: 결정론적 오라클 설계를 통한 신뢰의 재구조화

AI 도입으로 인한 기존 QA 체계의 붕괴는 소프트웨어 공학의 역사에서 피할 수 없는 지각변동이다. 비결정성과 오라클 문제라는 거대한 파도는 우리가 지난 수십 년간 의존해 온 ’확정적 정답’의 세계를 허물어뜨렸다. 그러나 이 붕괴는 동시에 더 견고하고 지능적인 품질 보증 체계를 구축할 수 있는 기회이기도 하다.

우리는 이제 단순한 문자열 비교를 넘어 의미론적 정합성을 이해하고, 확률적 결과를 통계적으로 제어하며, AI 판사의 편향성을 기술적으로 보정할 수 있는 능력을 갖추어야 한다. 특히 AI가 생성하는 불확실한 결과물들 사이에서 ’결정론적 정답지’를 제공할 수 있는 하이브리드 오라클 시스템의 설계는 AI 기반 소프트웨어의 신뢰성을 담보하는 최후의 보루가 될 것이다.

이어지는 장들에서는 이러한 붕괴된 체계 위에서 어떻게 다시 확고한 검증 기준을 세울 것인지, 즉 비결정성의 바다에서 결정론적 오라클을 구축하는 구체적인 기술적 해법들을 상세히 다룰 것이다. 품질 보증은 이제 끝난 것이 아니라, AI라는 새로운 엔진을 장착하고 더 높은 수준의 신뢰성을 향해 재도약하는 과정에 있다.

12. 참고 자료

1. The “Oracle Problem” and Its Impacts in Mixed Reality, https://ntrs.nasa.gov/api/citations/20230012828/downloads/Lehman%20-%20Oracle%20Problem_r3.pdf
2. Testing AI Systems: Handling the Test Oracle Problem, https://dev.to/qa-leaders/testing-ai-systems-handling-the-test-oracle-problem-3038
3. The Oracle Problem in Software Testing: A Survey, http://www0.cs.ucl.ac.uk/staff/m.harman/tse-oracle.pdf
4. The Death of Traditional QA - Functionize, https://www.functionize.com/blog/the-death-of-traditional-qa
5. AI Is Disrupting Test Automation - Virtuoso QA, https://www.virtuosoqa.com/post/ai-test-automation-future
6. (PDF) The Oracle Problem in Software Testing: A Survey, https://www.researchgate.net/publication/276255185_The_Oracle_Problem_in_Software_Testing_A_Survey
7. What is Test Oracle in Software Testing? - testRigor, https://testrigor.com/blog/what-is-test-oracle-in-software-testing/
8. Software Engineering for Machine Learning Applications, http://research.nii.ac.jp/iMLSE/SEMLA.pdf
9. The End of “Expected Result”: Why Traditional QA Fails in the AI Era …, https://medium.com/trendyol-tech/the-end-of-expected-result-why-traditional-qa-fails-in-the-ai-era-ba8318a3cbb5
10. 10 LLM Testing Strategies To Catch AI Failures | Galileo, https://galileo.ai/blog/llm-testing-strategies
11. Flaky Tests: The Silent Productivity Killer - Viral Patel, https://viral-patel.kit.com/posts/flaky-tests-the-silent-productivity-killer
12. Flaky Tests in Machine Learning: Challenges and Countermeasures, https://semaphore.io/blog/flaky-tests-machine-learning
13. Taming Test Flakiness: How We Built a Scalable Tool to Detect and, https://www.atlassian.com/blog/atlassian-engineering/taming-test-flakiness-how-we-built-a-scalable-tool-to-detect-and-manage-flaky-tests
14. Selenium at scale: Managing flaky tests in fast-moving Devops teams, https://www.t-plan.com/blog/selenium-at-scale-managing-flaky-tests-in-fast-moving-devops-teams/
15. How to Eliminate Flaky Tests Using AI-Based Stability Checks, https://rtctek.com/how-to-eliminate-flaky-tests-using-ai-based-stability-checks/
16. AI Boosts Dev but QA Lags: Testing Automation Gap Persists, https://www.itprotoday.com/it-management/ai-boosts-dev-but-qa-lags-testing-automation-gap-persists
17. Deterministic Software Testing vs Non-deterministic LLM Agent, https://medium.com/@promptedmind28/deterministic-software-testing-vs-non-deterministic-llm-agent-testing-what-you-need-to-know-f3abd5f9009d
18. Testing the Untestable: Strategies for Non-Deterministic Systems, https://www.octoco.ai/blog/testing-the-untestable
19. BERTScore in AI: Enhancing Text Evaluation - Galileo AI, https://galileo.ai/blog/bert-score-explained-guide
20. LLM Response Evaluation with Spring AI: Building LLM-as-a-Judge, https://spring.io/blog/2025/11/10/spring-ai-llm-as-judge-blog-post
21. LLM Evaluation metrics explained. ROUGE score, BLEU, Perplexity, https://medium.com/data-science-in-your-pocket/llm-evaluation-metrics-explained-af14f26536d2
22. Understanding BLEU and ROUGE score for NLP evaluation - Medium, https://medium.com/@sthanikamsanthosh1994/understanding-bleu-and-rouge-score-for-nlp-evaluation-1ab334ecadcb
23. Understanding BLEU and ROUGE score for NLP evaluation, https://www.geeksforgeeks.org/nlp/understanding-bleu-and-rouge-score-for-nlp-evaluation/
24. Utilising LLM-as-a-Judge to Evaluate LLM-Generated Code - Medium, https://medium.com/softtechas/utilising-llm-as-a-judge-to-evaluate-llm-generated-code-451e9631c713
25. Standardized Assessment Framework for Evaluations of Large, https://www.preprints.org/manuscript/202501.0471
26. Evaluating Large Language Models Benchmarks & Challenges, https://www.enkefalos.com/ai/evaluating-large-language-models/
27. BERTScore: A Contextual Metric for LLM Evaluation - Analytics Vidhya, https://www.analyticsvidhya.com/blog/2025/04/bertscore-a-contextual-metric-for-llm-evaluation/
28. Arena G-Eval vs Single-Output “LLM-as-a-judge” — Case Study, https://medium.com/@jolalf/arena-g-eval-vs-single-output-llm-as-a-judge-case-study-43c86fe0f1c9
29. Robust Statistical Evaluation of LLMs with Imperfect Judges - arXiv, https://arxiv.org/html/2601.20913v1
30. RESpecBench: How reliable is LLM-as-a-judge? Rigorous, https://openreview.net/forum?id=eFwJZIN9eI
31. Mitigating the Agreeableness Bias in LLM Judge Evaluations, https://aicet.comp.nus.edu.sg/wp-content/uploads/2025/10/Beyond-Consensus-Mitigating-the-agreeableness-bias-in-LLM-judge-evaluations.pdf
32. Awesome LLM Evaluation | LLMEvaluation - GitHub Pages, https://alopatenko.github.io/LLMEvaluation/
33. Design choices made by LLM-based test generators prevent them, https://www.researchgate.net/publication/387184471_Design_choices_made_by_LLM-based_test_generators_prevent_them_from_finding_bugs
34. Metamorphic Testing of AI-based Applications: A Critical Review, https://thesai.org/Downloads/Volume11No4/Paper_98-Metamorphic_Testing_of_AI_based_Applications.pdf
35. Metamorphic Testing: A Review of Challenges and Opportunities, https://scispace.com/pdf/metamorphic-testing-a-review-of-challenges-and-opportunities-32h35onaoz.pdf
36. How effectively does metamorphic testing alleviate the oracle, https://vuir.vu.edu.au/33046/1/TSEmt.pdf
37. A Machine Learning Approach for Developing Test Oracles for, https://ksiresearch.org/seke/seke16paper/seke16paper_137.pdf
38. Metamorphic Testing: Testing the Untestable, https://research.nottingham.edu.cn/files/31438001/293_combinepdf_2_.pdf
39. Metamorphic Testing of Large Language Models for Natural, https://valerio-terragni.github.io/assets/pdf/cho-icsme-2025.pdf
40. publications - Valerio Terragni, https://valerio-terragni.github.io/publications/
41. Manual vs Automated Testing in the Age of AI - Sutherland Global, https://www.sutherlandglobal.com/insights/blog/why-traditional-testing-wont-work-in-the-age-of-ai
42. AI Vs. Conventional Testing: A Comprehensive Comparison Of, https://kuey.net/index.php/kuey/article/download/7495/5589/14614
43. AI Test Case Prioritization in CI/CD Pipelines - Ranger, https://www.ranger.net/post/ai-test-case-prioritization-cicd-pipelines
44. Limitations of AI in Quality Assurance: Test Your Software … - Avenga, https://www.avenga.com/magazine/limitations-of-ai-in-quality-assurance-test-your-software-with-ai-test-your/