이 글은 다양한 글과 책을 참고하여서 작성을 하였지만 개인적인 생각을 정리한 글입니다. 따라서 표준이나 학문적으로 잘 정리된 글은 아닐 것입니다. 제가 혹시 잘못 정리한 내용이 있으면 댓글 남겨주시면 제가 확인하는 대로 피드백을 하도록 하겠습니다.

들어가기

"Software Quality란 무엇인가?"라는 주제로 글을 쓰기 위해서 먼저 Software에 대해서 정의해보려고 합니다.

Software의 정의는 매우 다양합니다. 가장 일반적인 정의를 확인하기 위해서 위키백과(wikipedia)를 참고하면 다음과 같습니다.

컴퓨터 소프트웨어(computer software, 혹은 간단히 소프트웨어, 문화어: 쏘프트웨어, 순화 용어: 무른모)는 저장장치에 저장된 특정한 목적의 하나 또는 다수의 컴퓨터 프로그램을 뜻한다. 프로그램 소프트웨어는 컴퓨터 하드웨어에 직접 명령어를 주거나 다른 소프트웨어에 입력을 제공함으로써, 그것이 수행하도록 구현된 기능을 수행한다.

위키백과의 정의를 참고하시고, Software Quality에 대한 글을 쓰기 위해서 제 나름대로 간략하게 다시 정의를 하였습니다.

Software는 사용자의 요구사항을 사용자 대신 처리하여서 사용자에게 만족을 주는 프로그램이다.

일반적으로 Quality란 대상을 사용하는 사람의 다양한 기준에 만족하는 것을 뜻합니다. 사람이 매우 다양하기 때문에 똑같은 제품을 소유한 사람들도 자신의 기준에 따라서 모두 만족의 정도가 모두 다를 것입니다.

