EMOCON 2015 - 품질과 테스트는 다르다

본 자료는 1920x1080의 와이드모니터에 최적화 되어 있습니다.

품질이랑 테스트는 다른 거, 이해하고 실무에 적용할 수 있는 자그마한 이야기

EMOCON, 2015 – 두 번 째 날, 끝에서 두 번 째 이야기

※ 본 발표의 내용은 이상한모임의 의견이 아닌 발표자 개인의 의견임을 고지합니다.

(1) 본 발표의 자료는 간결하고 짧게 핵심 내용을 전달하지 않았고, 않겠습니다. 이 자료가 좋은 자료는 아닐 것 같습니다. 다만, 발표자로서 전달 드리고 싶은 내용들은 모두 전달하려 노력하였으며, 언제든 다시 돌려보기 하시면서 필요한 내용들을 들으실 수 있는 수준으로 제작하려 노력하였습니다.

(2) 본 자료는 품질에 관심이 많지만 세미나 참석이 어려운 실무자들을 위한 자료입니다. 품질에 관심이 없으시거나 학교에 재학 중이신 분들은 이해가 어려우실 수 있습니다. 내용이 어려우시다면 품질에 조금만 관심을 가져 주세요.

(3) 발표 시간이 새벽 시간이라 질문과 답변을 충실히 이행할 수 없을 듯 합니다. 본 발표에 대한 질문과 답변은 마지막 페이지에서 제공되는 google docs로 구성된 설문 페이지에서 진행 됩니다. 발표를 들으신 분들은 감상평을 적어 주세요. 참여하시는 분들 중 추첨하여 소정의 상품을 제공할 예정입니다. (기본적인 예의범절을 지키지 않은 내용은 무시하겠습니다.)

저작권 알림

본 자료에서 사용한 컨텐츠들은 카피레프트의 취지에 맞지 않을 수도 있는 인터넷에서 수급한 자료들로 이루어져있습니다. 그렇기에 본 자료에 등장하는 PPT의 원본파일에 대한 공개는 고려 후 결정하겠습니다. 저작권이 존재하는 자료들을 사용하였기에 비영리 목적이나 자료 공개는 어려울 것으로 예상하고 있습니다. (알아 보겠습니다.) 다만, (컨텐츠가 아닌) 본 자료를 통해 오늘 제가 언급한 내용들은 그 사실 여부나 옳고 그름을 떠나 제가 공부하고 이해한 내용들로 이루어져 있으므로, 누구라도 얼마든지 인용가능하며 상업적 목적의 사용을 허가합니다. 오히려 품질에 대한 실무 관점의 기본 이해가 널리 퍼지기를 기원합니다. 다만, 카피레프트 적용 시 소스 공개 원칙에 따라 오늘 말씀 드린 내용이 혹시라도 도움이 되셔서 또 다른 발표나 방송, 자료 등을 제작하신다면 해당 원문이 저에게서 언급되었음을 청중들에게 자그마하게 언급해 주신다면 저는 충분히 감사 드리겠습니다. • 전체 폰트 : 네이버 나눔고딕 • 커버 & 엔딩페이지 배경 : https://imageshack.us/user/syndicates (저작권 고지가 없어 확인 못함) • 그 외 : 각 페이지 내에 원본 출처를 기입하려 노력하였음 (다 기입하지 못한 것은 저작권자의 고지에 따라 삭제 가능)

카피레프트(copyleft)란 독점적인 의미의 저작권(카피라이트, copyright)에 반대되는 개념이며, 저작권에 기반을 둔 사용 제한이 아니라 저작권을 기반으로 한 정보의 공유를 위한 조치입니다. 카피레프트를 주장하는 사람들은 보통, 지식과 정보는 소수에게 독점되어서는 안 되며, 모든 사람에게 열려 있어야 한다고 주장랍니다. (위키피디아 참고) 소스코드 공개 의무가 발생하는 라이센스는 상호주의(reciprocal) 혹은 copyleft 라이센스라고 하며, 그 결과물이 원 소프트웨어의 파생물(derivative work)일 경우 소스코드를 공개해야 합니다. (KLDPWiki 참고)

EMOCON 2015의 저작권이 아닌 본 자료의 개별 저작권 알림입니다. 본 자료는 카피레프트의 취지를 따릅니다. 본 자료의 제작자는 1998년 처음 웹개발로 코딩을 시작할 때부터 리눅스를 흠모하며 오픈소스와 카피레프트 진영의 편에 서 있으려 노력했으며, 인류는 가능한 모든 지적 재산물을 (무료까지는 아니라도) 저가로 나누어야 한다고 굳게 믿습니다. 또한 가능하다면 돈과 쇼핑몰이라는 개념 대신 개개인의 노력의 가치를 판단할 수 있는 물물교환이 성립되는 사회가 더 훌륭한 사회임을 강력히 믿습니다.

COPYLEFT all WRONGS reserved @ xelion.pe.kr 그리고 weirdmeetup.slack.com, 2015 EMOCON 품질이랑 테스트는 다른 거, 이해하고 실무에 적용할 수 있는 자그마한 이야기

ⓒ

