패턴 라이팅, 우리의 테스팅 역량을 강화시켜줄 히든 카드
STEN_조현길
이전에 Tester's Insight 잡지를 위해 냈던 패턴 관련 원고인데 이번 달에 발매될 호에 실리게 되었습니다.
바쁘신 와중에 리뷰를 해주신 창준님께 감사드리며, 부끄럽지만 전문을 공개해봅니다.
참고 부탁드리며 오늘도 세로토닌이 넘치는 하루 되시길 바랍니다.
조현길 올림.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
패턴 라이팅, 우리의 테스팅 역량을 강화시켜줄 히든 카드
"Each pattern is a three-part rule, which expresses a relation between
a certain context, a problem, and a solution."
-Christopher Alexander, The Timeless Way of Building-
서언
지식 근로자가 자신의 노하우와 프랙티스를 공유하고 발전시키는 효과적인 방법이 무엇이 있을까? 개인적으로 블로깅을 하거나 잡지
에
원고를 내거나 책을 쓰는 등 여러 가지 방법이 있을 수 있겠지만, 그러한 것들이 빠르게 발간되고 여러 사람의 아이디어가 반영되
어 발전되고,
패턴화되어 공유되는 것은 쉽지 않은 일인 것 같다. P-Camp나 Xper 메일링 리스트, 김창준 씨의 기고글 등에서 오래 전
부터 논의된
패턴 라이팅이 이러한 노하우의 정제 및 공유를 효과적이게 해주는 도구 중의 하나라고 생각되어 관련 내용을 정리하여 공유해보고
자 한다.
패턴 라이팅을 통해 테스트 엔지니어의 노하우를 패턴화시키고 공유해보는 것은 어떨까?
패턴이란?
반복적으로 발생하는 문제에 대한 성공적 해결책을 문서화한 것을 패턴이라고 하고, 이 패턴들로 구성되는 언어를 패턴 언어라 한
다. 패턴
언어에는 컴퓨터 프로그램 설계뿐만 아니라 조직 구성, 새로운 아이디어 도입, 그룹 스터디 방식, 교육 방법론 등에 대한 것까
지 다양한
것들이 존재하고 있다. 이러한 패턴 언어의 장점은 여러 가지가 있는데, 무엇보다도 지식 전파와 공유가 쉬워지며 효과적인 커뮤니
케이션을 할
수 있다. By 김창준
패턴 라이팅은 이러한 패턴을 의미있게 만들어내는 과정을 뜻한다. 2001년 부터 여러 차례 소프트웨어 테스팅 패턴 워크샵을 실
시해온
브라이언 매릭(Brian Marick)에 의하면 패턴 라이팅을 할 때에는 아래의 3가지 사항을 유념해야 한다고 한다.
1. 패턴은 문제에 대한 해결책을 제공해야 한다.
2. 패턴을 사용하는 사람들에게 그 문제에 이 패턴을 적용하는 것이 왜 나은지 이해시킬 수 있어야 한다.
3. 하나의 패턴이 하나의 문제를 해결하고 새로운 맥락을 만들어내는 식으로 반복적인 사고를 할 수 있게 도와야 한다.
테스트 엔지니어나 매니저는 현실적으로 테스트를 설계하거나 테스트를 수행하면서 수많은 문제상황을 만나게 된다. 이런 문제 상황
을 보통
해결되고 나면 그 노하우는 버려지는 경우가 대부분이지만, 패턴 라이팅을 하게되면 이런 노하우들이 축적되고 다음에 만나될 문제
상황에서
참고할 수 있는 해결책을 얻을 수 있기 때문에, 잘 만 활용된다면 정말 우리의 테스팅 역량을 강화시켜줄 히든 카드가 될 수 있
다고 생각한다.
케이스 스터디 사례 : 패턴을 만들기 위한 이전 단계인 케이스 스터디
"Buffering Defect Registration"
Situation : (상황)
-What was the setting in which this case study occurred?
SW Product를 처음 테스트하면서 테스트 중에 중요한 결함과 사소한 결함들을 여러 가지 발견했으나
개발팀의 리소스(시간, 인력)에 여유가 없을 때,
Task : (문제)
-What was the problem to be solved, or the intended effect?
한꺼번에 많은 결함을 등록할 경우, 원인은 같은데도 중복해서 등록된 결함들이 발생하지만 중요한 결함 해결보다는
결함처리 행정절차에 시간을 사용함으로써 이런 비효율적 중복을 걸러내지 못할 수 있다. 또한 한꺼번에 많은 결함을
초기에 리포트하면 개발팀의 사기나 자신감을 저하시키고, 결국 모든 결함을 해결하지 못하고 다음 릴리즈로 일부 결함을 연기하게
된다.
Actions : (해결책)
-What was done to fulfill the task?
1차 테스트에는 사소한 결함들은 개발팀에 숨겨두고, 중요하고 핵심적인 결함만 리포트하여 그들이 충분한 시간을 가지고 결함을
해결하고 제품을 안정화시킬 수 있도록 버퍼를 제공한다.
Results : (결과)
-What happened? Was is a success? What contributed to the outcomes?
-실패했던 면이 있었다면 무엇이었는가?
개발팀의 협업 만족도 증가. 현재까진 성공적으로 보임.
Reflection : (배운점)
-What did you learn from the experience?
-다음번에는 어떻게 다르게 해보겠는가?
개발자의 입장에서 그들을 배려한 테스팅을 하되 해피 패스(Happy Pass)가 되지 않게 주의할 필요가 있다.
이렇게 케이스 스터디 기술이 되었으면 여기에서 패턴을 뽑아냅니다.
패턴의 기술 방식은 통상 Name, Problem, Context, Solution, Example, Caution,
Related Patterns 와 비슷한 형태를 사용합니다.
패턴 적용 사례
한글판 발매를 앞두고 있는 "How We Test Software at Microsoft"에서는 실제적으로 테스트 케이스 설계
를 위한 실용적인 접근 방법을 다루는
챕터에서 패턴에 대한 이야기를 하고 있다. 마이크로소프트 사에서는 오랫동안 문제 해결과 테스트 설계를 위한 가이드와 전략을 축
적하는데
테스트 패턴을 사용해 왔고, 이렇게 축적된 테스트 패턴들을 테스트 엔지니어가 테스트 전략을 수립할 때 의사소통 수단이나 설계
기법 적용의
노하우를 이해하기 위한 수단으로 이용해 왔다고 한다. 내부적으로 로버트 바인더의 테스트 설계 패턴 템플릿을 활용하여 아래와 같
은 형식으로 패턴을 모으고 있다고 한다.
Name (이름) : 패턴명
Problem (문제) : 문제에 대한 간략한 설명
Analysis (분석) : 문제의 원인과 해답 분석
Design (설계) - 패턴이 설계에서 실제 적용되는 방법
Oracle (오라클) - 예상 결과에 대한 설명
Examples (예제) - 해당 패턴이 실제 결함을 발견할 수 있었던 사례
Pitfalls or Limitations (함정과 제약) - 패턴 적용 시 피하거나 고려해야할 환경과 정황 설명
Related Patterns List any related patterns (관련 패턴) - 관련된 패턴
일종의 사회운동(civic movement)인 플래닛(Planet: Pattern Language Network)에서도 케이
스 스터디를 뽑아 그 중에서 패턴 후보를
선별한 후, 이를 사례에 다시 적용하여 정제하고, 정제된 것들을 패턴으로만들고 공유하는 활동을 하고 있다.
플래닛에서 만들어진 케이스 스터디를 살펴보면 실제로 패턴 라이팅을어떻게 운용해야할 지에 대한 감을 잡는데 많은 도움을 얻을
수 있다.
결언
P-Camp를 통해 배운 OST, 월드 카페, 회고 등이 의견이나 지식의 공유 및 확산을 원활하게 하는 좋은 도구들이었다면,
패턴 라이팅은
의견이나 지식을 정제하고 재사용할 수 있게 하는 강력한 도구라고 생각한다. 테스트를 하면서 같이 일하는 동료들과 노하우를
공유하고 이를 통해 더욱 더 발전하는 조직이 되기 위해서 한 번쯤 도입을 시도해보기를 권장한다. STEN 사이트에도 패턴을 공
유하기
위해 정보자료실 게시판을 운용하고 있고, 향후 STEN 세미나를 빌어 업계의 패턴을 공유해보는 자리를 가지고자 계획 중이
다.
이에 대한 의견이나 공유하고 싶은 내용이 있으면 언제든지 STEN 게시판에 올려주기 바란다. 개발자들에게 유명한 GoF
(Gang of Four: Erich Gamma, Richard Helm, Ralph Johnson, Jone
Vlissides)의 디자인 패턴처럼 언젠가 테스트 패턴이라는
책으로 대한민국의 테스팅 노하우가 유명해지길 바라며 본 글을 마치고자 한다.
[적용사례 및 참고 싸이트]
[1] P-CAMP 행사: http://p-camp.tistory.com/entry/PatternWriting
[2] Creative Commons Korea 커뮤니티 내부 적용:
http://vc.cckorea.org/boards/14/posts/1611
[3] Creative Commons Korea 커뮤니티 내부 적용:
http://sites.google.com/site/cckwiki/contentworking/20090105
[4] Software Test Engineer Network 커뮤니티 공유 사례:
http://www.sten.or.kr/bbs/board.php?bo_table=infodata&wr_id=1070
http://www.sten.or.kr/bbs/board.php?bo_table=infodata&wr_id=1077
[5] Xper 커뮤니티 공유 사례:
http://groups.google.co.kr/group/xper/browse_thread/thread/a7f079dc1d5b48ca/404336907f4d1e9c?lnk=gst&q=pattern#404336907f4d1e9c
[6] 한미유치원 적용 사례:
http://sites.google.com/site/hanmikindergarten/jeongbowa-gang-yeon-1/gang-yeon-1
[7] 사회적 패턴 공유 운동 Planet - Pattern Language Network:
http://blip.tv/file/1813796
http://patternlanguagenetwork.myxwiki.org/xwiki/bin/view/Cases/
http://patternlanguagenetwork.myxwiki.org/xwiki/bin/view/Help/CaseStudyHelp
[8] 저자 워크샵 관련 김창준 님 기고:
http://www.ibm.com/developerworks/kr/library/dwclm/20081230/
http://www.yes24.com/chyes/ChyesView.aspx?title=003002&cont=185
[9] 브라이언 머릭(Brian Marick)의 테스트 패턴 워크샵
http://www.exampler.com/testing-com/test-patterns/w3/description.html
[10] How We Test Software at Microsoft
http://www.amazon.com/How-We-Test-Software-Microsoft/dp/0735624259
[11] PLOP(Pattern Languages of Program Design) Conference
http://en.wikipedia.org/wiki/Pattern_Languages_of_Programs
송홍진
무엇보다 중요한 것은 정보의 수집, 공유, 검증인데 아직까지 국내에서 패턴을 가공하고 정의할 만큼의 정보가 공유되기는 약간 시기상조인 것 같습니다. 정보를 공유하고자 하는 분위기가 성숙한 것도 아니고..
하지만 장기적으로 패턴을 가공하고 책으로 발간해 보는 작업에는 저도 동참하고 싶습니다.
저도 아주 관심이 높습니다.