들어가며

최근에 입사한 지 1년 된 프론트엔드 동료와 제품 개발을 함께 했습니다. 그에게 신규 기능 구현 업무를 할당했는데 기본적인 기능이 동작하지 않는 코드를 공유해 주었습니다. 테스트에 신경 써달라고 부탁했지만 비슷한 일이 반복되어 그에게 어떻게 테스트를 하는지 과정을 보여달라고 했습니다. 그가 테스트하는 사고 과정은 완전히 예상 밖이었습니다. 그의 테스트 과정을 본 후 그가 잘 몰라서 그랬던 것이고 내 말을 무시했거나 불성실한 게 아니란 걸 깨달았습니다. 그 날 이후 저는 그가 알고 있을 거라고 가정했던 기본적인 것들을 설명해 주어야겠다고 생각했습니다. 그래서 그에게 알려주고 싶은 테스트에 대한 기본적인 개념과 테스트 과정에서 집중해야 할 요소들에 대해 정리해 보게 되었습니다. 이 글이 테스트에 어려움을 겪는 주니어 개발자들에게 도움이 되길 바랍니다.

1. 테스트 케이스

테스트에는 두 가지 요소가 있습니다. 하나는 시스템에 어떤 입력을 가했을 때 기대되는 결과입니다. 테스트의 성공 여부를 결정하는 기준이라고 할 수 있습니다. 다른 하나는 입력을 가했을 때 실제 시스템이 주는 결과입니다. 기대하는 결과와 실제 결과가 다르면 테스트가 실패한 것입니다. 테스트를 하기 전에 어떤 입력에 대해 어떤 결과를 기대하는지 먼저 이해하고 테스트를 진행해야 합니다. 시스템에 어떤 입력을 가하고 기대하는 예상 결과를 정의한 것을 테스트 케이스라고 부르는데 이 테스트 케이스가 잘못 정의되면 잘못 개발된 기능이 성공이라는 결론을 내리게 됩니다. 또는 반대로 기능과 실질적으로 관계 없는 과도한 테스트를 하는 우를 범할 수도 있습니다. 그러면 어떻게 이 테스트 케이스를 적절히 잘 정의 내릴 수 있을까요?

2. 제품 요구사항

답은 제품 요구사항(스펙)에 있습니다. 앞에서 설명한 테스트 케이스는 사실 사용자 요구사항의 다른 표현일 뿐입니다. 사용자는 흔히 ‘A를 입력하면 B라는 결과가 나오는 시스템을 만들어주세요’ 라고 말합니다. 이 요구사항에 대한 테스트 케이스는 ‘A를 입력하면 B라는 결과가 나오는지 확인한다’ 입니다. 그래서 흔히 테스트 케이스와 요구사항을 본질이 같은데 서로 다른면을 바라보는 동전의 양면이라고 표현하기도 합니다. 결론적으로 구현한 기능을 바르게 테스트하는 테스트 케이스를 잘 정의하려면 제품의 요구사항을 잘 이해해야 합니다. 물론 요구사항을 잘 이해했다면 개발할 때도 테스트에 통과하는 시스템을 만들 확률이 높아질 것입니다.

3. 처음 만나는 프로덕트

여기서 한 가지 매우 중요한 포인트가 있습니다. 제품 요구사항은 제품이 만들어지기 전에 정의된다는 사실입니다. 사용자는(개발자도 사실 마찬가지입니다) 제품이 눈에 보이고 손으로 만져지기 전에는 제품이 어떠했으면 좋을지 정확히 정의내리기 어렵습니다. 그래서 제품이 처음으로 눈에 보이고 손으로 만져지는 테스트 시기는 제품의 요구사항을 개선해서 제품 자체를 개선하기 가장 좋은 시기입니다. 우리는 이제 한 단계 더 나아가야 합니다. 제품이 만들어지기 전에 정의한 제품 요구사항만 통과하는 테스트 케이스를 확인하는건 2% (아니 20%)부족합니다. 우리는 제품을 테스트하며 개선점을 찾아야 합니다. 그러면 이 제품 요구사항을 개선하는 좋은 방법은 무엇일까요?

4. 사용자 관점

답은 사용자에게 있습니다. 우리는 테스트를 하면서 제품의 사용자가 누구이고, 또 사용자라면 이 제품을 사용하며 어떤 느낌을 받을지 생각해 보아야 합니다. 사용자가 불편해 할 부분이 있는지 여전히 잘 모르겠다면 사용자를 만나고, 관찰하고, 질문해 보면 됩니다. 정리하면 테스트 케이스는 제품이 만들어지기 이전에 정의된 제품 스펙을 넘어 사용자 관점에서 더 섬세하게 개발되고 이로인해 제품은 개선되어져야 한다는 사실을 테스트 단계에 꼭 기억해야 합니다.

5. 그리고, 기술