팝콘 : http://egloos.zum.com/urlkn74/v/10971107 나초 : http://www.oeker.net/m/bbs/board.php?bo_table=group&wr_id=548449&sca=&sfl=&stx=&sop=and&page=5 종로 맥주창고 : http://www.erumf.com/jumpo/app/view/product/product_list.asp?page=7&biz_type=A&biz_sub_type=&stuff_case=&ordertype=&userid=&stuff_type= 건대 맥주창고 : http://hermoney.tistory.com/874 팝콘 기계 : https://www.menupan.com/Restaurant/GoodRest/GoodRest_View.asp?ID=151071 좋아요 표시 : 페이스북 http://www.facebook.com 김익환 대표님 책들의 썸네일 : 액티브액스 없는 결재 – 알라딘 서점

3

(사진은 실제 이야기의 이미지가 아닌 참고용)

+

비슷한 상황,……….. 왜 선택이 나뉠까요?

품질과 테스트 이야기

(1) 감상평 + 질문&답변 (상품 있음)

(3) 이상한 모임 (가입) : [email protected]로 메일 요청 : https://weirdmeetup.herokuapp.com

(2) 네이버 SW Tester 카페 : http://cafe.naver.com/swtester

(김익환님의 저서 중 1개)


ⓒ

3번 그림 : http://freeflaticons.net/gadgets-flat-icons/crowd-people-flat-icon 5번 그림 : MBC 무한도전 6번 그림 : http://if-blog.tistory.com/406 9번 그림 : http://www.welovesolo.com/electrum-glow-circle-abstract-background-psd/ 왼쪽 하단 그림 : http://www.wellingtonatwork.com/wellness/ 화이트보드 그림 : https://pixabay.com/ko/photo-303145/

4

품질이란 무엇인가

그래서 결론은?? ?

과거에 자신이

경험했던 기분 좋은

무엇!!

좋은 기억은 나쁜 기억보다

구체적이다

불가능 하지 않다 단지, 너무

복잡한 것이다

사용자에게 필요한 이익을

전달하는 것

요구사항 분석

(고객 관점 품질)

이익 증대

(사업 결과)

공정 향상

(프로세스 품질)

•다양한 관점을 가진 다양한 이해관계자 ★keyword! •회사란? 이익 창출을 위해 함께 하는 사람들의 모임 •그러므로 고객 관점의 품질은 가장 중요함 •좋은 것과 옳은 것의 구별 필요 •사업의 규모가 커지고 대규모 운영이 시작되는 시점에서는 ‘과정에 대한 증명’, 즉 ‘프로세스 품질’이 수반 되어야 함 •유지보수비용/운영비용 감소가 필요하기 때문

초기 : 품질 비용 = 마케팅비용 + 시장 진입 비용

확장 : 품질 비용 = 시장 점유 비용 + 시장 확장 비용

운영 : 품질 비용 = 유지보수 비용 + 대응/운영 비용


ⓒ

Galaga : Namco, 1981 Xevious : Namco, 1982 World of warcraft : Blizzard, 2004 아이온 : NCSoft, 2008 배틀크루저 : http://futurewarstories.blogspot.kr/2013/06/fws-ships-of-linethe-battleship-and.html 문화차이 : http://thearticulateceo.typepad.com/my-blog/2011/09/cultural-differences-the-power-distance-relationship.html

5

Galaga Xevious WoW Aion

그래픽 하 하 상 상

스토리 하 하 상 상

캐릭터 중 중 상 상

적 AI 중 중 상 상

공격패턴 하 하 상 상

수비패턴 상 상 상 상

(실무에서는 더 자세한 분류가 되겠지만…) 아마도 대략 이런 결과…

그런데 우리가 내일 우주로 나간다면?

2015년 기준으로 우리가 품질평가를 한다면?

품질관리를 할 때 고려 해야 할 인식의 차이들 • 사회적이고 관습적인 • 역사적인 • 분야별 • 사용자 별 • 목적별(기능별) • 그 외 기타


ⓒ

사진 : https://nmla.org/authors/gerald-weinberg/ 프로젝트 설명 : http://www.testingreferences.com/testingtimeline/testingtimeline.jpg 저서 설명 : https://en.wikipedia.org/wiki/Gerald_Weinberg 번역서 정보 : http://www.aladin.co.kr/shop/wproduct.aspx?ItemId=34228223

6

Quality is value to someone. 품질은 누군가에게 가치이다. - Gerald Jerry Weinberg

<인물 소개> 1959–1963년까지 미국방성에서 진행된 인간 우주 비행 프로그램인 Project Mercury에서 프로젝트 관리자로 참여하여 세계 최초의 소프트웨어 테스트 팀을 만드신 분

<저서> 1971. The Psychology of Computer Programming. Silver Anniversary Edition (1998) (한국어 번역서 : 프로그래밍 심리학, 번역자 조상민, 인사이트) 1975. An Introduction to General Systems Thinking. Silver Anniversary Edition (2001) 1982. Are Your Lights On?: How to Figure Out what the Problem Really is. 1986. Becoming a Technical Leader: An Organic Problem-Solving Approach 1986. Secrets of Consulting: A Guide to Giving and Getting Advice Successfully 1988. General Principles of Systems Design. With Daniela Weinberg 1992. Quality Software Management: Anticipating Change. Vol. 1: Systems Thinking 2002. More Secrets of Consulting: The Consultant's Tool Kit 2005. Weinberg on Writing: The Fieldstone Method 2008. Perfect Software: And Other Illusions about Testing 2010. Freshman Murders


ⓒ

프로젝트 성과 정의 : NIPA SW공학 백서 SW프로젝트 품질비용 정의 : NIPA SW공학 백서 PMBOK 정의 : Project Management Body of Knowledge 참고 PDCA : https://commons.wikimedia.org/wiki/File:PDCA_Cycle.svg

