기본이 바로 선 나라 » 테스트

Test 관련 Groups & Blog

정의의소 — Wed, 26 Nov 2008 08:40:02 +0000

테스트 관련 Groups는 어떤 곳에 참여하시나요?

알고 계시는 테스트 관련 Blog는 어떤 것이 있으신가요?

댓글이나 트랙백 주시면 업데이트 하겠습니다.

(사이트는 너무 많아서 다음에 찬찬히 정리해 보죠.)

Groups

http://tech.groups.yahoo.com/group/AgileEmbedded/
: 테스트는 아니지만 테스트부터 Embedded 업계에 있는 Agile 실천가들의 고민이
올라옵니다.

http://groups.yahoo.com/group/testdrivendevelopment/
: TDD 관련된 내용이 많이 올라옵니다. 그래서 Unit Test에 대한 질문들도 많이 올라오죠

http://groups.yahoo.com/group/Testingkings/
: 테스팅 전반적인 내용이 올라옵니다.

http://groups.google.co.kr/group/comp.software.testing
: 테스팅 전반적인 내용이 올라옵니다.

http://groups.google.co.kr/group/googletestframework
: Google C++ Testing Framework 그룹스 입니다.

https://lists.sourceforge.net/lists/listinfo/unittest-cpp-devel
: 그룹스는 아니지만 UnitTest++의 메일리스트 입니다.

Blog

http://googletesting.blogspot.com/
: 구글 테스팅 블로그죠.
http://www.aphids.com/agiletesting/
: Stan Taylor(Boland 에서 QA Architect로 근무)씨가 Agile Testing 관련 경험을 올리고있다.
http://xelion.pe.kr/
: 리얼 네트웍스에서 QA 관련 업무를 하시는 것 같다.
http://jooyunghan.da.to/blog/
: Agile과 Testing 쪽으로 업무를 하신다. 회사는 ^^
http://alones.kr/blog
: 테스팅 관련 업무를 한다. ^^;
http://testcrunch.kr
: 아직 활성되지 못한 테스팅 팀 블로그이다. (못난 관리자 때문이다. ㅡㅡ;)
http://techbard.tistory.com/
: 지금은 네이버에 계신 신재문님의 블로그이다.

너무 많은 정보들을 필요한 정보만 뽑아 내기가 혼자서는 쉽지가 않죠. 저는 RSS 리더에 등록하고 제목으로 읽어야 하는 것을 결정하고 필요에 따라서 따로 정리를 합니다.
테스트 관련 정보들을 수집하는 것을 목표로 가벼운 포스팅해 봅니다. 테스트 관련 정보들을 주간 단위로 정리해서 포스팅하는 것도 생각했었는데 최근에 업무가 자주 바뀌다 보니 그러지도 못햇네요. ㅡㅡ;

Share and Enjoy:

탐험적 테스팅 (Exploratory Testing)

정의의소 — Tue, 18 Nov 2008 00:48:15 +0000

제임스 바흐가 최근에 한국에 와서 쾌속 소프트웨어 테스팅 교육을 하였습니다. 저는 참석하지 못했습니다만 최근에 회사 내에서 이야기가 나오는 것 같아 정리해 봅니다.

탐험적 테스팅이란?
테스트 설계와 실행이 함께 이루어지는 테스팅을 말합니다.

스무고개를 할 때 미리 스무개의 질문을 모두 정해놓고 답을 듣는 것이 아니고, 하나의 질문을 묻고 거기에 대한 답을 들은 다음, 거기에 기반해 다음 질문을 생각해 내고 하면서 피드백의 순환고리를 돌며 진행하는 것이죠. – 김창준

최근 회사 내에서 품질 개선의 방법으로 관심을 받고 있는 것 같습니다. Agile한 테스트 방법이라고도 알려져 있는 탐험(탐색)적 테스팅이 어떤 것인지는 아래 제임스 바흐의 “Becoming a Software Testing Expert” 강연 동영상을 참고하시기 바랍니다.
탐험적 테스트 관련 자료는 satisfice.com에서도 받으실 수 있다고 합니다.

탐험적 테스팅은 적은 비용으로 높은 효과를 낼 수 있다고합니다. 저는 비용에 관한 것은 측정?해 보지 않아 잘 모르지만 학습과 테스트에 대한 집중의 효과는 크다고 생각합니다.

반복을 통해서 테스트 프로세스를 지속적으로 개선하고 테스터가 테스트 작업 자체에 더 집중하도록 하는것이 탐험적 테스팅에서 정말 중요한 포인트 같습니다. - 황상철

저는 회사 내에서 탐험적 테스팅이 테스트 케이스 없이 테스트할 수 있는 것이라는 오해는 없었으면 좋겠습니다. 어디다 이야기 할 곳이 없어 이렇게 블로그에 정리해봅니다.

값싼 인력으로 탐험적 테스팅을 하면 효과있을꺼라고 착각하시는 테스트 매니저, 관리자, 경영자분들… 아니거든요? 함께 수반해야 하는 것들이 많거든요? 쫌… 공부 좀 합시다. 귀를 열어 놓으시던지요.

Share and Enjoy:

테스터가 바라본 크롬(Chrome)

정의의소 — Sun, 07 Sep 2008 02:21:06 +0000

크롬에 대한 평가는 많은 블로거들이 해 주셨다. 그러나 그 기능의 대단함도 있지만 이것을 어떻게 개발하고 테스트를 하는가를 보면 더 대단하다는 것이 느껴진다.

테스팅업무를 하고 있으니 테스터 관점에서 크롬을 바라보면 대단하다고 할 수 밖에 없다.(그래도 버그가 많은 건 어쩔 수 없다.ㅡ,.ㅡ; 그 과정을 보자..)

구글 개발자 센터에서 살펴보면 모두 다 자동화 되어 있고, Unit Test Case도 각 각 다 있다.

Performance Test나 UI Test등에도 많은 신경을 썼다. 몇 가지는 좋은 아이디어를 얻을 수 있었다.

현재 진행하고 있는 테스트 항목은 아래와 같다.

automated_ui_tests
base_unittests - Test the base module
installer_unittests - Test the Chromium installer
interactive_ui_tests - Tests some of the interactive UI elements, such as the find-in-page feature and tab dragging.
ipc_tests - Tests the IPC subsystem for communication between browser, renderer, and plugin processes.
mini_installer_test - Tests the mini installer.
net_perftests - Performance tests for the disk cache and cookie storage.
net_unittests - Tests the network module.
npapi_layout_test_plugin - A NPAPI plugin used with the layout tests.
npapi_test_plugin - A NPAPI plugin used with the plugin_tests and ui_tests.
perf_tests - Tests performance for some submodules – JSON, Safe Browsing, URL parsing, etc.
plugin_tests - Tests the plugin subsystem.
reliability_tests - Tests to verify Chromium recovery after hanging or crashing of renderers.
security_tests - A set of security tests for Chromium.
selenium_tests - A driver for running selenium tests.
startup_tests - Test startup performance of Chromium.
tab_switching_test - Test tab switching functionality.
test_chrome_plugin
test_shell - Test Shell is a standalone application for running the renderer (WebKit).
test_shell_tests - A collection of tests within the Test Shell.
ui_tests - The kitchen sink for UI tests. UI tests are tests which launch Chromium and control it through Automation.
unit_tests - The kitchen sink for unit tests. These tests cover several modules within Chromium.

시간 날 때마다 하나의 항목씩 살펴보고 글을 포스팅 하고자 한다.

Unit Test는 GTest 를 사용한다.
: 역시 xUnit Test Framework는 자신의 시스템(입맛)에 맞게 직접 만들어 사용하는게 최고다. (Google에서는 Test Harness라고 한다. 사실 harness가 맞다. Test Framework에 대한 이야기는 다음에 다시 한 번 해 보자)

UI Test를 위해서는 자체 제작한 Tool을 사용한다고 한다.
: 아래 image diff가 있는 것을 보면 Capture & Playback 을 사용하는 듯 하다.

Image를 비교하기 위하여 bitmap 비교하는 툴을 사용한다고 한다.
: Test 자동화에서 이미지 비교는 한계가 있다. 어떻게 사용하는지 좀 더 깊게 살펴봐야겠다.
이슈 관리는 자체 시스템을 사용하고 있다. (이게 Google Code에 있는 건가? ^^)
: 필요 항목만 간략하게 구성해 놓았다. 현재 Open된 이슈만 1192개 이다.
Tester Section을 따로 가지고 있다.
: 버그 리포트 가이드 라인, 테스트 플랜, 그 외 관련 문서들이 정리되어 있고 업데이트 되어 있다.

구글 크롬 기능에 대해서 많은 찬사가 있었다. 그러나 내가 이때까지 본 오픈소스 중에서 가장 체계적인 테스트와 툴과 문서가 있는 프로젝트이다. 조금 더 깊게 살펴볼 필요가 있어서 연속된 포스팅으로 이어질 것 같다. 테스트도 잘하는 구글… 최고다.. 근데 버그가 많은 건 어쩔 수 없다. ㅎㅎ

Share and Enjoy:

테스트는 누가해야 하는가?를 읽고…

정의의소 — Sun, 03 Feb 2008 15:23:41 +0000

TestCrunch에 올라온 “테스트는 누가해야 하는가?”에 대한 트랙백을 위한 글 입니다.

Nikkei Electronics 2007년 4월 23일 자에 나온 “공들여 만드는 소프트웨어, 검증하기 쉬운 설계로“라는 제목의 자료에도 나오는 그림 중에 이런 말이 있습니다.

” 아니 이렇게 테스트하기 어렵게 설계하면 어떻게 해요!”
- 테스터

아직 우리나라 대부분의 업체에서는 테스터가 이렇게 이야기 할 수 있는 곳은 없을 것입니다.

“아니 이렇게 생산하기 어렵게 설계하면 어떻게 해요!”
- 생산담당자

생산하기 힘드니 다시 설계하라는 이야기를 하는 곳은 있을 수도 있을 겁니다.
생산을 고려해서 설계를하고 개발하라는 것입니다.

Application/Game 개발자분들은… 디자이너분들과 이런 이야기 자주 나누지 않습니까?

