테스트 케이스 절차 칸을 보다가 눈에 띄는 것이 있었다. 앞 두 줄이 같다.
Table of contents
Open Table of contents
상황 — 절차 칸의 앞 두 줄
한 케이스는 이렇다.
1. 카테고리 버튼 선택 > 특정 영역
2. 추천 카테고리 선택 > 1Depth 카테고리 선택
3. 2Depth 카테고리 > 정렬 드롭박스 선택
바로 아래 케이스도 앞 두 줄이 그대로다.
1. 카테고리 버튼 선택 > 특정 영역
2. 추천 카테고리 선택 > 1Depth 카테고리 선택
3. 2Depth 카테고리 > 목록 형태 변경 버튼 선택
같은 앞 두 줄이 스무 번 넘게 나오고 3번만 바뀐다.
정렬 드롭박스 선택
목록 형태 변경 버튼
1단 목록 확인
2단 목록 확인
큰 1단 목록 확인
롤링배너 확인
인기 브랜드 영역 확인
기획전 선택
목록 확인
푸터 확인
위로 버튼
새로고침
뒤로가기
카테고리 버튼 선택 과 추천 카테고리 선택 은 그대로이고 실제로 확인하는 것은 마지막 줄뿐이다.
앞은 전제였다
앞 두 줄은 확인할 자리까지 가는 길이다.
[전제 조건] 이 화면에 도달하는 방법
[확인 항목] 거기서 무엇을 보나
둘은 성격이 서로 다르다.
2Depth 카테고리 까지 가 있지 않으면 확인 자체를 시작할 수 없으니 앞에 적는 것은 맞다. 문제는 그것이 케이스마다 통째로 되풀이된다는 점이다.
전제 조건 과 확인 항목 을 한 칸에 이어 붙인 결과이기도 하다. 칸이 하나뿐이면 성격이 다른 둘을 갈라 둘 자리가 없다.
비교 — 전제를 분리하면
이렇게 둘 수도 있었을 것이다.
[전제] 카테고리 > 특정 영역 > 추천 > 1Depth > 2Depth 화면
케이스 1 정렬 드롭박스 선택
케이스 2 목록 형태 변경
케이스 3 롤링배너 확인
...
전제 를 한 번만 적고 나머지는 정렬 드롭박스 선택 같은 확인 항목만 담는다.
대신 내주는 것이 있다.
[각 케이스에 전부] 한 행만 보면 됨
[전제 분리] 전제를 찾아 올라가야 함
한 행을 보고 바로 수행하려면 전부 적힌 쪽이 낫다.
어느 쪽이 나은지는 어떻게 수행하느냐에 달렸다.
[순서대로 다 수행] 전제 분리가 낫다 — 한 번 가서 여러 개 확인
[골라서 수행] 각 행에 전부 있는 쪽
회귀 테스트는 위에서부터 순서대로 도는 쪽에 가깝다. 그러면 1Depth 카테고리 까지를 매번 다시 밟지 않고 한 번 가서 열 개를 확인하는데 문서에는 매번 적혀 있다.
읽는 부담도 있다. 스무 행이면 60줄인데 실제 정보는 20줄이고 앞 두 줄이 같으니 다른 부분을 찾을 때 눈이 미끄러진다.
탭마다 반복이 곱해진다
다른 반복도 있다. 탭이 셋이다.
추천상품 / 신규상품 / 무료배송
각 탭에 같은 확인 항목 다섯이 붙어 있다.
롤링배너 확인
목록 확인
푸터 확인
위로 버튼
새로고침
추천상품 과 신규상품 과 무료배송 각각에 다섯이면 열다섯 케이스가 된다.
세 탭이 정말 다를 이유가 있는지를 보면 다른 것은 하나뿐이다.
[다른 것] 보여주는 목록의 내용
[같은 것] 화면 구성, 배너, 푸터, 스크롤 동작
푸터 확인 이나 위로 버튼 은 한 탭에서 보면 나머지도 같을 가능성이 높다.
구현을 알면 줄어든다
그래도 전부 도는 이유가 있어 보인다.
탭마다 별도 화면으로 구현됐을 수 있다
한 탭만 고치다 다른 탭을 깨뜨렸을 수 있다
구현이 공통인지 아닌지를 모르면 다 확인하는 쪽이 안전하다.
[구현이 공통] 한 탭만 확인해도 됨
[구현이 별도] 전부 확인
케이스 개수가 푸터 를 그리는 코드가 하나인지 셋인지에 달려 있는 셈이다.
문서를 쓰는 쪽이 구현을 알면 케이스를 줄일 수 있고 모르면 전부 적는 것이 안전하다. 안전한 쪽을 고른 결과가 지금의 열다섯이다.
제약 — 곱해서 느는 개수와 등급
이 방식으로 가면 개수가 이렇게 는다.
탭 3개 × 확인 5개 = 15
탭이 5개가 되면 = 25
확인이 8개가 되면 = 40
탭 수와 확인 수가 더해지는 것이 아니라 곱해진다.
배포마다 회귀 테스트를 돌면 그 시간이 계속 늘어난다. 앞서 본 등급 열이 여기서 이해가 되는데 전부 못 할 때 무엇을 버릴지를 미리 정해 둔 것이다.
이런 반복은 자동화에 맞아 보이기도 한다.
[사람] 같은 앞 두 줄을 매번 수행
[자동] 전제 함수 하나, 확인 여러 개
전제 함수 하나로 빠질 것이 문서에 스무 번 적혀 있다는 뜻이기도 하다.
다만 롤링배너 확인 처럼 눈으로 보는 것은 자동으로 판정하기 어렵다. 롤링배너가 3초 간격으로 도는지 같은 것은 사람이 보는 편이 빠를 수 있다.
정리
- 케이스마다 앞 두 줄이 반복되고 실제 확인은 마지막 줄이다
- 앞은 전제이고 뒤는 확인 항목이라 성격이 다르다
- 전제를 분리하면 문서가 짧아진다
- 대신 한 행만 보고 수행하기는 어려워진다
- 순서대로 도는 문서면 분리하는 쪽이 맞아 보인다
- 같은 앞 두 줄이 이어지면 다른 부분에서 눈이 미끄러진다
- 탭마다 같은 확인이 반복돼 곱해서 는다
- 그것이 필요한지는 구현이 공통인지에 달렸다
- 문서 쓰는 쪽이 구현을 알면 케이스를 줄일 수 있다
- 곱해서 늘면 전부 수행하는 것이 언젠가 불가능해지고 등급이 그래서 있다
- 반복되는 앞부분은 함수로 뺄 수 있다는 신호다