장바구니로 보내던 안내

구매 한도 관련 테스트 케이스에 이런 것이 있었다. 이전 구매와 합쳐서 한도를 넘기는 절차가 적혀 있다.

Open Table of contents

상황 — 한도를 합산하는 케이스

절차는 이렇다.

1. 옵션 구매수량 제한 상품 진입
2. 제한 옵션을 n개 무통장 입금으로 구입
3. n + a 의 합이 제한을 넘기도록 a개 수량 입력
4. 구매하기 > 즉시구매

기대 결과 칸은 이렇게 적혀 있다.

얼럿 노출되며, 장바구니로 이동된다.
"1인당 구매한도를 초과하여, 수량이 변경된 상품이 있습니다.
 장바구니에서 다시 수량을 확인해주세요."

이 절차의 핵심은 두 번 나눠 사는 데 있다. n개 를 먼저 사고 a개 를 더 담는 흐름이다.

한도를 판정할 때 a 만 보는 것이 아니라는 뜻이다. 앞서 산 n 을 함께 세고 있다.

1인당 구매한도 를 세는 방식은 둘로 갈릴 수 있다.

[이번 주문만]  a 가 한도 이하면 통과
[누적]         n + a 로 판정

케이스가 성립하려면 누적 쪽이어야 한다. 이번 주문만 보면 a 를 한도 이하로 두는 것만으로 얼마든지 살 수 있다.

누적으로 세려면 그 사람의 지난 주문을 더하는 조회가 한 번 더 붙는다. 한도가 걸린 상품에서만 돌겠지만 어디까지 거슬러 더하는지는 케이스에 없다.

케이스가 결제 수단을 무통장 입금 으로 못 박아 둔 것이 눈에 걸린다.

주문 완료
입금 대기
입금 확인

입금 대기 가 끼는 무통장은 주문과 결제 사이에 며칠이 놓인다. 카드는 그 둘이 거의 붙어 있다.

[주문 시점]      입금 안 해도 한도에 포함
[입금 확인 시점]  입금해야 포함

입금 확인 을 기준으로 삼으면 입금 안 한 주문이 한도에 안 들어간다. 같은 상품을 계속 주문해 둘 수 있게 된다.

한 사람이 많이 가져가는 것을 막는 것이 목적이면 주문 완료 시점이 맞다. 결제 수단을 굳이 적어 둔 것은 그 차이가 드러나는 조합을 고른 것으로 읽힌다.

주문 완료 시점으로 센다면 그다음 물음은 취소한 주문을 어떻게 다루느냐가 된다.

[돌아옴]     정상적으로는 맞음. 대신 취소를 반복해 우회 가능
[안 돌아옴]  실수로 취소한 사람이 못 삼

돌려주면 주문과 취소를 되풀이해 한도를 넘길 여지가 생긴다. 안 돌려주면 잘못 누른 사람이 그 상품을 영영 못 산다.

어느 쪽으로 갔는지는 문서 어디에도 없다. 둘 다 불편이 남는 자리라 무엇을 골랐는지보다 왜 골랐는지가 적혀 있어야 한다.

기대 결과 에서 눈에 띄는 것은 이동 쪽이다.

[정상]  상세 → 결제
[이 경우]  상세 → 장바구니

즉시구매 는 원래 장바구니를 거치지 않는 흐름인데 여기서만 그쪽으로 보낸다.

[결제로 바로]  조정된 수량으로 결제 화면. 확인이 스쳐 지나감
[장바구니로]   목록에서 수량을 직접 보고 고칠 수 있음

수량이 조정됐다면 사용자가 그 수를 보고 고칠 기회가 있어야 한다. 결제 화면에서는 그 확인이 스쳐 지나간다.

얼럿 문구도 장바구니에서 다시 수량을 확인해주세요 로 어디서 무엇을 하라고 알려 준다. 목적지가 아니라 할 수 있는 일이 있는 곳으로 보낸 셈이다. 장바구니에서 출발한 경우에는 이미 그 화면이라 이동 없이 글로만 알린다.

같은 목적을 출발지에 따라 다른 방식으로 이루고 있다. 이런 분기는 화면 흐름도에 잘 안 드러나고 케이스에만 남는다.

여기서 기대 결과 에 안 적힌 것이 하나 보인다.

[적혀 있음]  얼럿 노출, 장바구니 이동
[안 적힘]    그 상품이 장바구니에 담겨 있는지

즉시구매 는 장바구니에 담지 않는 흐름이다. 이동만 하고 담기지 않으면 사용자는 빈 장바구니를 보게 된다.

수량을 고치라고 보냈는데 고칠 대상이 없는 상태가 된다. 화면이 바뀌는 것은 눈에 띄고 자료가 어떻게 되는지는 덜 띄어서 앞의 것만 적힌다.

기대 결과 에 화면 쪽과 자료 쪽을 함께 적어야 이런 자리가 비지 않는다.