7

품질(Quality)

어떤 개체가 명시적이거나 암시적인 요구사항을 만족시키는 능력을 나타내는 전반적인 특성 (ISO8492)

품질관리 (Quality Management)

수행된 프로젝트가 요구사항을 만족하는지를 품질정책, 목표, 책임을 결정하도록 수행 조직의 프로세스와 활동들을 포함하는 과정.

품질비용 (Cost of Quality, 품질원가)

제품과 서비스를 만드는데 사용된 모든 비용. 여기에는 예방비용, 평가비용, 내부실패 비용, 외부실패 비용, 고객의 요구를 초과하여 충족시켜주기 위한 비용, 그리고 상실한 기회의 비용 등이 포함.

품질보증 (Quality Assurance)

Managerial Process for Quality (관리적인 측면)

ISO8402, 품질 감사

품질통제 (Quality Control)

Technical aspect for Quality (기술적인 측면)

적합 감시, 합부 판정

=

프로젝트 관리(Project Management)는 착수, 기획, 실행, 감시, 통제, 종료의 형태로 이루어져 있으며 이는 PDCA cycle의 프레임을 차용한 방식.

• P = Plan = 계획, 설계 등을 의미

• D = Do = 실행, 구현, 관리 등을 의미

• C = Check = 검토, 점검 등을 의미

• A = Act = 조치, 개선 등을 의미

프로젝트 성과 정의

▶ 납기성과: 고객과 합의한 프로젝트 종료일을 준수하였는지를 나타내는 지표

▶ 비용성과: 고객과 계약한 프로젝트의 계약 비용과 프로젝트 종료 시점의 실적 내용을 분석한 지표

▶ 품질성과: 프로젝트 종료 후 수집된 운영 결함밀도(3개월)에 응답한 프로젝트 평균 기준으로 분석

SW프로젝트 품질비용 정의

① 예방비용 : 결함발생을 방지하기 위해 수행하는 활동에 대한 비용

② 평가비용 : 주입된 결함을 찾는 데 투입되는 비용

③ 내부 실패비용 : 내부적으로 결함을 수정하기 위한 재작업 비용

④ 외부 실패비용 : 외부에서 발생한 결함을 수정하기 위한 비용으로 오픈 이후 결함 조치나 납기지연으로 인해 추가되는 비용


ⓒ Reliability 그림 : http://www.dreamstime.com/photos-images/reliability.html\

QA QC Test

핵심 개념 Did right thing has been done right? 올바른 일들이 올바르게 처리되었는가?

Does everything meet its requirement? 모든 것들이 요구사항을 만족하는가?

Finding error!! 에러를 찾는 것!!

영역 프로젝트 제품 정의 불가 – 작은 단위 모듈 기능부터 사용자 경험까지

핵심 활동 프로세스 개선 활동 개선에 필요한 데이터 수집 활동

활동 방향 데이터를 기반으로 가설을 설정하고 프로세스를 개선 데이터를 기반으로 증명하고 개선 데이터를 통해 가정/가설을 증명, 개선됨을 확인 8

HW와 SW 공정 내에서의 활동 구분

1. 소프트웨어의 특징

2. 소프트웨어는 무형적인 성격 때문에 측정하기가 쉽지 않음

• 개발 공정 내 변화가 많음, 쉬움

• 소프트웨어는 작동하는 데에 필요한 의존성이 높은 경우가 많음

3. 소프트웨어는 재료가 사람

• 맛있는 과일 샐러드를 잘 만들기 위해서는 과일의 신선도를 유지하는 것이 관건

• 좋은 목공예 제품을 만들기 위해서는 적합한 재료를 잘 관리하는 것이 관건

• But SW에서는 개발자들을 지속적으로 100% performance로 유지하는 것이 불가능

4. 이를 해결하기 위해 SW 분야에서는 “소프트웨어 공학 – 방법론”이 발달

하드웨어 종속적

무형적 (소스 코드)

수정이 용이 개발 공정이

난해함

많은 내/외부 의존성 존재

적은 비용 복제 수월

1. 하드웨어에 대한 사용자가 느끼는 품질 = 가격 대비 성능

2. 하드웨어의 성능이란?

• 긴 수명

• 내구성

3. 하드웨어의 기능 요소

• 설계한 대로 작동하는 지

4. 하드웨어의 비기능 요소

• 부품 교체에 대한 용이성

• 사용 편의성

5. 이를 해결하기 위해 제조 분야에서는 “신뢰성 공학”이 발달


ⓒ

9

시스템 테스트 통합 테스트

1. 시스템 테스트를 진행할 때는 요구사항에 맞게 시스템이 정상적으로 작동하는 지를 총체적으로 테스트함

1. 통합 테스트를 진행할 때는 독립 모듈이 잘 작동하는지, 혹은 여러 개의 모듈이 그룹으로 통합될 시 정상적으로 작동하는 지 테스트함

2. 시스템 테스트를 진행하는 테스터들은 기능과 비기능(성능, 부하, 피로도, 보안, 복구 등) 모두에 대해 집중해서 진행해야 함

2. 통합 테스트를 진행하는 테스터들은 두 개 이상의 모듈이 합쳐지는 것을 “기능”으로 정의하고, 이에 집중해야 함

3. 이 테스트를 수행하기 위해서는 통합 테스트가 먼저 수행되었어야 함

3. 이 테스트를 수행하기 위해서는 단위테스트가 먼저 수행되었어야 함

