✅ 도움이 되는 분

• 처음 웹/앱을 만드는 창업가
• 웹/앱 개발을 완료하지 못하고 있는 창업가
• 서비스 기획/PO/QA 없이 인수 테스트를 해야하는 모든 이들

🎯 핵심 질문

최초 버젼 웹앱 테스트 어떻게 할까?

🤝 전제 : 우리는 '사람'이다.

웹/앱이 시작은 했으나 완성되지 못하는 90%의 이유는 "완성"에 대한 생각이 서로 다르기 때문이에요. 즉, 웹/앱을 기획하는 사람과 구현하는 사람 사이의 간극 때문이에요. 통상적으로 창업자는 해결하고자 하는 '시장에 대한 지식'이 있지만 코드를 작성하지 못하고, 개발자는 그 지식이 없는 대신 웹/앱을 구현할 수 있는 지식이 있기 때문이에요.
 
우리가 웹/앱을 만들기 시작해야 할때 놓치지 말아야 할 사실이 있어요.  앱/웹에 대한 구체적이지 못한 기획을 바탕으로 내가 생각한 결과물을 만들어주는 사람은 없다라는 것이죠. 이걸 항상 마음에 담아두어야 그 상황이 닥쳐도 당황하지 않고 문제를 해결할 수 있어요.
 
이전 직장에서 처음 앱을 배포해 본 디자이너의 당황해 하는 표정을 아직도 잊을 수 없네요. 자신의 UX 디자인과는 다른 결과물이 나왔기 때문이죠.

한번에 양쪽이 만족하는 결과는 나오지 않기 때문에 앱/웹 개발에 테스트는 필수 절차에요. 그것도 1차에서 결코 끝나지 않고, 2,3.. n차까지 진행될수 있어요. 이걸 예상하고 웹앱개발을 시작하셔야 해요.

그 철학의 뿌리는 상호 전문지식을 존중하지만 휴먼에러가 나올 수 있는 “사람"이라는 것을 인정하는 것입니다.
 

⛰ 구체적이지 못한 해피 패스(Happy path)를 넘어

우리는 고객이 우리앱을 “행복하게" 사용하는 시나리오만을 생각하는 경향이 있어요. 이건 어쩌면 당연해요. 그러려고 앱을 만들기 때문이죠. 하지만 앱/웹 개발을 완료하기 위해서는 매우 구체적인 생각이 필요해요. 고객이 우리앱을 행복하게 사용하는 시나리오(Happy path) 외에, 배드 패스(bad path), 새드 패스(sad path)를 정의하고, 상세한 비즈니스 로직 단위의 구체적인 정의가 필요해요. 
 

Happy, Bad, Sad path 용어 점검!

• happy path는 웹/앱이 우리의 예상대로 작동하는 경우를 가정한 시나리오에요. 일반적으로 기능이 올바르게 작동하는 경우를 테스트해요.
• bad path는 사용자의 잘못된 입력이나 부정적인 사용 사례를 가정한 시나리오에요. 예상하지 못한 입력이나 예외 상황이 발생했을 때 어떻게 작동하게 만들것인지를 테스트해요. 
• sad path는 웹/앱의 오류 상황에 대한 시나리오에요. 예외 처리 또는 오류 복구 기능이 기획대로 작동하는지를 테스트해요.

자세한 예시는 아래에서 마저 설명해 볼게요.
 

어느 정도로 구체적 이어야 할까?
지난 글에서 소개한 가입 과정을 예로 들어보죠. 앱/웹을 처음 만드는 분들은 "가입" 과정이라고 하면 간단히 생각하는 경향이 있어요. 아이디, 비번을 새로 만들게 하면 끝이 아닐까? 하지만 실제 개발을 위해서는 더욱 세부적인 생각이 필요해요.
 
먼저, 가입하는 방식부터 정의해야 해요.
고객의 id는 고유하게 식별 가능해야 하기 때문에 id로서 입력한 이메일, 소셜 로그인 계정, 휴대폰 번호중 어떤 것을 활용할지 고려해야 해요.
 
