🧪 Software Testing · 5/8 · 약 8분

시리즈 전체 보기

웹 문서 편집기를 처음 검토할 때는 원본 문서가 브라우저에서 얼마나 비슷하게 보이는지가 가장 눈에 띄었다. 텍스트가 보이고 표가 그려지면 편집도 어렵지 않을 것처럼 느껴졌다.

하지만 문서를 열어 보는 일과 수정한 결과를 다시 원래 형식으로 저장하는 일은 전혀 다른 문제였다. 화면은 멀쩡해 보여도 표의 병합 정보, 목록의 계층, 식별자의 연결이 저장 과정에서 달라질 수 있다. 도입 판단의 기준을 ‘렌더링 성공’에서 ‘왕복 뒤 의미 보존’으로 바꿔야 했다.

#DocumentEditor · #RoundTrip · #Compatibility · #Web

이 글에서 다룰 것

1. ‘잘 열린다’를 네 단계로 쪼갰다

문서가 브라우저에 나타났다는 한 문장에는 서로 다른 성공 조건이 섞여 있다. 단계별로 나누면 어디까지 확인했는지가 분명해진다.

단계 확인 질문 대표 위험
읽기 원본 구조와 값을 손실 없이 가져왔는가? 지원하지 않는 요소를 조용히 누락
렌더링 사용자가 문서를 이해할 수 있게 보이는가? 표·목록·스타일의 시각적 왜곡
편집 허용된 변경을 구조를 깨지 않고 반영하는가? 한 셀 수정이 주변 요소까지 변경
저장과 재열기 다시 연 문서에서 구조와 의미가 유지되는가? 재저장 과정의 비가역적 손실 
원본 문서
   ↓ 읽기
중간 표현
   ↓ 렌더링·편집
변경된 중간 표현
   ↓ 다시 저장
새 문서
   ↓ 재열기·비교
시각·구조·의미 보존 결과

이 전체를 한 번 통과해야 비로소 왕복 호환성을 논의할 수 있다. 앞 단계의 성공이 뒷 단계의 성공을 자동으로 보장하지 않는다.

2. 시험 문서는 기능이 아니라 위험으로 골랐다

간단한 한 문서가 왕복에 성공해도 복잡한 문서가 안전하다고 말하기 어렵다. 서로 다른 위험을 가진 가상 문서 묶음을 만들어 같은 시험을 반복하는 방안을 검토할 수 있다.

가상 문서 포함 요소 확인하려는 위험
기본 문서 제목, 문단, 단순 표 기본 읽기·쓰기 흐름
구조 문서 병합 셀, 중첩 목록, 여러 구역 계층과 관계의 보존
추적 문서 REQ-001을 포함한 표와 참조 식별자와 연결 의미의 보존
경계 문서 지원 여부가 불명확한 요소 누락·대체·중단 정책

문서별로 ‘원본 그대로 두는 요소’와 ‘수정할 요소’를 미리 정한다. 그래야 수정하지 않은 영역이 함께 변하는 부작용도 발견할 수 있다.

3. 유사성보다 보존 수준을 따로 기록했다