테스트를 잘 하려면 사용자 외에 또 다른 관점을 잘 이해해야 합니다. 그건 바로 우리가 구현에 사용하고 있는 기술입니다. 우리는 사용자의 요구사항을 여러가지 기술을 사용해 개발합니다. 이 기술에 대한 이해도가 떨어지면 역시 제대로된 테스트를 할 수 없습니다. 예를 들어 웹 어플리케이션을 개발하고 있고 나는 프론트엔드 개발자라고 합시다. 그리고 ‘A 메뉴를 선택하면 B 기능이 동작하도록 한다’ 는 제품 요구사항을 개발하고 있다고 합시다. 프론트엔드 개발자는 사용자가 A 메뉴를 선택했을 때 API 서버로 B 기능을 수행해 달라는 HTTP 요청을 전송할 것입니다. 이 때 웹 프론트엔드에서 API 서버로 정상적인 HTTP 요청이 전송되었는지 테스트가 되어야 하는데 HTTP 요청에서 어떤 부분을 기술적으로 확인해야 하는지 전혀 모른다면 테스트가 제대로 될 수 없습니다.

6. 인터페이스

우리는 여러 다른 컴포넌트들과 인터랙션함으로 전체 제품을 구성합니다. 이 때 내가 인터랙션하는 인터페이스를 잘 이해하고 모든 인터페이스가 정상적으로 동작하고 있는지 확인해야 합니다. 앞에서 예를 들었던 프론트엔드 컴포넌트라면 사용자와 API 서버라는 외부 인터랙션 대상이 있습니다. 그래서 프론트엔드 개발자는 사용자가 보는 화면도 확인하고 API 서버와 주고 받는 HTTP 요청과 응답도 확인해야 합니다.

7. 모든 케이스

계속해서 프론트엔드 개발자의 예를 들면 내가 개발한 모든 메뉴를 클릭해 보고 예상한 결과가 출력되는지 확인해 보아야 합니다. 사용자가 메뉴를 클릭하고 원하는 화면이 뜨지 않는다는 것을 발견하도록 내버려 두어서는 안됩니다. 만약 숫자를 입력 받는 에디트 박스라면 너무 많은 경우의 수가 있어 모든 수를 입력해 볼 수는 없습니다. 이럴 결우에는 최소한 경계값을 테스트 해보아야 합니다. 일반적인 정상 값, 정상적인 최대 값, 정상적인 최소 값, 최대 범위 초과 값, 최소 범위 초과 값 정도를 입력해 보면 됩니다.

8. 일관성

일관성이라는 주제는 사용자의 경험에 매우 중요한 포인트 입니다. 사용자가 하나의 시스템에 있는 여러 기능을 사용할 때 마다 미묘하게 다른 입력과 출력 패턴을 익히고 경험해야 한다면 시스템에 익숙해 지기 힘들고 규칙을 기억해야 사용할 수 있는 어려운 시스템이 됩니다. 이 일관성은 시스템의 메뉴를 입력하고 상태를 확인하는 사용자의 사용 경험 뿐만아니라 시스템의 바라보았을 때 느끼는 감성적인 느낌도 포함합니다. 예를 들어 글자크기, 자간, 레이아웃등이 뒤죽박죽이면 시스템을 보는 사용자가 좋은 느낌을 받지 못합니다. 앞서 잠시 언급했지만 처음으로 제품을 눈으로 보는 테스트 단계는 이 일관성을 개선하기 더할 나위 없이 좋은 단계입니다.

9. 섬세함

고객은 제품에서 엉성한 부분 하나를 발견하면 전체 제품에 대한 나쁜 인상을 가지게 될 확률이 높습니다. 작은 엉성한 부분이 그대로 릴리즈 되게 내버려 두어서는 안됩니다. 제품의 겉모습부터 내부의 작은 동작들까지 고객의 관점에서 섬세하게 체크되고 개선하려 노력해야 합니다.

10. 적극적인 태도

위의 모든것을 신입 사원 때 부터 잘 할 수 없습니다. 그러면 신입사원이 어떻게 테스트를 잘하고 좋은 제품을 만들 수 있을까요? 바로 적극적인 태도입니다. 신입사원 때는 어떤 질문을 해도 문제가 되지 않는 좋은 시기입니다. 위의 것들을 잘하려면 고객이 무엇을 원하는지, 제품 스펙은 무엇인지, 기술적으로 내가 무엇을 확인해야하는지 알아야합니다. 그러나 나는 잘 모릅니다. 그렇다면 물어보고 뛰어다니며 조사하고 정리하고 그리고 그것을 제품에 적용하는 적극적인 태도 외에는 답이 없습니다. 적극적으로 행동해야 합니다. 가만히 알려줄 때까지 기다려서는 답이 없습니다.

연관 자료

📌 발표영상(유튜브)
📌 발표자료
📌 발표를 준비하며 도움받은 7가지
📌 발표 피드백 부연 설명