4. 요구명세를 기반으로 진행 4. 인터페이스 명세를 기반으로 진행

5. 시스템 테스트는 코드에 대한 테스트를 수행하지 않음 5. 통합 테스트는 통합되는 구조에 대해 테스트 수행

6. 밑거름이 될만한 프레임워크가 필요치 않음 6. 바탕이 되는 프레임워크가 필요함

7. 시스템 테스트를 진행하는 테스터들은 시스템 기능에 집중함

7. 통합 테스트를 진행하는 테스터들은 모듈들의 통합에 집중함

8. 시스템의 기능에 집중하여 테스트 8. 모듈들 간의 통합에 집중하여 테스트

9. 늘상 블랙박스 테스팅 형식으로 진행 9. 화이트박스 테스팅과 블랙박스 테스팅 모두 사용 가능

시스템 테스트와 통합 테스트 비교 QDev에 대한 이야기 • 핵심 내용 : 프로그래머가 잘 하는 분야가 있고, Tester가 잘 하는 분야가 있고, QA가 잘 하는 분야가 있으니 이를 잘 통합해서 사용해 보자는 내용 • 자료 위치 : https://goo.gl/Zp5gGh • 자료 저작권자 : 임도형

우리는 일반적으로 사용하는 QA라는 단어에 대한 고찰 • “QA하자” = Test 하자 •“QA 했어?” = 검증(Verification) 했어? •“개발자 QA 했어?” = 확인(Validation) 했어? •“우리 제품은 QA가 부족해” = 우리 제품은 품질이 낮아 뭔가 좀 잘 못 되었다는 생각이 들어서 오늘의 발표를 준비 했습니다. “QA하자”, “QA 했어?” 대신 “테스트 하자”, “테스트 했어?”라는 이야기를 들을 수 있었으면 합니다.

요구공학 •BA(Business Analyst)라는 키워드는 중요해 질 것으로 예상 •요구공학을 실무적용 강의하는 사람 소개 가능 (연락주세요 ^^)

애자일의 역사 •애자일이 어떻게 발생해서 어떤 방향으로 가고 있는 지도 향후 품질과 테스트에 많은 영향을 줄 것으로 예상 •위치 : http://guide.agilealliance.org/timeline.html


ⓒ

번역 : 현재 발표자 번역 참고 : 위 번역 중 몇 개는 "린과 애자일 개발" 책 참고함 - http://www.aladin.co.kr/shop/wproduct.aspx?ItemId=15210284 원문 출처 : https://www.scrumalliance.org/community/articles/2009/april/top-ten-organizational-impediments#sthash.xkBSoFaX.dpuf

10

10. 조직의 장애물 제거 실패 (Failure to Remove Organizational Impediments) : 아래 장애물들의 제거에 실패하는 경우 조직은 위태로워짐 9. 조직 내 잘 못 가이드된 가격 절감과 시너지 효과 (Misguided Cost Savings and Synergy Efforts) : 전사적인 가격 절감과 시너지를 고려하지 않고, 눈 앞의 국지적 효과를 추구하는 부서는 문제가 생김 8. 교육의 부재 (Lack of Training) : 조직 내 필요한 역량에 대한 학습을 낭비라고 생각함 7. 단일기능 조직 (Single-Function Groups) : 교차기능 조직(Multi-functional group)이 아닌 단일기능 조직으로 업무를 구성 6. 국지적 vs 범용적 최적화 (Local vs Global Optimization) : 단일업무, 혹은 국지적 최적화만 선택해서 전사적인 해결책을 찾지 않음 5. 책의 정보만으로 충분하다고 가정하는 것 (Assumption that Book Learning is Enough) : 자신이 모든 것을 이해하고 있고, 자신의 경험만으로 업무를 이끌며, 외부의 지식 차용하는 것은 불필요하다고 생각하는 것은 옳지 않음 4. 개인 역량 평가와 보상 (Individual Performance Evaluation and Reward) : 소프트웨어에서는 평가와 보상 체계를 개인으로 가져가면 개발자와 관리자를 좌절시키고 팀의 성과를 방해하게 됨 3. 비현실적인 약속들 (Unrealistic Promises) : 비현실적인 약속을 남발하면, 그 조직은 근본적인 원인을 해결하기보다는 현실적인 불끄기에 집중하게 됨 2. 애자일은 개발자에게만 해당한다고 생각하는 것 (Assuming Agile Is All About Developers) : 켄트 벡 역시 애자일을 개발팀에만 도입하면 결과적으로 낭비가 생겨 사업이 어려워지는 것을 보았다는 포스팅을 남긴적이 있음 1. 묘책이 있다고 생각하지만 표면적인 해결방법만 채택 (Silver bullet thinking and superficial adoption) : 근본적인 원인이 있음은 모두 알지만 현실적인 이유로 표면적인 해결방법만을 채택하고 가면 개선은 이루어지지 않음

조직의 장애물 TOP 10


ⓒ 부엌칼 그림 : https://namu.wiki/w/부엌칼 나비 병 그림 : http://m.blog.daum.net/ccsj77/445

11

“위험(Risk)은 품질(Quality)과 어떤 관계가 있는가” 리스크 항목 분석 : 예제는 이상한모임의 2015 이모콘 제가 어떤 테스트 항목을 도출하여 자료를 준비했는가에 대한 내용

(1) 위험 분석 시각 항목에 대한 우선순위를 식별 - 식별된 우선순위 별로 테스트 강도를 정함 (2) 분석된 위험 대비 수행할 테스트 활동들을 준비 - 위험의 정의 : “발생하지 않은 기회와 위협”

