기본 콘텐츠로 건너뛰기

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

결론은 3가지입니다.

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

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

댓글

이 블로그의 인기 게시물

테슬라 구매 과정 후기

올해 제 인생 최대 지름이 될.. 테슬라 구매를 했습니다. 스파크만 13년을 몰았는데... 내자분이 애들도 컸고.. 이젠 스파크가 좁고 덥고 힘들다면서... 4월 6일 하남 테슬라 전시장에서 새로 나온 업그레이드 된 모델 3를 보고 4월 7일 덜컥 계약을 해버리게 되었습니다. 이후에 4월 11일에 보조금 설문 조사 문자를 받았습니다. 그리고 다시 기다림의 시간이.. 사실, 처음에 하얀색을 계약을 했다가 하얀색은 관리하기가 너무 힘들거 같아 4월 20일에 블루로 변경을 했었는데.. 다른 사람들은 하나 둘 차량을 인도 받는데.. 아무리 기다려도 인도 일정이 배정이 되지 않아서... 혹시나 하고 4월 25일 하얀색으로 변경하자마자 VIN이 배정되고 4월 29일 인도 일정 셀프 예약 문자가 왔습니다. 파란색이 정말 인기가 없었나 봅니다. (그런데, 소문에 듣자하니.. 파란색은 5월 첫주부터 인도 일정 셀프 예약 문자가 왔었다고 합니다.. 크흑.. ㅠㅠ) 덕분에 기다리고 기다리긴 했지만 아무 준비도 없던 와중에 이제부터 정말 실제 차량을 인도받기 위한 질주가 시작되었습니다. 4월 30일 셀프 인도 예약 완료 문자가 왔고 5월 2일 오전 10시 5분에 전기자동차 구매지원 자격 부여 문자가 오고 오후 3시 5분에 전기차 보조금 지원 대상자 확정 문자를 받았습니다. 사실 기다림의 시간이 제일 힘든건.. 보조금을 못받으면 어떻게 하지?라는 초조함이었습니다. 얼마 안되는 보조금이라고 하더라도 한푼이 아쉬운 입장에서는 정말 필요한 돈이었는데.. 다행히 큰 문제 없이 지원 대상자가 될 수 있었습니다. 그리고 5월 2일 오후 4시 12분에 차량 대금을 후다닥 결제를 진행했습니다. 유투브와 네이버 카페 등을 열심히 읽어두었지만 막상 진행해보니 다른 설명과는 좀 다르게 진행되어서 불안했었는데.. 큰 문제 없이 결제가 완려되었습니다. 이미 차량 인도는 5월 14일로 결정되었기 때문에 이제는 차량 등록에 대한 기다림이 시작되었습니다. 드디어 5월 8일 오후 2시 23분에 등록 대행 비용 및

테스트 케이스와 체크리스트의 차이가 뭐여?