Hardware같이 정형화 된 제품들은 고객별로 자신이 필요하고 원하는 기준을 측정해놓은 값이 명확하기 때문에 비교하여서 선택하기가 매우 쉽습니다. 예를 들자면 아래와 같이 휴대폰은 각 항목들의 비교가 상대적으로 쉽습니다.(아래 그림은 다나와(http://www.danawa.com)에서 휴대폰 모델 비교한 화면입니다)

하지만, Software는 Hardware처럼 정량적인 숫자로 동일한 종류의 제품끼리 비교하는 것이 매우 어렵습니다.
예로 카카오톡과 라인은 모두 한국 회사들이 만든 모바일 메신저이지만 카카오톡은 한국에서 압도적인 사용자 점유율을 자랑하고 라인은 일본 및 동남아에서 많이 쓰이는 모바일 메신저입니다. 두 개의 메신저의 비교는 어렵습니다. 어떤 모바일 메신저를 선택하는 것이 어떤 메신저가 더 빠르고 더 좋은 성능을 가져서라기 보다는 자신이 모바일 메신저를 쓰는 이유가 다르기 때문일 것입니다.

위에서 이야기 했지만 Hardware 제품들은 일반적으로 서로 정량화 해서 비교할 항목들이 정형화되어 있기 때문에 자신의 기준에 맞춰서(성능, 가격, 무게 등) 제품을 선택하기가 상대적으로 쉽고 기대하고 있었던 것이 명확했기 때문에 고객이 품질(Quality)에 만족하기가 쉽습니다.

하지만, Software Quality는 고객의 요구사항이 있지만 Hardware보다 자신이 무엇을 원하는지를 알기가 더 힘이 듭니다.

그러면 Software 개발에 관련된 사람들은 어떻게 사용자의 요구사항을 알수 있을까요??? 알아야 만족을 시킬수 있겠죠? 모르는데 할 방법이 없으니까요.

그러면, 여기에서 사용자의 요구사항에 대해서 더 알아보시죠. 알아야 만족시키니까요.
참고적으로, 스티브 잡스가 이런 이야기를 했던 것을 아시는지요?

"A lot of times, people don't know what they want until you show it to them"
"사람들은 대개 자신이 원하는 것을 보여주기 전까지는 무엇을 원하는지 모른다"

사용자들 자신도 모르는 요구사항을 어떻게 우리는 알수가 있을까요?

사용자 요구사항이란

세일즈쪽에서 정의하는 요구사항의 인식 단계는 다음과 같이 3단계로 정리하는 경우가 있습니다.

첫번 단계로 Latent Pain입니다. 고객이 인식하지 못하는 요구사항입니다. 자신이 필요한 것이 무엇인지 명확히 모르지만 잠재적으로 문제가 있는 단계입니다. 고객이 명확히 모르지만 뭔가 자신에게 필요한 문제점을 정리해야 합니다.

두번째 단계로는 Admitted Pain으로 자신의 문제가 어느정도 정리가 되었지만 이것을 해결할 수 있는 구체적인 해결방안은 없는 상태입니다. 일반적으로 소프트웨어를 개발하기 위해서 수집하고 정리하는 요구사항을 이 단계의 Pain에서 모으고 정리하게 됩니다.

세번째 단계로는 Solution Vision입니다. 문제를 파악하고 고객이 해결안을 가진 상태입니다. Solution이라고 해서 특정 제품을 이야기 하는 것이 아닙니다.

위의 3단계를 가지고 딱 맞는 예는 아니겠지만 이해를 돕기 위해서 정리하면 다음과 같은 예가 있을 수 있을 것 같습니다.

1. 요즘 나 외로운데. 하는 느낌을 가지게 됩니다.
2. 아! 내가 너무 바빠서 친구들하고 연락을 거의 못하고 있네..어떻하지? 연락하고 싶기는 한데 왠지 전화하기는 부담스럽고.. 얼굴 볼 시간도 없는데 전화만 하는 것도 민망하네..
3. 모바일 메신저로 그냥 메세지나 가끔 보내는 방법을 써볼까? 내 친구들 요즘에 인스타그램 많이 하는 것 같던데 나도 쓰면서 친구들 사진에 댓글 달고 내 소식도 올리고 해볼까?

그러면, Software Quality를 어떻게?

일반적으로 Software Quality를 달성하는 가장 기본되는 일은 고객의 요구사항이 제대로 구현되었는지 확인하는 다양한 작업(Task)입니다. 이에 대해서는 매우 다양한 방법 및 작업들이 있어서 여기에서 정리하기에는 너무 길어질 것 같아서 다음에 기회가 되면 상세하게 정리해보려고 합니다.

이 글에서는 위에 "사용자 요구사항이란?"에 정리했던 Latent Pain에 집중하겠습니다. 고객이 원하지만 자신이 모르는 것에 대해서 Software Quality를 만족시키는 작업(Task)을 어떻게 해야할까요?

개인적으로 Latent Pain을 만족시킬 수 있는 것은 Solution Vision에서 제품에 고객이 기대하지 않았지만 고객을 만족시킬 추가적인 것을 더하는 활동이라고 생각합니다.

고객의 요구사항이 정의되고 정리된 내용이 정확히 구현이 되었는지 확인하는 활동이 Function Test라고 생각합니다. 그외의 활동을 모두 Non-Function Test라고 분류해 보겠습니다.

Non-Function Test는 일반적으로 성능, 부하 테스트를 예를 드는 경우가 대부분입니다. 사실 고객은 Software의 성능에 대해서 구체적인 숫자를 제시하는 경우가 매우 적습니다. "단순히 빠르게 실행이 되었으면 좋겠습니다.", "부드럽게 동작하면 좋겠습니다." 라고만 이야기들을 하시죠. 고객에게 서비스를 제공하는 것이지 고통에 대한 체험을 제공하지 않기 위해서 Software의 안정성 및 얼마나 많은 요구를 처리할 수 있는지 확인하는 과정이 성능, 부하테스트입니다.

Non-Function Test에는 성능, 부하 테스트 외에도 해당 Software를 사용하는 고객의 경험을 생각하고 고객이 요구하지는 않았지만 고객에게 제공하여서 기대하지 않았던 만족을 위한 다양한 활동으로 채워나가야 한다고 생각합니다.

1. 제가 경험해본 것은 아니지만, 게임쪽 QA에서는 Fun QA라는 영역도 있다고 알고 있습니다.
2. 이전에 없던 Software를 만들기 위해서는 UX/UI를 디자인해나가는 과정에서의 다양한 리서치 및 고객 시연 및 체험 테스트를 하기도 합니다.

고객을 만족시키는 것이 제품을 만드는 가장 큰 이유가 아닐까요? 고객이 요구한 것을 제대로 구현하도록 하는 활동이 Software Quality에 관련된 사람들이 해야 할 당연한 일입니다.

Software Quality Assurance는 고객을 만족시키는 활동입니다.

개인적인 의견으로 Software Qualiaty Assarance Engineer라면 고객을 만족시키는 모든 일에 욕심을 내야 한다고 생각합니다. 그 활동이 어떤 일이 되었던지요.

역활을 나누면 분명히 중간에 놓치는 부분이 생깁니다. 서로 협업하여서 빈 부분을 채워나가는 적극적인 활동을 SQA Engineer가 되도록 노력해보고 싶습니다.

어떤 종류의 Software인지 그 Software를 쓰는 고객들이 누구인지에 따라서 우리가 효율적이고 효과적으로 Software Quality Assurance 활동을 해야 합니다.

효율적이고 효과적인 활동을 해야하는 이유는 우리에게 주어진 자원은 무제한이 아니기 때문에 사용이 가능한 자원(시간, 인력 등..)을 효율적으로 사용하고 고객이 바라는 우선 순위에 맞게 효과적으로 사용해서 고객에게 선택받는 Software를 만들어 나가는 활동을 끊임 없이 해야만 합니다.

정확한 예시는 아니겠지만 제 나름대로 그런 활동들의 일부를 정리하면 다음과 같을 것입니다.

• 모바일 메신저라면 안정적인 서비스, 빠르고 정확한 메세지 전달, 사용하기 편리한 UX/UI등이 우선순위일 것입니다.
  - 부하테스트가 다양하게 수행이 되어야 할 것입니다. 성능, 확장성, 안정성에 대한 성능 테스트를 준비하고 수행해야 합니다.
  - 타겟 고객을 대상으로 한 UX/UI의 A/B 테스트가 수행하여서 고객에 대한 리서치를 지속적으로 해야할 것입니다.
• 핀테크(뱅킹) 서비스라면 보안성, 신뢰성이 우선되고 그 다음에 사용하기 편리한 UX/UI등의 우선 순위라고 생각합니다.
  - 국내 서비스라면 금융감독원의 보안성 기준에 대한 테스트가 반드시 수행이 되어야 할 것입니다.
  - 다양한 보안 테스트를 준비하고 지속적으로 수행하면서 시스템의 보안에 대해서 지속적으로 신경을 써야 합니다.
  - 핀테크라면 연계된 다양한 금융시스템들이 있기 때문에 연계되는 부분에 대해서 자동화 테스트를 구축하고 지속적으로 모니터링을 해야 합니다.

(또 다른 시선) 항상 품질이 좋은 제품이 시장에서 압도적인 선택을 받는 것은 아닙니다. 코카콜라와 펩시콜라는 블라인드 테스트를 하면 서로 맛을 구분하기가 쉽지 않고 펩시콜라가 선택을 더 받는 다는 조사결과가 있지만 시장 점유율은 코카콜라가 압도적입니다.

참고문헌

[조대협의 서버 사이드 소프트웨어 개발과 테스트] / 조대협 지음/ 프리렉
Three Levels of Buyer Need: https://flylib.com/books/en/2.327.1/chapter_two_principles.html
코카콜라 펩시콜라 비교 자료: https://happist.com/568445/%EC%B0%A8%ED%8A%B8%EB%A1%9C-%EC%9D%BD%EB%8A%94-%ED%8A%B8%EB%A0%8C%EB%93%9C-%EC%BD%9C%EB%9D%BC%EC%A0%84%EC%9F%81-120%EB%85%84-%ED%8E%A9%EC%8B%9C-%EC%A0%88%EB%B0%98%EC%9C%BC%EB%A1%9C-%EC%AA%BC