여기에서는 이메일 가입 기능을 예로 설명할게요.
 
1)고객이 가입할지 / 로그인을 할지 의도를 확인해요.(가입 버튼 로그인 버튼)

2)가입하는 사용자에게 식별이 가능한 고유한 id로서 이메일을 입력 받아요.

• 이떄, 사용자가 입력한 이메일의 형태의 유효성을 검사할지 정해요.(Bad path 고려)
• 입력한 이메일 소유를 인증하는 절차를 둘지, 인증 없이 사용할지 결정헤요.(다른 사람의 메일을 기입할 수 있기 때문)

3)이메일을 인증하는 절차를 두기로 했다면, 인증 방법을 선택해요.

• 이메일 기입후, 인증 버튼을 클릭하면 해당 메일로 인증된 이메일이 식별됨을 알 수 있는 링크를 보내주는 방법
• 이메일 기입후, 인증 버튼을 클릭하면 해당 메일로 인증 코드를 보내주고, 일정 시간 안에 가입 화면에서 그 인증 코드를 입력하게 만드는 방법

 
4)이메일 인증 방법을 정했다면, 인증을 통과한 유저와 통과하지 못한 유저에 대한 정책을 정해요.

• 인증을 통과한 유저는 다음 절차를 진행함.
• 인증을 통과하지 못한 유저는 다음 절차 진행하지 않음.(Bad path 고려)
  • 부여되지 않은 일회용 인증 코드를 입력하는 경우 몇번까지 입력을 허용할지
  • 일회용 인증 코드의 유효한 입력시간 등을 정해요

5)인증을 통과한 유저는 가입시 비밀번호를 설정해요.

• 비밀번호에 입력이 가능한 문자, 숫자, 기호는 어떤 것을 허용할까?
• 비밀번호 설정에 최소 자리와 최대 자수는 몇자일까? 거기에 공백을 포함할까?
• 비밀번호 확인시, 통과하지 못한 유저에게 어떤 메시지를 줄까? 등을 정해요

6)비밀번호 확인 설정까지 완료되면, 회원가입 버튼을 활성화할지, 추가 정보를 입력하면 활성화할지도 정해요.

• 회원가입 버튼이 늘 활성화되어 있고, 클릭시 가입 조건을 입력하세요라는 메시지를 주는 방식도 있어요.

7)가입 완료시 바로 로그인 상태가 될지 , 다시 로그인 정보를 입력 후에 로그인 상태가 될지도 정해요.
8)가입완료한 고객이 가입한 이메일과 비밀번호를 잊어버렸다는 문의를 할때는 어떻게 대처할지도 정해요.
 
이 정도로 구체적 이어야 해요.

⭐️ 테스트 전에 해야할 일 : 인수 조건 협의

웹/앱 개발을 하기 위해 구체적인 내용이 필요하다보니 웹/앱을 만들고자하는 창업자와 개발자 사이에 다른 그림을 그리는 함정에 빠지기 쉬워요. 프로젝트 실패의 50%가 잘못된 요구사항 계획과 커뮤니케이션 이슈로 인해 발생하기도 하죠. 이런 최악의 상황을 피하기 위해 웹/앱을 기획하는 사람과 구현하는 사람 사이에 “동일한" 그림을 서로 확인해야 해요. 그 수단이 인수조건 협의에요. 인수조건은 사용자의 조건과 상황, 그에 따른 결과로 구성되요. 쉬운 이해를 돕기 위해 위에서 언급한 가입시 이메일을 인증하는 것까지를 예시로 할게요. 
 

인수조건 예시