“이런 디자인/컨셉은 개발하기 힘들다… 당신들이 개발을 안해봐서 그런가 본데… 이건 너무 힘들어요…”
- 개발자

테스트도 개발의 한 부분이고 중요하다는 것을 개발자가 더 잘 알고 있을 것입니다.
그러나 오랜 관습과 바쁘다는 현실에서 변화하기가 쉽지 않은 것 같습니다.

개발자 테스트하면 자주 등장하는 TDD는 테스트보다는 Design적인 측면이 더 중요하게 생각되는 것 같습니다.
Test Driven Development 보다는 Design의 의미가 강하다고 생각됩니다.
TDD에 의해서 모든 테스트가 끝나지 않습니다. TDD는 품질에 대한 최소한의 요구사항이라고 생각합니다.

“Clean code that works!"- Test Driven Devlopment 에서 Kent Bect

TDD는 분석/설계 도구이지 테스트 도구가 아닙니다. TDD를 통해서 얻는 Code Coverage는 TDD의 목적이 아니라고 생각됩니다. 부수적인 이득이라고 봐야겠죠.
TDD의 궁극의 목적은 “Clean Code That Works”라고 봅니다.

테스트를 위하여 API 뿐만 아니라, 시스템 전체를 고려한 설계와 개발이 이루어지고 함께 테스트가 진행되어야 더욱 빠른 개발을 할 수 있다고 생각합니다.

Share and Enjoy:

‘행위의 중복’을 없애는, 사람을 위한 자동화

정의의소 — Sat, 12 Jan 2008 00:28:59 +0000

프로젝트를 진행함에 있어 가장 중요한 요소 중의 하나가 자동화라고 생각합니다.

IBM developerWorks의 자동화 관련된 내용을 오픈마루 강규영님께서 정리해 주셨네요.

진행하고 있는 프로젝트와 비교해 보시고 적용 점을 찾아 보시면 많은 도움이 있을 것 같습니다.

제가 올해 부터 진행하는 프로젝트에 하나 씩 적용하면서 어떻게 적용하였고 어떤 장,단점이 있는지를 정리하려고 합니다.

인프라(툴), 프로세스, 테스트(기법)의 내용이 주된 내용이 될 것 같습니다.

똘똘하게 일합시다.(Work smart) ^,.^;

