아쿠아, AI로 테스트케이스 만들고 커버리지까지 더 촘촘하게 본다

AI가 테스트케이스 생성까지 들어옴

• 아쿠아 클라우드가 기존 ‘아쿠아 AI 코파일럿’을 갈아엎고 ‘아쿠아 인텔리전스’를 공개함

  • 대상은 그냥 테스트 자동 실행 도구가 아니라, 테스트 설계부터 커버리지, 개발 도구 연동, 계정 보안까지 묶은 테스트 관리 플랫폼임
  • 애자일 환경에서 매 스프린트마다 요구사항 보고 테스트케이스 짜야 하는 QA 조직을 정면으로 겨냥한 느낌임

• 핵심은 요구사항 문서, 짧은 업무 설명, 음성 프롬프트만으로 테스트케이스를 만들 수 있다는 점임

  • 단일 테스트케이스뿐 아니라 여러 테스트케이스를 한 번에 생성할 수 있음
  • 원문 기준으로는 테스트 데이터까지 같이 만들도록 설계됐다고 함

• 흥미로운 건 “대충 AI가 예시 몇 개 만들어줌” 수준이 아니라 테스트 설계 기법을 넣었다는 점임

  • 등가 분할(Equivalence Partitioning), 경계값 분석(Boundary Value Analysis), 의사결정 테이블(Decision Table)을 생성 과정에 반영함
  • 숙련된 테스터가 일정에 쫓기면서도 챙기던 사고방식을 AI 생성 플로우에 박아 넣겠다는 방향임

프로젝트 문서 기반으로 테스트를 만들게 함

• 지식베이스도 커짐. 업로드 가능한 파일 크기가 기존 10MB에서 100MB로 늘어남

  • 지원 형식은 PDF, DOCX, XLSX, 마크다운(Markdown), TXT임
  • 파일 검색과 실시간 처리 상태 확인도 추가돼서, 문서가 준비됐는지 사용자가 확인할 수 있음

• 이 방향은 일반적인 테스트 예시 생성보다 “우리 프로젝트 문서 기준 테스트”에 초점이 있음

  • QA 조직 입장에서는 요구사항, 테스트케이스, 테스트 데이터 사이의 연결성을 유지하는 게 중요함
  • 특히 감사나 규제 대응이 있는 조직에서는 “이 테스트가 어떤 요구사항에서 나왔는지”가 그냥 관리 포인트가 아니라 생존 포인트임

커버리지 계산도 더 현실적으로 바뀜

• 커버리지 대시보드는 기존처럼 테스트 시나리오 상태만 보는 방식에서 한 단계 내려감

  • 이제 시나리오 안에 들어 있는 개별 테스트케이스 실행 결과를 기준으로 진행률을 보여줌
  • 예를 들어 테스트케이스 20개짜리 시나리오와 5개짜리 시나리오를 같은 무게로 계산하지 않는다는 얘기임

• 이건 보기보다 실무 체감이 큰 부분임

  • 시나리오 10개 중 8개 완료 같은 숫자는 그럴듯해 보여도, 실제 테스트케이스 수가 다르면 진행률이 왜곡될 수 있음
  • 아쿠아는 실제 실행된 테스트케이스 수와 결과를 반영해 완료율을 산정하고, 차트에서 개별 테스트 결과와 소속 시나리오를 같이 보여줌
  • 기존 대시보드 설정은 유지된다고 하니, 운영 중인 팀 입장에서는 마이그레이션 부담을 줄이려는 쪽으로 보임

지라·애저 데브옵스 연동도 강화

• 지라(Jira) 쪽은 클라우드 플러그인을 아틀라시안(Atlassian)의 포지(Forge) 플랫폼으로 옮김

  • 지라 로드맵과 보안 체계에 맞춘 연동 기반을 만들려는 움직임임
  • 지라 안에서 테스트케이스와 테스트 시나리오 통계를 더 명확하게 확인할 수 있다고 함

