전략적 테스트 실행을 위한 테스트 설계 기법 활용
테스트 설계 기법
테스트 설계 기법
테스트 기법이란 소프트웨어를 분석하고 이를 바탕으로 테스트 케이스를 도출하는 방법입니다. 테스트 기법 또는 테스트 설계 기법이라는 용어로 사용되고 있습니다.
테스트 설계기법은 ‘테스트 케이스를 도출'하여 '테스트 보장성을 확보'하는데 목적과 목표가 있습니다. 테스트 수행을 위해 어떤 종류의 테스트 기법으로 케이스를 작성할지 방법론을 제시합니다.
하지만, 실무에서는 기대하는 바와 다르게 기법에 따른 설계가 잘 작동되지 않습니다. 설계기법을 열심히 공부하고 실무에 돌아와서는 기존 방식대로 기능을 나열하는 수준으로 TC를 작성하고 사용합니다. 결제와 같은 복잡한 테스트 수행 조건과 기능들이 얽혀있는 컴포넌트와 같은 경우에는 결정 테이블이나 구조기반 기법을 사용해서 테스트 케이스를 도출하나 그 외 일반적인 기능 테스트는 대부분 설계기법이 잘 사용되지 않습니다.
이는 단순히 ‘테스트 케이스를 작성하는 방법'으로만 설계 기법을 접근하기 때문이라고 생각합니다.
테스트 기법을 실무에 잘 활용하려면 접근 방법을 달리 생각해야합니다.
‘테스트 케이스를 어떤 기법을 사용해서 작성' 할 것인가 하는 테스트 케이스 작성 방법론으로서 접근이 아니라, ‘전략적으로 테스트를 실행하기 위한 테스트 설계기법 활용' 을 목적으로 접근해야 합니다.
즉, 테스트에 보장성을 확보하고자 테스트 케이스를 설계기법에 따라 다양하게 도출하는 것이 아닌 프로젝트 상황에 맞는 테스트 전략을 계획하고 계획된 목표와 목적 달성에 가장 적합한 테스트 설계 기법을 선택하여 테스트 케이스를 만들어야 하는 것입니다.
예를들어 제품 출시를 위해 테스트를 계획할 때 QA는 테스트 일정(시간적 제약), 투입 리소스 (보유지식/역량수준), 시스템 복잡도, 리스크 수준, 요구사항 기준 등을 고려하여 테스트를 설계합니다. 주어진 테스트 일정과 투입된 리소스가 매우 부족한 상황이라고 가정할 때 투입된 리소스를 적절히 분산하여 테스트 대상을 가능한 범위에서 빠짐없이 테스트할 것인지 또는 주요 기능에 선택&집중하여 테스트할 것인지 등 주어진 조건안에 최대한 품질을 확보할 수 있는 전략을 세우고 전략에 따라 테스트케이스를 설계할 것 입니다. QA가 최종 선택한 전략이 ‘주요 기능에 대한 선택과 집중'이라면 테스트 설계 기법 중 동등분할 기법을(입출력값 영역을 수학적 등가집합으로 만든뒤 대표값 하나를 선택해서 테스트케이스를 만드는 기법) 사용하거나 조합테스트 중 Each choice testing기법을(입력 값을 최소 한번 이상 테스트하는 기법) 사용하여 테스트케이스를 설계하는 것입니다.
✻ 테스트 케이스 설계시 테스트 기법을 사용하는 이유
보다 적은 테스트 케이스로 보다 많은 결함을 찾을 수 있도록 테스트 케이스 설계가 가능
일정 수준의 테스트 보장성 확보
적절한 테스트 기법을 선택하고 다양한 테스트 기법의 조합으로 테스트 노력 대비 좋은 결과를 얻을 수 있음
테스트 설계 기법은 하나의 기법만 사용하지 않고 테스트 케이스를 계획하고 개발하는 과정에서 여러 가지 기법을 동시에 사용할 수 있습니다. 예를들어 앞선 예시를 기준으로 설명해본다면 ‘주요 기능에 대한 선택과 집중'으로 QA전략이 계획된 경우 동등분할 기법으로만 테스트 케이스를 작성할 시 품질의 보장성이 떨어질 수 있습니다. 이 경우 동등분할 기법과 경계값 분석 기법, 조합테스트 기법을 함께 사용하여 부족하거나 누락될 수 있는 범위의 품질을 확보할 수 있도록 여러가지 기법을 동시에 사용하는 것이 좋은 전략이 될 수 있습니다.
✻ 테스트 설계 기법 선택 방법
테스트 케이스 설계를 위해 아래 요인을 고려하여 적절한 테스트 설계기법을 선택합니다.
테스트할 대상이되는 시스템 종류
서버, OS, 응용프로그램(사용자가 사용하게되는 프로그램/앱. ex_메신저, 메일, 게임 등) 등 시스템 종류와 구성에 따라 기법 선택
리스크 요소
ex_리스크와 중요도가 높은 시스템을 테스트 ⇒ 코드 구조를 참고하여 테스트 할 수 있는 구조기반 기법을 사용하는 것이 적합
고객 요구사항
ex_단시간내 일정 수준의 품질만 보장하여 제품 출시를 요구 ⇒ 요구사항에 맞는 테스트 기법으로 선택
QA 또는 테스트 담당자의 보유 지식
ex_테스트 담당자의 보유지식/역량수준이 1년차 내 신입이며 시스템 내부 구조(코드) 분석이 불가한 경우 명세기반 기법으로만 케이스 설계
전략적으로 테스트를 실행하기 위한 테스트 설계 기법 활용
계획된 전략에 맞게 테스트 설계기법을 활용하여 테스트케이스를 작성하는 방법을 구체적으로 살펴보겠습니다. 본 장의 구성은 일반적으로 알고 있는 테스트 설계 기법 종류 중 '명세기반기법'에 해당하는 기법의 설명과 해당 설계기법을 전략적으로 활용할 수 있는 예시로 작성하였습니다. (구조기반기법과 경험기반기법은 추후 별개로 작성해볼까합니다.)
명세기반기법
1. 등가분할
시스템 입력의 결과로 나타나는 결과값이 동일한 경우 하나의 그룹으로 간주합니다. 한 그룹 내 입력값은 어떠한 값을 선택해도 항상 같은 결과를 기대할 수 있다는 것을 전제로 합니다. 등가 분할은 이 원리를 이용해서 입/출력값 영역을 수학적 등가 집합으로 만든 뒤 대표값 하나를 선택하여 테스트 케이스를 만드는 기법입니다.
예를들어 A클래스에 해당되는 입력값이 1~100이고, 결과값이 N으로 동일할 경우 1~100까지 모든 값으로 테스트 케이스를 만들지 않고 1~100 중 하나의 대표값만 선택하여 테스트 케이스를 만드는 것입니다. 클래스가 A~Z로 수가 많을 경우 입력 대표값 하나씩과 각 클래스별 출력값을 확인했다는 것이 보장되어 테스트 커버리지를 달성하게 됩니다. 테스트 담당자에 따라 하나의 대표값만 확인하기 불안해서 같은 클래스 내에 2~3개 정도 케이스를 추가 할 수 있지만 결과적으로 등가 분할의 보장성은 대표값 하나로 테스트 하는 것과 결과가 동일합니다.
이런 특징으로 인해 등가 분할은 모든 경우의 수에서 테스트 케이스 갯수를 줄여줄 수 있습니다. 하지만 결과가 항상 같은 결과를 기대하는 것을 “가정"하여 테스트가 실행되고 테스트 강도가 약해서 실무에서는 특수한 상황(ex_입/출력값이 방대하나 테스트 일정/투입인력이 부족할 경우 샘플링테스팅 일환으로 등가 분할 기법을 사용하여 테스트를 진행)에서만 테스트 기법이 활용되고 있습니다.
등가 분할의 또 다른 특징으로는 명세 기반 기법으로 분류되어있지만 구조기반기법/경험기반 기법에서 입/출력값이 있는 경우 모든 상황에서 기법을 활용할 수 있습니다. 또한 단위/통합/시스템/인수 테스트 등 모든 테스트 레벨에서와 기능/비기능/리그레션 등 모든 테스트 타입에서도 활용이 가능합니다.
평가 점수에 따른 상여금 지급 시스템을 등가분할을 사용하여 TC를 작성해보겠습니다.
[조건]
평가점수 90~100점 : 상여금 600만원
평가점수 80~89점 : 상여금 400만원
평가점수 70~79점 : 상여금 200만원
평가점수 0~69점 : 상여금 0원
"정수"만 입력 가능
범위를 벗어나거나 잘못된 입력은 "ERROR"출력
[TC 도출 전 사전 작업]
1) 입/출력값을 수학적 등가 집합의 형태로 묶기
상여금 0원 : 0 <= 평가점수 <= 69
상여금 200만원 : 70 <= 평가점수 <= 79
상여금 400만원 : 80 <= 평가점수 <= 89
상여금 600만원 : 90 <= 평가점수 <= 100
2) 테스트 컨디션 도출
유효한 입력 파티션 (Input Valid Partition)
90 <= 총 점 <= 100, '상여금 600'
80 <= 총 점 < 89, '상여금 400'
70 <= 총 점 < 79, '상여금 200'
0 <= 총 점 < 69, '상여금 0'
비 유효한 입력 파티션 (Input Invalid Partition)
평가 점수 = 실수 값(소수점 포함)
평가 점수 = 영/한문자 / 특수문자
[테스트 케이스 도출]
각 집합별로 하나의 대푯값을 선택해 테스트 케이스를 작성한다
TC 를 직접 작성해보니 등가분할 기법이 좀 더 쉽게 이해됩니다. 그럼, 실무에서 등가분할 기법을 어떤 경우에 활용해볼수 있을까요.
✻ 전략을 반영한 등가 분할 기법 활용 예시
테스트 일정 + 투입인력이 충분할 경우, “강한 등가 분할 테스팅"으로 등가 집합 사이의 조합으로 나타낼 수 있는 모든 경우의 수를 테스트 할 수 있도록 설계한다.
테스트 일정 + 투입인력이 부족할 경우, “약한 등가 분할 테스팅"으로 등가 집합에서 하나의 대표값만 선택해서 테스트 케이스를 설계한다.
데이터 테이블 검증 시, 테스트 일정과 투입인력은 충분하지만 테스트할 데이터의 양이 몇 만건에 해당된다. 이 경우, 모든 등가집합의 조합에 대한 테스트를 수행하는 것은 비효율적이다. 약한 등가 분할 테스팅을 선택하여 등가 집합에서 하나의 대표값에 대한 테스트를 수행하도록 설계한다.
2. 경계값 분석
등가 분할 후 각 범위의 경계에 해당되는 입력값에서 결함이 발생되는 경우가 많다는 경험에 기반하여 결함 검출 가능성을 높일 수 있도록 경계값을 포함하여 테스트 케이스를 설계하는 기법입니다. 경계값은 임의의 데이터를 사용하지 않고 class 경계에 있는 실 데이터를 이용해야 합니다. 이를 위해 상세한 명세 또는 설계서가 필요합니다. 예를들어 A클래스에 해당되는 입력값이 ‘1 <= X < 100’ 일 경우 경계부분에 해당되는 최소값과 최대값, 즉 0, 1과 99, 100 이 경계값에 해당됩니다.
보통 경계값 분석은 하나의 기법이 단독으로 사용되지 않고 등가 분할 기법과 함께 테스트 범위 확장 형태로 함께 사용됩니다. 이렇다 보니 등가 분할과 마찬가지로 모든 테스트 레벨, 테스트 타입에 적용할 수 있고 테스트 커버리지를 보장할 수 있습니다.
평가 점수에 따른 상여금 지급 시스템으로 경계값 분석 TC를 작성해보겠습니다.
[테스트 컨디션 도출]
유효한 입력 파티션(Input Valid Partition)
0 > 총 점
총 점 > 100
비 유효한 입력 파티션(Input Invalid Partition)
0 > 평가 점수
평가 점수 > 100
총 점 = 정수 이외의 값
[테스트 케이스 도출]
✻ 전략을 반영한 경계값 분석 기법 활용 예시
등가 집합에서 하나의 대표값만 선택해서 테스트하기에 테스트 강도가 약하다 판단될 경우 등가 분할 기법 + 경계값 분석 기법을 함께 활용하여 테스트 강도 및 커버리지를 확보하고 품질을 보장하는 형태로 활용한다.
시간/초기화 조건이 있는 이벤트 또는 컨텐츠(ex_00시 컨텐츠 초기화, 출석보상 등) 검증 시, 경계값에서 이슈가 발생되는 경험이 많다. 테스트 범위에 이런 조건이 포함되어있는 경우, 경계값 분석 기법을 적극적으로 활용한다.
3. 결정테이블 테스팅
결정 테이블 테스팅은 발생 조건에 따른 결과를 테이블 형태로 나열한 것으로 시스템의 동작을 유발시키는 조건(conditions)과 처리(actions)의 모든 가능한 조합을 고려하고 조합에 대한 예상 결과를 포함하여 테스트 케이스를 설계하는 기법입니다.
결정 테이블 테스팅은 요구사항을 도출하거나 내부 시스템 설계를 문서화 하는데 유용하며 명세서 또는 시스템 설계 자체를 테스트 하는데 주로 적용됩니다. 명세서의 품질이 낮다면 모든 조건과 정확한 처리를 찾기 어려울 수 있고 시스템 설계 자체에 결함이 있을수 있어 테스트 전문가의 시각에서 결정 테이블 기법을 적용한 테스트 케이스를 설계하는 것만으로도 개발 초기 명세서와 내부 시스템에서 오류를 발견할 수 있습니다.
한가지 유의할 점은, 결정 테이블 테스팅을 전체 시스템에 적용할 경우 너무 많은 경우의 수가 도출될 수 있어서 가급적 해당 기법은 중요한 코어 시스템에서만 사용하는 것을 권장해드립니다.
세금 지불에 대한 테스트를 위해 결정테이블 테스팅을 사용하여 TC를 작성해보겠습니다.
[조건]
16세에서 65세 사이 그룹은 세금을 내야한다.
소득이 20,000달러 미만인 사람은 20% 세금을 내야하고, 그 외 사람은 50% 세금을 내야한다.
만약 이 사람들 중 아이가 있으면 10% 감세를 받을 수 있다.
[TC 도출 전 사전 작업]
조건의 조합 생성
(1) 나이
1 < ~ < 16 : 세금 안낸다
16 <= ~ <= 65 : 세금 낸다
65 < ~ : 세금 안낸다
(2) 소득
0 < ~ < 20,000달러 : 20% 세금
20,000달러 <= ~ < 이상 : 50% 세금
(3) 자녀
있음 : 10% 감세
없음 : 감세없음
[결정테이블로 입력 조건과 처리 표현]
입력 조건과 동작은 참(True)과 거짓(False)로 표현한다.
[테스트 케이스 도출]
모든 가능한 동작을 유발시키는 조건의 조합으로 테스트 케이스를 작성한다.
✻ 전략을 반영한 결정 테이블 테스팅 기법 활용 예시
결정 테이블 기법을 활용하여 테스트를 수행하기 전 명세서와 시스템 설계 단계에서 결함을 발견하여 개발 초기 단계부터 품질을 향상할 수 있다
일정 이슈 등으로 유효 케이스에 대한 테스트만 진행이 가능한 상황일 경우 모든 가능한 동작을 유발하는 조건의 조합을 커버할 수 있어서 결정 테이블 테스팅 기법이 유용하다
4. 상태전이 테스팅
명세를 구성하는 모델이 ‘상태 다이어그램'이라면, 소프트웨어가 상태 다이어그램에 맞게 구현되어있는지 확인하기위해 상태 전이 테스팅 기법을 사용하여 모든 입출력 상태의 입력 조합과 상태간에 전이되는 것, 상태를 변화 시키는 이벤트와 상태의 변화로 유발되는 동작까지 보장하는 테스트 케이스를 생성할 수 있습니다.
✻ 상태 전이 테스팅 기법으로 테스트케이스를 설계하는 방법
[1] 상태 전이 기법으로 테스트 케이스 도출
- 전형적인 상태의 순서를 커버하는 방식
- 특정한 상태 전이 순서를 실행하는 방식
- 모든 상태를 커버하는 방식(유효케이스)
- 불가능한 상태 전이를 테스트 하는 방식 (비유효 케이스)
- 모든 상태 전이를 커버하는 방식
테스트 전략에 따라 하나만 선택 또는 복수 선택으로 설계 할 수 있습니다.
[2] 도출된 테스트 케이스로 연속된 테스트 시나리오 작성
상태 전이 테스팅 기법으로 테스트 케이스를 설계할 때 유의해야 할 사항은 테스트 효율성을 높이고 더 깊이 있는 테스트 결과를 얻기 위해 테스트 실행 순서를 연속된 상태 전이를 이어서 테스트 할 수 있도록 테스트 시나리오를 작성해야 합니다.
상태 전이 테스팅 기법을 사용해서 테스트 케이스를 도출하고 도출한 순서대로 순차적으로 테스트를 수행하는 것이 아니라 테스트 수행 절차가 연속된 시나리오를 가지고 테스트가 실행될 수 있도록 작성되어야 하는 것입니다.
예를 들어, 상태전이 기법으로 도출된 테스트 케이스가 아래와 같다면,
TC 1) 1 → 2 → 4
TC 2) 1 → 3 → 5
TC 3) 4 → 6
연속된 상태 전이를 이어서 테스트 수행할 수 있도록 테스트 시나리오를 작성해야합니다.
TC 1) 1 → 2 → 3 → 4
TC 2) 3 → 4 → 5 → 6
✻ 전략을 반영한 상태 전이 기법 활용 예시
테스트 일정 + 투입인력이 충분할 경우, 모든 상태 전이를 커버할 수 있도록 설계한다.
개발자 테스트 또는 스모크 테스트 또는 리그레션 테스트로 사용하는 경우, 전형적인 상태 전이를 커버할 수 있도록 설계한다.
일정/투입인력 부족으로 적은 케이스로 많은 결함을 찾도록 전략이 계획된 경우, 유효+비유효 상태를 커버할 수 있도록 설계한다.
기획/개발 담당자의 보유 지식/경험이 부족한 경우, 특정한 상태 전이를 추가로 설계하여 예외처리에 대응할 수 있도록 테스트 케이스를 설계한다.
5. 유즈케이스 테스팅
유즈 케이스 또는 시나리오 테스팅은 유저(행위자, actor)와 시스템 사이 상호작용을 사용자의 시각에서 표현한 시나리오이며, 비즈니스 시나리오 또는 프로세스 흐름을 기반으로 테스트 케이스를 설계하는 기법입니다.
유즈 케이스는 시스템을 실제로 사용하는 행위의 절차(흐름)로 기술되기 때문에 흐름상 예상하지 못했던 정보나 존재할 수 있는 결함을 발견할 수 있고 인수테스트나 통합 테스트 단계에서 각각의 컴포넌트 사이의 상호작용으로 발생되는 결함을 발견하는데 유용합니다.
유즈 케이스 테스팅 기법이 “사용자 시각에서 표현"되는 시나리오다 보니 작성자의 경험치/역량수준/보유지식에 따라 시나리오 품질과 해석의 차이가 발생될 수 있고 표준으로 사용할 수 있는 테스트 케이스도 존재하지 않아서 해당 기법 사용시 일정 수준의 품질 결과를 얻을 수 있도록 작성에 각별히 유의해야 합니다.
시나리오 품질과 해석의 차이를 줄이기 위한 방법으로 다른 테스트 기법을 활용하여 시나리오를 작성하는 것도 좋은 방법이 될 수 있습니다.
예를들어 시스템 레벨 시나리오 테스팅은 ‘상태 전이 테스팅 기법'을 활용하여 수행순서(흐름)을 전이로 간주하여 시나리오를 작성하거나, 단위 레벨 시나리오 테스팅은 결정테이블/등가분할&경계값 분석/구조기반기법 등을 활용할 수 있습니다.
음료자판기 시스템으로 유즈케이스 TC를 작성해보겠습니다.
[조건]
1. 0 < 투입금액 < 1000 음료선택불가
2. 1000 <= 투입금액 < 10,000 음료선택가능
[결과]
1. 음료선택
2. 음료방출
3. 잔액반환
4. 취소
[테스트 케이스 도출]
상태 전이 기법을 활용하여 시스템 레벨 시나리오 테스트 케이스로 생성해본 케이스
✻ 전략을 반영한 유즈 케이스 테스팅 기법 활용 예시
상태는 다르나 수행 순서(흐름)에 반복이 많은 경우 상태 전이 기법의 테스트 케이스 도출 전략을 활용하여 흐름의 반복 횟수를 줄여 제한적으로 커버리지를 달성 할 수 있도록 테스트 케이스를 설계한다.
a) 테스트 일정 + 투입인력이 충분할 경우, 전형적인 상태 순서 + 모든 상태 전이를 커버할 수 있도록 설계b) 일정/투입인력 부족으로 적은 케이스로 많은 결함을 찾도록 전략이 계획된 경우, 유효케이스의 상태 전이를 커버할 수 있도록 설계
입력값의 조합 수가 많은 경우 등가 분할+경계값 분석 기법 활용 또는 조합 테스팅 기법을 활용하여 테스트 케이스를 설계한다.
6. 조합 테스팅
조합 테스팅은 입력값을 조합해서 최대 커버리지를 가지는 최소 개수의 테스트 케이스를 설계하는 기법입니다.
잠재적 조합 요소의 거대한 양을 처리하기 위해 테스트 케이스를 선정하는데 도움을 주는 통계적 테스트 기법으로 테스트 할 입력값의 양에 따라 All Combinations Testing, Pairwise Testing, Each Choice Testing으로 분류되며 이 중 대표적인 조합 테스팅인 페어와이즈 기법은 대부분 결함이 2개 요소의 상호작용에서 발생된다는 경험에 기반하여 테스트 하는데 필요한 각 값들이 최소한 한번씩은 조합을 이루도록 설계하는 기법입니다.
조합 테스팅은 의도적으로 테스트 케이스 수를 줄여서 테스트 하는 기법인 만큼 리스크 수준이 높지만 입력값의 누락없이 잘 조합된 최소 개수의 테스트 케이스로도 일정 수준의 품질은 보장될 수 있습니다. 그래도 가급적 pairwise 기법과 each choice 기법은 일정 및 투입 리소스가 부족한 상황 등 제한적인 테스트 환경에서만 사용할 것을 권장합니다.
✻ 조합 테스팅 기법 종류
All Combinations Testing
: 입력값의 모든 조합을 모두 테스트
Pairwise Testing
: 입력 값의 모든 쌍의 조합이 TC내에 최소 한번 이상 들어가도록 설계
Each Choice Testing
: 입력 값을 최소 한번 이상 테스트
회원종류별 쿠폰 지급 시스템으로 조합 테스팅 기법 중 Pairwise Testing TC를 작성해보겠습니다.
[조건]
1. 비회원
2. 일반회원
3. VIP회원
4. 배송비쿠폰
5. 신용카드/무통장입금/휴대폰
[결과]
1. 주문처리
2. 주문거부
3. 쿠폰적용
4. 정상결제
[테스트 케이스 도출]
✻ 전략을 반영한 조합 테스팅 기법 활용 예시
테스트 일정 + 투입인력이 부족할 경우, Pairwise 또는 Each Choice 기법으로 테스트 케이스를 설계한다.
테스트 투입 인력에 테스트 전문가 또는 테스트 리더가 포함된 경우, 주어진 입력값 외 경험에 기반하여 의미있고 결함이 발견될 가능성이 높다고 판단되는 입력값(유효/비유효 포함)도 포함하여 테스트 케이스를 설계한다.
테스트 설계 기법을 전략적으로 테스트를 실행하기 위한 활용방법의 목적으로 접근해본 이유는, 이렇게 좋은 설계 기법들이 실무에 잘 사용되지 않는것이 늘 아쉬웠기 때문입니다. 무엇이 문제여서 쉽게 접근하기도, 사용하기도 어려운 것인지..굉장히 오랜 시간 고민했던것 같습니다. 그에 대한 개인적인 해답을 얻은 것이 우리가 너무 방법론적으로만 설계기법을 인식하고 있기때문이 아닌가라는 결론에 이르게 된것이었고, 테스트 전략에 맞춰 테스트를 효율적으로 수행하는 것과 유용한 품질의 제품을 얻기위한 방법으로 설계 기법을 활용했을때 만족스러운 결과를 얻을 수 있었습니다.
별것 아닐수 있지만, 경험을 통해 얻은 바를 공유하고자 한 것은,
그 내용이 너무 자그마하지만(너무 작아서 귀여울 지경인..) 지금도 현장에서 저와 같은 고민을 하고 있을 동료나 후배QA들에게 이 글을 읽기 이전보다 업무를 좀 더 효율적으로 수행할 수 있게되고, 효과적인 결과를 얻을수 있는데 도움이 될 수있지 않을까하는 바램으로 글을 작성하게 되었습니다.
글의 내용을 적용해본 결과 또는 내가 알고 있는 또다른 경험과 노하우가 있는 분이 있다면, 각지에서 함께 일하는 동료들을 위해 노하우를 공유해주시면 좋을것 같네요. 지식은 공유될 때 가치가 있는 것이니까요. :)
