The life of TB

Method & Tools 2009 Summer에 실린 "코딩과 테스팅: 테스터와 프로그래머가 함께 작업하기"라는 제목의 아티클을 번역해 보았다. 많은 것을 생각하게 하는 매우 좋은 아티클이다. 읽고 생각하고 동의해서 실제로 적용해 보는 동료들이 많았으면 하는 바램이다. 이제와서 드는 생각은 우리가 알게 모르게 미신 숭배에 젖어 있었다는 것이다. 무슨 말이냐 하면, V 모델이 소프트웨어 개발을 간단하게 설명하기 위해 옛날에는 유효한 표현이었는지는 모르겠으나, 이제는 그러한 사고가 고착화 되어 소프트웨어 개발 자체가 "단계별"의 과정이라고 아무런 의심없이 생각하게 되었다는 점이다. 문제는 이러한 "단계별"이 가져다주는 효과보다는 이것에서 오는 구조적인 딱딱함과 오래 걸림의 비효율을 깨닫지 못한다는 점이다...

2005년도에 지속가능한 소프트웨어 개발: 애자일 관점 이라는 제목의 책이 출간되었다. 오랜동안 보아오다가 이번에 5장 결함 예방 부분을 QA/테스터가 알아야 하는 내용만 추려 번역해 보았다. 쥔장이 알기로는 저자는 Alias 라는 소프트웨어 회사에서 그래픽 툴을 만들었던 사람으로 알고 있다. 이후로 이 회사는 Autodesk사와 합병 되었으니 지금은 어디에 계신지는 모르겠다. 책 내용은 개발자에 대한 당부와 지침들로 가득차 있지만, 특별히 이 장은 테스트와 밀접한 연관이 있으므로 QA/테스터가 반드시 알아야 하는 내용들로 가득차 있다. 7년 전이므로 애자일의 원형을 볼 수 있지 싶다. 책소개 한 번 한다. 한 권씩 사주시라...http://www.amazon.com/Sustainable-Software..

프리 마인드 (freemind)는 주인장이 가장 애용하는 마인드 맵 SW 입니다. 주인장은 마인드 맵 개념을 접하고는 그 창시자인 토니 부잔의 책까지 샀더랍니다. 이 책은 역서가 2001년에 출판된 것으로 절판으로 더 이상은 살 수가 없더군요. 저는 운좋게 해당 출판사에 마지막 남은 몇 권 (창고에서 잠자고 있었는지, 누런게 표지가 바란 - 그래도 구하고 뿌듯했음, 레어 아이템이니까!)중 거의 마지막 것을 구매했습니다. 사고 보니 이 책은 책읽기 (속독)에 관한 책이더군요. 결국 토니 부잔이 속독 - 빠른 지식 습득의 방법- 을 고민하다가, 최종적으로 나온 것이 마인드 맵 방식으로 사고하고, 그 사고된 결과를 타인에게 이해시키기에 적합한 것 틀을 고안해 낸 것은 아닌지 생각됩니다. 많은 사람들이 마인드 ..

쥔장은 이 책에 상당히 감명 받았으므로, 다시 끌어올려 봅니다. 저자들 소개를 여기에 옮겨보죠. Andreas Spillner is a professor of Computer Science in the Department of Electrical Engineering and Computer Science at Bremen University of Applied Sciences. For more than 10 years, he was president of the German Special Interest Group in Software Testing, Analysis, and Verification of the German Society for Informatics. He is a member of th..

TinyTask provides basic automation (recording and playback). It is a case study in minimalist programming: the entire program is only 29k -- and over 10k are graphics, which means the executable portion is just a few K in size. It was used as the test harness for the "Recording" feature of vTask Studio. New: now includes an EXE compiler! Turn your recordings into standalone programs. If you were..