• 로그인을 통해 식별되지 않은 사용자는 “가입"을 통해 식별된 사용자만 이용가능한 서비스를 이용할 수 있다.
  • 식별되지 않은 사용자는 자신이 보유한 고유한 이메일과 비밀번호, 생년월일을 입력함으로써 “가입”할 수 있다.
    • 식별되지 않은 사용자는 “가입하기"버튼을 클릭함으로써 고유한 이메일을 입력할 수 있다. 
    • 이메일을 입력한 사용자는 인증 코드를 통해 입력한 이메일을 인증한다.
      • 이메일을 입력하고 인증하기 버튼을 클릭하면 인증코드가 이메일로 전송되고, 사용자가 이 인증코드를 입력하고 확인 버튼을 클릭하면 이메일이 인증된다.
      • 이메일 포맷
        • xx@xx.xx 이메일 형태에 맞지 않는 이메일을 입력한 상태에서 인증하기 버튼을 클릭하면, 이메일 형태를 맞게 입력하라는 메시지를 본다.
        • 이메일 형태 검사는 @의 유무로만 한다.
      • 인증코드
        • 인증 코드는 2분만 유효하다. 즉 2분 안에 입력해야만 이메일을 인증한다.
        • 인증 코드는 6자리의 영문과 숫자로 구성된다.
        • 사용자는 입력한 이메일로 인증코드를 받는다.
        • 인증 코드는 2분이 지나지 않더라도, 다음 인증코드가 발급되면 유효하지 않다.
        • 사용자는 재발송 버튼을 클릭함으로써, 입력한 이메일로 인증코드를 다시 받는다.
        • 인증코드 재발송 버튼 클릭은 1분간 2번만 가능하다.

인수 조건 작성법

• 첫째, 인수조건은 사용자의 입장에서 작성되어야 해요.
• 둘째, 인수조건은 제품의 의도와 명확한 그림에 대해 제품 개발과 관련된 멤버 모두가 공통적으로 이해할 수 있도록 작성해요.
• 셋째, 인수조건은 테스트 가능하도록 true / false가 명확하게 작성해요.
• 여러 작성 형태가 있으나, 대표적으로 시나리오 oriented를 추천해요. 개발시 테스트 형태와도 가장 유사하기 때문이죠.
  • given - when -then 에 맞춰 작성해요

given : 사용자의 상태
when : 사용자의 액션
then : 사용자가 보게 되는 것

🏃🏼‍♂️ 인수조건 협의후 테스트 절차 🏃🏼‍♂️ 

인수조건을 협의한 다음 UX/UI 디자인, 개발, 테스트 케이스 작성을 거쳐 테스트를 진행해요.
이때 테스트하는 방식을 협의할 필요가 있는데요. 시간과 자원의 한계로 인해 초기 창업자는 "수동"으로 테스트하는 방법을 추천해요.
테스트 진행은 인수 조건을 바탕으로 만들어진 테스트 케이스 문서를 바탕으로 이루어져요. 여기에서 발생하는 버그를 확인하고 버그 간 먼저 해결해야할 우선순위를 정해 해결해 나가요. 모든 테스트 케이스를 통과할 수 없기 때문에 출시까지 반드시 해결해야하는 최우선순위 버그를 메이커(디자이너, 개발자)들과 협의해요.
 

🛬 마치며

앱/웹을 만드는 과정은 생각보다 쉽지 않아요. 인수조건 협의 부터 세부 ux 디자인, 개발, 테스트, 상용 배포까지 각자 다른 전문성을 가진 멤버들이 협업해야하는 과정이에요. 따라서, 우리가 문제라고 정의한 것을 뾰족하게 만들 수 있는 "최소한"의 인수조건이 필요해요. 현재의 기획에서 최대한 덜어내야 웹/앱의 개발 완료를 경험하실 거에요. 모든 창업자 분들 파이팅입니다.
 
제 글이 도움이 되었다면, 좋아요. 구독 꼭 부탁드리겠습니다.

더 좋은 콘텐츠로 만나뵙겠습니다. 
___
 

🙋🏻‍♂️ 글쓴이 소개
✅0 to 1 business : 세번의 창업, 한번의 액싯(500K AUD), 소프트뱅크 벤쳐스 투자 유치
✅ 1 to 10 단계의 business : 혜움, 핀다, 그린랩스

✅ linkedin : https://www.linkedin.com/in/%ED%86%B5%EB%AF%BC-%EC%9C%A0-9aa1a1160/