The life of TB

오랜만에 내글을 쓴다. 세상살이가 그렇듯 쥔장도 다 사정이 있었으니 용서를 바란다. ^^ 오늘은 결정 테이블에 대해서 함께 생각해 보도록 하자. 미리 말씀 드리지만, 사람은 완벽할 수 없으니, 이견이 있으신 분은 언제든 한 수 가르침 바란다. (아는체 하려고 태클 거는 분, 글 내용하고 별 관계없는 걸로 태클 거는 분들 사양합니다.) 내용은 테스팅 이론에 대해서 잘 알고 있다고 가정하므로, 아예 처음부터 이게 왜 그래요? 이런 질문은 정중히 사양한다. ^^ 결정 테이블은 두 개로 구성되어 있다. 조건부 (Condition Section) / 액션부 (Action Section) 이 결정 테이블을 사용하기 위한 전제가 있는데, 1) 조건의 순서에 따라서 액션이 달라지지 않는다. 오로지 조건의 trigger..

내글 2010. 7. 2. 14:04

현대의 소프트웨어 테스팅 패러다임을 크게 두 개로 나누면, 스크립티드 테스팅(Scripted Testing)과 탐색적 테스팅 (Exploratory Testing)으로 나눌 수 있다. 스크립티드 테스팅은 다음과 같은 사상에 의거해 수행한다. 실행 이전에 계획을 세우고, 계획된 대로 진행한다. 테스트에 반복성, 객관성, 감사성을 적용한다. (from Lee Copeland) 테스트를 준비하고, 준비한 테스트를 실행한다. 탐색적 테스팅은 직관적(intuitive) 테스팅으로 불리며 다음과 같은 사상에 의거해 수행한다. 근거로 삼을 아무런 테스트 베이시스가 없다. 구조적인 테스트 프로세스를 따르지 않는다. 테스터의 경험과 직관만이 사용된다. 계속적으로 테스트 케이스가 변경된다. 즉, 스크립티드 테스팅과 탐색적..

내글 2007. 12. 24. 14:56

쥔장이 만나본 여러 사람들은 테스트 기법을 알긴 하지만 그걸 어디에 써야 하는지 고민스럽다는 얘기를 많이 한다. 이에 여러 날을 걸쳐 테스트 기법을 연구하던 중 테스트 대상 시스템 (SUT)의 어떤 특징을 만나면 어떤 테스트 디자인 기법을 사용해야 하는지에 대한 가이드를 제시하고자 한다. 주의!: 이 분류는 ISTQB나 BS에서 제시하는 분류도 아니며, 학술적으로 인정받는 분류도 아니다. 단지, 기법을 알고 이를 어디에 써야 하는지 고민하는 분들을 위한 쥔장의 지침으로 이해해 주면 좋겠다. PS) 여러날을 고민 끝에 내린 결론이므로 성급하게 본인의 정리나 발견인양 무단으로 발표하고 다니는 분들이 없었으면 좋겠다.

내글 2007. 12. 2. 16:05

저 유명한 Testing Embedded Software에서 Hans Schaefer가 발표했다고 하면서 아래의 가이드를 제시했다. 결함이 자주 발견되는 지역은 다음과 같다. 복잡한 컴포넌트 완전히 새롭게 작성된 컴포넌트 자주 변경되는 컴포넌트 어떤 툴이나 기법이 최초로 적용되는 컴포넌트 개발 도중에 개발자가 변경된 컴포넌트 극심한 시간적인 압박하에서 작성된 컴포넌트 일반적인 경우보다 더 빈번하게 최적화가 되어야 하는 컴포넌트 이전에 많은 결함이 발견된 컴포넌트 (예를 들면, 이전 릴리즈나 이전 리뷰에서) 수많은 인터페이스를 가진 컴포넌트 또 실패의 확률은 아래의 경우 더 커진다. 경험이 부족한 개발자 유저의 입장을 대변하는 인력의 불충분한 참여 개발 과정에서 품질 보증 활동이 미흡한 경우 저수준 테스트..

내글 2007. 11. 29. 13:23

원고 청탁을 받고 쓴 글이다. 주제는 Testing Principles에 대한 필자의 부연 설명과 생각이다. 이 글을 찾는 모든 사람들에게 도움이 되시길... PS) 원고가 실제 요청자에게 게시된 이후에 공개하도록 하겠다. 본래 목적에 충실해야 하니까. ^^

내글 2007. 9. 7. 09:37

본인의 예전 기고가 ZDNet에 실려서 이에 펌한다. ^^ http://www.zdnet.co.kr/builder/dev/etc/0,39031619,39161120,00.htm

내글 2007. 9. 5. 19:29

테스트 플랜 (test plan)에 대해서 오해도 많고 실수도 많은 것 같다. 계획을 문서화 한다는 것은 어느 산업 분야나 이슈이며 어려운 작업임에는 틀림이 없는 것 같다. 이에 QA엔지니어가 테스트 플랜을 작성하는 데 있어 "블랙 박스"의 관점으로 접근할 때 필요한 내용을 서술해 보겠다. 인수 테스팅 상황 상용 어플리케이션이라면 포장지를 뜯고 사용자 매뉴얼을 읽으며 CD(혹은 DVD)를 트레이에 집어 넣으면서 시작하게 될 것이다. 기업용으로 특화된 어플리케이션이라면 해당 설치 예정 부서의 네트워크 망을 이용해서 어딘가의 웹서버에서 파일을 다운로드 받아 본인들이 직접 설치하거나 또는 TCO Stream 등의 전사적 PC 제어 소프트웨어를 통해 자동 다운로드 후 설치 과정이 사용자 모르게 진행되는 시나리오..

내글 2007. 8. 2. 10:08

QA 부서와 그가 생산한 리포트를 받고 최종 결과 리포트의 의미를 전달 받는 사람들 간에 용어의 정의부터 달라 혼선을 겪는 경우가 많다. 따라서, 버그의 성질을 표시하는 중요 속성에 대해서 정의하고 판단 기준으로 삼는 것이 바람직하다. 버그(결점) 심각도는 버그의 심각성을 결정하는데 반해, 버그 중요도는 버그 긴급성 또는 수정의 촉박함을 결정한다. 영문으로는 Severity / Priority로 표기하며, 심각도는 단순히 심각한 정도(시스템이나 기능에 미치는 영향)만을 나타내며, 중요도는 심각도와 상관없이 단순히 수정의 시급성 및 그 버그의 최종적인 영향력 및 파괴력만을 의미하며 여기서 파생된 개념이 수정 작업의 실행 및 반영시기의 정도이다 . 이 두가지를 혼동하여 사용하고, 심한 경우 구별없이 버그를 ..

내글 2007. 5. 30. 13:53