구축의 기본 절차 (4) 구현과 테스트, 그리고 구현 이후

구현 단계

구현 단계에서는 디자인, 퍼블리싱, 프로그래밍이 차례로 진행된다.

- 디자인 단계에서는 화면 설계서를 바탕으로 그래픽 작업이 진행되며, “재해석”

- 트렌드에 맞추고, 요소는 살려두면서 맛을 살리고, 요소의 재조합, 브랜드의 가치를 높이는 방향 등.

 

- 기획 쪽에서는 요소들이 유지가 되어야 한다. 순서를 지켜야 한다는 것은 강조가 필요.

디자인은 재료를 가지고 재해석해서 맛을 내는 단계이고 그래픽적인(미적인) 것을 통해서 사용자들로 하여금 더 몰입감 있게 쓰게끔 하는 목적이다 보니까 그 해석하는 과정에서 요소를 없애거나 구조 변경하는 것들에 대해서 적절한 피드백을 줘야 한다

 

- 퍼블리싱 단계에서는 디자인된 그래픽을 HTML, CSS, JavaScript로 코딩하여 웹 브라우저에 표시될 수 있도록 한다.

=> 소위 디지털화 작업.

그걸 통해서 화면을 재구성하고 필요한 인터랙션 같은 것들을 넣어주는 것. 회원 가입 등의 기능은 못함.
프로그래밍 단계에서는 퍼블리싱된 파일에 회원 가입, 결제 등의 기능을 구현하는 작업이 이루어진다.
api 연결해서 하나의 상품이 완성됨.

⇒ 프로그래밍 단계까지 가게 되면 이제 하나의 움직이는 상품이 만들어지는 것

 

그래서 구현의 시작은 화면 설계서의 확정이지만 구현의 끝은 테스트 상품의 완성.
테스트할 수 있는 대상이 만들어지는 것

 

구현 완료 이후

이렇게 구현 단계가 모두 완료되면, 작업 관리서에서 전체 일정의 90% 이상이 완료로 표시되게 된다.

- 그 때부터는 테스트를 할 수 있는 환경이 만들어지게 되고, 검수 단계로 넘어가게 된다.

 

검수를 진행하기 위해서는 '검수 계획서'를 작성해야 한다.

이 검수 계획서는 기획자가 작성하며, 크게 단위 테스트와 통합 테스트로 나누어진다.

 

검수

기획 담당자는 디자이너가 작업을 완료하면 기획팀에 검수 요청을 한다.

"디자인이 완료되었으니 확인해 주세요"라고 요청이 오면, 기획자가 검수하고 통과되면 퍼블리싱 단계로 넘어간다.

 

퍼블리싱이 완료되면 다시 기획자가 확인 요청을 받고, 검수가 끝나면 프로그래밍 단계로 진행된다.

이렇게 단계별로 진행되는 과정에서, 기획자는 항상 기준에 부합하는지를 체크한다.

• 특히 크로스 브라우징 같은 경우에는 퍼블리셔가 작업한 것이 특정 브라우저에서는 제대로 표시되지만, 다른 브라우저에서는 깨지는 문제가 생길 수 있다. 이런 부분도 기획자가 확인하고 체크해야 하는 사항이다.

 

테스트(작업 관리서)

구현이 끝나면, 테스트 단계로 넘어가게 된다.

- 테스트 단계에서 이루어지는 작업은 '작업 관리서'를 통해 관리된다.

• 이 작업 관리서는 정보 구조도와 유사한 형태를 가지며, 각각의 단계별 완료 여부를 기재하는 문서이다.

 

여기에는 기획, 디자인, 퍼블리싱, 프로그래밍 등 단위별로 담당자와 상태값이 포함되어 있다.

이를 통해 각 페이지에 대한 설계가 완료되었는지, 디자인이 완료되었는지, 퍼블리싱이 완료되었는지를 단계별로 체크할 수 있다.

 

구현 단계가 다 끝났다고 한다면 이 현황판에 전체 일정이 이제 90% 이상이 찍히고, 테스트할 수 있는 환경이 만들어지니 그때가 이제 검수를 할 수 있는 시점이다. 검수를 하기 위해서 우선 검수 계획서라고 하는 걸 만든다.

 

 

