기본 콘텐츠로 건너뛰기

소프트웨어 테스트 설계 잘하는 법(?) - 10년차 야매 테스터의 꼼수

테스터로 사노라면 참 쉬운일이 하나도 없습니다.

물론 요구사항 수집, 분석, 정의하고 설계하고 개발하는 모든 일이 쉬운게 없습니다.

사람마다 차이가 있겠지만 테스트를 하다보면 가장 막막한 것이 얼마나 테스트를 해야 충분한걸까? 나는 테스트를 잘 하고 있는걸까? 테스트 케이스는 어떻게 만들어야 하는걸까? 결함을 어떻게 하면 잘 발견할 수 있을까? 머.. 이런것이 아닐까라고 생각해봅니다.

비슷한 질문은 수없이 많겠지만 결론적으로 말해보면 커버리지(테스트의 충분함)은 테스터의 영원한 숙제가 아닐까 합니다.

모든 경우를 고려한 테스트가 불가능하다는 것은 이론적으로 체험적으로 이미 아는 사실이고.. 그렇다면 어떻게 테스트를 하면 충분한 테스트일까요? 어떻게 테스트를 해야 발 뻗고 잠이 들까요? 도데체 어떤 테스트를 해야할지 어떻게 결정할 수 있을까요?

이런 고민을 해결하고자 혼자서 공부도 해보고 교육도 들어보고 컨설팅도 받아보지만 딱 부러지게 맘에 드는 해답이 없는게 현실이 아닌가 싶습니다.

그래서 이제 10년차가 된 야매 테스터(전 소프트웨어 공학을 전공한적도 없고.. 남들 다 있다는 석/박사 학위도 없습니다.)의 꼼수를 알려드릴까 합니다. 물론.. 미천한 저의 경험이기 때문에 도움이 많이 되시지 않으시다면 저에게 가르침을 주시면 고맙겠습니다.

자.. 먼저 생각해볼 것은 왜 그렇게 우리는 테스트를 막연하게 생각하는 것일까요? 왜 무엇을 얼마나 해야할지 쉽게 결정을 내리지 못하는걸까요?

이 질문에 대답을 하기 위해서 필요한 것이 소프트웨어란 무엇인가입니다.

知彼知己 百戰不殆 不知彼而知己 一勝一負 不知彼不知己 每戰必敗 (지피지기 백전불태 부지피이지기 일승일부 부지피부지기 매전필패) 라고 손자병법의 유명한 구절이 있습니다.

적을 알고 나를 알면 백번 싸워도 위태로울 것이 없으나 나를 알고 적을 모르면 승과 패를 각각 주고 받을 것이며 적을 모르는 상황에서 나조차도 모르면 싸움에서 반드시 패배한다는 것입니다.

테스트를 잘 하기 위해서는 나와 우리 팀과 우리 조직이 무엇을 잘 하고 무엇을 못하는지 우선 알아야 하고 내가 테스트해야하는 대상에 대해서도 잘 알고 있어야 합니다.

여기서 중요한 것은 알고 있다와 아는 것 같다를 구별할 수 있어야 합니다.

많은 테스터들이 자신이 테스트하는 제품을 매우 잘 이해하고 있다고 생각하지만 막상 대상에 대해 잘못 이해하고 있거나 잘 모르는 경우가 꽤 많습니다.

테스트 해야 될 대상을 먼저 잘 이해하고 아는 것이 매우 중요합니다.

그렇다면.. 소프트웨어란 무엇일까요? 여러분은 소프트웨어를 무엇이라고 생각하십니까?

저는 소프트웨어를 아래와 같이 이해하고 있습니다.

소프트웨어는 크게 2가지 부분으로 이루어져 있습니다.

하나는 논리(logic, condition) 다른 하나는 데이터입니다.

데이터를 좀 더 세분하면 입력값과 출력값으로 구분할 수 있습니다.

즉, 소프트웨어란 입력값을 받아 출력값을 출력하는 로직의 중합체라고 볼 수 있습니다.

하드웨어, 정황, 사용자가 얽히고 설켜 매우 복잡하게 보이는 제품이라 할지라도 각각을 저 3가지로 분류해서 정리하면 좀 더 명확하게 제품을 바라볼 수 있습니다. 아무리 복작한 로직이라고 하더라도 결국은 입력값에 따른 출력값에 따라 구분해보면 꽤 깔끔하게 정리할 수 있습니다.

그래서 첫번째 팁대상을 단순하게 바라보자는 것입니다. 대상을 정확하게 분석하고 최대한 단순하게 정의하는 것이 중요합니다.

추가적인 팁이라면 우선은 데이터는 신경쓰지 말고 논리(흐름, flow)만 집중하는 겁니다.