Rex가 새로운 책을 또 내었나보다. 영어로 된 텍스트를 번역하는 입장에서 이런 저질의 저자가 없다. 이른바 현학적 허세를 맘껏부려 본질을 흐리게 한달까? ISTQB 자격증이 Fo. 레벨을 넘어, Adv. 레벨로 가는 모양인데, 시의 적절한 건지 알 수는 없지만, 역시나 또 책을 내었다. 이 책에 대한 아마존의 서평을 보면 참으로 가관인데... 평가가 정말 극명하게 갈린다... 어떻게 이럴 수가 있는가? 칭찬 일색: Contains alot of good ideas, July 10, 2009 Survival Companion to the ISTQB Syllabus, May 26, 2009 I Found it Helpful, April 28, 2009 VERY VERY HIGHLY RECOMMENDED!!..

Continuous Integration이라는 제목의 책이 역서가 나온 모양이다. 이름하여, 지속적인 통합인데, 사실 당연한 얘기가 안 지켜진다는 것은 그만큼 사람들의 타성과 관성이 무서운 것이며, 다른 방식을 배척하고 고집을 부리는 것이 일견 엔지니어들의 특성 중 하나라고 할 수 도 있을 듯 하다. (모든 사람들의 특성인가? ^^) 아래는 목차... PART I 지속적 통합의 배경: 원칙과 실천 방법 chapter1 시작하기 변경할 때마다 소프트웨어를 빌드하기 개발자 버전 관리 저장소 지속적인 통합 서버 빌드 스크립트 피드백 메커니즘 통합 빌드 머신 지속적인 통합의 특징 소스 코드 컴파일 데이터베이스 통합 테스트 검사 (Inspection) 배포 문서와 피드백 요약 질문 chapter2 지속적인 통합 ..

이 툴은 쥔장이 리소스 변화를 측정하기 위해서 자주 쓰는 툴인데, Home User만 무료이다가 이제 완전히 무료 제품으로 변경된 듯 하다. http://redmondlab.googlepages.com/systemometer 이 툴의 장점이라하면, 장시간 (수일 ~ 수주)의 리소스 변화에 대해서 각각 그 값을 로그로 충실히 남겨준다는 것인데, 물론 윈도우 내부의 PerfMon도 이러한 역할을 하지만, 사용법이 이것이 더욱 간단하고 쉽다. 특히 별 특징 없는 그래프 몇개를 보여주고 마는 것과 달리 수치가 계속 로그로 남기 때문에 그 변화량을 추적하기 너무도 간단하다!

Preface Dedication Part I-A Mathematical Context Chapter 1-A Perspective on Testing 1.1 Basic Definitions 1.2 Test Cases 1.3 Insights from a Venn Diagram 1.4 Identifying Test Cases 1.4.1 Functional Testing 1.4.2 Structural Testing 1.4.3 The Functional Versus Structural Debate 1.5 Error and Fault Taxonomies 1.6. Levels of Testing Chapter 2-Examples 2.1 The Triangle Problem 2.1.1 Problem Statement..

Copyright Preface Organization Audience Acknowledgments Chapter 1. Requirements Phase Item 1: Involve Testers from the Beginning Item 2: Verify the Requirements Item 3: Design Test Procedures As Soon As Requirements Are Available Item 4: Ensure That Requirement Changes Are Communicated Item 5: Beware of Developing and Testing Based on an Existing System Chapter 2. Test Planning Item 6: Understan..

Copyright Advanced Praise for Critical Testing Processes Foreword Acknowledgments Preface Introduction Book Scope Who Should Read This Book? Demystifying Processes Types and Relationships of Critical Testing Processes Critical Testing Processes in Context Sumatra, a Hypothetical Project Terminology On Using This Book To Your Testing Success! Part I. Plan Chapter 1. Start with the Big Picture: Pu..

Chapter 1 - The Testing Process Chapter 2 - Case Studies Section I - Black Box Testing Techniques Chapter 3 - Equivalence Class Testing Chapter 4 - Boundary Value Testing Chapter 5 - Decision Table Testing Chapter 6 - Pairwise Testing Chapter 7 - State-Transition Testing Chapter 8 - Domain Analysis Testing Chapter 9 - Use Case Testing Section II - White Box Testing Techniques Chapter 10 - Contro..