[#M_ more.. | less.. |

필자 | 강규영, 엔씨소프트 오픈마루 스튜디오 웹서비스 개발팀 alankang@openmaru.com

2007년 10월 30일
2008년 01월 08일 수정

어느 정도 경험이 있는 개발자라면, 혹은 마틴 파울러의 "리팩토링"을 읽어본 개발자라면, 소스 코드 중복이 왜 문제이며
중복을 어떻게 하면 효과적으로 제거할 수 있는지 잘 알고 있을 것입니다. 하지만 제거해야 할 중복은 소스 코드에만 있는 것이
아닙니다.

소프트웨어를 빌드할 때마다 반복적으로 입력하는 명령어들, 코드를 수정한 후 수동으로 수행하는 반복적 테스트, 주기적으로 작성하는 각종 리포트 등은 소스 코드 중복은 아니지만 "행위의 중복"이며 제거해야 할 대상입니다.

이 연재는 다양한 자동화 기법을 통해 이러한 "행위의 중복"을 제거하는 효과적이고 검증된 방법들을 상세히 설명합니다. 이를 통해
반복적이고 지루한 작업은 컴퓨터에 떠넘기고, 여러분은 더 창의적이고 가치 있는 일에 집중할 수 있게 될 것입니다.

1편: 빌드 스크립트에서 나는 “악취(smell)” 제거하기 (한글)

빌드 스크립트에 대하여 "악취(bad smells)" 개념을 적용하고 아홉 가지 꼭 피해야 할 악취들을 소개합니다.

2편: 연속 테스팅 (한글)

연속 테스팅(continuous testing)을 소개합니다. 연속 테스팅이란 저장소의 코드가 바뀔 때마다 자동으로 테스트를 수행하게 하는 방식으로, 코드 수정에 대한 피드백 주기를 크게 줄여줄 수 있습니다.

3편: Eclipse 플러그인으로 코드 품질 높이기 (한글)

코딩 표준, 코드 중복, 코드 커버리지, 의존성 분석, 복잡성 감시 등 이른바 "5대 코드 분석 영역"을 설명하고, 다양한 정적 코드 분석 플러그인을 통해 이러한 분석을 자동으로 수행하는 방법을 소개합니다.

4편: Continuous Integration 서버 선택하기 (한글)

지
속적 통합(continuous integration)을 위한 오픈 소스 소프트웨어들을 소개하고 각각의 특징을 분석합니다. 지속적
통합은 앞서 소개된 연속 테스팅 등과 함께 행위의 중복을 제거하고 피드백 주기를 줄이기 위해 필수적인 실천법(practice)
중 하나입니다.

5편: Continuous Inspection (한글)

앞
서 소개한 코드 분석 기법들을 통해 자동으로 코드 검사를 수행하여, 이를 통해 짝 프로그래밍, 주간 코드 리뷰 등을 통해 얻을
수 있는 유용함을 얻을 수 있는 방법을 소개합니다. 저자는 한편, 모든 수동 소스 검사를 자동화할 수는 없고 다만 수동 소스
검사 과정을 더 효율화한다는 개념으로 접근해야 한다는 것을 강조합니다.

6편: 지속적인 피드백 (한글)

다
양한 소프트웨어, 하드웨어 장치를 통해 자동화 결과에 대한 피드백을 받는 방법을 소개합니다. 저자가 강조하는 것은 이 연재에서
소개되는 모든 장치를 적용하는 것이 아니라 상황에 맞는 적절한 장치를 선택적으로 적용해야 한다는 점입니다.

7편: 아키텍처 건전성 (한글)

아키텍처 수준에서의 디자인 문제를 정량적으로 측정하는 방법, 앞서 소개한 정적 소스 분석 도구들을 이용하여 이러한 검사를 자동으로 수행하는 방법, 그리고 디자인 문제가 발생하면 빌드 프로세스가 멈추도록 하는 방법 등을 소개합니다.

8편: Raven으로 자바 프로젝트 구현하기 (한글)

Ruby를 기반으로 구현된 빌드 플랫폼인 Raven을 사용하여 빌드 스크립트 내에서 Ruby의 힘과 유연성을 확인해 봅시다.

9편: Continuous Integration 반패턴(anti-pattern) (한글)

자
동화 전문가이자, Continuous Integration: Improving Software Quality and
Reducing Risk 의 공동 저자인 Paul Duvall이 CI 반패턴(anti-pattern)을 설명하고, 이를 피하는
방법을 설명합니다.

_M#]

Share and Enjoy:

Continuous Integration

소프트웨어 테스팅 법칙 293가지

정의의소 — Mon, 05 Nov 2007 09:52:15 +0000

팀에 후배가 들어오면 꼭 한 번 읽어 보라고 하는 책 중에 한 권입니다.

이론적인 것을 공부해야한다는 부담담 대신에 가볍게 그리고 테스트가 무엇이고 테스터는 어떻게 해야하는지에 대해서 간략하게 이해할 수 있는 책인 것 같습니다.

아래 제목만 보시고 흥미 있으시면 책을 읽어 보시고 아니면 그정도는 아니다 싶으시면 dejavu_blog에 추가로 요약된 글을 보시면 좋을 것 같습니다.

근데 내 책은 어디갔지? 작년 신입 사원인가? 재작년 신입사원한테 빌려 준 것 같은데… ㅡㅡ;

제1장 테스터의 역할

법칙 1 테스터는 프로젝트의 전조등이다. (가장 좋아하는 말…^^)
법칙 2 임무에 따라 행동이 결정된다.
법칙 3 테스터는 많은 고객들에게 서비스를 제공한다.
법칙 4 고객이 가치 있다고 생각하는 “버그”를 발견하라.
법칙 5 중요한 버그를 신속하게 찾아내라.
법칙 6 프로그래머와 함께 진행하라.법칙 7 모든 것에 의문을 가져라. 그러나 밖으로 크게 드러내지는 마라.
법칙 8 테스터가 실패에 초점을 맞추면 고객은 성공에 초점을 맞출 수 있다.
법칙 9 모든 버그를 찾아낼 수는 없다.
법칙 10 “완전히” 테스트한다는 말을 조심하라.
법칙 11 테스트를 통해서 품질을 보장할 수는 없다.
법칙 12 문지기가 되지는 마라!
법칙 13 테스트에서 “내 업무가 아니야”의 논리를 조심하라.
법칙 14 프로세스 개선 그룹이 되는 것을 조심하라.
법칙 15 테스트를 잘 수행하기 위하여 필요한 항목들을 모든 사람들이 이해할 것이라고 기대하지 마라.

제2장 테스터의 사고방식

법칙 16 테스트는 응용 인식론이다.
법칙 17 인식론을 배우면 테스트를 잘 수행할 수 있다.
법칙 18 테스트는 인지심리학에 바탕을 둔다.
법칙 19 테스트는 당신의 머리 속에 있다.
법칙 20 테스트에는 원하는 결과와 실제 결과의 단순 비교가 아닌 추론이 필요하다.
법칙 21 기술적, 창조적, 비판적, 실질적 사고를 하는 사람이 뛰어난 테스터이다.
법칙 22 블랙박스 테스트는 알지 못함을 기반으로 테스트를 실행하는 방법이다.
법칙 23 테스터는 여행객 이상이다.
법칙 24 모든 테스트는 질문에 대한 대답을 찾는 과정이다.
법칙 25 모든 테스트는 모델을 기반으로 수행된다.
법칙 26 육감은 좋은 출발점이나 결론은 형편없다.
법칙 27 반드시 직접 테스트해보아야 한다.
법칙 28 답사에는 다양한 사고가 필요하다.
법칙 29 판독을 위하여 가정적 귀납법을 이용하라.
법칙 30 제품을 평가할 때 추측과 반박의 논리를 사용하라.
법칙 31 요구조건은 중요한 사람에게 품질과 조건이다.
법칙 32 회의, 추론, 참조를 통해 요구사항을 알아내라.
법칙 33 명시적인 명세서뿐만 아니라 암묵적인 명세서도 사용하라.
법칙 34 “동작한다”는 말은 사실 적절한 수준으로 특정 요구조건을 만족하는 것처럼 보인다라는 의미이다.
법칙 35 결국 우리가 가지는 모든 것은 제품에 대한 인상이다.
법칙 36 ‘테스트’와 ‘테스트하다’를 혼동하지 마라.
법칙 37 복잡한 제품을 테스트할 경우: 시도해보고 그만두기
법칙 38 테스트에 대한 아이디어를 신속하게 떠올리기 위하여 시행착오법을 사용하라.
법칙 39 편향성을 피할 수는 없지만 관리할 수는 있다.
법칙 40 자신이 멍청하다는 사실을 알고 있다면 실제로 멍청한 짓을 잘하지 않는다.
법칙 41 버그를 놓쳤을 때, 버그가 의외의 것이라서 놓쳤는지 아니면 단순히 전략의 자연스러운 결과였는지를 확인하라.
법칙 42 혼란스러움도 테스트 도구이다.
법칙 43 참신한 시각이 오류를 발견한다.
법칙 44 이해하지 못한 채 절차를 따라하지 마라.
법칙 45 테스트 절차를 작성할 때 “1287”을 피하라.
법칙 46 테스트 과정에서 중요한 성과 중 하나는 날로 나아져 가는 영리한 테스터이다.
법칙 47 다시 창안하지 못한다면 테스트를 자유로이 구사할 수 없다.

제3장 테스트 기법

법칙 48 테스트는 테스터, 범위, 잠재적 문제, 행위, 평가에 중점을 두는 기법들로 구분할 수 있다.
법칙 49 누가 테스트를 수행하는가에 중점을 둔 사람 중심 기법
법칙 50 무엇을 테스트하는가에 중점을 두는 범위 기반 기법
법칙 51 왜 테스트를 하는가(테스트에 대한 위험)에 중점을 둔 문제 중심 기법
법칙 52 어떻게 테스트를 수행하는가에 중점을 둔 행위 기반 기법
법칙 53 테스트를 통과했는지의 여부를 어떻게 알 것인가에 중점을 두는 평가 기반 기법
법칙 54 생각하는 방식에 따라 기법이 분류된다.

제4장 버그 보고

법칙 55 버그 보고서의 질이 곧 테스터의 능력을 말해준다.
법칙 56 버그를 보고해야 해당 버그가 고쳐진다.
법칙 57 버그 보고서를 효과적인 세일즈 도구로 만들어라.
법칙 58 버그 보고서는 당신을 대표하는 것이다.
법칙 59 시간을 들여서 버그 보고서의 가치를 높여라.
법칙 60 이해 당사자도 버그를 보고할 수 있다.
법칙 61 다른 사람이 작성한 버그 보고서를 옮겨 적을 때에는 조심하라.
법칙 62 품질 격차도 버그로 보고하라.
법칙 63 몇몇 이해 당사자들은 버그를 보고할 수 없다. 사람이다.
법칙 64 버그가 쟁점이 될 경우, 이 버그 때문에 영향을 받게 될 이해 당사자의 관심을 이끌어내라.
법칙 65 프로그래머의 성능을 모니터하기 위하여 버그 추적 시스템을 절대로 사용하지 마라.
법칙 66 테스터의 성능을 모니터하기 위하여 버그 추적 시스템을 사용하지 마라.
법칙 67 결함은 즉시 보고하라.
법칙 68 명백한 버그가 이미 보고되었을 것이라고 추측하지 마라.
법칙 69 설계 오류를 보고하라.
법칙 70 극단적으로 보이는 버그들이 보안상 잠재적인 취약점이 된다.
법칙 71 드문 경우를 드물게 만들어라.
법칙 72 사소한 버그일지라도 보고해서 고쳐야 할 가치를 가진다.
법칙 73 심각도와 우선순위의 차이를 명확히 이해하라.
법칙 74 실패는 오류의 현상이지, 오류 그 자체는 아니다.
법칙 75 따라하기 테스트를 통해 사소한 오류를 발견하라.
법칙 76 재현 불가능한 오류를 항상 보고하라: 이 오류는 시한폭탄이 될 수 있다.
법칙 77 재현되지 않는 버그도 재현된다.
법칙 78 버그 보고서의 처리 비용을 생각하라.
법칙 79 도구나 환경에 관한 버그는 특별히 취급하라.
법칙 80 프로토타입이나 초기의 개인적인 버전에 대한 버그는 보고하기 전에 물어보라.
법칙 81 버그 보고서를 중복 작성하면서 스스로 문제를 고칠 수도 있다.
법칙 82 모든 버그는 보고되어야 할 가치를 지니고 있다.
법칙 83 요약 부분은 버그 보고서에서 가장 중요한 부분이다.
법칙 84 버그를 과장하지 마라.
법칙 85 문제는 명확하게 보고하되, 해결하려고 하지 마라.
법칙 86 보고서의 어조를 조심하라.
법칙 87 지치거나 까다로운 사람조차도 쉽게 읽을 수 있도록 가독성이 뛰어난 보고서를 작성하라.
법칙 88 보고서 작성 기술을 향상시켜라.
법칙 89 적절한 경우에 시장/기술 지원 데이터를 사용하라.
법칙 90 각자 다른 사람의 버그 보고서를 검토하라.
법칙 91 보고서를 읽게 될 프로그래머를 만나보라.
법칙 92 버그를 프로그래머에게 보여주는 것이 가장 좋은 방법일 수도 있다.
법칙 93 프로그래머가 버그를 고쳤다고 말할 때, 여전히 버그가 있는지를 확인하라.
법칙 94 버그 수정은 바로바로 점검하라.
법칙 95 버그가 제대로 고쳐지지 않았다면 프로그래머와 함께 이야기를 나눠보라.
법칙 96 버그 보고서는 테스트에 의해 마감되어야 한다.
법칙 97 모든 버그를 수정해야 한다고 주장하지 마라.
법칙 98 보류된 버그가 사라지도록 내버려두지 마라.
법칙 99 테스트 관성이 버그 보류의 원인이 되어서는 안 된다.
법칙 100 버그 보류에 대해서는 바로 이의를 제기하라.
법칙 101 싸우기로 했다면 이겨라.

제5장 테스트 자동화

법칙 102 테스트에 드는 비용을 몇 푼 아끼기보다는 개발 프로세스의 속도를 높여라.
법칙 103 동일한 테스트를 반복하기보다는 더 넓은 범위를 테스트하라.
법칙 104 상황에 적절한 자동화 전략을 선택하라.
법칙 105 100% 자동화를 지시하지 마라.
법칙 106 테스트 도구는 전략이 아니다.
법칙 107 뒤죽박죽일 때에는 자동화를 하지 마라.
법칙 108 수동 테스트와 자동 테스트를 동일시하지 마라.
법칙 109 ‘얼마나 자주 실행하는가’라는 기준으로 테스트의 가치를 평가하지 마라.
법칙 110 자동화된 회귀 테스트를 통해 발견할 수 있는 버그의 개수는 적다.
법칙 111 테스트를 자동화할 때에는 발견하지 못하는 버그가 무엇인지를 고려하라.
법칙 112 잘못된 자동화의 문제점은 아무도 알아차리지 못한다는 사실이다.
법칙 113 반복 오류를 잡아라.
법칙 114 테스트 도구도 버그가 있다.
법칙 115 사용자 인터페이스는 변경된다.
법칙 116 호환성, 친밀성, 서비스에 따라 GUI 테스트 도구를 선택하라.
법칙 117 자동화된 회귀 테스트들은 사라진다.
법칙 118 테스트 자동화는 소프트웨어 개발 프로세스이다.
법칙 119 테스트 자동화는 중요한 투자이다.
법칙 120 테스트 자동화 프로젝트에는 프로그래밍, 테스트, 프로젝트 관리에 관한 기술이 필요하다.
법칙 121 파일럿 프로젝트를 통해 실행 가능성을 증명하라.
법칙 122 테스터와 프로그래머에게 자동화된 프로젝트에 대한 특권을 부여하라.
법칙 123 재검토가 용이하도록 자동화된 테스트를 설계하라.
법칙 124 자동화된 테스트를 허술하게 설계하지 마라.
법칙 125 테스트 스크립트에 복잡한 논리를 넣지 마라.
법칙 126 단순히 코드를 반복하지 않기 위하여 테스트 라이브러리를 만들지 마라.
법칙 127 데이터 중심 테스트 자동화는 많은 변종 테스트의 실행을 용이하게 도와준다.
법칙 128 키워드 중심 테스트 자동화는 프로그래머가 아닌 사람이 테스트를 쉽게 생성할 수 있도록 도와준다.
법칙 129 자동화 기법을 사용하여 테스트 입력을 생성하라.
법칙 130 테스트 생성과 테스트 실행을 구분하라.
법칙 131 표준 스크립트 언어를 사용하라.
법칙 132 프로그래밍 인터페이스를 사용하여 테스트를 자동화하라.
법칙 133 유닛 테스트 스위트를 개발하라.
법칙 134 테스트를 이해하지 못하는 사람에게 자동화를 맡기지 마라.
법칙 135 테스트를 존중하지 않는 자동화 담당자는 피하라.
법칙 136 테스트 용이성이 자동화보다 훨씬 더 나은 투자인 경우가 자주 있다.
법칙 137 테스트 용이성이란 가시성과 제어성을 의미한다.
법칙 138 초기에 테스트 자동화를 시작하라.
법칙 139 중앙 집중화된 팀에게 분명한 권한을 부여하라.
법칙 140 바로 효과를 볼 수 있는 것부터 자동화하라.
법칙 141 흔히들 알고 있는 것보다 훨씬 많은 테스트 도구들이 존재한다.

제6장 테스트 문서화

법칙 142 솔루션을 효과적으로 적용하려면 문제를 명확히 이해해야 한다.
법칙 143 테스트 문서 템플릿을 사용하지 마라: 템플릿이 필요하지 않다면 무용지물에 불과하다.
법칙 144 테스트 문서 템플릿을 사용하라: 템플릿은 일관성 있는 의사전달을 촉진시킨다.
법칙 145 IEEE 829 표준안을 사용하여 테스트 문서를 작성하라.
법칙 146 IEEE 829 표준안을 사용하지 마라.
법칙 147 요구조건을 분석한 다음 어떤 제품을 만들지 결정하라: 이 말은 소프트웨어와 마찬가지로 문서화에도 적용된다.
법칙 148 테스트 문서 요구조건을 분석하기 위하여 다음 사항을 물어보라.
법칙 149 핵심적인 문서 요구사항을 세 부분 이하로 한 문장씩 요약하라.

제7장 프로그래머와의 상호관계

법칙 150 프로그래머들의 사고방식을 이해하라.
법칙 151 프로그래머와 신뢰를 쌓아라.
법칙 152 서비스를 제공하라.
법칙 153 성실하고 능력을 갖추어야 존중을 받게 된다.
법칙 154 사람이 아닌 작업에 집중하라.
법칙 155 프로그래머들은 자신의 일에 대해 이야기하는 것을 좋아한다. 궁금한 점이 있으면 직접 물어보라.
법칙 156 프로그래머는 테스트를 도와주고 싶어한다.

제8장 테스트 프로젝트 관리

법칙 157 서비스 문화를 만들어라.
법칙 158 통제 문화를 만들지 마라.
법칙 159 임금님 귀(?)처럼 다양한 의견을 들어라.
법칙 160 개발 프로젝트가 아니라 테스트 서비스를 제공하는 하위 프로젝트를 관리하는 것이다.
법칙 161 모든 프로젝트는 진화한다. 잘 진행된 프로젝트는 진화도 잘한다.
법칙 162 항상 뒤늦은 변경사항이 존재한다.
법칙 163 프로젝트에는 기능, 신뢰성, 시간, 돈 사이의 트레이드오프가 존재한다.
법칙 164 프로젝트 관리자가 프로젝트의 수명주기를 선택하도록 하라.
법칙 165 폭포수 수명주기 모델은 시간에 대한 신뢰성이 부족하다.
법칙 166 진화 수명주기 모델은 시간에 대한 기능이 부족하다.
법칙 167 개발 초기에 프로젝트에 대한 자원을 할당하라.
법칙 168 계약에 따른 개발과 시장에 대한 개발은 다르다.
법칙 169 테스터 용이성 기능을 요구하라.
법칙 170 빌드에 대한 일정을 협의하라.
법칙 171 빌드를 전달하기 전에 프로그래머가 한 일(그리고 하지 않은 일)을 이해하라.
법칙 172 빌드를 준비하라.
법칙 173 때로는 빌드에 대한 테스트를 거부해야 한다.
법칙 174 빌드를 평가하기 위하여 연기 테스트를 사용하라.
법칙 175 때로는 테스트를 멈추고, 개발 주기를 수정한 다음 소프트웨어를 다시 설계하는 것이 올바른 결정이다.
법칙 176 실제로 사용되는 개발 사례에 프로세스를 적용하라.
법칙 177 프로젝트 문서는 재미있는 소설이다: 유용하지만 충분하지는 않다. – Brian Marick
법칙 178 사용하지 않을 항목은 요청하지 마라.
법칙 179 다른 정보 출처도 이용하라.
법칙 180 프로젝트 관리자에게 구성 관리 문제점을 보고하라.
법칙 181 프로그래머는 태풍과 같다.
법칙 182 테스트 계획을 잘 세우면 뒤늦게 변경하기도 쉽다.
법칙 183 인위적인 결과물을 다른 사람에게 전달할 때마다 테스트를 수행해야 한다.
법칙 184 충분히 많은 테스트를 수행했음을 판단하는 공식은 존재하지 않는다.
법칙 185 충분한 테스트란 고객이 좋은 판단을 내릴 수 있도록 충분한 정보를 제공한다는 의미이다.
법칙 186 단순히 테스트를 두 번 수행하기 위한 예산을 책정하지 마라.
법칙 187 작업에 대한 일정 계획을 세울 때 각 작업에 필요한 소요시간을 평가하라.
법칙 188 작업을 담당할 사람이 직접 소요시간을 이야기하도록 하라.
법칙 189 테스터와 다른 개발자 사이의 적절한 비율은 없다.
법칙 190 작업에 실패하였다면 담당 작업을 서로 바꾸거나 사람을 교체하라.
법칙 191 테스터를 기능별로 순환시켜라.
법칙 192 짝을 이뤄 테스트를 하라.
법칙 193 프로젝트에 버그 헌터를 지명하라.
법칙 194 테스트 세션, 특히 답사 방식의 테스트 세션을 계획하라.
법칙 195 테스트를 세션 단위로 수행하라.
법칙 196 테스터의 작업을 방해하는 중단요소를 밝히기 위하여 행동 기록을 사용하라.
법칙 197 정기 상태 보고서는 강력한 도구이다.
법칙 198 부사장이 통계 데이터를 가지는 경우가 가장 위험하다.
법칙 199 버그 개수라는 관점에서 프로젝트의 진척도를 측정하지 않도록 주의하라.
법칙 200 더 많은 독립 기준을 사용할수록 더 많은 것을 알게 된다.
법칙 201 다차원 상태를 보고하기 위하여 균형 잡힌 점수 카드를 사용하라.
법칙 202 주간 상태 보고서는 다음과 같이 작성하라.
법칙 203 프로젝트 상황판은 현재 상태를 알려주는 또다른 유용한 방법이다.
법칙 204 마일스톤(milestone)이 잘 정의되어있다면 마일스톤 보고서가 유용하다.
법칙 205 제품 출시에 찬성한다는 서명을 하지 마라.
법칙 206 만족할 정도로 테스트를 해본 제품에 대해서만 서명하라.
법칙 207 출시 보고서에는 제품에 대한 자신의 의견이 아니라 테스트 작업 결과에 대해 적어야 한다.
법칙 208 최종 출시 보고서에는 수정되지 않은 버그의 목록도 함께 적어두라.
법칙 209 유익한 출시 보고서에는 10가지 단점이 들어있어야 한다.

제9장 테스트 그룹 관리

법칙 210 개성이 사라지면 직장이 무기력해진다.
법칙 211 팀을 경영진처럼 대하라.
법칙 212 팀원들이 작성한 버그 보고서를 읽어라.
법칙 213 경영자의 입장에서 팀을 평가하라.
법칙 214 어떻게 진행되고 있는지 정말 알고싶다면 팀원과 함께 테스트를 수행하라.
법칙 215 여러 개의 프로젝트를 효율적으로 담당하도록 요구하지 마라.
법칙 216 테스트팀의 영역 전문 지식을 만들어라.
법칙 217 테스트 팀원을 관련 기술 전문가로 만들어라.
법칙 218 기술을 적극적으로 개발하라.
법칙 219 기술 지원 기록을 재검토하라.
법칙 220 새로운 테스터가 성공하도록 도와주어라.
법칙 221 새로운 테스터에게는 소프트웨어에 대한 문서를 점검하도록 하라.
법칙 222 새로운 테스터가 제품에 익숙해지도록 긍정적 테스트를 수행하라.
법칙 223 초보 테스터에게는 새로운 버그 보고서를 작성하기 전에 예전 버그 보고서를 수정하도록 하라.
법칙 224 새로운 테스터가 새로운 버그를 테스트하기 전에 예전 버그를 다시 테스트하도록 하라.
법칙 225 초보 테스터에게 거의 종료된 프로젝트를 맡기지 마라.
법칙 226 팀원의 의욕은 중요한 자산이다.
법칙 227 자신을 혹사시키지 마라.
법칙 228 팀원들을 초과 근무로 혹사시키지 마라.
법칙 229 팀원들을 대우해 주어라.
법칙 230 교육 기회를 만들어라.
법칙 231 당신이 내리는 채용 결정은 가장 중요한 판단이다.
법칙 232 채용 기간동안 숨쉴 여유를 제공하는 외주업체를 사용하라.
법칙 233 다른 그룹에서 거절된 사람을 테스트팀에 받아들이지 마라.
법칙 234 그룹에서 해야 하는 업무와 그 업무를 수행하는 데 필요한 기술의 관점에서 계획을 수립하라.
법칙 235 다양한 배경 지식을 가진 사람들로 테스트팀을 구성하라.
법칙 236 기회가 닿은 지원자를 채용하라.
법칙 237 교감에 의해 채용하라.
법칙 238 자신의 업무를 좋아하는 사람을 채용하라.
법칙 239 성실한 사람을 채용하라.
법칙 240 면접시 당신이 왜 그를 테스터로 채용해야 하는지, 테스터에게 그를 채용해야만 하는 고유한 기술을 보여달라고 하라.
법칙 241 면접시 비공식 적성 테스트의 한 방법으로 직장에서 실제로 사용할 기술을 보여달라고 요청하라.
법칙 242 채용시 작업 예제를 요구하라.
법칙 243 마음먹었다면 바로 채용하라.
법칙 244 채용 약속을 서면으로 받아서 잘 보관하라.

제10장 소프트웨어 테스트 분야에서의 경력 관리

법칙 245 진로를 선택하고, 그 방향에 매진하라.
법칙 246 테스터의 연봉이 프로그래머의 연봉보다 많을 수 있다.
법칙 247 진로 변경을 편안하게 느끼고, 다른 직종을 추구하라.
법칙 248 어떤 진로를 택하든지 적극적으로 추구하라.
법칙 249 경력을 소프트웨어 테스팅 이외의 영역까지 확장하라.
법칙 250 현재의 회사를 벗어나는 경력을 확장하라.
법칙 251 컨퍼런스는 이야기를 나누기 위한 것이다.
법칙 252 다른 많은 회사들도 지금 회사와 별반 차이가 없다.
법칙 253 현 직장이 마음에 들지 않는다면 다른 직장을 찾아보아라.
법칙 254 현 직장에서 승부를 걸어야 할(그리고 잃을) 경우에 대비하라.
법칙 255 일하고 싶은 회사의 목록을 작성하여 관리하라.
법칙 256 포트폴리오를 작성하라.
법칙 257 이력서를 세일즈 도구로 사용하라.
법칙 258 내부 추천제도를 이용하라.
법칙 259 급여 데이터를 알아보라.
법칙 260 구직 광고를 보고 지원하는 것이라면, 광고 내용에 대한 답변을 준비하라.
법칙 261 인터뷰 기회를 이용하라.
법칙 262 마음에 드는 회사라면 그 회사에 대한 정보를 습득하라.
법칙 263 직장 인터뷰 중 질문을 하라.
법칙 264 직급을 협상하라.
법칙 265 인사부에 대해 조심하라.
법칙 266 펄(Perl)을 배워라.
법칙 267 자바나 C++를 배워라.
법칙 268 테스트 도구의 데모 버전을 다운로드 받아서 사용해보라.
법칙 269 글 쓰기 능력을 향상시켜라.
법칙 270 대중 앞에서 말하는 기술을 향상시켜라.
법칙 271 자격증을 취득하는 것도 고려하라.
법칙 272 단 2주만에 검은 띠를 딸 수 있다면, 싸움을 피하라.
법칙 273 CSTE 자격증을 취득하라.

제11장 테스트 전략 계획

법칙 274 테스트 전략에 대한 세 가지 기본 질문은 쓰는가?, 얼마나 많이?이다.
법칙 275 가능한 테스트 전략은 매우 많다.
법칙 276 테스트 계획은 실제 테스트 프로세스를 이끌어줄 아이디어의 모음이다.
법칙 277 자신의 상황에 적절한 테스트 계획을 수립하라.
법칙 278 전략, 지원 방안, 그리고 작업 결과물에 대한 결정을 알 수 있는 테스트 계획을 수립하라.
법칙 279 지원 방안과 작업 결과로 인해 전략이 가려지지 않도록 하라.
법칙 280 테스트 사례에 대한 거짓말
법칙 281 테스트 전략은 테스트보다 더 큰 것이다.
법칙 282 테스트 전략은 테스트를 설명한다.
법칙 283 다양한 임시 방법을 적용하라.
법칙 284 강력한 테스트 전략의 원 재료를 만들어라.
법칙 285 프로젝트에 대한 첫 번째 전략은 항상 잘못된 전략이다.
법칙 286 프로젝트의 각 단계마다 스스로에게 “현재 무엇을 테스트할 수 있으며, 어떻게 테스트할 수 있는가?”라는 질문을 던져보라.
법칙 287 프로젝트의 성숙도에 따라 테스트를 진행하라.
법칙 288 테스트 복잡성에 대한 논의를 단순화하기 위하여 테스트 수준을 사용하라.
법칙 289 그레이박스를 테스트하라.
법칙 290 이전 테스트 자료를 다시 사용할 경우 무조건적 신뢰는 위험하다.
법칙 291 두 명의 테스터가 동일한 것을 테스트한다고 해서 중복된 노력을 들이고 있는 것은 아니다.
법칙 292 제품의 위험요소 뿐만 아니라 프로젝트의 요소들에 대한 테스트 전략을 수립하라.
법칙 293 테스트 주기를 테스트 프로세스의 심장박동처럼 취급하라.

팀에 후배가 들어오면 꼭 한 번 읽어 보라고 하는 책 중에 한 권입니다.

아래 제목만 보시고 흥미 있으시면 읽어 보시고 아니면 그정도는 아니다 싶으시면 dejavu_blog에 추가로 요약된 글을 보시면 좋을 것 같습니다.

제1장 테스터의 역할

법칙 1 테스터는 프로젝트의 전조등이다.
법칙 2 임무에 따라 행동이 결정된다.
법칙 3 테스터는 많은 고객들에게 서비스를 제공한다.
법칙 4 고객이 가치 있다고 생각하는 “버그”를 발견하라.
법칙 5 중요한 버그를 신속하게 찾아내라.
법칙 6 프로그래머와 함께 진행하라.법칙 7 모든 것에 의문을 가져라. 그러나 밖으로 크게 드러내지는 마라.
법칙 8 테스터가 실패에 초점을 맞추면 고객은 성공에 초점을 맞출 수 있다.
법칙 9 모든 버그를 찾아낼 수는 없다.
법칙 10 “완전히” 테스트한다는 말을 조심하라.
법칙 11 테스트를 통해서 품질을 보장할 수는 없다.
법칙 12 문지기가 되지는 마라!
법칙 13 테스트에서 “내 업무가 아니야”의 논리를 조심하라.
법칙 14 프로세스 개선 그룹이 되는 것을 조심하라.
법칙 15 테스트를 잘 수행하기 위하여 필요한 항목들을 모든 사람들이 이해할 것이라고 기대하지 마라.

제2장 테스터의 사고방식

제3장 테스트 기법

제4장 버그 보고

제5장 테스트 자동화

제6장 테스트 문서화

제7장 프로그래머와의 상호관계

제8장 테스트 프로젝트 관리

제9장 테스트 그룹 관리

제10장 소프트웨어 테스트 분야에서의 경력 관리

제11장 테스트 전략 계획

Share and Enjoy:

2007 ASTA Software Testing Conference & Tutorials

정의의소 — Sun, 09 Sep 2007 16:26:12 +0000

국제 소프트웨어 테스팅 컨퍼런스가 다음 달 코엑스에서 열립니다.
자세한 내용과 일정은 여기를 참고하시면 될 것 같습니다.
테스팅 관련 블로그에서 여러 번 소개가 되고 있지만 제가 관심이 가는 주제를 정리(발표자 이름에 빨간색)하면서 포스팅합니다.

컨퍼런스 등록 페이지에 나와 있는 것처럼 꼭 소프트웨어 테스팅 문화가 긍정적이고 테스트가 전문직이라는 것이 각인되었으면 하는 희망을 해 봅니다.

이번 ASTA 국제 컨퍼런스는 한국이 ‘체계적인 SW 테스팅 문화의 부재’라는 부정적인 이미지를 탈피하고 아시아에서 테스팅 산업을 선도하고 있다는 이미지를 각인시키는 전환점이 될 것입니다.

저도 이번 컨퍼런스는 꼭 가고 싶지만 제 부서에서는 책임(저는 선임 ㅡㅡ;)급에서 몇 명이 참석 할것 같습니다.

저희 대장이 그렇게 해라~ 하고 전체 메일을 보내셨습니다. 관심 없는 책임들도 있을 텐데… 나중에 기회가 생길지도 모르니 이렇게 정리해 봅니다. ㅎㅎㅎ
못 가더라도 분위기 잘 잡아서 제가 듣고 싶은 것에 꼭 참가시켜서 잘 정리하고 오시도록 유도해 봐야겠습니다. ^,.^; (우리 회사는 교육이나 컨퍼런스에 다녀오면 꼭 전달 교육이라는 것을 해야 합니다.)

실무자 보다 어르신들(개발, SE 관련 임원분들)께서 꼭 참석하시면 좋겠습니다만, 그분들은 전시회 같은 컨퍼런스 말고는 왜 안 가시는 지 모르겠습니다.

가셔서 직접 느끼시고 오셨으면 좋겠는데…
다녀와서 우리도 저렇게 하자라고 강하게 밀어붙이셔도 되는데…
이런 일이라면 일이 많아져도 행복할텐데…

1st Day – Monday, Oct 8, 2007
Class Time	Room 310			Room 311
Class Time	A	B	C	A	B	C
10:00am ~ 5:00pm	Assessing your Test Team Effectiveness, Efficiency, and More (Rex Black)	Testing embedded and real time systems I (Hans Schaefer)	Agile Test Management using SCRUM (Klaus Olsen)	Q-patterns for reusable test cases (Vipul Kocher)	Hands-on technique building risk-based testing strategy using TPMS™ and deriving test cases (Wonil Kwon)	System Performance Testing-Why and How to do it? (Bumwoo Lee)

2nd Day – Tuesday, Oct. 9, 2007
Class Time	Room 310			Room 311
Class Time	A	B	C	A	B	C
10:00am ~ 5:00pm	Introduction to Critical System Quality (Bernard Homes)	Testing embedded and real time systems II (Hans Schaefer)	Test design & technique (Rex Black)	Test Automation – an ROI based approach (Jerry E. Durant)	Applying Test Best Practice with Test Software Solution Tool (Yungjoo Chey & Sunghun Park)	How to organize a testing team effectively (Yeongseok Lee)

1st Day – Wednesday, Oct 10, 2007
Track Time	TrackⅠ (401) ( External Test Expert)	TrackⅡ (402) ( Internal Test Expert )	TarckⅢ (403) ( Auto Tool & Internal Test Expert)
09:00 ~ 09:50	Registration
10:00 ~ 10:50	Keynote Speech
11:00 ~ 11:30	Automation Tool venue visit
11:30 ~ 12:50	Critical Test Processes: Plan, Prepare, Perform, Perfect (Rex Black)	Case study: How to Test Web-based Applications? (Janet Jing XU)	TMM(Test Maturity Model) in Practice (Byunggul Lee)
12:50 ~ 14:00	Lunch Break
14:10 ~ 15:30	Testing real life stories (Alon Linetzki)	Using MindMap for Software Testing Activities (Micky Suzuki & Akira Ikeda)	Using TMap to prevent a billion-dollar-cost defect (Yongtae Jung)
15:40 ~ 17:00	Planning and Managing Acceptance Testing (Hans Schaefer)	Code review and inspection practice in Japan (Nobuhiro Hosokawa)	Nightly incremental static analysis and report system (Jaehwang Kim)
17:10	End of first conference

2nd Day Thursday, Oct 11, 2007
Track Time	TrackⅠ (401) ( External Test Expert)	TrackⅡ (402) ( Internal Test Expert )	TarckⅢ (403) ( Auto Tool & Internal Test Expert)
09:30 ~ 09:50	Automation Tool venue visit
10:00 ~ 11:00	Risk based testing By IBM (Dongyoung Kim )	Optimize Quality for business outcomes:A practical approach to software testing (Bohee Seo )	Continuous Integrated Testing (CIT): Test Early, Test Often with Confidence (HyunSoo Kim)
11:00 ~ 11:30	Tea Break
11:30 ~ 12:50	Using SCRUM as a Test Management method (Klaus Olsen)	Noun and Verb Technique (Vipul Kocher)	Lesson learned from the Survey on software process Capability and K-Model as the Goverment Certification (Sangeun Lee & Wonil Kwon)
12:50 ~ 14:00	Lunch Break
14:10 ~ 15:30	Test Plan 101 using IEEE 829 (Bernard Homes)	Creating a company Wide Measurement Program for Verfication (Sigrid Eldh)	Unit testing best practice @TDD (Test Driven Development) (ChangJoon Kim)
15:40 ~ 17:00	eXtreme Testing meets Risk Based Testing (Yaron Tsubery)	Forth Generation Test Strategy: A Quicker Test for Death March Projects (Tsuneo Yamaura )	Introduction of Product Evaluation Service for Quality Improvement and Case Study (JaeWoo Bae)
17:10	End of second conference

Share and Enjoy:

프로젝트를 성공시키는 지름길「테스트 용이성」

정의의소 — Thu, 06 Sep 2007 22:39:16 +0000

zdnet에 공감이 많이 가는 글이 올라와 소개합니다.
웹젠의 QA 팀장이신 신재문님께서 작성하신 글입니다.

자세한 내용은 아래 글을 펼치시거나 위 링크를 따라가시면 됩니다.

Testability는 개발자와 테스터 입장이 많이 다릅니다.
개발자분들께서 한 번 읽어 보시고 어떻게 생각하시는지 트랙백이나 답글 남겨 주시면 고맙겠습니다. ^^;

제가 앞선 글에서도 말씀드렸지만 저는 요즘 플랫폼을 개발하는 과제에 테스트 환경과 테스트 케이스 확보를 목표로 과제 지원하고 있습니다.
그러나 요즘 제가 하는 일을 보면 테스트 관련 내용보다 프로세스 관련 일을 더 많이 하고 있습니다.
요구사항(SRS) 정리, 디자인 문서 정리(HLD, DLD), Programming Guide 정리, Coding Rule 정리, API Reference 정리, SCM, … 등에 일이 집중되고 있습니다. 제가 왜 테스트보다 이런 일에 집중하고 있는지는 신재문님의 글을 읽어보시면 이해가 되실 것 같습니다.

프로젝트 시작 시 테스트를 고려하지 않고 개발을 시작했기 때문에 막상 테스트를 하려고 하니 당장 요구사항이 명확하지 않아 무엇을 테스트해야 할지가 분명하지 않았고 코드와 문서가 일치되지 않는 등의 문제를 발견하게 되었습니다. 그래서 테스트보다 우선적으로 이런 것들부터 정리해야겠다 싶어 문서 및 프로세스를 정리하고 있는데 과제 일정이라는 난관?에 부딪혀 요즘은 적정수준?으로 정리를 하고 있습니다.

“Testability”를 위한 활동은 테스터가 편하기 위한 것들이 아니라 프로젝트를 성공시키는 중요한 요소이며 개발자들을 더 편하고 행복하게 하는 것임을 말씀드리고 싶습니다. ^^;

[#M_ more.. | less.. | 프로젝트를 바탕으로 업무를 진행해야 하는 많은 IT 관련 종사자와 마찬가지로 QA나 테스터 또한 프로젝트의 성과나 결과에
많은 영향을 받게 되며, 프로젝트를 통해 자신의 존재 가치를 증명해야 하는 숙명을 지니고 있다고 할 수 있다.

일반적으로 이러한 프로젝트의 목표는 상당 부분 달성하기 어려우며 극한 상황에서의 인내와 이전에 경험한 다른 프로젝트에서 얻은
노하우들을 필요로 하게 된다. 특히, 갈수록 치열해지는 경쟁으로 인해 프로젝트를 제 시간 안에 효율적으로 완료할 수 있는지에
대한 중요성은 날이 갈수록 더해지고 있다.

여기에서는 QA나 테스터의 관점에서 프로젝트를 성공시키기 위해 관심을 가져야 하는 요소인 테스트 용이성(Testability)을 살펴 보고 이에 대한 향상 방안에 대해서 고민해 보도록 한다.

테스트 용이성(Testability)이란 무엇인가?
일반적인 테스트 용이성(Testability)의 정의는 다음과 같다.

- 소프트웨어 제품의 가시성(Observability)과 제어성(Controllability)을 의미한다.
- 비기능적인(non-functional) 요구 사항이다.
- 기능이나 코드의 테스트가 손쉬운지를 판단하는 특성이다.
- 테스트를 시스템적으로 수행할 수 있도록 하기 위해 소프트웨어에 미리 준비된 어떤 것이다.”

즉, 테스트 용이성(Testability)은 일반적으로 테스팅 활동으로 불리는 모든 영역에 걸쳐 영향을 주고받게 되며, 테스팅
활동은 그 자체로는 성립하지 않거나 독립적으로는 존재하지 못하고 개발팀, 프로젝트 매니저 등 기타 프로젝트 관련자들과의 상호
작용이나 관계에서만 의미가 있게 되므로, 테스트 용이성 또한 포괄하는 범위가 매우 광범위하다고 할 수 있다.

그러므로 지면상 이와 관련한 모든 이슈를 다루기보다는 현실적으로 많이 겪게 되는 상황과 연관된 이슈만을 다루도록 한다. 이
기고에서의 테스트 용이성은 “테스팅을 효율적이고 효과적으로 수행하게 하는 모든 방법”이라고 정의하도록 한다.

테스트 용이성이 왜 중요한가?
소프트웨어 제품 테스팅 관점에서 프로젝트의 목표는 제 시간 안에 출시되어야 하며, 가능한 한 버그가 적은(또는 심각한 버그가
적은) 상태의 제품을 출시하는 것이다. 또한 무사히 제품 출시 과정을 겪었다 하더라도 이후의 유지 보수, 개정판 출시 등의
일련의 과정 또한 무시할 수 있는 작업이 아니다.

이러한 작업에는 대개 많은 지원 비용, 유지 보수 비용이 발생하게 마련이다. 따라서, 제품 출시 과정 상의 테스트 용이성(Testability)의 성격과 제품 출시 이후 그것의 성격은 달라질 수 있다.

제품 출시 과정 중에 발생하는 테스팅 활동은 프로젝트의 성격에 따라 수 많은 방법론이 있을 수 있으나, 최소한의 테스트 활동을
통해 최대한의 결점을 검출해 내야 한다는 목표는 동일하다. 따라서, 테스트 용이성(Testability)의 개념이 테스트
효과성(Test Effectiveness), 테스트 효율성(Test Efficiency)에 지대한 영향을 미친다는 점은
확실하다.

제품의 상태에 대한 파악이 용이하고 제어된 환경에서 제품을 구동할 수 있으며, 간단한 방법으로 제품의 모드를 변경하는 등의
일련의 활동을 통해서 제품을 좀 더 다양한 입력 조건/동작 조건하에 놓이게 하면 할수록 문제를 발견해 낼 확률이 더욱 높아지기
때문이다.

특히, 제품의 출시 이후에 반드시 수행될 수 밖에 없는 회귀 테스트(Regression Testing)나 확인
테스트(Conformance Testing, Re-Testing) 등에서 동일한 테스트를 여러 번 반복해야 하는 상황인 경우,
이 사실은 더욱 극명하게 드러나는데 테스트 용이성(Testability)이 향상되고 높을수록 적은 리소스로 테스트를 수행할 수
있음은 물론이고 테스트 자동화의 구현이 용이하기 때문이다.

이러한 일련의 상황을 통해서 많은 이득을 얻을 수 있음은 물론이고, 품질에 대한 확신을 가지기 쉬울 것이라는 점은 분명하다.

그림 1. Testability가 영향을 주는 요소들

테스트 용이성(Testability)의 단계별 향상 방안
테스트 용이성(Testability)의 향상 방안을 알아보기 전에 일반적인 제품 개발 프로세스에 대해서 알아보도록 하자. 각 상황에 따라 요구되는 테스트 용이성(Testability)의 특성이 다르기 때문이다.

일반적인 제품 개발 프로세스는 요구사항 수집, 분석, 디자인, 코딩, 테스팅, 구현, 유지보수의 단계를 가진다.

1) 요구 사항 정의 단계 : 요구 사항을 수집하여 “요구 사항 문서”를 작성, 리뷰, 확정하는 단계이다. 요구 사항에는 기능적 요구 사항뿐 아니라 비 기능적인 요구 사항 또한 정의될 수 있다.

따라서 이 단계에서 테스트 용이성(Testability)을 향상 시킬 수 있는 개발팀의 협조를 약속 받거나(명시적인 요구 사항이
아니더라도), 프로젝트 매니저에게 테스트 용이성(Testability)을 높이기 위해 개발팀에서 해주어야 하는 관련 작업에
대해서 설명하고 동의를 구해야 한다.

2) 제품 디자인 단계 : 앞 단계에서 개발팀 및 프로젝트 매니저 등 프로젝트 관련자와 테스트
용이성(Testability)의 구현과 향상에 대해서 동의를 구한 상태라면, 이 단계에서는 테스터의 지식 수준이나 제품의 성격,
프로젝트의 상황에 따라서 사용할 수 있는 테스팅 인터페이스나, 제품 내의 테스트 코드 또는 부가적인 테스팅 툴에 대한 요구
스펙을 정해 개발팀에 전달해야 한다.