단위 테스트 vs 통합 테스트

검수 계획서에서 단위 테스트는 페이지 단위로 이루어진다. 장바구니 페이지라면, 그 페이지에서 나올 수 있는 모든 케이스를 테스트하여 정상적으로 작동하는지 확인하는 것이다.

- 모든 케이스가 정상적으로 작동하면 그 페이지는 통과된다.

 

통합 테스트는 사용자의 흐름을 예측하여 테스트한다.

• 예를 들어, 비회원 사용자가 사이트를 방문해 상품을 둘러보다가, 주문 과정에서 회원 가입을 하고, 쿠폰을 적용하여 결제하는 등의 복잡한 과정을 테스트하는 것이다.

- 이런 복잡한 과정에서는 단위 테스트에서 발견하지 못한 오류들이 나타날 수 있다. 이러한 로직상의 오류를 발견하기 위해 통합 테스트가 진행된다.

- 통합 테스트는 사용자의 실제 사용 흐름을 예측하여 오류를 잡아내는 것이 목적이다.

 

테스트 진행 방법은 이 케이스별로 테스트 아이디가 별도로 부여된다.
이 케이스가 정상인 경우는 정상 표시를 해 주는데 만약에 하나라도 이 페이지가 오류가 있으면 그 오류에 대한 이유를 기록을 한다.

 

단위 테스트

단위 테스트는 페이지별로, 화면 설계서에 기재된 항목을 기준으로 테스트가 이루어진다.

=> 화면 설계서에 기반하여 해당 항목들이 정상적으로 작동하는지를 확인하는 것이다.

 

• 단위 테스트는 보통 기획자가 작성하고, QA(품질 보증) 팀이 이를 보완하여 테스트를 진행한다. QA가 없는 프로젝트에서는 기획자가 직접 테스트를 진행하기도 한다.
• 단위 테스트는 페이지별로 테스트 아이디를 부여하여 진행되며, 정상적인 경우는 정상 표시를 한다.
• 하지만 하나라도 오류가 있으면, 그 이유를 기록하고 해당 페이지는 오류로 처리된다.

이런 방식으로 반복적으로 오류를 수정하면서, 전체 페이지가 정상으로 나올 때까지 테스트를 진행한다.

=> 단위 테스트는 보통 짧게는 2주, 길게는 한 달 정도 진행된다.

 

통합 테스트

단위 테스트가 완료되면, 통합 테스트 단계로 넘어간다. 통합 테스트 시나리오는 최대한 많은 상황을 고려하여 작성되며, 각 케이스를 기반으로 테스트를 진행한다.

⇒ 로직적인 오류를 잡아내기 위함.

 

통합 테스트는 어떤 사용자의 흐름을 예측해서 테스트를 하는 거죠.예를 들어서 어떤 비회원 사용자가 사이트 방문해서 사이트를 보다가 상세 페이지에서 주문을 하는 과정에서 회원 가입을 하면 쿠폰을 준대. 이 흐름 전체를 다룬다.

 

• 예를 들어, 커머스 사이트의 경우, 결제와 관련된 케이스들이 매우 중요하다. 결제 유형에 따라 테스트 케이스를 세분화하여 모든 결제 유형이 정상적으로 작동하는지 확인해야 한다.
• 결제에서 문제가 발생하면 치명적인 오류가 될 수 있기 때문에, 결제와 관련된 부분은 특히 신경 써서 테스트해야 한다.

 

오픈 시기 생성

테스트가 완료되면, 오픈 시기를 잡는다. 오픈 시기가 결정되면, 개발 서버에서 작업한 내용을 라이브 서버로 옮기고 도메인을 연결하여 사이트를 라이브로 전환한다.

라이브로 전환되면, 에이전시 측에서는 1~2주 정도 대기하면서 문제가 생길 경우를 대비해 대응 기간을 갖는다.

=> 이 대응 기간이 끝나면, 프로젝트는 종료되고 에이전시는 철수하게 된다.