개념
"동작한다"와 "충분하다"는 다른 질문이다
모듈 1(레슨 4)에서 배운 테스트 유형 중, 지금까지 이 강의 대부분은 기능 테스트(Functional Testing) — "이 기능이 명세대로 동작하는가"를 다뤄왔다. 이 모듈은 다른 질문을 던진다.
기능 테스트: "로그인 버튼을 누르면 로그인이 되는가?"
비기능 테스트: "로그인이 1만 명이 동시에 몰려도 3초 안에 되는가?"
"로그인 정보가 안전하게 전송되는가?"
"시각장애인도 스크린 리더로 로그인할 수 있는가?"기능은 완벽히 맞아도, 느리거나, 안전하지 않거나, 일부 사용자가 못 쓴다면 그 소프트웨어는 실제로 쓸모가 없다.
비기능 테스트의 다섯 축
이 모듈에서 다루는 다섯 가지 관점을 먼저 지도로 그려본다.
1. 성능(Performance) — 얼마나 빠르고, 얼마나 많은 부하를 견디는가 (레슨 2~4)
2. 보안(Security) — 공격과 취약점에 얼마나 안전한가 (레슨 5~6)
3. 접근성(Accessibility) — 장애가 있는 사용자도 쓸 수 있는가 (레슨 7)
4. 시각적 정확성(Visual) — 화면이 의도한 대로 보이는가 (레슨 8)
5. 호환성(Compatibility) — 다양한 환경에서 일관되게 동작하는가 (레슨 8)왜 이 관점들이 자주 뒤로 밀리는가
기능 결함은 화면에 바로 드러나서 눈에 띄지만, 비기능 문제는 특정 조건에서만 드러난다 — 사용자가 갑자기 몰릴 때(성능), 공격자가 시도할 때(보안), 스크린 리더 사용자가 접근할 때(접근성). 평소에는 안 보이기 때문에 일정이 촉박하면 가장 먼저 생략되는 영역이 되기 쉽다. 하지만 문제가 실제로 터지면 그 파급력은 기능 버그보다 훨씬 크다 — 서비스 전체 장애(성능), 개인정보 유출(보안), 법적 분쟁(접근성, 모듈 8에서 배운 규제 산업일수록 더 그렇다)으로 이어질 수 있다.
비기능 테스트도 리스크 기반으로 접근한다
모듈 4(레슨 2)에서 배운 위험기반 테스트 원칙이 여기서도 그대로 적용된다. 모든 서비스가 다섯 축을 똑같은 깊이로 다룰 필요는 없다 — 결제 서비스는 보안에, 대규모 트래픽 서비스는 성능에, 공공기관 서비스는 접근성에 더 무게를 둬야 한다.
이 모듈의 목표는 전문가가 되는 것이 아니다
성능·보안·접근성은 각각 전담 전문가가 있을 만큼 깊은 영역이다. 이 모듈의 목표는 QA가 그 전문가가 되는 것이 아니라, "이 관점에서 뭔가 놓치고 있을 수 있다"는 감각을 갖추고, 최소한의 기초 검증을 스스로 할 수 있게 되는 것이다.
실무에서 왜 필요한가
"기능 테스트는 다 통과했는데 왜 배포 못 하나요?"라는 질문에, 비기능 테스트의 언어로 "동시 접속자 늘어나면 응답 시간이 급격히 느려질 수 있습니다"거나 "스크린 리더로 이 폼을 완성할 수 없습니다"라고 구체적으로 답할 수 있는 QA는, 서비스 전체의 완성도를 훨씬 폭넓게 책임질 수 있다.