QA가 개발자에게 보내는 편지
To. 테스트가 고민인개발자에게
안녕하세요. 크몽에서 QA를 담당하고 있는 제임스입니다.
이번 세션에는 개발자가 아무리 많은 시간과 다양한 케이스에 대해 테스트를 수행해도 막상 QA 단계에서 테스트하면 기본적인 결함이 발생하는 이유가 무엇일까요?
이 주제로 간단하게 이야기하고 마지막에는 개발자가 가장 효율적으로 테스트하는 방법에 대해서 말씀드리겠습니다.
아래 상황을 예로 들어보겠습니다.
개발이 완료되고, QA 단계에서 테스트하게 된 상황입니다.
- QA 담당자 : 빌드 주세요.
- 개발자 : 1.0.0 빌드 올렸습니다. 테스트 부탁드립니다.
- QA 담당자 : 1.0.0 설치했는데 앱이 실행이 안 되네요? 재빌드 부탁드립니다.
- 개발자 : 빌드 옵션이 잘못돼서 재빌드했습니다. 1.0.1로 설치해서 재확인 부탁드립니다.
- QA 담당자 : 설치는 되었는데 로그인이 안 됩니다. 확인 부탁드립니다.
한 번쯤은 경험해 보았을 상황이라 생각합니다.
QA 담당자의 입장에서는 개발자가 설치 한번 안 해보고 테스트 요청한 건가? 설치만 하고 로그인 한번 안 하고 테스트 요청한 건가? 라고 생각할 수 있습니다.
하지만 개발자는 설치도 했고 로그인도 확인했습니다. 그래서 매우 억울하고 안타까운 상황이 발생하고 QA 담당자는 빌드를 기다려야 하는 비효율적인 상황에 놓이게 됩니다.
왜 이런 일이 발생할까요? 이유는 매우 간단합니다. 테스트 방법이 다르기 때문인데요. 간혹 정말 생각지 못한 범위에서 결함이 발생하기도 합니다. 이 경우에는 QA 단계에서도 발견하기 어렵기 때문에 개발자와 동일한 상황에 놓이게 됩니다. 이 부분은 뒷부분에 조금 더 자세히 말씀드리겠습니다.
위와 같은 상황이 발생하는 지극히 주관적이지만 제가 알고 있는 개발자의 개발/수정/테스트하는 경우를 예를 들어 보겠습니다.
첫 번째 경우,
한 사람이 A라는 Feature를 개발하기 위해 A-1, A-2, A-3, A-4, A-5의 작업을 생성해서 개발을 시작했다고 해봅시다.
- A-1, A-2 개발이 완료되어 Resolved 처리 하였습니다.
- A-3 개발 중 버그가 발견되어 A-3-b를 생성하여 작업하였습니다.
- A-3–b 개발 완료 후 확인 테스트를 수행하였고, Resolved 처리 하였습니다.
- A-4, A-5 개발이 완료되어 Resolved 처리 하였습니다.
- A라는 상위 Feature에 대해서 Source Merge 후 테스트하고 상태를 Resolved 처리 하였습니다.
이런 상황에서 A(상위 Feature)를 Resolved 전에 A 기능에 대해 테스트하게 되면 개발 중에 발견한 버그도 확인이 되고 문제없이 QA로 인계가 될 것입니다.
중요한 것은 A-3-b를 수정하고 테스트할 때 기존 개발 완료 처리 했던 A-1, A-2에 영향이 없는지 분석/검토해야 합니다. 좀 더 나아가서 A-3-b가 B-3와 같이 개발 범위가 아닌 부분에 영향이 없는지도 검토가 되어야 하고, 필요에 따라 테스트가 수행되어야 합니다.
대부분의 경우는 위와 같은 상황에서 충분히 분석되지 않고 테스트도 수행되지 않아 QA로 인계하였을 때 결함이 발생합니다.
두 번째의 경우,
A, B, C, D, E의 Feature를 한 사람이 아닌 여러 사람이 개발하는 경우입니다. 이 경우는 첫 번째 상황보다 매우 복잡하고 경우의 수가 무한에 가까운 수준으로 올라가게 됩니다.
하지만 매우 안타깝게도 대부분의 개발은 두 번째 상황으로 개발이 진행됩니다. 그렇기 때문에 개발자는 많은 시간과 다양한 케이스에 대해서 테스트를 수행하더라도 막상 QA 담당자가 테스트하게 되면 매우 기본적인 결함이 발견되는 것입니다.
그렇다면 이 상황을 어떻게 풀어야 할까요? 문제점은 명확하게 알고 있기 때문에 방치하거나 QA 담당자가 알아서 하겠지? 라기보다는 최대한 문제를 해결하기 위해 노력해야 합니다.
개발자가 Feature에 대한 개발이 완료된 경우 체크리스트를 작성해서 테스트하시길 권장해 드립니다. 단위 테스트를 위해서 가장 많이 활용하는 것이 체크리스트이며 체크리스트는 요구에 대한 검증이 아닌 기능의 동작에 초점이 맞춰진 방법입니다.
메뉴 트리 방식의 체크리스트도 좋고, 기능 명세에 대한 체크리스트도 좋습니다. 다양한 방식이 있으니 검토해 보시고 활용해 보시길 적극 추천해 드립니다. 체크리스트를 도입하게 되면 QA 단계의 테스트에서 기본적인 결함은 발견되지 않을 것입니다.
좀 더 나아가서 체크리스트의 목록을 자동화 테스트하는 방법입니다. 빌드 전 테스트가 수행될 수 있도록 CI/CD를 구축하는 것이 가장 바람직하며, 한번 정해진 시나리오로 매번 테스트하는 것이 아닌 시나리오는 점차 늘려가면서 커버리지를 높이는 것이 중요합니다.
그렇다면 개발자가 체크리스트도 수행하고 테스트 자동화도 구축해서 커버리지도 높였다고 하면 그러면 QA 담당자는 무엇을 하지? 라고 생각하실 수도 있을 것 같습니다.
가끔 QA는 무엇을 하는 사람들이지? 라는 질문을 받곤 하는데요. 회사에 개발자가 테스트하면 되지 QA 담당자 혹은 테스터가 무슨 필요 있어? 라고 하는 회사도 있습니다.
결론을 말씀드리면 QA 담당자 혹은 테스터는 선택 아닌 필수라고 말씀드리고 싶습니다. 제가 QA라서 말씀드리는 것은 아니고 소프트웨어는 매우 가변적이고 복잡성이 높기 때문에 최대한 테스트를 많이 해야 하는데 개발자가 테스트하거나 기획자, PM, PO, 디자이너 등이 테스트를 많이 하게 되면 본연의 업무에 집중할 수 없게 됩니다.
그렇기 때문에 요구사항에 대해서 검증하고 테스트 커버리지를 최대한 높일 수 있는 테스트에 집중하고 품질을 고민할 수 있는 전문 인력이 꼭 필요한 것입니다.
개발에서 최대한 테스트를 수행하고 커버리지를 높였다고 하면 QA는 좀 더 다양한 테스트를 통해 커버리지를 높이는 활동을 하게 됩니다.
또한 요구사항에 대한 검증은 자동화 테스트로 해결할 수 없기 때문에 요구대로 개발이 되었는지 테스트 케이스라는 문서를 통해 확인하는 작업을 하게 됩니다. 테스트 케이스로 작성된 문서는 이후 시나리오화해서 자동화 테스트로 커버할 수도 있습니다.
이 외에도 VOC(Voice of Customer)를 통해 사용성 품질을 모니터링하고, 기능뿐만 아니라 비기능 측면의 품질을 높이기 위한 활동을 할 수도 있습니다. 그러기 위해서는 품질을 정량화해야 하고, 모니터링할 수 있는 환경을 구축해야 합니다.
마지막으로 지극히 주관적이지만 제가 생각하는 개발 잘하는 개발자는 코딩을 잘하는 프로그래머가 아닙니다.
코드 10줄을 5줄로 할 수 있는 사람보다 중요한 것은 내가 요구대로 개발한 것인지? 예외적인 상황에서 결함은 없는 것인지? 결함이 발생했을 때 빠르게 해결할 수 있는지를 다양하게 고민하는 개발자가 정말 개발 잘하는 개발자라고 생각합니다.
그래서 개발 잘하는 사람은 개발과 테스트 비율이 3:7인 사람이라고 생각합니다. 물론, 테스트의 7의 비율은 커뮤니케이션과 문서작업 코드 리뷰 등 개발 외 활동하는 비율이라고 생각해 주시기를 바랍니다.
From. 고민 해결에 도움이 되고자 하는 QA가 드림
P.S
개발자는 테스트에 너무 몰입하기보다는 자신이 개발한 Feature에 대해서는 명확하게 요구대로 개발되었는지 검증(Verification)하고, 영향 범위에 대한 정보를 QA 담당자에게 공유하여 다양한 방법으로 테스트할 수 있게 하는 것이 가장 효과적이고, 효율적인 방법이라 생각합니다.
개발자든 QA 담당자든 항상 시간에 쫒기고 있기 때문에 FM에 기록된 모든 것을 다 할 수 없습니다. 최대한 그물망(품질의 구멍)을 좁힐 방법을 서로 고민하고 방법을 찾아서 협업하는 것이 가장 좋은 방법이라는 것을 항상 생각하고 있어야 합니다.
긴 글 읽어 주셔서 감사합니다.
[깨알 상식 : Verification(검증)과 Validation(확인) 구분하기]
- Verification : Are we building the system right? (우리가 제품을 올바르게 만들고 있나?) : 디자인과 코드를 검사하는 정적인 방법
- Validation : Are we building the right system? (우리가 올바른 제품을 만들고 있나?) : 실제 제품을 검사하는 동적인 방법
출처 : 위키백과