상태전이와 같은 모델링도 좋고 클라시피케이션 트리 메소드도 괜찮고 마인드맵이나 피쉬 본도 좋습니다. 무엇이 되었든 깔끔하게 전체 시스템의 흐름을 볼 수 있는 방법이면 좋습니다.

대상을 분석해서 흐름을 완성했다면 이제 설계 기법을 적용해 볼 시간입니다.

대상 분석을 잘 하셨다면 설계 기법은 약간의 노력과 학습만으로 충분히 적용할 수 있습니다.

설계 기법은 여러 종류가 알려져 있지만 두가지로 나눠볼 수 있습니다.

하나는 데이터 검증에 이용되는 기법으로 동등분할, 경계값 분석, 문법 테스팅, 랜덤 테스팅과 같은 기법들이 있습니다.

다른 하나는 논리 검증에 이용되는 기법으로 결정테이블, 상태전이, 유즈케이스 등의 기법들이 있습니다.

논리 검증에 이용되는 기법들은 분석과정에서 제품을 어떻게 모델링했는가에 따라 해당하는 기법을 적용하시면 됩니다.

저는 상태전이를 즐겨 사용하는 편입니다.

데이터 검증에 사용되는 기법은 리스크를 고려해서 테스트 강도에 따라 적절한 기법을 사용하시면 됩니다.

저는 경계값 분석과 랜덤 테스팅을 즐겨 사용하는 편입니다.

이렇게 테스트 대상 제품을 데이터와 로직으로 구분해서 모델링하고 설계기법을 적용하는 것이 경험을 기반으로(했다고 말하고 마구잡이로) 테스트하는 것과의 차이는 제품에 대한 이해가 달라지고 제품을 이해한만큼 정교한 테스트를 설계함으로써 테스트에 대한 자신감을 얻을 수있다는 것입니다.

중요한 것은 제품을 논리와 데이터로 구분해서 바라보는 것입니다.

딱 요기까지가 기능 테스팅입니다. 기본중의 기본 테스트입니다.

처음에는 욕심 많이 안부리고 제품 분석에 능숙해질때까지 열심히 노력하는 것이 중요합니다.

그리고나서 익숙해지면 이제 다음단계로 넘어가봅시다.

기능 테스트가 어느 정도 익숙해지면 이제 비기능 테스트를 슬금 슬금 고민해볼 때입니다.

비기능 테스트는 가장 대표적인 사용성/효율성/보안성 테스트와 호환성/신뢰성/유지보수성/이식성 테스트가 있습니다.

이 모든 테스트를 다 잘하는 사람은 아마 없을겁니다. 각각의 테스트마다 전문가가 되기 위해서는 꽤 많은 시간과 땀과 열정을 쏟아 부어야 합니다.

고로 여러분이 저 모든걸 다 잘하실 필요는 없고 가장 자신있는 테스트에 열정을 쏟으시기 바랍니다.

저는 사용성을 주력으로 삼고 있고... 우리 나라에서는 아무래도 효율성이 인기가 좋은 편입니다. 보안성은 인기가 좋을 듯 하지만 대우는 글쎄요.. 신뢰성은 찾아보기 좀 힘든 편이고 호한성, 유지보수성, 이식성은 그냥 대충 하는 편입니다.(제가 주변에 여기 저기 구경 다녀본 경험상..)

설계자 또는 관리자라면 저 테스트 중에서 어떤 테스트를 우리 제품에서 수행해야하는가가 매우 큰 고민 중 하나일것입니다.

여기서 두번 째 팁은 고객과 대화를 많이 해봐야 한다는 것입니다. 여기서 고객은 여러 사람이 될 수 있습니다. 최종 사용자가 될 수도 있고, 제품을 구매하는 사람이나 테스터에게 테스트를 의뢰하는 사람이 될 수도 있습니다. 대화를 많이 해야하는 이유는 테스트를 실행하는 목적과 고객에게 전달해야할 데이터와 가치를 명확하게 하기 위해서입니다.

누가 언제 어디서 제품을 어떤 방식으로 사용하고 제품이 어떤 플랫폼에서 어떤 다른 시스템과 어떻게 통신하고 데이터를 주고 받는지 명확하게 이해할 수 있다면 어떤 테스트를 수행해야 할지 좀 더 쉽게 결정을 내릴 수 있습니다.

이것을 좀 더 전문적으로 얘기하면 아래와 같은 제품 구성요소를 식별하는 것이 중요합니다.

시간 / 인터페이스 / 플랫폼 / 운용

위에 소개된 4가지 관점으로 제품의 정황을 분석하고 해당 내용을 고객과 대화를 많이 나눠야 좀 더 완성도 높은 테스트를 계획하고 수행할 수 있습니다.

