품질을 높여주는 테스트

개발된 사이트의 품질을 높이기 위해서는 테스트가 중요하다. 테스트를 통해 많은 오류와 버그, 불필요성, 불편성 등을 찾아내고 수정에 수정을 하다보면 그만큼의 품질은 좋아진다. 다만, 테스트 중에 새로운 기능을 추가하는 것은 사이트를 망치는 지름길이다.

 

개발된 기능도 테스트가 진행중인데, 새로운 기능을 추가하게되면 다시 만들고, 똑같은 테스트를 해야하기 때문에 시간이 배 이상으로 늘어난다. 새로운 기능에 대해서만 테스트하는 걸로 생각해서는 안된다. 새로운 기능이 추가되면, 기존에 복잡하게 얽혀 있는 코드들에게도 영향을 미치기 때문이다. 

 

테스트 시나리오에 있는 내용대로 반복해서 테스트하기에는 시간이 오래 걸린다. 테스트 시나리오는 전 화면에 대한 테스트 내용이 있기 때문에 문서의 내용도 길고, 테스트할 요소도 많아 테스트 시나리오 하나만 가지고 테스트를 진행하기에는 시간적인 문제와 테스트 인력의 피로감이 많다.

 

---

테스트 시나리오대로 전체 테스트를 하기 전에 개발자들이 자신이 개발한 부분을 테스트하면 그나마 한결 수월한 테스트가 진행될 수 있다. 이런 개발자들이 하는 테스트를 단위테스트(Unit test)라고 한다. 단위테스트는 자신이 개발한 부분만 테스트 하기 때문에 전체적인 흐름이나 기능이 많은 페이지단위의 검증 테스트는 힘들다. 

 

단위 테스트는 개발자가 직접 하는 테스트이기 때문에 그나마 스트레스를 덜 받는다. 자신이 테스트하고 자신이 수정하면 되기 때문에 테스트 인력이나 관리 인원에게 압박을 받지 않는다. 다만, 자신이 테스트하기에 적확한 테스트를 수행하기는 다소 무리가 있다. 

 

자신이 만든 것에는 주관적이고 관대하기 때문이다.

---

개발자들의 단위테스트가 다 완료되고 난 후에 다음 일정이 진행되면 좋겠지만, 프로젝트에는 일정이 있기 때문에 단위테스트가 완료되지 않더라도 다음 일정이 진행된다. 개발자들의 단위테스트가 무한하다고 한다면 아마도 프로젝트는 끝나지 않고, 단위테스트에 머무를 것이다. 자신이 만든것을 다른 사람에게 공개하고, 심사를 받거나 평가를 받는건 부담과 두려움이 앞서기 때문이다. 

 

아무리 자신있게 만든 것이라 할지라도 하루가 지나면 아쉬움이 남기 때문이다. 

 

단위 테스트가 완료되건 완료되지 않았건 일정대로 다음 테스트가 진행된다. 이제 개발자들의 테스트가 아닌 테스트 인력들이 테스트 시나리오를 보고 전체 테스트를 진행한다. 이런 테스트를 통합테스트(Integration Test)라고 한다. 테스트 인력에는 전문 테스트 인력도 있지만 고객(발주사)이 직접 테스트를 진행한다. 

 

단위 테스트를 진행한 후에 진행되는 테스트라서 오류가 많이 나오지 않을 거라고 예상하지만, 50%도 채 안되는 성공률을 기록하는 경우가 많다. 그렇다고 단위테스트에서 개발자들이 소홀히 했던 것은 아니다. 앞서 단위 테스트는 주관적이고, 관대하기때문에 다른 사람의 입장에서 객관적이고, 관대하지 않은 테스트가 진행되기에 미처 발견되지 못한 오류나, 기능과 기능의 연결성이 부족한 것도 원인이 될 수 있다. 또한, 고객(발주사)의 인력이 테스트하게 되면 요구사항이나 기획에 없던 내용인데, 오류라고 던지는 경우도 있다. 

 

요구사항이나, 스토리보드, 테스트 시나리오에 없는 내용을 오류라고 던질 경우에는 PM이나 PL이 조절해줘야 한다. 만약 테스트 인력이나, 고객(발주사)의 테스트를 개발자가 바로 응대하게 되면 남아 있는 개발자는 아마도 없을 것 같다. 모든 기능이나 사이트의 전체를 개발자 개개인은 모르기 때문에 응대도 안될 뿐더러, 응대를 한다해도 수정은 거의 불가능하다. 응대을 하다보면 수정 개발 할 시간이 안되기 때문이다. 

---

