한 권으로 끝내는 Node & Express(2판): 모던 웹을 위한 서버 사이드 자바스크립트의 모든 것

81

5

장

품질보증

립하는 일

이라고 생각합니다.

필자는 프로젝트가 크든 작든, 설령 주말에 재미로 진행하는 프로젝트라도

QA

계획을 세우길

권합니다.

QA

계획은 거창하거나 정교할 필요는 없습니다.

QA

계획의 목표는 프로젝트가 의

도한 대로 동작하도록 하기 위해 취한 단계 전체를 기록하는 겁니다.

어떤 형태든

QA

계획은 살아 있는 문서입니다. 다음과 같은 상황이 생길 때마다

QA

계획을

업데이트해야 합니다.

●

새로운 기능 추가

●

기존 기능의 변경

●

기능 제거

●

테스트 기술이나 테크닉의 변경

●

QA

계획에서 놓친 버그

마지막 항목은 좀 더 언급할 가치가 있습니다.

QA

계획이 아무리 빈틈없다 하더라도 버그는

일어날 겁니다. 그리고 그런 일이 생기면 버그를 어떻게 예방할 수 있을지 생각해보세요. 답을

찾으면 이런 타입의 버그도 예방할 수 있도록

QA

계획을 수정합니다.

여기까지 읽었다면

QA

에 상당한 노력이 필요하다는 걸 깨닫고, 어느 정도까지 해야 합리적일

지 궁금해졌을 겁니다.

5.2

QA

에 가치가 있을까?

QA

는 꽤 많은 비용이 들어갑니다. 때에 따라선

아주

많은 비용이 들어갑니다. 그만한 가치가

있을까요?

QA

는 복잡한 인수가 들어가는 복잡한 방정식입니다. 대부분의 조직은 투자했으면

얻는 것이 있어야 한다는 방식에 따라 움직입니다. 돈을 썼다면, 최소한 쓴 만큼은 (가능하면

더) 벌어야 하는 게 당연합니다. 하지만

QA

에서는 그런 관계를 명확하게 따질 수 없습니다.

잘 만들어지고 잘 알려진 프로젝트 하나가 있고, ...