프로젝트의 막바지에 도달할수록 여러 불확정 요소들이 돌출되어 예상 대비 실제 달성이 더뎌질 수 있으므로, 개발팀의 리소스가
투입되어야 하는 이러한 작업에 대해서 프로젝트 초기부터 개발팀과 협의하여 일정에 반영할 것을 요구하는 것이 보다 테스트
용이성(Testability)을 높일 수 있는 방법이기도 하다.

3) 코딩 단계 : 앞의 단계에서 개발 관련 인원 모두의 합의가 이루어져 있고(테스트 용이성을 향상하기로),
테스트를 손쉽게 하기 위한 구체적인 방안들도 개발팀에 전달되어 있는 상태라면 이제 실제로 개발팀에서 제품 내에 그 요구 사항을
반영하든지, 제품의 일부 기능을 동작시킬 수 있는 스텁(Stub), 드라이버(Driver) 또는 커스텀 테스팅 툴(Custom
Testing Tools) 등을 제작하고 구현하는 단계이다.

4) 테스팅 단계 : 제품의 제작과 테스트 용이성(Testability)을 높이기 위한 부가적인 작업이 완료되었다면 이제 미리 준비된 여러 방법들을 이용해서 실제로 제품을 테스팅하는 단계이다.

이 과정을 통해 개발팀에서 테스팅 인터페이스를 잘못 구현했거나, 제품 내에 테스팅을 쉽게 하기 위한 코드를 삽입했는데 그것이 본래 구현되어야 할 스펙 상의 제품 기능에 영향을 미치거나 하는 상황이 발생할 수 있다.