• 지라 데이터센터 사용자는 여러 아쿠아 환경을 특정 지라 프로젝트와 연결할 수 있음

  • 대규모 조직이나 다중 프로젝트 환경에서는 테스트 관리 단위를 프로젝트별로 쪼개는 게 중요함
  • “한 팀이 한 프로젝트만 본다”는 전제가 깨진 조직에서는 이런 연결 방식이 은근히 필요함

• 애저 데브옵스(Azure DevOps) 연동은 사용자 정의 리치 텍스트 필드까지 양방향 동기화함

  • 재현 절차(Repro Steps), 승인 기준(Acceptance Criteria) 같은 필드를 이름 기준으로 맞춰 동기화함
  • 같은 내용을 개발 도구와 QA 도구에 두 번 입력하는 일을 줄이고, 양쪽 내용이 달라지는 문제도 줄이는 목적임

규제 산업용 보안 통제까지 포함

• 이번 버전에는 프라이빗 클라우드와 온프레미스 배포 환경을 위한 비밀번호 정책도 들어감

  • 관리자는 비밀번호 만료 주기를 지정할 수 있음
  • 최근 사용한 비밀번호 재사용을 막을 수 있음
  • 반복 로그인 실패 시 계정을 잠그는 정책도 적용 가능함

• 이 기능은 은행, 보험, 공공기관 같은 조직을 꽤 노골적으로 겨냥함

  • 이런 곳은 테스트 이력뿐 아니라 계정 관리, 주기적 인증 갱신까지 컴플라이언스 체계에 들어가는 경우가 많음
  • 기술 계정과 외부 인증 계정은 예외로 둘 수 있어서, 자동화 계정까지 무작정 잠가버리는 상황은 피하려는 설계임

결국 QA 운영 전체를 묶으려는 업데이트

• 이번 개편은 AI 테스트케이스 생성 하나만 내세운 업데이트라기보다 QA 운영 체계를 넓게 묶으려는 쪽에 가까움

  • 테스트 설계는 AI가 돕고
  • 커버리지는 개별 테스트케이스 기준으로 더 정확하게 보고
  • 개발 도구와 QA 도구는 동기화하고
  • 계정 보안은 감사 기준에 맞추는 흐름임

• 한국 개발자나 QA 조직에도 꽤 직접적인 얘기임

  • 금융, 공공, 의료 쪽 프로젝트를 해본 팀이면 테스트 근거와 이력 관리가 얼마나 귀찮은지 바로 알 거임
  • 특히 지라나 애저 데브옵스를 이미 쓰는 조직이라면, AI 생성보다도 연동과 추적성 개선 쪽이 더 현실적인 관심 포인트가 될 수 있음

---

기술 맥락

• 여기서 중요한 선택은 AI를 단순한 테스트 문장 생성기가 아니라 요구사항 문서 기반 테스트 설계 도구로 놓은 거예요. QA에서 진짜 어려운 건 케이스를 많이 뽑는 게 아니라, 어떤 요구사항 때문에 이 케이스가 나왔는지 설명하는 일이거든요.

• 커버리지를 시나리오 단위가 아니라 개별 테스트케이스 실행 결과로 계산하는 것도 같은 맥락이에요. 시나리오마다 포함된 테스트케이스 수가 다르면 완료율이 쉽게 왜곡되니까, 실제 실행 단위로 내려가야 관리자가 믿을 수 있는 숫자가 나와요.

• 지라와 애저 데브옵스 연동을 강화한 이유도 QA 도구만 따로 좋아져서는 운영이 안 되기 때문이에요. 개발팀은 이슈와 요구사항을 개발 도구에서 보고, QA팀은 테스트 관리 도구에서 보니까 두 시스템의 필드가 어긋나면 같은 결함을 두고도 서로 다른 얘기를 하게 돼요.

• 비밀번호 만료, 재사용 차단, 로그인 실패 잠금 같은 기능은 화려하진 않지만 규제 산업에서는 꽤 현실적인 요구예요. 은행이나 공공 프로젝트에서는 테스트 계정도 감사 대상이 될 수 있어서, QA 플랫폼이 보안 정책을 같이 품어야 도입 장벽이 낮아져요.