“개발자도 알아야할 소프트웨어 테스팅 용어”에서 혼용해서 함께사용되곤 하는 용어를 찾아보았습니다.

Fail : 실제 결과가 예상 결과와 비교하여 다를 경우 테스트는 실패라고 간주됨. (A test is deemed to fail if its actual result does not match its expected result.)

Failure : 컴포넌트나 시스템이 예상된 인도(delivery)나 서비스 또는 예상 결과와 실제적인 편차를 보이는 것. (Actual deviation of the component or system from its expected delivery, service or result.)

Fault : Defect 참고

Defect : 필요한 기능을 수행하지 못하도록 하는 컴포넌트나 시스템 상의 결점. 결함의 예는 부정확한 구문이나 부정확한 데이터 정의 드이다. 실행 중에 결함이 발생할 경우, 컴포넌트나 시스템의 장애(failure)를 야기시킬 수 있다. (A flaw in a component or system that can cause the component or  system to fail to perform its required function, e.g. an incorrect statement or data definition. A defect, if encountered during execution, may cause a failure of the component or system.)

Error : 부정확한 결과를 초래하는 인간의 활동. (A human action that produces an incorrect result.) 일반적으로 프로그래머에 의하여 생성된 실수(mistake)로 프로그램의 결함으로 나타난다.

제가 이것을 왜 정리했냐면 테스트에 대한 결과(효과)를 정리하는 과정에서 Test Case에 대한 Fail을
Defect으로 간주해서 그 수치를 늘리려고 하시는 분이 있어서 입니다. 아무리 급해도 그렇지 이건 아니라고 생각합니다.

테스터가 Test Case를 수행하다 실패한 것이 fail입니다. 이 때까지는 이것은 Defect이 아닙니다.  이 fail이 개발 담당자에 의해서 결함이라고 판단 되었을 때 이것은 Defect이 되는 것입니다. 그리고 Defect은 실패의 상황이 아닐 수도 있습니다. 로직의 오류가 인스펙션을 통해서 발견되어, 실제로 어떤 상황(문제)으로 나타나지 않더라고 이것은 Defect이라고 할 수 있습니다.

이런 말을 적는 저도 참 답답합니다만… 그 분도 참 답답합니다. ㅡ,.ㅡ;

 

All About Agile Bolg에서 Agile 관련해서 최근에 올라온 흥미있는 글이라고 올라왔습니다.
나중에 읽어보기 위해서 기록용으로 포스팅합니다.

Agile 관련해서 괜찮은 내용도 많이 있으니 All About Agile에 한번 방문해 보시죠? ^^;

How good are you at single-tasking? – by Christophe Louvion

7 Principles of Lean Software Development – by pbielickie

Scrum: The Experimentation Framework – by Artem Marchenko

Mike Cohn Interviewed by Jurgen Appelo

The Role of the Business Analyst in Agile Projects – by Shane Hastie

Video Interview on Agile Testing – by James Bach

Self Organized Does Not Mean Self Directed – by Glen Alleman

Top 10 on AgileSoftwareDevelopment.com – by Artem Marchenko

User Stories Gone Wild! – by Chris Sterling

Self Managing Teams Outside of Agile – by Damon Poole

 

이 버그를 누구에게 넘겨 줄 것인가?하는 글에 대한 Ray 님의 블로그 포스팅을 따라가서 김성훈 교수님에 대해서 알게 되었다.
아래는 “김성훈 교수와 일해보세요“에 나와있는 김교수님에 대한 소개이다.

김성훈 박사는 홍콩과학기술대학 (Hong Kong University of Science and Technology, HKUST 이하 홍콩과기대) 컴퓨터 공학과 조교수로 일하고 있습니다. 그는 1995년 세계 최초의 한글 검색엔진인 “까치네”를 개발했고 (주)나라비전에서 6년간 CTO로 근무하면서 깨비웹메일의 개발을 이끌었습니다. 2000년 미국으로 건너간 그는 프로그램을 개발하면서 느낀 불편한 점을 바탕으로 소프트웨어 공학 (효과적으로 소프트웨어 버그를 찾는 연구) 으로 2006년 캘리포니아 주립대학교 Santa Cruz에서 박사학위를 받았으며 2006년 부터 2008월까지 MIT 프로그램분석 연구실에서 버그 검출에 대한 연구를 진행하였습니다.

그의 논문들은 소프트웨어 공학의 최고 저널인 IEEE Transaction on Software Engineering 등에 게재 되었고 2007년 International Conference on Software Engineering 에 발표된 그의 논문은 한국인 최초로 최우수 논문상을 수상하기도 했습니다. 그는 자동화된 테스팅 및 버그 검출기술, 소프트웨어 history 마이닝, 동적/정적 분석기술 등의 개발로 안정화된 프로그램을 만들고 프로그래머들이 더욱 신나게 일할 수 있는 방법을 연구하고 있습니다.