따라서 실제 제품 테스팅에 이를 사용하기 이전에 테스트 용이성(Testability)을 개선하기 위해 개발팀에서 준비한 내용을 사전 검증하는 과정이 반드시 필요하다.

테스트 용이성(Testability) 향상을 위한 상세 방안

1) 테스트 용이성(Testability)을 방해하는 상황
앞에서도 언급했듯이 테스트 용이성(Testability)을 높이는 요구는 거의 테스터가 하게 되며, 그 시점은 스펙이 작성될 때
요구되는 것이 가장 좋다. 다만, 이 경우에 개발팀에서의 나름의 논리로 인해 이것이 좌절될 수도 있는데, 필자의 경험으로 보아
대강 다음의 상황이 가능할 것이다.

상황1) 제품 개발의 궁극적인 목표는 최종 사용자(End-User)를 편하게 해주어야 하는 것이다. 왜 테스터가 편하게 테스팅 할 수 있도록 개발팀에서 부가적인 작업을 해주어야 하나?

해결1) 이런 상황은 일단 개발 조직의 성숙도가 높지 않다고 판단할 수 있다. 왜냐하면, 개발 과정은 전적으로 개발팀의 몫이고
이후의 테스팅 및 품질을 향상시키는 작업은 모두 테스트/QA팀의 책임이라는 생각이 그들을 지배하고 있다고 볼 수 있기 때문이다.