테스트 실무에서 가장 혼돈되어 사용되는 용어 중 하나가 테스트 케이스와 체크리스트입니다. 많은 경우 체크리스트를 테스트 케이스로 사용하는 경우가 많습니다. 실제로 인터넷 커뮤니티나 블로그, ISO, IEEE, ISTQB 등등을 검색해보시면 테스트 케이스와 체크리스트에 대한 구분이 다 제각각입니다. 각각에 대한 정의가 다 제각각입니다. 사정이 이러하다보니 많은 사람들이 테스트 케이스와 체크리스트를 잘 구분하지 못하고 혼동해서 사용하는 경우가 많습니다. 물과 기름처럼 테스트 케이스와 체크리스트를 정확하게 구분할 수는 없겠지만.. ISTQB를 기준으로 말씀드리면 설계 기법을 통해 도출된 것은 테스트 케이스 그렇지 않은 것은 체크리스트라고 생각하시면 쉽습니다. 예를 들면 아래는 결정 테이블 테스팅 기법을 통해 도출된 테스트 케이스의 예제입니다. 실제 테스트 케이스는 위보다 복잡하겠지만 어쨌든 얘기하고 싶은 것은 위와 같이 설계 기법을 통해서 도출된 것은 테스트 케이스라고 합니다. 그런데 딱 보시면 아시겠지만 실제 테스트에서는 저 정도로는 테스트 커버리지를 충분히 만족했다고 얘기하기 힘듭니다. 그렇습니다. 어떤 분들은 테스트 케이스가 전가의 보도, 은 총알 쯤으로 생각하시는데.. 테스트 케이스는 일종의 마지노 선이라고 보시면 됩니다. 최소한 제품을 테스트 할때 이정도는 해줘야 한다는 최후의 방어선 정도라고 보시면 됩니다. 전쟁에서 최후의 방어선은 물러설 수 없는 마지막 보루입니다. 하지만 최후의 방어선만 지킨다고 전쟁에서 승리할 수는 없습니다. 프랑스는 마지노 요새만 믿고 있다가 독일에게 깔끔하게 발렸던 과거가 있지요. 전쟁에서 승리하려면 앞으로 나가야하고 치밀한 전략과 전술이 뒷받침 되어야 합니다. 더 높은 커버리지를 도달하고, 충분히 좋은 테스트가 수행되려면 테스트 케이스는 기본이 되어야 하고 거기에 더해서 체크리스트가 따라와 줘야 합니다. 이러한 체크리스트는 팀의 경험과 과거 프로젝트의 데이

비츠 스튜디오 버즈 플러스(투명) 사용 후기

제 내자분은 아직도 유선 이어폰을 쓰고 있습니다. 그게 좋다고 하시더라구요. 작년에 혹시나 해서 앤커 사운드코어 라이프Q35를 구매해서 조공해봤지만 결국은 안쓰시더라구요. 그래서 작년 추운 겨울에 제가 귀마게 용으로 잘 사용해왔는데.. 여름이 되니.. 와.. 이건 너무 덥고 무거워서 못쓰겠더라구요. 아이폰도 사고 애플 워치도 샀으니.. 다음은 에어팟인데.... 노이즈 캔슬링이 된다는 에어팟 프로 2는 ... 네... 너무 비싸더라구요... 이건 내자분께 얘기해봐야 결제가 될리가 없어서... 고민하고 있던차에.. 네.. 저는 봐버리고 말았습니다. 비츠 스튜디오 버즈 플러스의 그 영롱한 투명 버전의 자태를... 급 뽐뿌가 왔지만.. 여전히 20만원의 고가더라구요... 초기 출시 시기에 이벤트로 16만원 정도 했던거 같은데.. 그정도 가격이면 선 결제 후 보고 하면 될거 같은데.. 20만원은 너무 너무 비싸서 침만 삼키던 차에.. 당근에 15만원에 올라온 물건을 덥석 물었습니다. 애플 뮤직 6개월 프로모션 코드도 사용하지 않은 따끈따끈한 제품이라서 그냥 질렀습니다. 이상하게 인터넷이 실제 리뷰 게시물을 찾기 힘들어서.. 고민을 잠깐 했지만.. 그 투명하고 영롱한 자태에 그만... 어쨌든 구매하고 한달 정도 사용해본 후기를 간단하게 남겨봅니다. 1. 노이즈 캔슬링은 기대한 것과는 좀 다르고 앤커 사운드코어 라이프Q35 정도 되는 것 같습니다. 노이즈 캔슬링은 활성화하면 이게 소리를 막아준다기보다는 주변의 작은 소음만 제거해준다고 생각하시면 됩니다. 그러니까 옆에서 소근 거리는 소리나 선풍기 바람 소리 같은 작은 소리들이 사라지고 음악 같은 내가 듣고자 하는 소리가 굉장히 뚜렸해지만 지하철 안내 방송 같은 조금 큰 소리는 그냥 들립니다. 그래서 주변음 허용 모드를 켜보면 너무 시끄러워서 안쓰게 되더라구요. 전 에어팟 프로 2를 사용해 본적이 없어서 비교할 수는 없지만.. 아주 못쓸 정도의 성능은 아니라고 생각됩니다. 2. 저는 귓구멍이 너무 작아서 XS 사이즈의 이어팁