그의 최근 주요 논문:

ReCrash: Making software failures reproducible by preserving object states
by Shay Artzi, Sunghun Kim, and Michael D. Ernst.
In ECOOP 2008
Object-Oriented Programming, 22nd European Conference, (Paphos, Cyprus), July 9-11, 2008, pp. 542-565.
Details. Download: PDF, PostScript, ReCrash implementation.

Classifying Software Changes: Clean or Buggy?
by Sunghun Kim, E. James Whitehead, Jr., and Yi Zhang.
IEEE Transactions on Software Engineering, vol. 34, no. 2, March/April 2008, pp. 181-196.
Details. Download: PDF.

Predicting faults from cached history
by Sunghun Kim, Thomas Zimmermann, E. James Whitehead, Jr., and Andreas Zeller.
In ICSE’07, Proceedings of the 29th International Conference on Software Engineering, (Minneapolis, MN, USA), May 23-25, 2007, pp. 489-498.
Details. Download: PDF.

김교수님은 현재 소프트웨어 스토리라는 블로그를 운영하고 있다.
거기서 Dissertation Defense 슬라이드가 소개되어 있었는데 내가 계속 관심을 가지고 우리회사에서 가장 필요한 일 중의 하나라고 생각했던 것이 소개되어 있었다.
버그를 잘 찾는 것과 그에 대한 해결에만(물론 이것도 중요하다) 집중되어 있는 현재 상황을 극복할 수 있는 방법중의 하나라고 생각했던 것이다.

김미령 박사의 “Analyzing and Inferring the Structure of Code Changes“도 흥미있었는데 이 두 부분에 대해서 잘 적용하면 우리가 만들고 있는 툴로도 많은 효과를 가지고 올 수 있을 것 같다.

<Adaptive Bug Prediction by Analyzing Project History>

나의 연구는 소프트웨어 개발 history에서 버그 패턴을 찾아 보는 연구이다. 어느 부분에 버그가 집중되는지를 캐쉬알고리즘으로
풀었고 소프트웨어에 변화가 생길때마다 이 변화에 버그가 있는지를 학습하여 새로운 변화가 있을때 버그가 있을지를 예측하는 연구였다.


조금 있으면 김교수님은 홍콩으로 가실 것 같은데 그 전에라도 우리 회사의 문제에 대해서 이야기하고 김교수님의 생각을 들어보는 자리가 있었으면 좋겠다. 일단 연락부터 한 번 드릴까? ^,.^;

최근에 Agile과 CMMI, 조직 문화에 대해서 공부하고 있었는데 잼난 것을 찾은 것 같아 흥분된다. 이런 시국에는 역량 강화를 할 수 있는 절호의 기회다. 열심히 공부하자.. 푸핫…

 

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

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

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

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

Groups

Blog


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

 

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

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

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

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

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

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

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

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

 
크롬에 대한 평가는 많은 블로거들이 해 주셨다. 그러나 그 기능의 대단함도 있지만 이것을 어떻게 개발하고 테스트를 하는가를 보면 더 대단하다는 것이 느껴진다.
테스팅업무를 하고 있으니 테스터 관점에서 크롬을 바라보면 대단하다고 할 수 밖에 없다.(그래도 버그가 많은 건 어쩔 수 없다.ㅡ,.ㅡ; 그 과정을 보자..)
구글 개발자 센터에서 살펴보면 모두 다 자동화 되어 있고, 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을 따로 가지고 있다.
    : 버그 리포트 가이드 라인, 테스트 플랜, 그 외 관련 문서들이 정리되어 있고 업데이트 되어 있다.

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

 

EUREKA ITEA 소프트웨어 클러스터 Agile 프로젝트의 결과는 유럽 제조회사들이 현저하게 더 짧은 시간과 더 적은 비용으로 고품질의 임베디드 소프트웨어 개발을 가능하게 만들었다.

본 방법을 항공과 통신부터 소비재 전자재품까지의 산업 전반에 걸친 68번의 파일럿 사례 연구에 적용하여, 본 프로젝트는 ‘민첩(agile)’ 방법론이 임베디드 소프트웨어공학에 대단한 발전을 이끌 수 있음을 확실히 보여주었다. 알맞은 세공(suitable tooling)은 민첩 방법론의 어플리케이션을 단순화 하는 것으로 설명된다. 결국, 더 많은 소프트웨어 개발이 아시아에 아웃소싱을 주는 것보다 오히려 유럽에서 하는 것이 비용 효과적으로 실행될 수 있다.