특히나 개발 조직에서는 테스팅이 상당한 비용을 소모하는 개발 활동의 일부라는 생각을 하지 못할 수 있기 때문에, 개발 관련 인원
모두(테스터 또한) 공동의 목표를 향해 프로젝트에서 각자 나름의 파트에서 최선을 다하는 것이라는 인식을 이해시키고, 이에 따라
테스터의 업무가 효율적으로 이루어 지도록 개발팀에서 지원하는 것이 오히려 좋은 제품과 일정 준수에 도움이 된다는 점을 서로
공유하고 있어야 한다.

상황에 따라 테스터 만으로는 개발팀과 이러한 인식을 공유하기가 어려울 수 있다. 이런 경우 테스트 매니저나 프로젝트 매니저의 지원이 필요한 것은 물론이다.

상황2) 제품 개발 일정도 빠듯한 상황이어서 테스트 용이성(Testability) 개선 요구를 들어줄 수 없다.

해결2) 이런 상황에서는 원론적인 답 밖에는 없는 것 같다. 프로젝트의 요구 사항 정의와 일정 계획에 제품 기능 구현뿐 아니라
테스트 용이성(Testability)을 높이기 위한 작업들도 공식적인 업무로 추가했어야 했다. 아마 요구 했더라도 구두 상으로만
확답을 받거나 한 경우 제품의 기능 구현 과정이 계획보다 늦어지게 되면 테스트 용이성(Testability)을 위한 개발팀
작업의 우선 순위가 떨어질 수도 있다는 점을 유의해야 한다.

