본 글은 글쓴이의 개인적인 생각이 담겨있을 수 있습니다.
PICK 프로젝트 - pick-server-Saturn
https://github.com/DSM-PICK/pick-server-Saturn
QA?
Quality Assurance의 약자로 품질 보증이라는 뜻이다.
쉽게 생각하면 기능이 모두 정상적으로 돌아가는지 확인하는 것이라고 생각할 수도 있는데,
일반적인 테스트와는 달리 기능, 성능, 디자인의 측면에서 모두 확인하기 때문에
더 넓은 범위에서의 테스트라고 볼 수 있다.
그렇게 결론적으로 우리의 서비스의 품질이 보증되고 있는지를 확인하는 작업이 바로 QA이다.
PICK 1차 QA
그렇게 PICK의 모든 기능을 개발한 우리는 마지막으로 QA를 하기로 했다.
출석이 잘 되는지, 출결변동사항 등록은 잘 작동하는지, 출석 데이터는 자동으로 들어가는지,
동아리는 잘 변경되는지, 동아리 원은 잘 이동 되는지 기능을 검증할 예정이었다.
문제점
당연히 PICK의 모든 기능이 개발되어 있을 것이라고 생각했는데,
기능이 개발 안 된 곳이 있다는 것을 QA를 시작하고 나서 알게 되었고
QA를 시작한 시간은 자정이었기 때문에 다시 돌리기도 애매했다.
기숙사 담당 선생님께 허락을 맡아 진행했다.
결국 새벽 4시까지 프론트엔드 개발을 담당한 친구들이 개발을 열심히 하다가
첫 번째 QA는 끝이 나고 만다.
PICK 2차 QA
제대로 된 QA를 하지 못한 1차 QA와는 다르게
이번에는 확실히 기능이 모두 개발된 상태였기 때문에
제대로 된 QA를 할 것이라는 희망을 품고 QA를 진행했다.
이번에도 새벽에 QA를 잡았다.
QA를 새벽에 하는 이유는 수업시간엔 할 수 없고,
쉬는 시간에 하기엔 시간이 너무 짧으며,
방과 후 시간은 개인 시간을 보증해줘야 한다고 생각했기 때문이다.
성능적인 측면에서의 문제는 프론트엔드와 백엔드가 잘 협력해서
자주 사용되는 API의 크기를 조절하는 것으로 전에 해결했었다.
그래서 기능과 디자인 측면에서 QA를 진행했는데,
디자인 보다는 기능이 돌아가는 것이 필수적이기 때문에 기능을 중점으로 QA를 진행했다.
그렇게 6개 정도의 오류를 발견할 수 있었고 그때는 시간의 제약이 있었기 때문에
새벽 2시에 QA를 종료해야 했다.
이렇게 찾은 오류는 내일 바로 고치도록 하였다.
QA를 하면서 느낀건데 내가 짠 코드에서는 왜 오류가 나고
이렇게 하면 오류가 날 것 같은 것을 알겠는데
다른 친구가 짠 코드를 테스트할 때는 왜 이런 상황에서 오류가 나는지를 잘 모르겠다.
실제로 QA를 전문적으로 하는 사람들은 모든 분야에 대해서 알고 있어야
적절하게 QA를 할 수 있다고 하는데 이게 이런 점에서 비롯된 것 같다.
PICK 3차 마지막 QA
마지막 QA는 학교 수업이 모두 마친 오후 9시 반부터 11시까지 했다.
이미 오류를 다 고쳤기 때문에 자잘한 버그나 디자인적인 측면에서 많이 보았다.
QA를 하게 되면 Test 서버에 이것 저것 바꿔보고 고쳐보고 넣어보는데,
이 곳에서 문제가 발생한다.
문제점
알고보니 프론트엔드의 코드에서 서버에 API 요청을 보내기 위한
BASE_URL을 테스트 서버가 아닌 실 서버에다가 요청을 보내고 있었다.
그래서 실 서버의 데이터가 바뀌어 있었고,
학교 수업이 끝난 뒤가 아닌 출석부를 사용하고 있었을 때라면 큰 문제가 생겼을 것이다.
하지만 데이터베이스를 임의로 수정하고 BASE_URL도 다시 변경하면서 복구 해내긴 했지만
위험한 순간이었다.
마무리
이렇게 PICK 개발도 다 하고 QA도 성공적으로 마치면서
PICK을 후배들에게 넘길 수 있을 것 같다.
다음엔 PICK 후기를 끝으로 PICK을 마무리 해야겠다.