인터페이스가 중요하다면 호환성 테스트를 플랫폼이 중요하다면 이식성 테스트를 운용이 중요하다면 사용성 테스트를 수행하는 방식입니다.

이건 테스터가 혼자서 결정을 내릴 수 있는 문제는 아닙니다.

테스트 설계를 잘하는 마지막 팁은 질문을 잘하는 것입니다.

제품을 어떤 관점에서 바라보고 분석하고 확인해야할지 명확해졌다면 내가 이해하고 있는것과 이해하지 못하는 것에 대해 끊임없이 자신과 이해관계자에게 질문을 많이 하는 것이 중요합니다.

뭔가 거창한걸 소개하는 듯 했는데.. 오늘도 역시나 용두사미가 되어버렸습니다.

설계 잘하는 꼼수를 소개한다는 글이 두리뭉실한 소리로 가득차버렸네요.

미천한 제 글솜씨를 탓하시고 궁금하신 내용은 댓글로 남겨주시면 성심껏 답변해드리겠습니다.

결론은 3가지입니다.

첫째, 소프트웨어는 복잡해 보일 뿐 복잡하지 않다. 흐름에 주목하자. 데이터는 그 다음이다.
둘째, 내가 왜 테스트를 해야하는지, 고객에게 어떤 내용을 전달해야하는지 고객과 충분히 대화를 하자.
셋째, 알고 있다고 생각하지 말고 정말로 알 때까지 질문을 멈추지말자.

이 글을 읽으시는 분들에게 정말로 아주 깨알만한 도움이라도 되시면 좋겠습니다.

댓글

이 블로그의 인기 게시물

매우 매우 매우 실망스러운 레일플러스 모바일 교통카드

우리 나라에서 버스나 지하철 같은 교통 수단을 이용하는 대부분의 사람들은 티머니와 같은 선불교통카드나 카드사와 연계된 후불교통카드를 쓰는 경우가 거의 대부분일 것입니다.

저도 현금으로 지하철이나 버스를 이용해본지가 언제인지 기억이 가물가물 합니다. (최근에는 현금을 들고 다닐 필요가 거의 없긴 하죠. 그러다보니 가끔 지방에 가서 카드가 안되는 가게나 주차장 등에서 난감하기도 하고요..)

그런데, 이런 카드 말고 스마트폰으로 교통 수단을 이용하는 사람들도 있습니다.

우리 나라에서 스마트폰으로 교통 수단을 이용하는 것은 심카드를 기반으로 구현된 기술로 문제는 해외 단말은 이 기능을 지원하지 않는 다는 것입니다.

해외 단말들이 이와 같은 기능을 구현하기 위해서는 HCE 라는 방식이 필요한데.. 이런 방식으로 결제 시스템을 구현은 할 수 없지만 지금까지는 이 기술로 구현된 사례가 없었는데, 얼마전 코레일에서 레일플러스 모바일 교통카드를 HCE 로 구현하여 서비스를 시작했습니다.

이로서 해외 단말을 사용하는 사람들도 스마트폰으로 버스나 지하철과 같은 교통수단을 이용할 수 있게 될것이라고 환호했습니다만, 실상은 그렇지 않다고 볼 수 있습니다.

저는 넥서스 5X 사용자로 심카드를 기반으로 하는 결제 시스템을 쓸 수 없었기 때문에 저도 코레일에서 저 서비스를 내놓았을 때 기대에 부풀어서 나오자마자 바로 설치해봤습니다. 처음 서비스 시작한 시점이 8월이었는데, 그 때에는 안드로이드 8.0을 지원하지 않아서 서비스는 시작되었지만 사용할 수 없었습니다.

그러다가, 9월 업데이트로 안드로읻 8.0(오레오)에서도 해당 앱이 정상적으로 동작하게 되어서 한번 사용해 본 소감을 남깁니다.

우선 현재 시점으로 해당 서비스를 이용하는 방법은 크게 2가지입니다.

하나는 레일플러스 모바일 교통카드 앱을 설치하여 이용하는 방법이고, 다른 하나는 신한 판(앱카드)를 설치하여 이용하는 방법입니다.

카드 종류는 선불과 후불 2가지 종류가 있는데, 레일플러스 모바일 교통카드 앱은 2가지를 모두 지원하고…

최선희 한복 수선 후기

2년 전에 제가 쾌자를 하나 구매하고 후기 적었던걸 기억하시는 분 계신가요?

http://murianwind.blogspot.kr/2013/06/blog-post_10.html