결론

위험과 품질의 상관관계

크게 상관 없음 (위험관리는 품질과 매우 상관 있음)

(1) 정확히 표현하면, 해당 제품으로부터 발생하는 위험 대비, 제품이 전달하는 가치가 더 크고 명확할 경우 위험은 사용자들은 일반적으로 해당 위험을 수용(Acceptance)함 (2) 사용자들은 특정 제품이 사용자에게 전달하는 가치가 굉장히 크나, 위험도 역시 그만큼 큰 경우는 사용자 교육 등을 통해 위험 사항들을 회피(Avoidance)하거나 책임을 전가(Transfer)하려는 경향을 보임

위험과 테스트의 상관관계

매우 크게 관련 있음

(1) 예상 가능하여 개발 중 분석된 모든 위험은 테스트되어야 위험이 완화(Mitigation)되며, 해당 위험에 대한 관리 사항은 이후 제품의 유지보수에도 지속적으로 확인되어야 함 (2) 개선(Enhancement)할 수 있는 구간인 지 확인 후 개선되지 못하는 항목인 경우 대응 방안(Contingency plan)을 마련해야 함


ⓒ

12

분석 학파 Analytical School

산업 학파 Factory School

품질보증 학파 Quality Assurance School

정황주도 학파 Context-Driven School

핵심 신념

• 소프트웨어는 논리적 산물 • 테스팅은 목표지향, 엄격함, 포괄적 • 테스팅 기법들은 추론분석적인 형태 • 테스팅은 기법

• 소프트웨어 개발은 프로젝트 • 테스팅은 진행현황을 측정하는 것 • 테스팅은 예측가능성, 반복가능성, 계획 등 반드시 관리되어야 함 • 테스팅은 비용 효율적이어야 함 • 저-숙련 노동자들에게는 방향지정이 필요 • 테스팅은 규칙을 따르는 것

• 소프트웨어 품질에는 훈련이 필요 • 테스팅은 개발 프로세스가 잘 준수되고 있는지를 정의 • 테스터는 개발자들이 규칙을 잘 따르고 있는 지를 감시 • 테스터는 나쁜 소프트웨어를 사용하지 않도록 사용자들을 보호해야 함

• 소프트웨어는 사람에 의해 만들어짐. 사람은 정황을 설정 • 테스팅은 버그를 찾는 활동. 버그는 이해관계자들을 괴롭히는 모든 것 • 테스팅은 프로젝트에 대한 정보를 제공 • 테스팅은 숙련된 정신적 활동 • 테스팅은 전문분야

핵심 명제 • 어떤 기법을 이용해야 하는가? • 어떤 측정기준을 사용해야 하는가? • 지금 올바른 프로세스를 제대로 따르고 있

는가? • 현재 시점에서 어떤 테스트를 진행해야 가장 가치 있는가?

모델의 예 • 코드 커버리지 (Code Coverage) • 구조적 테스팅으로 알려져 있음 • 테스팅의 목표지향적 "측정"을 제공함

• 요구사항 추적 관리 (Requirement Traceability) • 모든 요구사항이 테스트되었는 지 보증

• 수문장 (Gate Keeper) • 소프트웨어는 QA가 '준비되었습니다'라고 말할 때까지는 준비된 것이 아님

• 탐색적 테스팅 (Exploratory Testing) • 테스트 설계와 실행을 동시에 진행 • 빠른 학습

주요 개념

• 정확하고 상세한 사양(specification)은 테스팅을 위한 전제조건 • 테스터는 소프트웨어의 동작이 사양을 준수하는 지 검증

• 테스팅 활동과 다른 활동들 간에 명확한 경계가 필요 (시작/중단 기준 필요) • (추적을 어렵게 만드는) 계획 변경은 지양 • 테일러링주의(Taylorism) • 테스팅 산업 표준, 모범 사례, 자격증 장려

• "테스팅" 보다는 "품질보증"을 선호 • 테스팅은 "프로세스 개선"을 위한 징검다리일 뿐 • 개발자들을 멀리해야 함

• 테스팅 결과 기반 계획 수립, 변화 수용 • 도전받지 않는 가정은 위험함 • 테스트 전략의 효과는 현장 조사를 통해서만 결정될 수 있음 • 사례를 통한 역량 향상에 집중

효과적 사업 형태 • 학문적 • 고-신뢰성 산업 (예, 통신업계)

• IT 프로젝트 • 정부 프로젝트

• 대형 관료 조직 • 스트레스 하에 있는 조직

• 시장 변화, 고객 요구에 빠르게 대응해야만 하는 상용 소프트웨어

위험 기반 테스팅에 대한 관점

• 운영 프로파일을 사용 • 신뢰성 계산

• 위험에 대한 경영관점의 인식에 초점 • 가정-모델링-증명기법(Pseudo-math)을 사용하기도 함

• 프로젝트 위험을 밝힘 • 프로젝트가 통제 불능임을 입증

• 테스팅은 위험에 대한 팀의 이해/인식 개발 • 위험을 식별할 수 있도록 테스트를 설계하는 테스터의 역량 향상

명세 존재 여부에 대한 관점

• 불가능 • 어쨌든 특정 부분의 스펙은 필요함 • 프로세스를 따르도록 강요 • 유용하다고 생각하는 수행 • 감추어진 스펙들을 찾아내기

테스터 자격증에 대한 관점