상황3) 이미 구현되어 있는 코드에 테스트 코드를 추가하는 경우의 부작용(Side-effect)를 알 수 없기 때문에 테스트 코드를 추가하는 것은 안 된다.

해결3) 이 경우 테스트 용이성(Testability) 개선을 위한 활동이 공식 업무로 계획되어 있었으나 개발팀에서 이를 잊어
버리고 작업을 진행해 왔을 수 있다. 틈틈이 개발팀의 작업 과정을 테스터가 살펴보고 테스팅을 위해 구현하기로 약속한 기능들의
구현 일정과 내용을 확인하도록 한다.

상황4) 테스트 코드나 테스트 용이성(Testability)을 개선하기 위한 개발 활동들은 공식적인 개발 업무가 아닌 개인적인 활동으로 업무로 인정 받지 못한다.

해결4) 개발자나 테스터가 해결할 수 있는 문제가 아니다. 프로젝트에 대한 책임을 지고 있거나 그 보다 더 많은 책임을 가지고 있는 인원이 결정을 해야 한다.

실제 스펙의 기능을 구현한 코드가 아닌 경우에라도 공식적인 업무로 인정 받아야 한다. 왜냐하면, 테스트를 용이하게 하거나
디버깅을 용이하게 하거나 그러한 사항을 고려하거나 하는 일련의 모든 활동의 목적이 결국은 문제가 적고, 제 시간에 잘 테스트된
제품을 출시하기 위한 행동이기 때문이다.

2) 테스트 용이성(Testability)을 향상시키는 구체적인 방안
이제부터 좀더 상세하게 테스트 용이성(Testability)을 높이기 위한 방안을 알아보겠다. 제품 개발에 관련된 주체 별로 해야 하는 역할과 할 수 있는 범위가 달라질 수 있으므로 이에 대해서 좀 더 알아보자.

표 2. 테스트 용이성(Testability)을 향상시키기 위한 주체 별 역할

프로젝트 매니저 : 많은 경우 스펙이나 요구 사항 문서는 시간이 지나면서 점점 더 쓸모 없어 지게 된다. 개발
과정이 진행될수록 초기에 생각하지 못했던 상황이나 검증되지 않았던 부분이 드러나기 때문으로, 이 경우 요구 사항 문서는 버전
1.0에서 더 이상 올라가지 않는 경우가 많다.

스펙은 테스터가 테스팅 활동을 수행하는데 있어 바이블과 같은 문서이므로 이것이 현재 개발활동과 괴리가 있게 되면 테스터의 판단
또한 자의적이고 임의적으로 흐를 수 밖에 없다. 매니저는 테스트 용이성(Testability)을 향상시키기 위해 스펙 문서의
빈번한 업데이트 및 실제 개발 내용과의 동기화에 신경을 써야 한다.

많은 경우 프로젝트를 구성하는 것은 사람이며, 프로젝트의 결과로서 성공 여부를 판단할 수 있다고 하겠지만, 이에 영향을 미치는
중요한 요인 또한 사람과 사람 사이의 관계이다. 프로젝트 구성원들 모두는 나와 다른 역할을 가진 구성원에 대해서 좀 더 이해하고
의사 소통이 빈번히 이루어질 때 실수나 오류의 가능성도 줄어 들 수 있다.

따라서 매니저가 프로젝트의 각 구성원들 간의 의사 소통에 직접 관심을 가져야 하며, 그렇게 됨으로써 테스트 용이성(Testability)의 개선에 영향을 줄 수 있다.

다만, 개발자와 테스터간의 개인적인 친분으로만 업무가 진행된다면 테스터들이 객관적인 시각을 잃어버려 문제를 명확하게 지적하기
어려워 질 수 있다. 따라서, 활발하고 부드럽게 의사 소통이 진행되지만 테스터로서의 시각을 유지할 수 있는 방법이 요구된다.
매니저가 직접 실천할 수 있는 활동들에는 다음이 있을 수 있다.

-테스트 팀과 개발팀 간의 공식적인 의사 소통 방법을 마련한다.
-가능한 한 초기에 테스터를 프로젝트에 포함시킨다.
-필요한 경우 각 그룹의 이메일을 다른 그룹으로 포워딩한다. 이는 개발팀의 일원이라는 소속감을 증대시켜 줄 것이다.
-일체감을 형성할 수 있거나, 긴장을 완화시키거나, 많은 얘기를 나눌 수 있는 비 공식적인 외부 활동을 마련해 본다(영화 보러 가기, 볼링, 도미노 쌓기 등).

개발자 : 실제 구체적으로 테스트 용이성(Testability)을 향상하기 위해 중요한 역할을 하며, 코딩을 함에
있어서 테스트 코드의 추가를 용이하게 하는 구조적인 코드를 작성하거나 코딩 규칙을 준수함으로써 테스트
용이성(Testability)을 높일 수 있다.

또한, 테스터가 테스트를 용이하게 하기 위한 부가적인 옵션이나 스위치를 제공해서 반복적인 테스트를 용이하게 하거나 기능을
분리해서 각각 테스트 할 수 있게 하거나, 별도의 커스텀 테스팅 툴을 제공해서 결과 확인을 용이하게 하는 활동이 가능하다.
개발자가 테스트 용이성(Testability)을 높일 수 있는 활동에는 (표3)과 같은 것들이 있을 수 있다.

표 3. 개발자가 테스트 용이성(Testability)을 높일 수 있는 활동들

테스터 : 개발팀에 테스팅 인터페이스나 테스트 툴에 대한 요구 사항을 명확하게 요구 해야 한다. 또한, 제품을
구성하고 있는 기반 기술, 제품의 특성 등에 대해서 좀 더 심도 있게 이해하고 있어야 한다. 특히, 제품의 비즈니스 로직을
이해하는 것이 중요하다. 개발자가 디버깅을 위해 사용하는 환경에 능숙하다면 많은 도움이 될 수 있다.

많은 경우 테스팅 후에 문제가 발견되고 이의 원인을 분석하는 과정이 개발 과정에서 매우 많이 발생할 수 있으므로 테스터 역시
디버깅 환경에 익숙해 지고 그런 환경에서 테스팅을 진행할 수 있게 되면, 개발팀의 시간을 많이 절약할 수 있고 테스터 역시
버그를 찾아낼 가능성이 높아진다.

테스팅 과정에서 수 많은 툴의 도움을 받을 수도 있는데 이에 대해서는 (표4)를 참고한다. 버그 리포트를 명확하게 작성하는 것도 테스트 용이성(Testability)을 개선할 수 있다.

필자는 경험적으로 버그를 발견한 경우 그것이 2번 이상 재현이 가능한 경우에만 리포트를 하였다. 이전에 한 번만 발견된 버그를
리포트 했다가 실제로 개발자와 동석해서 재현해 보는 과정에서 재현이 되지 않아 서로 간에 시간을 낭비한 경우가 있었기 때문이다.

만일 한 번 밖에 재현되지 않는 버그를 발견했다면 더 이상 재현되지 않는 버그로 리포트를 하라. 이것을 어떻게 처리할 것인지는 차후 결정될 것이다.

