테스터로 사노라면 참 쉬운일이 하나도 없습니다.
물론 요구사항 수집, 분석, 정의하고 설계하고 개발하는 모든 일이 쉬운게 없습니다.
사람마다 차이가 있겠지만 테스트를 하다보면 가장 막막한 것이 얼마나 테스트를 해야 충분한걸까? 나는 테스트를 잘 하고 있는걸까? 테스트 케이스는 어떻게 만들어야 하는걸까? 결함을 어떻게 하면 잘 발견할 수 있을까? 머.. 이런것이 아닐까라고 생각해봅니다.
비슷한 질문은 수없이 많겠지만 결론적으로 말해보면 커버리지(테스트의 충분함)은 테스터의 영원한 숙제가 아닐까 합니다.
모든 경우를 고려한 테스트가 불가능하다는 것은 이론적으로 체험적으로 이미 아는 사실이고.. 그렇다면 어떻게 테스트를 하면 충분한 테스트일까요? 어떻게 테스트를 해야 발 뻗고 잠이 들까요? 도데체 어떤 테스트를 해야할지 어떻게 결정할 수 있을까요?
이런 고민을 해결하고자 혼자서 공부도 해보고 교육도 들어보고 컨설팅도 받아보지만 딱 부러지게 맘에 드는 해답이 없는게 현실이 아닌가 싶습니다.
그래서 이제 10년차가 된 야매 테스터(전 소프트웨어 공학을 전공한적도 없고.. 남들 다 있다는 석/박사 학위도 없습니다.)의 꼼수를 알려드릴까 합니다. 물론.. 미천한 저의 경험이기 때문에 도움이 많이 되시지 않으시다면 저에게 가르침을 주시면 고맙겠습니다.
자.. 먼저 생각해볼 것은 왜 그렇게 우리는 테스트를 막연하게 생각하는 것일까요? 왜 무엇을 얼마나 해야할지 쉽게 결정을 내리지 못하는걸까요?
이 질문에 대답을 하기 위해서 필요한 것이 소프트웨어란 무엇인가입니다.
知彼知己 百戰不殆 不知彼而知己 一勝一負 不知彼不知己 每戰必敗 (지피지기 백전불태 부지피이지기 일승일부 부지피부지기 매전필패) 라고 손자병법의 유명한 구절이 있습니다.
적을 알고 나를 알면 백번 싸워도 위태로울 것이 없으나 나를 알고 적을 모르면 승과 패를 각각 주고 받을 것이며 적을 모르는 상황에서 나조차도 모르면 싸움에서 반드시 패배한다는 것입니다.
테스트를 잘 하기 위해서는 나와 우리 팀과 우리 조직이 무엇을 잘 하고 무엇을 못하는지 우선 알아야 하고 내가 테스트해야하는 대상에 대해서도 잘 알고 있어야 합니다.
여기서 중요한 것은 알고 있다와 아는 것 같다를 구별할 수 있어야 합니다.
많은 테스터들이 자신이 테스트하는 제품을 매우 잘 이해하고 있다고 생각하지만 막상 대상에 대해 잘못 이해하고 있거나 잘 모르는 경우가 꽤 많습니다.
테스트 해야 될 대상을 먼저 잘 이해하고 아는 것이 매우 중요합니다.
그렇다면.. 소프트웨어란 무엇일까요? 여러분은 소프트웨어를 무엇이라고 생각하십니까?
저는 소프트웨어를 아래와 같이 이해하고 있습니다.
소프트웨어는 크게 2가지 부분으로 이루어져 있습니다.
하나는 논리(logic, condition) 다른 하나는 데이터입니다.
데이터를 좀 더 세분하면 입력값과 출력값으로 구분할 수 있습니다.
즉, 소프트웨어란 입력값을 받아 출력값을 출력하는 로직의 중합체라고 볼 수 있습니다.
하드웨어, 정황, 사용자가 얽히고 설켜 매우 복잡하게 보이는 제품이라 할지라도 각각을 저 3가지로 분류해서 정리하면 좀 더 명확하게 제품을 바라볼 수 있습니다. 아무리 복작한 로직이라고 하더라도 결국은 입력값에 따른 출력값에 따라 구분해보면 꽤 깔끔하게 정리할 수 있습니다.
그래서 첫번째 팁은 대상을 단순하게 바라보자는 것입니다. 대상을 정확하게 분석하고 최대한 단순하게 정의하는 것이 중요합니다.
추가적인 팁이라면 우선은 데이터는 신경쓰지 말고 논리(흐름, flow)만 집중하는 겁니다.
상태전이와 같은 모델링도 좋고 클라시피케이션 트리 메소드도 괜찮고 마인드맵이나 피쉬 본도 좋습니다. 무엇이 되었든 깔끔하게 전체 시스템의 흐름을 볼 수 있는 방법이면 좋습니다.
대상을 분석해서 흐름을 완성했다면 이제 설계 기법을 적용해 볼 시간입니다.
대상 분석을 잘 하셨다면 설계 기법은 약간의 노력과 학습만으로 충분히 적용할 수 있습니다.
설계 기법은 여러 종류가 알려져 있지만 두가지로 나눠볼 수 있습니다.
하나는 데이터 검증에 이용되는 기법으로 동등분할, 경계값 분석, 문법 테스팅, 랜덤 테스팅과 같은 기법들이 있습니다.
다른 하나는 논리 검증에 이용되는 기법으로 결정테이블, 상태전이, 유즈케이스 등의 기법들이 있습니다.
논리 검증에 이용되는 기법들은 분석과정에서 제품을 어떻게 모델링했는가에 따라 해당하는 기법을 적용하시면 됩니다.
저는 상태전이를 즐겨 사용하는 편입니다.
데이터 검증에 사용되는 기법은 리스크를 고려해서 테스트 강도에 따라 적절한 기법을 사용하시면 됩니다.
저는 경계값 분석과 랜덤 테스팅을 즐겨 사용하는 편입니다.
이렇게 테스트 대상 제품을 데이터와 로직으로 구분해서 모델링하고 설계기법을 적용하는 것이 경험을 기반으로(했다고 말하고 마구잡이로) 테스트하는 것과의 차이는 제품에 대한 이해가 달라지고 제품을 이해한만큼 정교한 테스트를 설계함으로써 테스트에 대한 자신감을 얻을 수있다는 것입니다.
중요한 것은 제품을 논리와 데이터로 구분해서 바라보는 것입니다.
딱 요기까지가 기능 테스팅입니다. 기본중의 기본 테스트입니다.
처음에는 욕심 많이 안부리고 제품 분석에 능숙해질때까지 열심히 노력하는 것이 중요합니다.
그리고나서 익숙해지면 이제 다음단계로 넘어가봅시다.
기능 테스트가 어느 정도 익숙해지면 이제 비기능 테스트를 슬금 슬금 고민해볼 때입니다.
비기능 테스트는 가장 대표적인 사용성/효율성/보안성 테스트와 호환성/신뢰성/유지보수성/이식성 테스트가 있습니다.
이 모든 테스트를 다 잘하는 사람은 아마 없을겁니다. 각각의 테스트마다 전문가가 되기 위해서는 꽤 많은 시간과 땀과 열정을 쏟아 부어야 합니다.
고로 여러분이 저 모든걸 다 잘하실 필요는 없고 가장 자신있는 테스트에 열정을 쏟으시기 바랍니다.
저는 사용성을 주력으로 삼고 있고... 우리 나라에서는 아무래도 효율성이 인기가 좋은 편입니다. 보안성은 인기가 좋을 듯 하지만 대우는 글쎄요.. 신뢰성은 찾아보기 좀 힘든 편이고 호한성, 유지보수성, 이식성은 그냥 대충 하는 편입니다.(제가 주변에 여기 저기 구경 다녀본 경험상..)
설계자 또는 관리자라면 저 테스트 중에서 어떤 테스트를 우리 제품에서 수행해야하는가가 매우 큰 고민 중 하나일것입니다.
여기서 두번 째 팁은 고객과 대화를 많이 해봐야 한다는 것입니다. 여기서 고객은 여러 사람이 될 수 있습니다. 최종 사용자가 될 수도 있고, 제품을 구매하는 사람이나 테스터에게 테스트를 의뢰하는 사람이 될 수도 있습니다. 대화를 많이 해야하는 이유는 테스트를 실행하는 목적과 고객에게 전달해야할 데이터와 가치를 명확하게 하기 위해서입니다.
누가 언제 어디서 제품을 어떤 방식으로 사용하고 제품이 어떤 플랫폼에서 어떤 다른 시스템과 어떻게 통신하고 데이터를 주고 받는지 명확하게 이해할 수 있다면 어떤 테스트를 수행해야 할지 좀 더 쉽게 결정을 내릴 수 있습니다.
이것을 좀 더 전문적으로 얘기하면 아래와 같은 제품 구성요소를 식별하는 것이 중요합니다.
시간 / 인터페이스 / 플랫폼 / 운용
위에 소개된 4가지 관점으로 제품의 정황을 분석하고 해당 내용을 고객과 대화를 많이 나눠야 좀 더 완성도 높은 테스트를 계획하고 수행할 수 있습니다.
인터페이스가 중요하다면 호환성 테스트를 플랫폼이 중요하다면 이식성 테스트를 운용이 중요하다면 사용성 테스트를 수행하는 방식입니다.
이건 테스터가 혼자서 결정을 내릴 수 있는 문제는 아닙니다.
테스트 설계를 잘하는 마지막 팁은 질문을 잘하는 것입니다.
제품을 어떤 관점에서 바라보고 분석하고 확인해야할지 명확해졌다면 내가 이해하고 있는것과 이해하지 못하는 것에 대해 끊임없이 자신과 이해관계자에게 질문을 많이 하는 것이 중요합니다.
뭔가 거창한걸 소개하는 듯 했는데.. 오늘도 역시나 용두사미가 되어버렸습니다.
설계 잘하는 꼼수를 소개한다는 글이 두리뭉실한 소리로 가득차버렸네요.
미천한 제 글솜씨를 탓하시고 궁금하신 내용은 댓글로 남겨주시면 성심껏 답변해드리겠습니다.
결론은 3가지입니다.
첫째, 소프트웨어는 복잡해 보일 뿐 복잡하지 않다. 흐름에 주목하자. 데이터는 그 다음이다.
둘째, 내가 왜 테스트를 해야하는지, 고객에게 어떤 내용을 전달해야하는지 고객과 충분히 대화를 하자.
셋째, 알고 있다고 생각하지 말고 정말로 알 때까지 질문을 멈추지말자.
이 글을 읽으시는 분들에게 정말로 아주 깨알만한 도움이라도 되시면 좋겠습니다.
물론 요구사항 수집, 분석, 정의하고 설계하고 개발하는 모든 일이 쉬운게 없습니다.
사람마다 차이가 있겠지만 테스트를 하다보면 가장 막막한 것이 얼마나 테스트를 해야 충분한걸까? 나는 테스트를 잘 하고 있는걸까? 테스트 케이스는 어떻게 만들어야 하는걸까? 결함을 어떻게 하면 잘 발견할 수 있을까? 머.. 이런것이 아닐까라고 생각해봅니다.
비슷한 질문은 수없이 많겠지만 결론적으로 말해보면 커버리지(테스트의 충분함)은 테스터의 영원한 숙제가 아닐까 합니다.
모든 경우를 고려한 테스트가 불가능하다는 것은 이론적으로 체험적으로 이미 아는 사실이고.. 그렇다면 어떻게 테스트를 하면 충분한 테스트일까요? 어떻게 테스트를 해야 발 뻗고 잠이 들까요? 도데체 어떤 테스트를 해야할지 어떻게 결정할 수 있을까요?
이런 고민을 해결하고자 혼자서 공부도 해보고 교육도 들어보고 컨설팅도 받아보지만 딱 부러지게 맘에 드는 해답이 없는게 현실이 아닌가 싶습니다.
그래서 이제 10년차가 된 야매 테스터(전 소프트웨어 공학을 전공한적도 없고.. 남들 다 있다는 석/박사 학위도 없습니다.)의 꼼수를 알려드릴까 합니다. 물론.. 미천한 저의 경험이기 때문에 도움이 많이 되시지 않으시다면 저에게 가르침을 주시면 고맙겠습니다.
자.. 먼저 생각해볼 것은 왜 그렇게 우리는 테스트를 막연하게 생각하는 것일까요? 왜 무엇을 얼마나 해야할지 쉽게 결정을 내리지 못하는걸까요?
이 질문에 대답을 하기 위해서 필요한 것이 소프트웨어란 무엇인가입니다.
知彼知己 百戰不殆 不知彼而知己 一勝一負 不知彼不知己 每戰必敗 (지피지기 백전불태 부지피이지기 일승일부 부지피부지기 매전필패) 라고 손자병법의 유명한 구절이 있습니다.
적을 알고 나를 알면 백번 싸워도 위태로울 것이 없으나 나를 알고 적을 모르면 승과 패를 각각 주고 받을 것이며 적을 모르는 상황에서 나조차도 모르면 싸움에서 반드시 패배한다는 것입니다.
테스트를 잘 하기 위해서는 나와 우리 팀과 우리 조직이 무엇을 잘 하고 무엇을 못하는지 우선 알아야 하고 내가 테스트해야하는 대상에 대해서도 잘 알고 있어야 합니다.
여기서 중요한 것은 알고 있다와 아는 것 같다를 구별할 수 있어야 합니다.
많은 테스터들이 자신이 테스트하는 제품을 매우 잘 이해하고 있다고 생각하지만 막상 대상에 대해 잘못 이해하고 있거나 잘 모르는 경우가 꽤 많습니다.
테스트 해야 될 대상을 먼저 잘 이해하고 아는 것이 매우 중요합니다.
그렇다면.. 소프트웨어란 무엇일까요? 여러분은 소프트웨어를 무엇이라고 생각하십니까?
저는 소프트웨어를 아래와 같이 이해하고 있습니다.
소프트웨어는 크게 2가지 부분으로 이루어져 있습니다.
하나는 논리(logic, condition) 다른 하나는 데이터입니다.
데이터를 좀 더 세분하면 입력값과 출력값으로 구분할 수 있습니다.
즉, 소프트웨어란 입력값을 받아 출력값을 출력하는 로직의 중합체라고 볼 수 있습니다.
하드웨어, 정황, 사용자가 얽히고 설켜 매우 복잡하게 보이는 제품이라 할지라도 각각을 저 3가지로 분류해서 정리하면 좀 더 명확하게 제품을 바라볼 수 있습니다. 아무리 복작한 로직이라고 하더라도 결국은 입력값에 따른 출력값에 따라 구분해보면 꽤 깔끔하게 정리할 수 있습니다.
그래서 첫번째 팁은 대상을 단순하게 바라보자는 것입니다. 대상을 정확하게 분석하고 최대한 단순하게 정의하는 것이 중요합니다.
추가적인 팁이라면 우선은 데이터는 신경쓰지 말고 논리(흐름, flow)만 집중하는 겁니다.
상태전이와 같은 모델링도 좋고 클라시피케이션 트리 메소드도 괜찮고 마인드맵이나 피쉬 본도 좋습니다. 무엇이 되었든 깔끔하게 전체 시스템의 흐름을 볼 수 있는 방법이면 좋습니다.
대상을 분석해서 흐름을 완성했다면 이제 설계 기법을 적용해 볼 시간입니다.
대상 분석을 잘 하셨다면 설계 기법은 약간의 노력과 학습만으로 충분히 적용할 수 있습니다.
설계 기법은 여러 종류가 알려져 있지만 두가지로 나눠볼 수 있습니다.
하나는 데이터 검증에 이용되는 기법으로 동등분할, 경계값 분석, 문법 테스팅, 랜덤 테스팅과 같은 기법들이 있습니다.
다른 하나는 논리 검증에 이용되는 기법으로 결정테이블, 상태전이, 유즈케이스 등의 기법들이 있습니다.
논리 검증에 이용되는 기법들은 분석과정에서 제품을 어떻게 모델링했는가에 따라 해당하는 기법을 적용하시면 됩니다.
저는 상태전이를 즐겨 사용하는 편입니다.
데이터 검증에 사용되는 기법은 리스크를 고려해서 테스트 강도에 따라 적절한 기법을 사용하시면 됩니다.
저는 경계값 분석과 랜덤 테스팅을 즐겨 사용하는 편입니다.
이렇게 테스트 대상 제품을 데이터와 로직으로 구분해서 모델링하고 설계기법을 적용하는 것이 경험을 기반으로(했다고 말하고 마구잡이로) 테스트하는 것과의 차이는 제품에 대한 이해가 달라지고 제품을 이해한만큼 정교한 테스트를 설계함으로써 테스트에 대한 자신감을 얻을 수있다는 것입니다.
중요한 것은 제품을 논리와 데이터로 구분해서 바라보는 것입니다.
딱 요기까지가 기능 테스팅입니다. 기본중의 기본 테스트입니다.
처음에는 욕심 많이 안부리고 제품 분석에 능숙해질때까지 열심히 노력하는 것이 중요합니다.
그리고나서 익숙해지면 이제 다음단계로 넘어가봅시다.
기능 테스트가 어느 정도 익숙해지면 이제 비기능 테스트를 슬금 슬금 고민해볼 때입니다.
비기능 테스트는 가장 대표적인 사용성/효율성/보안성 테스트와 호환성/신뢰성/유지보수성/이식성 테스트가 있습니다.
이 모든 테스트를 다 잘하는 사람은 아마 없을겁니다. 각각의 테스트마다 전문가가 되기 위해서는 꽤 많은 시간과 땀과 열정을 쏟아 부어야 합니다.
고로 여러분이 저 모든걸 다 잘하실 필요는 없고 가장 자신있는 테스트에 열정을 쏟으시기 바랍니다.
저는 사용성을 주력으로 삼고 있고... 우리 나라에서는 아무래도 효율성이 인기가 좋은 편입니다. 보안성은 인기가 좋을 듯 하지만 대우는 글쎄요.. 신뢰성은 찾아보기 좀 힘든 편이고 호한성, 유지보수성, 이식성은 그냥 대충 하는 편입니다.(제가 주변에 여기 저기 구경 다녀본 경험상..)
설계자 또는 관리자라면 저 테스트 중에서 어떤 테스트를 우리 제품에서 수행해야하는가가 매우 큰 고민 중 하나일것입니다.
여기서 두번 째 팁은 고객과 대화를 많이 해봐야 한다는 것입니다. 여기서 고객은 여러 사람이 될 수 있습니다. 최종 사용자가 될 수도 있고, 제품을 구매하는 사람이나 테스터에게 테스트를 의뢰하는 사람이 될 수도 있습니다. 대화를 많이 해야하는 이유는 테스트를 실행하는 목적과 고객에게 전달해야할 데이터와 가치를 명확하게 하기 위해서입니다.
누가 언제 어디서 제품을 어떤 방식으로 사용하고 제품이 어떤 플랫폼에서 어떤 다른 시스템과 어떻게 통신하고 데이터를 주고 받는지 명확하게 이해할 수 있다면 어떤 테스트를 수행해야 할지 좀 더 쉽게 결정을 내릴 수 있습니다.
이것을 좀 더 전문적으로 얘기하면 아래와 같은 제품 구성요소를 식별하는 것이 중요합니다.
시간 / 인터페이스 / 플랫폼 / 운용
위에 소개된 4가지 관점으로 제품의 정황을 분석하고 해당 내용을 고객과 대화를 많이 나눠야 좀 더 완성도 높은 테스트를 계획하고 수행할 수 있습니다.
인터페이스가 중요하다면 호환성 테스트를 플랫폼이 중요하다면 이식성 테스트를 운용이 중요하다면 사용성 테스트를 수행하는 방식입니다.
이건 테스터가 혼자서 결정을 내릴 수 있는 문제는 아닙니다.
테스트 설계를 잘하는 마지막 팁은 질문을 잘하는 것입니다.
제품을 어떤 관점에서 바라보고 분석하고 확인해야할지 명확해졌다면 내가 이해하고 있는것과 이해하지 못하는 것에 대해 끊임없이 자신과 이해관계자에게 질문을 많이 하는 것이 중요합니다.
뭔가 거창한걸 소개하는 듯 했는데.. 오늘도 역시나 용두사미가 되어버렸습니다.
설계 잘하는 꼼수를 소개한다는 글이 두리뭉실한 소리로 가득차버렸네요.
미천한 제 글솜씨를 탓하시고 궁금하신 내용은 댓글로 남겨주시면 성심껏 답변해드리겠습니다.
결론은 3가지입니다.
첫째, 소프트웨어는 복잡해 보일 뿐 복잡하지 않다. 흐름에 주목하자. 데이터는 그 다음이다.
둘째, 내가 왜 테스트를 해야하는지, 고객에게 어떤 내용을 전달해야하는지 고객과 충분히 대화를 하자.
셋째, 알고 있다고 생각하지 말고 정말로 알 때까지 질문을 멈추지말자.
이 글을 읽으시는 분들에게 정말로 아주 깨알만한 도움이라도 되시면 좋겠습니다.
댓글
댓글 쓰기