• N/A • 테스터를 더 쉽게 고용하고, 훈련하고 관리하기 위함

• 역량 향상 • 자격증은 사례에 기반하는 것이지 역량에 기반하지 않음.

소프트웨어 테스팅 4가지 학파 (Four schools of software testing by Bret Pettichord)

※ 번역자 주 : School은 학교라는 의미도 있지만, 무리를 이루어 헤엄치는 물고기들을 의미하기도 합니다. 즉, 본문의 School은 물리적인 의미로서의 "학교"가 아니라, "무리, 군"을 의미합니다. 그러므로, 이는 “진영” 이라는 말로 표현할 수 있지만 단어에 정치적 느낌이 있습니다. 따라서 번역자는 이를 "학파"라는 의미로 치환하여 번역하였습니다.


ⓒ 타임라인 :http://www.testingreferences.com/testingtimeline/testingtimeline.jpg (한글판은 발표자가 제작 중입니다. Static Web으로 제작 중 관리가 안될 듯 하여 DB 사용하려고 다시 설계 중입니다. 2015년 12월 중으로 완료할 예정. 이직으로 개발 중단 상태이나 다시 하려 합니다.)

13


ⓒ

14

(위의 그림은 뒤쪽에서 설명할 페이지 – 뒤에서 다시 설명 예정) • 운영하면서 모인 데이터에 대한 분석 • 제품의 품질 요소로 분석 • 제품의 품질 요소를 역추적 후 각 요소를 테스트 • 요구사항 역추적 필요

원론적인 접근

만들고

내보내고

문제 생기면

고치고

이미 만들어져 오랫동안 서비스 되고 있는 제품

그런데 HW든 SW든 계속 쫓아다니면서 고칠 수는 없음. 그래서 해야 하는 것 = 예방 • HW : 신뢰도 확보, ensuring reliability • SW : 품질관리, quality assurance

•한 번도 만들어 보지 않은 제품에도 동일하게 적용 단, 적절한 시점에 Refactoring 해야 함을 인정하기 (모든 코드는 래거시임)

•위험을 분석하여 예측 AB 테스트 : 가정, 설정 후 검증


ⓒ

< 발표자 노트 > (1) 상태 전이 다이어그램(State Transition Diagram)은 Dynamic한 요소가 많이 배제된 Static 한 View를 차용하는 방식을 따르는 프로그램 분석 시 유용합니다. 대표적으로는 모바일앱이 있습니다. (2) 또한 상태 전이 다이어그램은 Game과 같이 input/output의 variance가 매우 큰 제품에서도 User의 Action 기준으로 state를 정의할 수 있게 해주므로 유용합니다. (3) 역공학의 기획 적용(Applying reverse engineering over system design)이라는 말은 발표자가 2010년에 만들어낸 말입니다. 일반적인 용어는 “요구사항 추적” 입니다.

15

모바일 노트

파일 브라우저 보기

최근 문서

새로 만들기

수정

메뉴

열기 삭제 저장 다른 이름으로 저장

새로 만들기 취소

메뉴

새로운 문서 새로운 폴더 검색 자르기 복사하기 붙여 넣기 삭제하기 새 이름으로

정렬하기 공유하기 정보보기

선택 백버튼

선택 백버튼

선택 백버튼

손가락 터치 - 클립보드 복사/붙여 넣기 - 확대/축소하기 - 단어/문장 선택하기

파일 메뉴 폰트 검색 되돌리기 다시 실행

키보드 보이기 이미지 붙이기 페이지로 보기 읽기 정보보기

모바일 노트 프로그램을 가상으로 꾸며서 만든 상태 전이 다이어그램 (State Transition Diagram) 예제

우리가 실무에서 일반적으로 부딪히는 어려움 • 이미 몇 년 간 서비스된 제품은 개선점을 찾아 내기도 매우 어려움 • 힘들게 찾아낸 개선점도 “요구사항의 문제”로 귀결되는 경우가 대부분. • 이런 경우 Tester들의 활동을 통한 요구사항 역추적이 가능 – 역공학의 기획 적용(Applying reverse engineering over system design) 테스트케이스 재-정비

테스트 기획/계획 재-정비

기능 대비 기획 역추적

컴포넌트/모듈 다이어그램화

기획 카테고리화

요구사항 역-추적

전체 “요구사항-기능-테스트” 정리하여 Requirement

Traceability Matrix 정비


ⓒ

※ 발표주 주석 : 발표자는 제품 공정에서 품질을 관리하는 가장 핵심적인 방법을 하나만 꼽으라면 “형상 관리” 활동을 꼽음. 형상관리를 통한 “개선활동”을 진행해야 제대로 개선되기 때문. 아이디어 아이콘 : http://www.freepik.com/free-icon/idea-hand-drawn-symbol-of-a-side-head-with-a-lightbulb-inside_734487.htm 베이스라인 관련 정보 : IEEE1024 + 과거에 발표자가 공부한 수 많은 표준과 업계 선배님들의 자료 분석하여 요약 형상식별 관련 정보 : 과거에 발표자가 공부한 수 많은 표준과 업계 선배님들의 자료 분석하여 요약

16

형상관리 관련 키워드들

• 형상 식별: 식별 항목, 식별 코드, 베이스라인 등

• 형상 관리 담당자: 이해관계자, 역할과 책임 분배 등

• 형상 통제: Change Control Board, 변경 통제 등

• 형상 상태 보고 : 형상 상태 보고서, Lessons Learned 등