그 쾌자.. 2년 동안 몇번 입기는 했지만.. 그 때 후기에도 적었던 것처럼 기존에 가지고 있는 생활 한복과 너무 너무 안어울려서.. 그냥 옷걸이에 걸려서 방치되어 있던 것을..

정말로 큰 맘 먹고 수선하기로 결정했습니다.

2년이 지나고 가장 큰 변화는 제가 한복에 워낙 관심을 가지다 보니 정보를 얻는 곳이 더 넓어진것도 있지만 모던 한복 또는 패션 한복이라는 분류로 한복을 좀 더 새롭게 해석해서 만드는 젊은 디자이너 분들이 매우 많아졌다는 것입니다.

요즘 가장 뜨거운 관심을 받고 있는 리슬이라는 브랜드가 있고요..(http://leesle.com/) (저와 제 아내는 요즘 리슬에 꼽혀서.. 거의 100만원에 육박하는 옷을 질렀습니다. 쿨럭 쿨럭..)

챠이킴(http://blog.naver.com/tchaikim)이라는 브랜드도 요즘 뜨거운 브랜드 중 하나입니다.

유명한 천의 무봉(http://blog.naver.com/y8317)도 있습니다.

그런데 대부분 이런 곳들은 가격이 머.. 만만치 않습니다. 그리고 우선 제가 원하는 수선을 전문으로 하는 곳은 아니죠..

그래서 수선을 잘 하는 한복집을 찾다가 최선희 한복(https://www.facebook.com/sunhee.choi3)이라는 곳을 알게 되었습니다.

수선도 잘 해주시고.. 원단도 잘 사용하신다는 평에..

어떨까? 하다가 큰 맘 먹고 다시 한번 도전해보기로 했습니다.

그리고 수선 후 이렇게 생긴 옷을 받았습니다.


쾌자를 전복으로 바꿔주셨습니다.

입어보니.. 이제 꽤 한복 같은 느낌이 납니다.

우선은 깃을 좀 높게 달아서 안에 입은 한복이 겉으로 드러나지 않으니 좋네요..

그런데 원래 이 옷은 여름에 겉에 두르려고 맞췄던 건데.. 이제는 그건 좀 무리지 않을까 싶긴 합니다. 음.. 여름에 한번 도전해 봐야겠어요.

솜씨도 좋으시고…

ISO/IEC 25010 제품 품질 모델 소개

소프트웨어의 품질 특성을 정의하고 있는 국제 표준 ISO/IEC 9126 은 IT 업계에서 소프트웨어로 종사하시는 분들이라면 누구든지 한번쯤은 들어보셨고, 현업에서도 잘 활용하고 계실거라고 믿습니다.

그리고 ISO/IEC 9126 이 근래에 ISO/IEC 25010 으로 개정된 것도 알고 계실 겁니다.

정식으로 개정되었기 때문에 이제는 9126이 아닌 25010으로 얘기를 하는것이 맞다는 것이 제 생각입니다.

그런데 구글님에게 아무리 물어보아도 국내에 최신 25010 이 소개된 자료를 찾을 수가 없어.. 제가 칼을 빼들었습니다.

무려 17,400원이라는 거금을 들여서 문서를 샀습니다.

전체 문서를 구매하면 당연히 비싸기 때문에 그냥 개요 문서만 샀습니다.

혹시 전체 내용이나 상세한 내용이 궁금하신 분은 꼭 한국표준정보망(https://www.kssn.net/)에 가셔서 구매하시기 바랍니다.

저도 자세한 내용을 공유해드리면 좋겠지만.. 문서 하단에 정확하게 저에게 라이센스를 부여하며 불법 복사 및 무단 배포를 금한다고 협박성 문구가 적혀 있는 관계로 간단하게 어떤 내용들이 언급되어 있는지 소개 정도 해드리겠습니다.

ISO/IEC 25010은 2011년 제1판이 발행되었고 국내에는 2011년 12월 30일 제정되어 배포되었습니다. 한국어 번역이 무지 잘된 상태는 아니지만 이해하는데 큰 문제는 없습니다.

문서를 읽어본 소감을 말씀드리자면 이전 ISO/IEC 9126 표준에 비해 많은 내용들이 이해하기 쉽도록 변경되고 실무에 바로 적용할 수 있을 정도로 잘 정리되었습니다.

가장 큰 변화는 주특성이 기존의 6가지에서 8가지로 늘었다는 것입니다.

각 주특성과 부특성을 살펴보면 아래와 같습니다. ( ) 의 내용은 기존의 ISO/IEC 9126에서의 명칭입니다.

우선 기존의 기능성은 기능 적합성(functional suitability)으로 변경되었습니다.
부특성으로는 기능 성숙도(functional completeness), 기능 정확성(명확성)(functional co…