http://www.amazon.com/Engineering-Economics-Prentice-Hall-Computing-Technology/dp/0138221227/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1202625954&sr=8-1 저 유명한 배리 보엠 교수의 클래식 책을 한 권 구매했다. 특이하게도 이것은 국내 중고 책서점에서 구매 했는데, 연륜을 말해 주듯이 상태가 그다지 좋지는 않은 듯. ^^ COCOMO라 불리는 공수 추정에 대한 이론적 근거 이기도 하고, 웬만한 소프트웨어 테스팅 서적에서 이 책 이름을 반드시 보았었다! 고로 구매를 결정! 아마존의 독자 서평을 무단으로 옮겨본다. ^^ Still a classic, January 26, 2004 By Bas (Ams..

세상의 모든 일들은 정도의 차이가 있지만, 서로 관련이 있다. 이러한 차이를 인지하지 못하는 것은 무척이나 대범하여 둔감하던가, 대인과 같아서 소소한 세상일에는 관심이 없거나, 아니면 목표 없는 인생일 것이다. 최초에 이 이론에 대하여 접한 것은 Systematic Software Testing에서 인데, 이것을 가지고 검색을 해보니 구체적인 저간의 배경이 나왔다. 내용을 읽고 나니 흡사 피플웨어 : 정말로 일하고 싶어지는 직장 만들기와 상황이 유사할 수도 있겠다는 생각이 들고, 또 주제도 노동자의 생산성과 관련이 있는등 흥미롭다. 특히나, Systematic Software Testing에서는 이 호손효과를 "테스팅 메트릭과 측정"의 장에서 다루고 있으니, 개념의 확장과 전이가 산업을 넘나들며 이용된다..

http://blogs.msdn.com/imtesty/default.aspx MS 내부의 테스터로 보이는 분의 블로그 내용을 펌한다. ^^ 가장 논란이 되는 주제 중 하나일 듯... ^^ Do testers need programming skills? The debate over whether testers need to at least understand programming concepts is still raging within the discipline. To me this debate is puzzling because it seems to suggest that as a professional, I don't have to really understand or be completely prof..

http://www.zdnet.co.kr/builder/man/etc/0,39031658,39165546,00.htm 요구사항 수집을 위한 10가지 기술 Tom Mochal ( TechRepublic ) 2008/01/29 요구사항을 알지 못하면 솔루션을 만들기가 너무 어렵다(사실은 많은 팀들이 오늘도 그것을 위해 노력하고 있다). 고객으로부터 첫 요구 사항을 얻어 내는 것을 "끌어내기" 단계라고 한다. 요구사항을 수집하는 데 사용할 수 있는 기술은 많이 있다. 각각은 상황에 따라 그 가치가 있고, 고객과 주주들이 원하는 완벽한 그림을 얻기 위한 다중 기술이 필요하다. 몇 가지 접근법에 대해 소개하겠다. #1. One-on-One 인터뷰 요구 사항을 얻기 위한 가장 보편적인 기술은 고객과 함께 앉아서 무..

아마존에서 책으로 팔리고 있는 Performance Testing Guidance for Web Applications이 PDF로 공개되었다. http://www.amazon.com/gp/product/0735625700 http://www.codeplex.com/PerfTestingGuide/Release/ProjectReleases.aspx?ReleaseId=6690 아마도 MS와의 연관이 있어 보이는데, 쥔장이 멋져 보이는 MS에서 나온 소프트웨어 테스팅 관련 material을 다수 읽어보고 느낀 점은 "형식은 있으나 내용은 없음" 이다. ^^ 이 PDF는 다르지 않았으면 좋겠다. (참고로 쥔장은 웹 도메인이 아니다.)