• 형상 감사 : Quality Assurance, Quality Control, Quality Audit

등

• 정의 : 베이스라인이란 소프트웨어 개발 생명주기의 특정 시점에서, 형상항목이 하나의 완전한 산출물로써 쓰여질 수 있는 상태의 집합 • 특성 : 베이스라인으로 한 번 잡힌 산출물은 향후 변경 시 반드시 공식적인 변경통제 절차에 따라서만 변경되어야 하며, 해당 부분에 대한 문서 산출물 등 증빙이 존재해야 함, IEEE1024

베이스라인

형상식별 • 정의 : 형상관리를 할 항목을 식별하여 베이스라인의 기준을 수립하는 활동 • 주요 활동 : 형상항목 선정, 베이스라인 기준 수립 • 형상항목 : 문서, 소스코드, 개발도구 등 • 형상항목 선정 방법 : 요구사항을 기반으로 어떤 산출물들이, 어떤 방식으로, 어떻게 집중적으로 관리되어야 하는 지를 선정 • 식별 코드 : 각 형상에 대한 식별할 수 있는 코드가 부여되어야 함. 예) 문서의 경우, WBS_Doc_Core_Arch_D71A01_v1.0.0.1.doc • 키포인트 : 어떤 형태로 관리하던 지 상관 없음. 프로젝트에 문제가 생겼을 때 추적할 수 있으면 됨.

형상관리를 왜 하는가?

• 형상관리 표준은 엄청나게 많음 : 산업에 따라, 위험도에 따라 다양한 관리 기법/표준/가이드가 존재 • 모두 맞추어 형상관리를 진행하는 것은 무리 • 제품의 특징에 맞는 중요 품질 요소들과 관련 사항들을 집중 관리해야 함

발표자가 실제로 사용한 형상관리 자료

(1) 예제 : 모든 항목을 기재하지 않았으며, 일반적으로 회사들에서 범용적으로 차용 가능한 항목들만 기재

(2) 접근 방법 : 분류 및 형상항목 식별의 수준은 각자 회사와 제품 맞는 수준으로 진행하면 됨

(3) 그 외 : 형상관리는 조직의 전략과 맞물리게 되므로, 조심스럽고도 철저하게 접근하여 분석 필요

대분류 중분류 설명

형상 정의 전체 제품 설계 형상 인터페이스 설계 규정 양산품 조달 관리 정책 … more

전체 제품에 대한 형상을 규정하고, 전체 제품 중 큰 컴포넌트 단위의 설계상 인터페이스를 정의. 이를 통해 회사의 구성원들이 회사의 방향과 제품의 방향을 이해하고 흔들리지 않도록 함.

변경 관리 패치 허용 기준 긴급 패치 기준 정규 패치 기준 … more

형상 정의란에서 정의한 항목들이 변경될 시 어떤 절차를 통해 번경되어야 하는 지에 대한 기본적인 정책 및 기준 제시. 이를 통해 주먹구구식 업무 처리나 변경을 예방할 수 있게 됨.

개발 관리 … more 공정상에서 구성원들이 알아야 할 규정, 절차 등

배포 관리 … more 제품 출하, 배포 시 필요한 규정, 절차 등

운영 관리 … more 제품, 서비스 운영 시 필요한 규정, 절차 등


ⓒ 야율초재 설명 : 나무위키 - https://namu.wiki/w/야율초재

17

“하나의 이익을 얻는 것이 하나의 해를 제거함만 못하고, 與一利不若除一害,

하나의 일을 만드는 것이 하나의 일을 없애는 것만 못하다.”

生一事不若滅一事

- 야율초재, 耶律楚材

<인물 소개> 싸움은 잘 하지만 통치력이 없던 유목민 출신의 몽골을 금나라로 정착시키는데 탁월한 공을 세운 인물. 몽골의 재상으로 써 징기츠칸이 죽고 난 뒤, 그의 아들 오고타이칸까지 황제로 섬기며 금나라를 발전시킴. 징기츠칸이 전쟁에 나가있는 동안 내정을 보살피고 나라를 부강하게 만듬. 코에이 게임의 징기츠칸에서 반드시 획득해야 하는 캐릭터.


ⓒ

18

발표자 경험담 수 많은 삽질과 실패를 기반으로 한 경험담

•시작단계보다 사업이 어느 정도 안정화된 시점이 훨씬 효과적, 안정적

•요구사항 분석 시기를 놓친 경우 아무리 노력해도 되돌릴 수 없었으나, 이는

조직 구성원들의 인식 문제가 가장 컸음

•사업을 위한 개발인지, 개발을 위한 사업인지 모를 정도로 개발 위주의 회사

인 경우 요구사항 분석/역추적은 불가능 했음

요구사항 분석

•어느 시점에 시작해도 무척 괴로움

•아이디어 회의가 아닌 개발 전에 기획 단단하게 만들기라는 인식이 조직에

퍼지기 매우 어려움. 대부분 기획 분석 활동과 기획 협업 활동을 혼동

•같은 조직 내에서도 중구난방으로 쌓인 경험치들은 오히려 언제 코딩을 시

작해야 할 지 그 시작지점을 찾기에 더 어렵게 만들었음

•“기획을 위한 개발 vs 개발을 위한 기획” 에 대한 논쟁을 발생시키기도 함

기획 협업

•코딩 규칙은 초기 스타트업 형태에서 중규모로 넘어갈 때 가장 적절

•코딩 규칙은 단위테스트와 기술부채를 해결하는 데에는 훌륭했지만 어느 시