이 상황에서 테스터의 임무는 버그의 원인을 찾아내는데 도움이 되는 정보(스텝, 기타 특이 상황 등)를 최대한 전달하는 것이다. 테스터가 양치기 소년이 되어서는 안 된다.

또 테스터가 팀 작업으로 테스팅을 진행하는 경우 버그 리포트의 작성 방법이나, 기술 형태가 일관성을 가지도록 노력한다. 테스터는
프로젝트 관련자들에게 신뢰와 일관성을 줄 수 있어야 한다. 버그 리포트를 작성하는 가이드를 만들어 이를 모든 테스터가 준수하도록
하는 것도 좋은 방법이다.

표 4. Testability 향상에 도움이 되는 툴

기타 고려 사항
최종 사용자(End-User)에게 전달해야 하는 제품을 가지고 테스트 하는 것이 효율적인지 또는 테스트나 디버깅을 용이하게 하기 위해 특별히 제작된 빌드를 가지고 테스트 하는 것이 효율적인지에 대해서 고려해보는 것이 좋다.

특히, 윈도우 환경을 지원하는 제품의 경우 제품을 컴파일 하는 옵션에 따라 디버그 빌드와 릴리즈 빌드로 나누어 제공될 수 있다.
이에 대한 유효성에 대해서는 많이 논의되지 않았고, 검증도 부족한 상황이지만, 개발팀 과의 협의를 통해 어떤 형태의 빌드를
가지고 테스트 할 지를 정하는 것도 생각해볼 요소이다.

다만, 최종 출시에 사용되는 빌드는 릴리즈 빌드이므로 이것으로 테스트를 수행해야 하지 않는가? 하는 의문이 제기될 수 있다.
따라서, 다수의 빌드를 테스트 하는 경우 프로젝트의 상황과 테스팅의 목적에 따라 디버그 빌드와 릴리즈 빌드를 바꾸어 가며 테스트
하는 방법이 있을 수 있다.

마치며
프로젝트 성공의 책임과 역할은 몇몇 사람에게만 있지 않다. 프로젝트 구성원 모두가 각자의 영역에서 맡은 바 임무를 성실히 수행해 나갈 때만 성공이 보장된다고 할 수 있다.

특히 국내 소프트웨어 업계의 특성상 소수의 테스터가 다수의 개발팀이 작업한 결과를 가지고 업무를 수행해야 하며, 테스팅을 고려하지 않은 제품 개발 방식이나 문화로 인해 테스터들이 어려움을 겪는 상황이 많은 것 같다.

더구나, 프로젝트의 막바지로 갈수록 테스팅 활동 자체가 병목이 되는 상황에서는 테스트 용이성(Testability)을 향상시키는 것이 프로젝트의 성공 가능성을 높인다는 인식을 공유할 필요가 있다.

이제부터라도 테스트 용이성(Testability)에 대해서 개발팀이나 프로젝트 매니저와 얘기를 나누어 보도록 하자. 프로젝트의 성공을 기원하는 자세로 열린 마음을 가지고 설득한다면 원하는 바를 이룰 수 있을 것이다. @

참고 문헌
1) Cem Kaner, James Bach, Bret Pettichord, 소프트웨어 테스팅 법칙 293가지, 정보문화사, p.177~178, p.208~209
2) Ipsita Chatterjee, Testing Testability,
http://www.stickyminds.com/sitewide.asp?ObjectId=8077&Function=DETAILBROWSE&ObjectType=ART
3) Joy Shafer, Improving Software Testability, http://www.veritest.com/tn/gp_intro.asp?kb=product_cert&wp=testability
4) Bret Pettichord, Design for Testability, 2003 Software Test
Automation Conference, http://www.io.com/~wazmo/papers/
design_for_testability_PNSQC.pdf

(자료 제공 : STEN Journal 2006 Vol.IV )_M#]

Share and Enjoy:

Test-Driven Development, A Year Later

정의의소 — Mon, 27 Aug 2007 22:35:54 +0000

어제 SQE 업무를 함께하고 있는 팀원들과 이런 저런 이야기를 하다가 TDD가 진짜로 필요한지에 대한 논의(논쟁?)을 잠시 했다. 그 중에는 개발 경험이 많은 친구도 있었고 그렇지 않은 친구도 있었다.
- 필요하다.
- 필요없다.
- 바쁘면 일단 구현하고 나중에 시스템 테스트를 하는 게 더 효율적이다.
- 정답은 없다. 팀 상황과 능력에 따라 다르다.
이런 내용들이었지만 담배피는 잠깐동안의 이야기였기 때문에 이렇게 정리가 되었다.

우선 나는 어떠한 형식이던지 테스트는 꼭 필요하고 TDD는 그 중 개발팀에서 주도적으로 할 수 있는 훌륭한 것 중의 하나라고 생각한다. 즉, 나는 믿는다. 이제 그 필요성을 사람들에게 느끼기 해 주기 위해서 앞 선 글에서도 이야기했지만 좀 더 깊게 공부와 사례 연구를 해서 Expert가 되고 싶은 거다.

TDD에 대해서 경험에 의한 솔직 담백 글이 있다. 기대도 이야기했지만 이런 변화를 SE, SQE팀에서 주기는 힘든 것 같다. 조금 더 내공을 쌓은 후 개발팀으로 복귀하는 것이 좋겠다는 생각을 다시 한 번 해 본다. 그러나 현재의 팀(SQE)에서도 얻는 것은 많다. 다양한 개발팀을 만날 수 있다는 것이다. 연구 과제, 상품과 과제, 프로세스를 잘 따르는 팀, 마구잡이? 개발 팀 등… 많은 사례를 볼 수 있는 것이 장점이다.

저는 프로그래머가 아닌지라, 제가 직접 TDD를 해본 적은 없습니다. 그저 지속적인 통합으로 인한 혜택들을 누리고 있을 따름이지요.
- 김기웅님의 “테스트 주도 개발 ,1년째” 중

하지만, TDD 를 하기 위해서 테스트 코드를 짜다보면
‘내가 제대로 이해하지 못한 상태로 필요한 코드를 copy & paste 해서 쓰고 있었구나’ 라는 느낌을 받게 됩니다.
그리고 원하는 부분을 집중 연구해 보기가 훨씬 쉬워집니다.
마치 실험실 속에 가운을 입고 연구하고 있는 듯한 느낌이 들기도 하죠.
그리고 원하는 코드를 break point 걸고 싶을 때도
간단하게 테스트 코드만 추가함으로서 몇 초안에 각 변수들이 실행시점에 어떤 값을 가지는지를 눈으로 직접 확인할 수 있습니다.
- 박피디님의 “Test-Driven Development, A Year Later” 중

나는 아직 그런 혜택도 못 받았고 그런 경험도 없지만 믿고 더 깊게 파고 들어 봐야겠다.

Share and Enjoy:

게임 업계에서의 Agile과 TDD

정의의소 — Tue, 21 Aug 2007 16:11:56 +0000

평소에 Agile과 TDD에 관심이 많았다.
Agile 중에서는 XP에 대해서 관련 프로젝트도 참여해 보았다. 충분한 가능성을 본 프로젝트이다.
TDD는 김창준 씨도 우리 팀에 오셔서 세미나를 하셨으나 그 당시에 우리 팀의 현실(수준?)에 맞지 않아 실천을 못 했다.
지금도 회사 내 다른 프로젝트에는 TDD를 적용하는 과제도 있을지 모르나 아직 대부분의 PL들은 큰 관심을 두지 못하는 것 같다. 앞선 글에서도 이야기했지만 지금 우리 회사는 변화고 있다. 그것이 느껴진다. 그래서 내가 열심히 해 보려고 하는 이유이다.(아~ 긍정적인 마인드..ㅋㅋ ㅡㅡ;)

Agile 중에 최근에 관심을 두게 된 것이 Scrum이고 TDD는 조금 더 깊게 들어보고 싶어 이리저리 검색을 해 보았다.
나만 몰랐는지는 모르겠지만 게임업계에서 Agile과 TDD 적용 사례에 관한 많은 글이 포스팅되고 있었다.
아래는 그 포스트 중 관심 있게 본 글 들이다.
우리가 회사에도 적용을 위해서는 많은 이들의 공감대와 Best Practice가 필요하다.
회사 블로그에 명준이가 적은 말이 공감된다.

어떤 방법론을 맹신하는 것은 바보같은 일이다. XP를 해도 실패할 건 실패하고,
Waterfall 모델로도 성공하는 프로젝트도 있다.

하지만 만약 유연한 변화 관리 모델과 명시적이고 간단 명료한 성과확인이

자주 이루어져서, 개발 업무에 도움을 준다면??

RUP를 경험해본 나로서는 Agile의 간단하면서도 직관적인 추적과 표기법이

무척 맘에 든다.

- 명준

Agile :
http://mypage.sarang.net/tt/143
마이에트라는 게임 개발사에서 적용한 애자일 방법을 소개함

http://betterways.tistory.com/9
High Moon 스튜디오에서 게임 개발시 애자일 방법을 이용함

http://betterways.tistory.com/183
애자일 게임 개발: 최전선의 이야기(Agile Game Development:Tales from the Trenches)

http://twiny.tistory.com/1654
기민한 방법론을 사용한 게임개발 (Paper Burns: Game Design With Agile Methodologies)

http://betterways.tistory.com/51
실전 애자일 게임 개발 (Agile Game Development From The Trenches)

TDD :
http://betterways.tistory.com/96

Share and Enjoy:

기본이 바로 선 나라 » 테스트

Test 관련 Groups & Blog

Related posts

탐험적 테스팅 (Exploratory Testing)

Related posts

테스터가 바라본 크롬(Chrome)

Related posts

테스트는 누가해야 하는가?를 읽고…

Related posts

‘행위의 중복’을 없애는, 사람을 위한 자동화

Related posts

소프트웨어 테스팅 법칙 293가지

Related posts

2007 ASTA Software Testing Conference & Tutorials

Related posts

프로젝트를 성공시키는 지름길「테스트 용이성」

Related posts

Test-Driven Development, A Year Later

Related posts

게임 업계에서의 Agile과 TDD

Related posts