전자기기에서 임베디드 소프트웨의 사용은 전자기기의 발전보다 더 빠르게 성장하고 있다. 과거 십년에 걸쳐 유럽에서 소프트웨어를 생산하기 위한 사람의 능력은 증가하지 않았다. “소프트웨어의 양은 매우 급속도로 증가하고 있고, 그것을 개발하는데 필요한 사람과 자원을 찾는 것은 더 어려워지고 있다. 결국, 유럽은 많은 개발 작업을 인도나 다른 나라에 외주를 주고 있다. 추가적인 문제는 충분한 신뢰도를 가지고 적기에 시장에 출시할 수 있도록 하는 개발 속도에 있다”고 핀란드의 VTT 기술 연구소의 프로젝트 코디네이터인 Pekka Abrahamsson 박사가 설명하였다.

그래서 Agile은 더 빠르고 신뢰성 있는 소프트웨어 시스템을 개발하고 변하는 시장의 요구에 맞추는데 필요한 프로세스와 기술에 초점을 맞추었다. “민첩성(agile)은 미국에서 8년 전에 나온 소프트웨어 개발에 관한 새로운 패러다임이다. 우리가 2004년에 ITEA 프로젝트를 시작하였을 때, 우리는 이러한 새로운 방법론이 항공, 통신, 자동차, 소비재 전자기기의 임베디드 소프트웨어를 위하여 개발될 수 있을지 알지 못하였다”고 Abrahamsson 박사가 말하였다.

이러한 새로운 패러다임에 기초가 되는 원칙 중 하나는 프로젝트에서 말미 때라도 변화를 기꺼이 받아들이라는 것이다. 변화는 항상 매우 문제가 되는 것처럼 보여왔지만, 민첩 방법론으로 제품이 시장에 투입되기 전 며칠 동안 새로운 특징(feature)을 추가하는 것이 가능하다.

게다가, 소프트웨어 기반의 특징은 종종 소비자에 의하여 효과적으로 사용되는 시스템에서 제공되는 특징의 5%만 가지고 빈약하게 사용된다. “우리는 시장에서 첫 번째로 소비자들을 얻는데 강조점으로 사용되는 중요한 특징을 확인하기 위하여 이것을 호전시켰다. 그래서 소프트웨어를 개발 중일 때, 우리는 항상 기술적인 문제에 대하여 이야기하지 않지만 비즈니스 수준의 문제에 초점을 맞춘다. 이것이 우리가 개발한 방법론의 일부분”라고 Abrahamsson 박사가 말하였다.

EUREKA 명칭(labelling)은 프로젝트를 위하여 지어진다. 왜냐하면 연관된 8개국 컨소시엄이 강한 산업 참여를 하고 있기 때문이다. Abrahamsson 박사는 “EUREKA 프로젝트의 경우 EU 프레임워크 프로그램 프로젝트(EU Framework Programme projects) 보다 관료가 훨씬 덜 관여한다. 게다가 당신은 산업 파트너의 수요를 더 잘 만나도록 프로젝트의 방향을 바꿀 수 있다. 이것은 EUREKA의 확실한 장점이다. 게다가 ITEA는 연단위로 만나는 커뮤니티를 제공한다. 나는 산업과 학계가 그들의 능력을 강화하는 이러한 큰 네트워킹 요소를 찾는다고 생각한다”고 지적하였다.

민첩 기술(Agile technology)은 개발 시작부터 끝 프로세스까지 걸쳐 있지만, 대부분 실제 프로세스와 기법 그리고 도구에 초점이 맞추어져 있다. “가치 집합과 12원칙 집합은 우리가 이러한 방법으로 왜 운영해야 하는지에 대한 이론적 기반을 제공한다. 그리고 그 프로세스는 월 주기 또는 2주 주기로 납품을 갖는 틀로 짜여져 있는 매우 빡빡한 시간이다. 이전의 방법론에서 우리는 3개월, 6개월 또는 1년 주기의 작동 시스템을 납품하려고 시도했었다. 이러한 짧은 주기는 대형 하드웨어 범위의 시스템 개발에 대한 생각에 대한 근본적인 변화를 요구한다. 매 2주 또는 매월 납품하는 능력이 요구된다. 그래서 전체 시스템을 고쳐 생각하는 것이 요구된다. 또 다른 중대한 요소는 투자가 요구되지만 이득이 매우 확실한 기술적 원인에 의한 것”이라고 Abrahamsson 박사가 말하였다. 게다가, Agile는 항공과 같은 높게 통제된 산업의 수요에 맞추는 방법을 고안하였다.