강컴에서 엘프리드 더스틴(Elfriede Dustn)이 저자인 것에 흥미를 느껴 쥔장이 원서를 살펴보던 것이 역서로 나온 것을 보게 되었다. 테스팅과 보안 기술의 영역을 넘나드는 것 같지만, 저자들의 비율로 보아서도 알듯이 기술서에 좀 더 가까울 듯 하다. 혹여나 이 책을 테스팅 일반 서적으로 오인하여 구입하시는 오류가 없으시길... ^^ 제1부 개 론 01 공격 당하기 전에 자신의 약점을 먼저 면밀히 조사하라 : 전통적 소프트웨어 검사를 벗어난 패러다임의 전환 47 ◈ 보안 검사 대 전통적인 소프트웨어 검사 50 _ SQL 주입 공격 패턴 53 ◈ 보안 검사의 패러다임 전환 53 ◈ 고수준 보안 검사 전략 55 _ 오류 주입 공격형 검사 : 탐정으로서 검사자 55 ◈ 공격자처럼 생각하라 57 _ 작업 ..

http://www.etnews.co.kr/news/detail.html?id=200801210141 테스트 효율화 3단계 작전 “테스트 목적이 양산 승인인지 조기 품질 확보인지 명확히 하라. 또 예비 테스트를 진행한 후 본 테스트를 수행하라. 체크리스트를 전략별로 작성하라.” 소프트웨어(SW)기업이 품질을 높이기 위해 테스트 조직을 별도로 두는 사례가 많아졌지만 노하우가 부족해 개발팀과의 불필요한 갈등을 겪는 등의 문제가 제기되고 있다. 최근 소프트웨어 테스트를 보다 효율적으로 수행할수 있는 3단계 해법이 제시됐다. 갈등도 줄이고 테스트와 개발 업무도 개선할 수 있는 방안이어서 관심을 끌고 있다. 국내 테스트 전문가가 머리를 맞대 테스트시 유념할 점을 3단계로 압축한 것. 이 3단계 방안은 테스트 관련..

http://www.zdnet.co.kr/builder/dev/web/0,39031700,39165068,00.htm 멀티브라우저에서의 웹 애플리케이션 테스트 Tony Patton ( TechRepublic ) 2008/01/16 웹 애플리케이션을 인터넷에 제공하는 것보다 복잡한 문제 중 하나는 다른 브라우저에서도 일관된 유저 경험을 확실하게 하는 포괄적인 테스트이다. 다양한 애플리케이션 테스트 방법에 대해 알아본다. 사용할 사람이 누구인가? 웹 애플리케이션을 테스트 할 때 가장 핵심 요인은 어떤 브라우저 플랫폼에서 돌게 할 것인가 아니면 어떤 브라우저 플랫폼이 지원될 것인가에 대한 결정이다. 인트라넷 애플리케이션인 경우에는 브라우저는 좀 더 쉽게 조절되지만, 공공 인터넷은 유저들이 무엇을 사용할 것인가..

http://www.zdnet.co.kr/builder/dev/etc/0,39031619,39165256,00.htm 애플리케이션 제품 개발을 위한 10가지 팁 TechRepublic Staffs ( TechRepublic ) 2008/01/21 개발자들은 보통 예산과 일정 및 비즈니스 요구사항이 정해지면 애플리케이션을 성공적으로 개발하려고 한다. 하지만 개발 시작에서부터 최종 작업까지는 넘어야 할 산이 많다. 프로젝트 수행에서는 애플리케이션에서 제품으로 넘어 가는 과정에서 사용자들의 교육도 잘 되어야 함은 물론이며, 애플리케이션에 대해서도 충분히 이해해야 하는 것들과 같이 예상하지 못한 힘든 시간이 든다. 힘든 시간은 엄청난 스트레스와 수면부족을 수반하기도 한다. 다음은 애플리케이션의 커스터마이징함에 ..

http://www.amazon.com/Software-Development-Computer-Monographs-Informatics/dp/0521337860/ref=sr_1_1?ie=UTF8&s=books&qid=1200916691&sr=8-1 얅은 북렛 형태의 책을 구매했다. 쥔장은 주로 읽던 책에 레퍼런스로 참고된 빈도가 높은 책들을 구매한다. 그런데, 이러한 레퍼런스 건너뛰기로는 계속 책을 사게 되는 듯 하다. ^^ PS) 늘 카메라가 좋지 못해 찍어 올리는 사진이 흐려서 죄송하다. ^^ 찍새 탓일 수도.

