소원의 나무라는 기법이 있습니다.
아마 여러분은 한번도 들어보신적이 없는 기법일 것입니다.
왜냐하면 이 기법은 제가 만들어낸 기법이기 때문입니다. 제약이론의 사고 프로세스의 기본 뼈대를 응용하여 이 기법을 만들어서 사용한지 벌써 2년정도가 되었습니다.
아주 예전에 UX Camp Seoul에서 발표했던 적도 있지만 아마 기억하시는 분은 거의 없으실 것입니다.
기본적인 내용은 옛날 옛적 제 글을 보시면 아주 조금 도움이 되실 것입니다.
만드는 사람이 행복해야 쓰는 사람도 행복하다.(소원의 나무 - UXcampSeoul 발표자료)
이번에 모처에 강의할 교육자료를 만들면서 제가 만든 이 기법으로 테스트 케이스를 만드는 방법을 PPT 자료로 만든것을 공유해볼까 합니다.
해당 강의가 진행될 확률이 적어져서 이왕 만든 자료를 그냥 가지고 있는 것도 아깝고, 혹시라도 관심을 가지고 써주시는 분이 계실지도 모른다는 생각에 공유를 해봅니다.
관심 있으신 분께서는 아낌없는 피드백을 주시면 고맙겠습니다.
사실 '소원의 나무'는 기법이라고 부르기도 좀 부끄럽습니다.
이 기법이 어디에선가 보장성이 검증 받은 것도 아니고 어떠한 논리적인 배경이나 논문 등에 소개된 적도 없기 때문에 좀 부끄럽기는 합니다. 하지만 2년 동안 제가 써본바로는 꽤 유용하다고 생각되는 기법입니다.
저는 주로 탐색적 테스팅과 같은 활동에서 주로 사용하고 있습니다.
어쩌면 탐색적 테스팅이라는 방법론에 딱 부러지게 명확한 설계 기법이 없는 상황에서 이 기법이 분명 유용하다는 생각도 해봅니다.
자, 그럼 사설이 너무 길어졌으므로 바로 '소원의 나무'로 테스트 케이스 만들기를 진행하도록 하겠습니다.
소원의 나무로 테스트 케이스를 만드는 순서는 위와 같습니다.
가장 중요한 포인트는 제약조건을 식별하는 것입니다.
예제로 안드로이드 마켓에서 구할 수 있는 'iPlayer'라는 앱을 이용했습니다.
기존에 기능리스트가 존재하는가와 관계 없이 우선 제품을 사용하면서 기능리스트를 작성합니다.
만약 기능리스트가 있다면 해당 기능리스트와 작성한 기능리스트를 비교 검증하면 좋습니다.
만약 기능리스트가 없다면 작성한 기능리스트는 개발자 등의 리뷰를 거치는 것이 좋습니다.
여러 기능 중에서 반복재생 기능에 대하여 작성한 초기 시나리오입니다.
여기서 중요한 것이 저 시나리오만으로는 실제로 결과값을 확인할 방법이 없기 때문에 결과값을 확인하기 위한 제약조건을 식별하고 시나리오를 확장하는 것이 이 기법의 핵심입니다.
위의 빈칸에 들어갈 내용이 무엇일까요?
도출된 제약 조건을 포함하여 시나리오를 확장합니다.
그리고 확장된 시나리오에 대하여 동일한 방식으로 제약 조건을 찾습니다.
위 빈칸과 검증식은 여러분이 직접 해보시기 바랍니다.
제약 조건을 반복해서 도출하면서 시나리오를 확장하다보면 결국에는 테스트 데이터에 도달하게 됩니다.
이 때 테스트에 필요한 테스트 데이터, 테스트 환경 등을 정합니다.
정해진 테스트 데이터와 테스트 환경 등과 시나리오를 결합하면 테스트 케이스가 완성됩니다.
테스트 케이스는 예외 흐름까지 고려해서 작성하도록 합니다.
소원의 나무에 대한 소개는 여기까지입니다.
이 기법은 확실히 테스터의 역량에 따라 테스트 케이스의 품질에 대한 편차가 클 수밖에 없습니다.
반면에 그러한 편차를 보정해줄 도구는 취약한 편이고 대체적으로 그러한 편차 보정을 집단 지성의 힘을 빌리는 형식을 취하고 있습니다.
시간은 없고 좀 더 논리적으로 체크리스트나 테스트 케이스를 작성하고 싶으신 분들은 한번 적용해 보시기 바랍니다.
아마 여러분은 한번도 들어보신적이 없는 기법일 것입니다.
왜냐하면 이 기법은 제가 만들어낸 기법이기 때문입니다. 제약이론의 사고 프로세스의 기본 뼈대를 응용하여 이 기법을 만들어서 사용한지 벌써 2년정도가 되었습니다.
아주 예전에 UX Camp Seoul에서 발표했던 적도 있지만 아마 기억하시는 분은 거의 없으실 것입니다.
기본적인 내용은 옛날 옛적 제 글을 보시면 아주 조금 도움이 되실 것입니다.
만드는 사람이 행복해야 쓰는 사람도 행복하다.(소원의 나무 - UXcampSeoul 발표자료)
이번에 모처에 강의할 교육자료를 만들면서 제가 만든 이 기법으로 테스트 케이스를 만드는 방법을 PPT 자료로 만든것을 공유해볼까 합니다.
해당 강의가 진행될 확률이 적어져서 이왕 만든 자료를 그냥 가지고 있는 것도 아깝고, 혹시라도 관심을 가지고 써주시는 분이 계실지도 모른다는 생각에 공유를 해봅니다.
관심 있으신 분께서는 아낌없는 피드백을 주시면 고맙겠습니다.
사실 '소원의 나무'는 기법이라고 부르기도 좀 부끄럽습니다.
이 기법이 어디에선가 보장성이 검증 받은 것도 아니고 어떠한 논리적인 배경이나 논문 등에 소개된 적도 없기 때문에 좀 부끄럽기는 합니다. 하지만 2년 동안 제가 써본바로는 꽤 유용하다고 생각되는 기법입니다.
저는 주로 탐색적 테스팅과 같은 활동에서 주로 사용하고 있습니다.
어쩌면 탐색적 테스팅이라는 방법론에 딱 부러지게 명확한 설계 기법이 없는 상황에서 이 기법이 분명 유용하다는 생각도 해봅니다.
자, 그럼 사설이 너무 길어졌으므로 바로 '소원의 나무'로 테스트 케이스 만들기를 진행하도록 하겠습니다.
소원의 나무로 테스트 케이스를 만드는 순서는 위와 같습니다.
가장 중요한 포인트는 제약조건을 식별하는 것입니다.
예제로 안드로이드 마켓에서 구할 수 있는 'iPlayer'라는 앱을 이용했습니다.
기존에 기능리스트가 존재하는가와 관계 없이 우선 제품을 사용하면서 기능리스트를 작성합니다.
만약 기능리스트가 있다면 해당 기능리스트와 작성한 기능리스트를 비교 검증하면 좋습니다.
만약 기능리스트가 없다면 작성한 기능리스트는 개발자 등의 리뷰를 거치는 것이 좋습니다.
여러 기능 중에서 반복재생 기능에 대하여 작성한 초기 시나리오입니다.
여기서 중요한 것이 저 시나리오만으로는 실제로 결과값을 확인할 방법이 없기 때문에 결과값을 확인하기 위한 제약조건을 식별하고 시나리오를 확장하는 것이 이 기법의 핵심입니다.
위의 빈칸에 들어갈 내용이 무엇일까요?
모범답안 보기
도출된 제약 조건을 포함하여 시나리오를 확장합니다.
그리고 확장된 시나리오에 대하여 동일한 방식으로 제약 조건을 찾습니다.
위 빈칸과 검증식은 여러분이 직접 해보시기 바랍니다.
제약 조건을 반복해서 도출하면서 시나리오를 확장하다보면 결국에는 테스트 데이터에 도달하게 됩니다.
이 때 테스트에 필요한 테스트 데이터, 테스트 환경 등을 정합니다.
정해진 테스트 데이터와 테스트 환경 등과 시나리오를 결합하면 테스트 케이스가 완성됩니다.
테스트 케이스는 예외 흐름까지 고려해서 작성하도록 합니다.
소원의 나무에 대한 소개는 여기까지입니다.
이 기법은 확실히 테스터의 역량에 따라 테스트 케이스의 품질에 대한 편차가 클 수밖에 없습니다.
반면에 그러한 편차를 보정해줄 도구는 취약한 편이고 대체적으로 그러한 편차 보정을 집단 지성의 힘을 빌리는 형식을 취하고 있습니다.
시간은 없고 좀 더 논리적으로 체크리스트나 테스트 케이스를 작성하고 싶으신 분들은 한번 적용해 보시기 바랍니다.
댓글
댓글 쓰기