테스트 인력이 오류를 찾아내 알려줄때는 테스트 시나리오를 작성한 엑셀에 기재하는 경우도 있지만, 엑셀로 기재된 오류들을 PM이나 개발자들이 보기에는 다소 힘든 점이 있다. 또한 엑셀은 하나의 파일이기에 개개인이 파일을 열어서 확인하고, 체크한 후 한사람이 모아서 취합해야한다. 번거롭다. 이런 번거로움을 해소하고 직관적으로 표시하기 위해 이슈 관리 프로그램을 사용한다. 

 

이슈 관리 프로그램을 다른 말로 이슈 트래킹(Issue Tracking)이라고도 부른다. 이슈를 추적한다라는 의미이다. 이슈 트래킹 프로그램에는 제목, 내용, 담당자, 기간, 수정 여부 등이 작성되며, 담당자 별로 자신에게 할당된 내용을 바로 확인할 수 있다. 또한 수정이 완료 되었는지 진행중인지 확인할 수 있기 때문에 누락없이 테스트여부를 진행할 수 있다.

 

이슈 트래킹 프로그램으로 많이 사용하는 툴로 레드마인(Redmine), 맨티스(Mantis), 지라(Jira), 깃허브(Github)등이 있으며, 회사 자체적으로 만든 프로그램이 있다. 

 

---

PM은 테스트 결과에 대해서 검토하고, 새로운 기능이면 추가 기능으로, 스토리보드에 없는 내용이지만, 미처 인지하지 못한 오류에 대해서는 수정 일정 등을 분류하여 관리하고, 개발자들에게 할당해줘야 한다. 새로운 기능이 많아 지면 많아 질수록 기간이 더 연장되는 것은 당연하며, 프로젝트가 흔들릴 수도 있다. 어느때보다는 이때가 PM의 중간 역할이 가장 중요하다. 

---

통합 테스트가 완료되면 바로 오픈하는것이 아니다. 통합 테스트는 테스트 시나리오에 나와있는대로 문서에 입각한 테스트이기 때문에 전체 흐름을 검토하기에는 조금 무리가 있다. 테스트 시나리오라는 문서가 아닌 사용자 입장에서 처음 진입부터 회원 가입, 로그인 등 처음부터 끝까지의 흐름을 테스트해야한다. 이런 테스트를 관통(전구간) 테스트(End-To-End Test)라고 한다. 

 

관통테스트는 기능 하나하나를 체크하는 것이 아닌, 전체 흐름에 대한 체크이다. 기능 하나하나에 대한 체크는 앞서 통합 테스트에서 진행했기에 이 부분에서는 흐름에 대한 오류만 체크한다. 처음 부터 끝까지 잘 흘러가는지 체크하기 때문에 중간에 오류로 인해 끊기면 그 부분을 우선적으로 수정해야한다. 수정되기 전까지는 다음 스탭 진행이 되지 않기 때문이다. 

 

통합테스트의 기능, 페이지 단위의 테스트도 중요하지만, 전체 흐름이 중간에 끊겨버리면 사이트 운영에 차질이 있기 때문에 무엇보다 중요한 테스트이다. 

---

관통 테스트까지 완료되었다면, 오픈을 하면 좋겠지만, 오픈하기 바로 전 다시 한번 고객(발주사)가 최종 테스트를 진행한다. 이를 인수테스트(Acceptance Test)라고 한다. 오픈을 해도 문제가 없는지, 고객의 입장에서 오류가 없는지 등을 최종적으로 한번 더 점검한다. 

 

이렇게 테스트를 단계별로 여러번 해도 오픈하면 생각지도 못한 오류가 튀어나온다. 지금껏 오픈 이후 오류가 없이 완벽히 돌아가는 사이트를 경험한 적이 없다. 개발자가 개발을 못해서도 아니고, 테스트 인력이 테스트를 못해서도 아니고, 발주사 인력이 점검을 철저히 못한 것도 아니다. 아무리 완벽을 기한다해도 오픈하면 여지없이 오류가 나온다. 

 

테스트는 오류를 완전히 없애는 것이 아닌, 최소화 시키는 것이다. 걸작이라고 칭찬한 영화도 옥의 티가 있는 것처럼 완벽한 것은 보기 힘들다. 완벽하다는 것은 더이상 손 볼 곳이 없다는 의미이다. 손 볼 곳이 없다면 애써 수정할 필요도 없고, 업그레이드할 필요성도 없다. 기능 추가로 업그레이드를 할 수도 있지만, 완벽한 것에 손을 대는건 좀 처럼 쉽지만은 않다. 새 신발, 새 차를 살때 처음에는 애지중지하는 것처럼 완벽은 강박관념을 만든다. 

 

오류나 실수가 있으면 그것을 고치기 위해서라도 손을 대고, 고치면서 기능 한 두개 더 추가하고, 그렇게 사이트가 발전한다. 

 

완벽은 목적이지 목표가 아니다.  

---