68건의 파일럿 개발품들은 17개의 회사의 1800명의 소프트웨어 공학자들이 연관되어 수행되었다. “우리는 리드 타임(lead time)과 비용을 70% 이상 줄이는 것을 달성할 수 있다고 본다. 만일 이러한 결과가 더 큰 범위의 유럽의 소프트웨어 개발에 승인될 수 있다면, 그것은 다른 방법보다 유럽에서 더 싸게 아웃소싱을 하게 될 것”이라며 Abrahamsson 박사가 말하였다.

Agile 프로젝트는 이러한 아이디어를 사용할 수 있는 12개의 도구를 개발하는데 성공하였다. 이러한 도구들 중 3개는 이미 상업화를 준비하고 있다. 그리고 벨기에 파트너인 E2S로부터 ATO 도구는 이미 거래되고 있다. 게다가 노키아와 같은 몇몇 파트너는 민첩 모드(agile mode)를 채택하고 있다. 이것은 전체 생산체제가 바뀌게 됨을 의미한다.

“우리는 시간, 비용, 품질에 대한 모든 영역에서 극적인 개선을 달성할 수 있는 벤치마킹을 하였다. 인도와 다른 나라에 있는 개발팀들이 이러한 지역에서 지금 그들 자신의 기술을 세우고 있다. 유럽은 몇 년간 지속되는 경쟁적인 우위를 갖고 있다”고 Abrahamsson 박사가 말하였다.

임베디드 민첩 연구소의 설립과 ITEA2 FLEXI 프로젝트의 Agile 결과는 비즈니스 및 혁신 프로세스로써 방법론을 확장할 것이다.
<원문 링크>

번역은 회사 어떤 분이… ^^;


 

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 뿐만 아니라, 시스템 전체를 고려한 설계와 개발이 이루어지고 함께 테스트가 진행되어야 더욱 빠른 개발을 할 수 있다고 생각합니다.

 

새로운 과제를 시작하면서 Remind 차원에서 다시 정리해 봅니다.

우리는 직접 개발하면서도 또 남이 개발하는 일을 도와주면서 소프트웨어 개발의 더 나은 방법을 발견하고 있다. 이 작업을 통해 우리는 아래 것들을 가치 있게 여기게 되었다.

  • ‘프로세스와 도구’보다는 ‘개인과 상호작용’
  • ‘포괄적인 문서화’보다는 ‘동작하는 소프트웨어’
  • ‘계약 협상’보다는 ‘고객과의 협력’
  • ‘계획 준수’보다는 ‘변화에 대응’

이 말은, 욎쪽에 있는 것들에도 가치가 있긴 하지만, 우리는[footnote]null[/footnote] 오른쪽에 있는 것들에 더 많은 가치를 둔다는 것이다.

© 2001, 애자일 선언 입안자들

더 많은 정보는 http://agilemanifesto.org/를 참고하세요.
- Practices of an Agile Developer 中…

 

Ship It 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드“를 다시 읽었습니다.

새로 시작하는 과제에 개발과 함께 SCM, Process, SQE를 담당하기로 하였습니다.
Scrum 적용부터 제가 하고 싶은 것을 함께 적용할 기회를 가지게 되었습니다.
팀원들에게 어느 정도 호응도 얻었습니다. ^,.^;

그래서 과제를 진행하는데 있어 몇 가지 정리할 것이 있어 Ship It을 다시 읽게 되었습니다. 그래서 부록에 있는 Tip 조언 요약을 정리해 봅니다. 아래의 글에서 나중에 글들이 링크될 수 있습니다. 어떻게 인프라와 프로세스를 구축했고 어떻게 팀원들을 설득했으며 어떤 문제로 어려워하고 있는지를 이 글을 기준으로 시작하려고 합니다.

앞으로 재발행될 요지가 큰 포스트입니다.ㅎㅎ

- TIP 조언 요약 -

  1. 습관을 고르세요.
  2. 모래 상자 안에 머무세요.
  3. 필요한 거라면 체크인하세요.
  4. 첫날에 빌드를 스크립트화 하세요.
  5. 어떤 컴퓨터에서라도 빌드가 되어야 합니다.
  6. 지속적으로 빌드하세요.
  7. 지속적으로 테스트하세요.
  8. 모두가 잊어버리는 사태는 피해야 합니다.
  9. 제품을 작동시켜보세요 – 테스트를 자동화하세요.
  10. 유연하고 많은 사람이 사용하는 테스트 장비를 사용하세요.
  11. 업무에 가장 적합한 도구를 사용하세요.
  12. 공개된 포맷을 사용해서 여러 도구를 통합하세요.
  13. 임계 경로 기술에 친숙해지세요.
  14. 목록에 따라 일하세요.
  15. 기술 리더가 알아서 하게 놔두세요.
  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. 항상 피드백을 빨리해 주세요.


© 2012 기본이 바로 선 나라 Suffusion theme by Sayontan Sinha