소프트웨어 비용 추정의 전문가 Boehm 교수와 각종 소프트웨어 측정 및 매트릭스의 전문가 Basili 교수가 작성. * 소프트웨어를 고객에게 전달한 후 결함을 발견하고 고치는 비용은 요구분석 및 설계 단계에서 하는 것보다 100배가 더 든다. → 되도록 요구분석 및 설계 단계에서 결함을 발견하자. * 현재 소프트웨어 프로젝트에 들어가는 전체 노력의 40~50%는 피할 수 있는 재작업(rework)에 소요된다. → 재작업을 피하는 것은 전체 개발 시간을 줄이는 데 큰 역할을 한다. * 피할 수 있는 재작업의 80%는 전체 결함의 20%로부터 발생된다. → 핵심적이고 파급력이 큰 결함을 파악하는 데 주력해야 한다. * 결함의 80%는 전체 모듈의 20%에서 발생한다. 그리고 모듈의 절반은 결함이 없다. →..

생소한 브라질 언어로 소프트웨어 관련 무료 소프트웨어 목록이 마인드 맵 형태로 정리된 URL을 공개한다. http://www.mindomo.com/view?m=d1535d37f8b0aa6df765a1db90bfa317

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

http://moai.tistory.com/224

Software Testing Foundations의 "테스팅의 심리" 부분을 발췌, 번역해 본다. 2.3 테스팅의 심리 사람들은 실수를 한다. 하지만, 그들은 그것을 허용하는 것을 좋아하지 않는다! 소프트웨어를 테스팅하는 한가지 목적은 소프트웨어나 그 명세 또는 고객의 필요 간의 불일치를 밝혀내는 것이다. 발견된 실패들은 개발자에게 리포트되어야 한다. 이 장은 어떻게 심리적인 문제들을 처리할 것인지를 서술한다. 소프트웨어 개발 작업은 종종 건설적인 액션으로 보인다. 문서나 소프트웨어를 점검하는 작업은 파괴적인 액션으로 보인다. 이러한 인식만으로는 이미 그 작업에 포함된 사람의 작업에 대한 태도가 다르다고 볼 수 있다. 하지만, 이러한 차이는 정당하지 않다. 왜냐하면, "테스팅은 극도로 창의적이며, 지적..

결정 테이블은 Cause-effect graphing이라고도 불리며, 요구사항의 논리와 조건의 발생 조건에 따라서 나올 수 있는 결과를 테이블의 형태로 나열한 것이다. 이것은 단순 논리(Simple binary, Y/N)를 사용해도 매우 거대해지고 복잡해 질 수 있는데, 이를 도와주는 상용 도구들이 있어 소개한다. 당연히 쥔장은 이들과 아무런 관련이 없다. ^^ 1. LogicGem 2. Prologa 공개용 솔루션이 존재한다면 많은 테스터들이 도움을 받을 수 있을 텐데, 좀 더 찾아봐야 하겠지만, 존재하지 않더라.

TMap NEXT를 구매했다. 752 pages나 되니 상당한 볼륨감! 최근에 이슈가 되고 있는 토픽들과 조금은 더 정리된 이론을 접하게 되지 싶다. 목차가 궁금한 분들을 위해 목차를 타이핑하는 수고를 아끼지 않겠다. ^^ Introduction Framework and importance of testing The essentials of TMap Introduction to the processes Master test plan, managing the total test process Acceptance and system tests Development tests Supporting processes Product risk analysis Quality characteristics and test..

어디나 마찬가지이지만, 추정은 어른들의 놀이(?)이다. 초기 단계의 테스트에서는 단순히 실행하는 데만 급급하겠지만, 머리가 크고 경험이 쌓이면 행동에 바로 옮기기 전에 생각을 하고, 계획을 짜고, 검토를 하고 어떤 기대와 예상을 의도하고 그것에 따라 움직인다. ^^ Boris Beizer는 그의 저서 Software System Testing and Quality Assurance에서 다음과 같이 말한 적이 있다. Testing is like playing pool. There's real pool and kiddie pool. In kiddie pool, you hit the balls and whatever pocket they happen to fall into, you claim as the in..