TestLink — 오픈소스 테스트 케이스 관리

개념

TestRail과 가장 크게 다른 지점은 기능이 아니라 "누가 서버를 운영하는가"다

모듈 7(레슨 1)에서 TestRail·Zephyr 같은 테스트 관리 도구를 배웠다. 그 도구들은 대부분 상용 SaaS 다. 돈을 내면 벤더가 서버를 운영해주고, 우리는 브라우저로 접속만 한다.

TestLink는 정반대 축에 있다. PHP로 만들어진 웹 애플리케이션이고, 소스를 내려받아 우리 팀이 직접 서버에 설치해서 운영한다 (PHP 런타임 + MySQL/MariaDB + 웹서버). 이 한 가지 차이가 나머지 장단점을 거의 전부 결정한다.

"무료"라는 말이 비용이 0이라는 뜻은 아니다 . 라이선스 비용이 서버 유지보수·업데이트·백업이라는 운영 인건비로 옮겨간 것 뿐이다. 이 교환이 이득인지 손해인지가 도구 선택의 핵심 질문이다.

그런데도 아직 쓰이는 이유 — 무료 + 온프레미스

TestLink의 UI는 솔직히 낡았다. 화면 밀도가 높고, 클릭 수가 많고, 최신 도구에 익숙한 사람이 처음 열면 당황한다. 그런데도 살아남은 이유는 단순하다. 무료이고, 우리 서버 안에 둘 수 있다 는 두 특성 자체가 어떤 팀에게는 다른 모든 단점을 덮을 만큼 크기 때문이다.

• 예산이 없는 소규모 팀·스타트업 초기 — 인당 과금 도구는 사람이 늘수록 비용이 붙는다. 아직 매출이 없는 단계에서는 "일단 서버 한 대에 올려두고 쓰는" 선택이 현실적이다.
• 폐쇄망을 요구하는 공공기관·금융권 일부 — 망분리 규정 때문에 외부 SaaS 접속 자체가 막혀 있는 환경이 있다. 이때는 도구가 좋은지 나쁜지가 아니라 설치 가능한지 가 1차 기준이 된다.
• 데이터 주권 — 테스트 케이스에는 내부 시스템 구조가 적히는 경우가 많다. 이를 외부에 두지 않겠다는 정책이 있으면 선택지가 자동으로 좁혀진다.

기본 구조는 다른 도구와 똑같다

TestLink를 열면 화면은 낯설지만 개념은 이미 아는 것들이다.

즉 테스트 스위트 → 테스트 계획 → 실행 결과 라는 뼈대가 TestRail과 개념적으로 동일하다. 이게 이 레슨의 가장 중요한 수확이다. 모듈 7에서 배운 것은 특정 도구 사용법이 아니라 도구를 넘나드는 보편 개념 이었다는 확인이다. 처음 보는 테스트 관리 도구를 만나도 "스위트는 어디, 계획은 어디, 실행 기록은 어디"만 찾으면 반나절이면 적응한다.

실무에서 왜 필요한가

신입 QA가 TestLink를 직접 고를 일은 드물다. 하지만 이미 TestLink가 깔려 있는 팀에 들어갈 확률 은 생각보다 낮지 않다 — 오래된 사내 시스템이나 폐쇄망 프로젝트에서 여전히 돌아가고 있다. 그때 "이건 왜 이렇게 불편하냐"고 반응하는 사람과, "온프레미스 제약 때문에 고른 도구구나"라고 배경을 읽는 사람은 팀에서 다르게 평가받는다.

더 실용적인 가치는 도구 선택을 비용 관점에서 말할 수 있게 된다 는 점이다. "TestRail 쓰죠"가 아니라 "인당 과금이니 팀이 커지면 비용이 늘고, TestLink는 무료지만 서버 담당자와 백업 절차가 필요합니다"라고 정리해 말하면 그 판단은 QA의 의견이 아니라 근거가 된다.

실습 과제

과제 1 — 도구 선택 근거 만들기 (8분)

아래 두 팀에 각각 TestRail과 TestLink 중 무엇을 권할지 고르고, 이유를 두 줄씩 적는다.

1. QA 2명·개발 5명인 시드 단계 스타트업. 클라우드 서비스를 자유롭게 쓸 수 있고, 인프라를 맡을 사람은 따로 없다.
2. 망분리가 적용된 금융권 프로젝트. 외부 인터넷 접속이 차단돼 있고, 사내 서버와 운영 담당자는 있다.

과제 2 — 개념 대응표 직접 채우기 (7분)

모듈 7(레슨 1)에서 배운 개념 네 가지(테스트 케이스, 테스트 스위트, 테스트 실행, 트레이서빌리티)를 왼쪽에 두고, 각각이 TestLink에서 어떤 메뉴 이름에 해당할지 오른쪽에 적어본다. 그다음 표를 채우면서 헷갈렸던 항목이 있었는지 한 줄로 남긴다 — 그 항목이 개념 자체를 덜 이해한 지점이다.

자가 체크리스트

• TestLink와 TestRail의 가장 큰 차이가 "셀프호스팅 대 SaaS"라는 점을 설명할 수 있다
• 라이선스 비용이 0이어도 운영 비용은 0이 아니라는 트레이드오프를 설명할 수 있다
• TestLink가 예산 제약·폐쇄망 환경에서 여전히 선택되는 이유를 말할 수 있다
• 테스트 스위트·테스트 계획·실행 결과라는 구조가 도구와 무관한 보편 개념임을 안다
• 주어진 팀 상황에서 어떤 계열의 도구를 권할지 근거를 들어 고를 수 있다

흔한 실수

• 무료니까 비용이 없다고 보고한다. 서버·백업·업데이트·장애 대응에 드는 시간이 실제 비용이다. 이걸 빼고 비교하면 나중에 "왜 QA가 서버를 고치고 있냐"는 상황이 온다.
• 백업 없이 운영한다. SaaS는 벤더가 알아서 해주지만 셀프호스팅은 아무도 대신 해주지 않는다. DB 백업과 복구를 실제로 해본 적이 있는지 까지가 백업이다.
• UI가 낡았다는 이유로 도구 전체를 무시한다. 그 팀이 그 도구를 고른 제약 조건이 따로 있다. 배경을 먼저 확인한다.
• 도구가 바뀌면 개념도 새로 배워야 한다고 생각한다. 메뉴 이름만 다를 뿐 스위트·계획·실행이라는 뼈대는 모듈 7에서 배운 그대로다.
• 보안 패치를 미룬다. 인터넷에 노출된 오래된 PHP 애플리케이션은 공격 대상이 된다. 폐쇄망이 아니라면 업데이트 주기를 정해둔다.

참고 자료

• TestLink 공식 사이트 — 다운로드와 설치 요구사항(PHP·MySQL 버전)
• TestLink 사용자 매뉴얼 — 테스트 프로젝트·계획·실행 메뉴 구조
• ISTQB Glossary — Test Management Tool — 도구 계열과 무관한 공식 정의