점에 가면 코딩 규칙을 유지보수하는 데에 들어가는 투입공수가 너무 커지는

현상 발생.

•동료검토는 도입초기 저항 외에는 좋은 결과를 가져왔으나, 기준이 명확치

않은 동료검토는 개발 속도를 느리게 만듦

•기준 없는 동료검토 진행 시 좋게 좋게 넘어가자는 프로그래머들간 MOU

기류 형성, 혹은 불신 기류 형성 감지

개발 관리

•정말 어려움

•사업과 개발의 앞단에서 해당 업무 담당자들과 씨름해야 하는 것이 가장 많

은 에너지를 소모하게 함

•개발 앞 단의 활동들에 철저히 관심 없는 테스트팀의 팀장들과 팀원들을 설

득하는 과정에서 싸가지 없다는 평가를 듣게 되었음 (& 부장한테 맞았음)

테스트 관리

•실무에서는 강력하고 똑똑한 Project Manager나 Scrum Master의 노력

없이는 QA 활동과 Testing 활동이 구분되지 않음. 그러다 보니 많은 실무자

들이 QA 활동과 Testing 활동을 같은 것으로 오인

•또한 검수 활동과 테스트 활동 구분을 못하는 회사가 대부분

•대부분의 회사가 소프트웨어 공학을 이론으로 치부하고, 자기들이 편하게

즐길 수 있을 듯한 외국의 사례들을 마구잡이로 차용. 그렇기 품질 강화를 위

한 필요한 기본적인 활동들이 무시되거나, 진행되더라도 잘못 되어버리는 경

우가 대다수.

•그나마 다행인건 품질관리 활동이 Scrum Master라는 직군의 활동 체계로

변화되면서 프로그래밍에 필요한 몇 가지 기본 활동들은 업계에 적용되는 중

품질 관리

Q : "그래서 실무에서 품질 관리는 어떻게 하는게 제일 좋은가요?"

A : “저도 잘 모르겠습니다.

다만 이짓거리를 십수년 해 보니 사람들이 말하는 품질과 테스트를 분리해야 발전할 수 있음을 알게 되었고, QA활동과 Testing 활동이 서로 다른 분야라는 것도 확실히 알게 되었습니다 그리고 지금도 열심히 미움 받으며 삽질 중입니다.”


ⓒ 배경 - http://www.pptbackgroundstemplates.com/technology/1082-adobe-creative-suite-backgrounds.html

19

正義 : 불의 하지 않아야 한다

현실 직시 : 조직의 현재 상태를 직시하라

가장 옳은 방법 : “항상 개선 하는 것”


ⓒ

William Edwards Deming 사진 : http://leadershipquote.org/ PDCA : https://commons.wikimedia.org/wiki/File:PDCA_Cycle.svg 데밍 소개 : http://www.12manage.com/methods_demingcycle_ko.html 데밍의 사상 : http://blog.daum.net/sjfor1313/17

20

"최선을 다한다는 것만으로는 충분치 않다. 무엇을 하느냐가 중요하고 그 다음이 최선이다.“ - 윌리엄 에드워즈 데밍

< 데밍의 사상 > 1. 제품과 서비스의 향상을 위해 일관성 있는 목적 만들기 (회사역할 재정립) 2. 새로운 기업철학 정립 (공부하는 조직으로 탈바꿈하기 위한 리더쉽 발휘) 3. 대량검사 탈피 (애당초 근본적으로 제품품질의 예방관리 철저) 4. 최저가격을 기준으로 발주주는 타성 종식 (총비용의 최소화를 지향) 5. 생산&서비스체계의 항구적,지속적 개선 (품질향상,낭비절감,지속개선추진) 6. 교육 강화 (정확한 방법의 체계적 교육 실시) 7. 리더쉽 정립 (감독자의 임무는 지시나 처벌이 아닌 리드 및 지원) 8. 두려움 몰아내기 (모르는 것은 질문과 학습을 통해 확신과 자신감 획득) 9. 부서간 장벽 파괴 (회사목표를 최우선으로 부서간 협동 & 협조 강화) 10. 작업장내 목표의 구호,경고,숫자 등 강제 게시 금지 (자율적 시행 유도) 11. 숫자로된 할당량이나 작업표준 제거 (질과 방법의 개선 추구) 12. 기량 자부심 저하요인 제거 (좌절감, 패배의식 배제) 13. 적극적인 교육프로그램 제작 운영 (팀웍 강화 및 신지식 습득기회 제공) 14. 변화를 달성하기 위한 조치 시행 (품질향상 달성 행동계획 수립)

< 인물 소개 > 미국의 통계학자. 일본의 부흥과 전사적 품질관리(TQM)의 고안, 일본 ‘개선문화’의 초석이 됨 2차 대전 후 일본인들에게 통계와 PDCA 사이클의 활용을 포함하여 많은 품질개선 방법을 가르침 (※ 어떤 종류든 품질에 대해 관심이 있다면 반드시 “공부” 하고 분석 해야 하는 사람.)

늦은 밤까지 긴 이야기 들어주신 여러분들께 진심으로 고마운 마음을 전합니다. 감사합니다.

(1) 이상한 모임 (가입) : https://weirdmeetup.herokuapp.com : [email protected]로 메일을 보내시면 됩니다!

(2) 네이버 SW Tester 카페 : http://cafe.naver.com/swtester ID : 천년나무

Technology

EMOCON 2015 - 품질과 테스트는 다르다