문성준의 단단해지기

 "테스트 프로세스의 기초"에 대해 이야기 해보려고 한다. 

 테스트 프로세스 주요활동 에는 아래와 같이 5개로 구분할 수 있다.

<<테스트 프로세스 주요활동>>

 

1. 계획과 제어(Planning and Control)

 

2. 분석과 설계(Analysis and Design)

 

3. 구현과 실행(Implementation and Execution)

 

4. 완료 조건의 평가와 보고 (Evaluating exit criteria and Reporting)

 

5. 테스트 마감 활동(Test Closure activities)

테스트 프로세스는 순차적이지만, 프로세스 내의 활동들은 중복되거나 동시에 발생할 수 있다.

1.     테스트 계획과 제어

-계획 : 테스팅의 미션과 목표를 정의하고 이를 만족 시키기 위한 테스트 활동을 수립하는 과정 , 모니터링 및 통제 활동의 피드백에 따라 조치를 할 수 있도록 수립되어야 한다.

 

-제어 : 실제 진행 상황과 계획을 비교하고 보고하는 활동 ,프로젝트의 미션과 목표를 위해 조치가 이루어 질 수 있다.

이를 위해 프로젝트의 진행이 지속적으로 모니터링 되어야 한다.

2.     테스트 분석과 설계 

 

-테스팅 목적에 부합하는 테스트 상황과 테스트 케이스를 생성한다.

 

-자료 리뷰( 요구사항 ,디자인 등) , 테스트 케이스 설계와 우선 순위를 선정한다.

 

-테스트 상황과 테스트 케이스에 필요한 데이터 식별 및 환경과 도구를 확보한다.

 

3.     테스트 구현과 실행 

 

-테스트의 조건들을 테스트 케이스로 전환하고 이를 위한 환경을 갖추는 일련의 활동을 말한다.

 

-계획된 절차에 따라 테스트 케이스를 직접 또는 자동화 툴을 사용하여 수행한다.

 

-테스트 실행 결과를 기록하고 테스트 수행 대상 및 소프트웨어 버전 등 테스트 기록을 남긴다.

 

-실제 결과와 기대 결과를 비교 후 불일치 시에 원인을 기록하거나 원인을 모르겠다면 발생 되기 까지의 프로세스를 남긴다.(반복적 , 간헐적인지 기록)

 

4.     테스트 완료 조건의 평가와 보고 

 

-테스트 수행 결과를 목적과 비교하여 평가한다.

 

-이해관계자들을 위한 테스트 요약 보고 작성한다.

 

5.     테스트 마감 활동 

 

-모든 테스트 활동에서 경험, 테스트 도구, 사실, 통계를 종합하기 위해 모든 데이터를 수집하고 완료한다.

이론적으로 이러한 프로세스를 바탕으로 테스트를 진행하게 된다.

그러나 이론과 실무에는 크다고하면 크고 작다고하면 작은 차이가 있으니

기본에 중점을 두고 테스팅하면 결함을 발견하는데 도움이 될 것이다.

후회없는 결정을 하기위해 집어든 책!

어쩌면 4차 산업혁명 시대인 지금에 딱 걸맞는 책인 것 같은 생각도 든다.

롤프 도벨리의 스마트한 선택들에 관한 얘기이다.

‘ 손 하나 까딱 안하고 실적을 올리는 방법’ 이 있을까?

아래의 예를 보면 이해할 수 있을것이다.

텔레비전 채널 A 의 시청률은 높고, 채널 B 의 시청률은 낮다. 회사에서는 당신에게 이 두 채널의 시청률을 높이라고 요구한다.

만약 높이지 못한다면 해고의 위기가 발생하고, 높인다면 엄청난 금전적 보상을 받게 될 것이다.

기간은 6개월 , 당신은 어떻게 할 것인가?

 (채널 A의 평균 시청률은 40% 채널 B의 평균 시청률은 15%)

답은 간단하다. 채널 A 의 평균 시청률에는 못 미치지만 채널 B 보다는 높은 시청률의 채널 A의 프로그램 하나를 채널 B로 옮기는 것이다.

그렇게 된다면 A의 평균시청률을 하락시키고 있던 프로그램이 B로 옮겨지는 것이기 때문에 채널 A의 평균 시청률은 소폭 증가할 것이고, 

채널 B의 시청률도 새롭게 편성된 A의 프로그램으로 인해 시청률이 올라가게 될 것이다.

프로그램의 편성만 바꿨을 뿐이다. 새로 편성하거나 , 기존 프로그램을 삭제하지도  않았다.

(채널 A의 평균 시청률은 45% 로 5%증가, 채널 B의 시청률은 20%로 5% 증가)

간단한 ‘무대의 이동’ 만으로 평균 수익률을 상승시킬 수 있다.

이런 효과를 미국 오클라호마 출신의 코미디언 윌 로저스의 이름을 따서 ‘윌 로저스 현상(Will Rogers Phenomenon)” 또는 ‘무대의 이동’ 이라고 부른다.

이 개념은 윌 로저스가 ‘오클라호마를 떠나 캘리포니아로 이주한 사람들 덕분에 오클라호마와 캘리포니아 양쪽 주에 사는 주민들의 평균 지능지수가 상승했다’ 라는 농담을 한 것에서 생겨났다.

어떻게 보면 조삼모사일 수도 있는 기발한 현상은 이미 우리가 무의식중에 사용하고 있을지 모른다.

 

테스팅 예를 들어보면 '프로그램 테스팅을 1,2,3차수를 모두 할 것인가' 아니면 '사전 테스팅 진행 후 1,2차 테스팅을 진행할 것인가' 의 차이이다.

 

결국엔 두 테스팅 모두 3번의 테스팅을 진행해야 하지만 사전 테스팅을 진행함으로써 제품 전반적인 이슈에 대해 파악하는 것이 더 효율적일지도 모른다는 내 개인적인 생각이다.

테스팅과 디버깅의 차이는 무엇일까?

다른 활동이지만 서로 의존하는 관계라고도 볼 수 있다.

 테스팅 : 결함을 발견하기 위한 활동

-테스트는 공정상의 결함을 발견할 수 있다.

-시스템이 정지되는 결함과 정지가 되지 않는 결함이 모두 포함된다.

 

 디버깅 : 결함의 원인을 찾고, 코드를 수정하는 개발활동

-디버깅 후 테스터에 의해 확인 테스팅을 수행하여 결함이 제대로 고쳐졌는지 확인이 필요하다.

"결국 테스팅과 디버깅을 반복해야 최종적으로 결함을 수정 및 해결 할 수 있다고 생각된다."

저번에 애자일 방법론의 간단한 개념에 포스팅을 했다면 , 

이번에는 애자일을 더 알아보기 위해 책을 한권 추천하려고 한다.

애자일 프랙티스

–밴캣 수브라마니암 , 앤디 헌트-

이 책은 애자일이 어떠한 것이고 전체적인 흐름과 소프트웨어 개발에 어떻게 적용되어 지는지에 대해 가볍게 읽기에 좋은 책이다.

중간중간 리뷰를 하자면 서문에 이러한 구절이 있다.

“용기를 내서, ‘ 위험을 무릅쓰고서라도(Damn the Torpedoes)’ 올바른 선택을 지속해 나간다면 프로젝트에서 성공한 자신을 발견하리라 믿습니다.”

여기서 올바른 선택은 무엇일까?

선택을 통해 완벽한 결과가 나와야 올바른 선택인지, 결과는 좋지않지만 과정적인 면에서 효과가 나왔다면 그게 올바른 선택인건지는 확답할 수는 없겠지만 다양한 소프트웨어 환경에서 올바른 선택이 무엇인지에 대해 방향성을 제시해 주는 책이다.

이 책에서 애자일 소프트웨어 개발은 다음과 같이 정의한다.

"소프트웨어는 늘 변하는 환경이다."

소프트웨어 프로젝트는 팀 내 개발자들의 숙련도와 훈련, 경쟁력에 의존한다.

이 부분을 보더라도 이 책에서는 소프트웨어의 다양성과 무궁무진한 변수를 항상 고려하고 염두해야한다고 보고있다.

이 책에서 애자일 정신의 기원을 알 수 있다. 

이 책의 저자인 앤디 헌트 또한 Agile Developer 의설립자로 유타주 스노버드에 모인 17명중 1명이다.

애자일 정신의 기원은 다음과 같다.

2001년 2월 경량 프로세스라고 막연히 불리며 떠오르던 경향에 대해 토론하기위하여 관심을 가진 사람들 17명이 유타주 스노버드에 모였다.

장황하고 , 부산물은 많고, 결과는 부실한 프로세스 때문에 프로젝트가 실패하는 것을 보아왔고, 방법론을 검토하는 좋은 수단이 있어야하는 필요성을 느꼈다.

이 17명은 ‘애자일’ 이라는 새로운 용어를 만들고 소프트웨어 개발에서 새롭게 집중해야할 접근 방법을 설명하기 위해서 애자일 선언을 공표하였다.

접근방법은 사람,(people), 협조(collaboration), 반응성(responsiveness), 동작하는 소프트웨어(working software)를 강조한다.

애자일 소프트웨어 개발 선언문

 

1.     ‘프로세스와 도구’ 보다는 ‘개인과 상호작용’을

 

2.     ‘포괄적인 문서화’ 보다는 ‘동작하는 소프트웨어’ 를

 

3.     ‘계약 협상’ 보다는 ‘고객과의 협력’을

 

4.     ‘계획 준수’보다는 ‘변화에 대응’을

 

왼쪽에 있는 것들에도 가치가 있지만, 오른쪽에 있는 것들에 더 가치를 둔다

 

더 많은정보는 http://agilemanifesto.org/

 

기원과 선언문에서도 볼 수 있듯이 애자일 접근 방법은 빠르게 반응하고 상호 협력하는 사람들과 논증 가능한 구체적인 목표를 결합하는 것이다.

애자일 실천방법은 어떻게 서술 했을까?

“ 애자일 개발은 고도의 협력적인 환경에서, 지속적인 조정을 위해 피드백을 사용한다.”

 

개발작업을 공유하며 일하고, 소프트웨어 비용을 지불할 고객과 가까이 일하고, 그들에게 시스템의 최신버전을 가능하면 빨리 그리고 자주 보여준다.

 

이 과정에서 피드백을 얻고, 자동화를 사용해서 끊임없이 프로젝트를 빌드하고 테스트한다.

 

이것을 리팩터링(refactoring) 이라 하고, 개발하면서 계속해야하는 것이다.

라고 서술되어 있다.

결국엔 리팩터링(refactoring)은 끊임없는 커뮤니케이션이다.

이 책은 전체적으로 위에서 서술한 바와 같이 전체적인 애자일을 글로 느껴보고 싶은사람에게 추천을 하고싶고,

애자일 시작 -> 애자일 성장 -> 사용자들이 원하는 내용제공 -> 애자일 피드백 -> 애자일 코딩 -> 애자일 디버깅 -> 애자일 협력

으로 서술 되어 있다.

이 책을 읽다보면 마음에 와닿는 어구들이 많이 등장한다.

대표적으로 뽑자면

“개인 감정을 드러내지 말고, 프로다운 자세를 유지하자.” 라는 어구가 굉장히 마음에 들었다.

나는 6개월동안 두 프로젝트를 진행하였다. 프로젝트를 진행하며 좋은사람들을 많이 만났지만 아닌 사람도 있었다.

그런 사람들을 보면 존경심보다는 피하고싶은 느낌밖에 들지 않았는데 그런사람들의 공통점이

개인감정을 드러내는데에 역력한 사람이였다.

그 사람들은 개인감정을 드러내기위해 틈을 놓치지 않았고, 사람을 몰아세우기를 좋아했다.

아마 업무에 대한 스트레스를 감정소비로 해소하는 사람 같았다.

마치 책 한권을 읽었는데 프로젝트의 시작과 끝을 경험해보는 느낌도 들었다.

취직하면 책은 안읽을 것 같았는데, 찾아보니 재밌는 내용이 많았다.

테스팅의 필요성과 품질에 관한 이야기를 저번에 했는데

테스트 품질관련 이야기를하면서 소프트웨어의 요구사항 (기능적, 비기능적) 에 대해서 다음에 포스팅 한다고 했다.

개인공부를 하던 중 기능적, 비기능적 뿐만아니라 도메인 요구사항도 있길래 몇글자 적어보려 한다.

기본적으로 소프트웨어 요구사항과 특성에는 뭐가 있을까?

총 5가지 이다. 사용성, 효율성, 신뢰성, 이식성 , 유지보수성 이다.

사용자가 소프트웨어를 얼마나 쉽게 사용할수 있는지 또 소프트웨어의 효율은 어떠한지, 특정 기능에 대해 실패 확률은 얼

마인지, 이 소프트웨어가 다양한 환경에서도 동작하는지, 이 소프트웨어를 얼마나 오래 쓸건지에 대해 특성을 정리해 보았

다.

<<소프트웨어 요구사항과 특성>>

 

1.     사용성(usability)- 사용자가 소프트웨어를 어떻게 쉽게 사용할 수 있을지가 기술되는 요구 사항

 

2.     효율성(efficiency)- 소프트웨어는 빠를수록, 메모리를 적게 사용할수록 좋다. 이에 대한 제약 사항을 정의

 

3.     신뢰성(reliability) –특정한 기능을 실행할 때 실패할 가능성

 

4.     이식성(portability)- 소프트웨어가 다양한 플랫폼에서 작동

 

5.     유지 보수성(maintainability)- 소프트웨어의 수정, 개선을 용이하게 하는 능력

소프트웨어 시스템의 요구사항은 크게 기능적(functional), 비기능적(non-functional) 또는 도메인 (domain) 요구사항으로 분류될 수 있다.

      << 기능적 요구사항(Functional requirements)>>

 

- 시스템이 제공하는 기능 또는 서비스에 대한 기술

 

- 기능적 사용자 요구사항은 시스템 동작사항에 대한 추상적 기술이지만, 기능적 시스템 요구사항은 시스템 서비스에 대한 상세한 

기술이어야한다.

 

- 특정 입력에 대해 시스템이 어떻게 반응해야 하는지에 대한 기술

 

- 특정 상황에 대해 시스템이 어떻게 동작해야 하는지에 대한 기술 ( 시스템이 하지 말아야할 것 에 대해 기술하는 경우도 있음)

 

- 소프트웨어 종류, 예상되는 사용자, 소프트웨어가 사용되는 시스템의 종류에 좌우

   <<비기능적 요구사항 (Non-functional requirements)>>

 

-       시스템 속성이나 시스템에 의해 제공되는 서비스나 기능에 대한 제약사항에 대해 정의 한다.

 

-       신뢰도, 반응 시간, 저장소 요구사항 등 대부분 개별적 기능이 아닌 전체적 모습에 관한 요구 ( 프로세스 요구사항이 있을 수도 있다.)

   <<도메인 요구사항 ( Domain requirements)>>

 

-       응용 도메인 으로부터 생기는 요구사항으로 특정 도메인의 용어나 개념이 반영되어 시스템의 특성에 영향을 준다.

 

-       새로운 기능적 요구사항 또는 기존의 요구사항에 대한 제약사항이 되거나 특별한 계산식을 정의하는 것 등이 될 수 잇다.

 

-       도메인의 요구사항이 만족되지 않으면 시스템이 쓸모 없게 된다.

 

-       문제점 : 해당 응용 도메인의 언어로 표현되기 때문에 시스템을 개발하는 소프트웨어 공학자가 이해하기 어렵다. 도메인 전문가에게는 분명한 부분이기 때문에 생략해버린 정보를 개발자가 알 수 없다.

도메인 요구사항은 글을 작성하고 있는 나도 학교에서 배운 기억이 없는것 같다.( 내가 수업시간에 졸았나?)

정리하자면, 기능적 요구사항은 단어의 뜻대로 사용자가 원하는 기능을 말한다. 사용자는 그 기능을 시스템을 통해 제공받기를 원하며, 시스

템은 사용자에게 필요한 기능을 제공해줘야 한다.

기능적 요구사항이 소프트웨어가 제공하는 기능이라면, 비기능적 요구 사항은 수행 가능한 환경, 품질 , 제약 사항이다.

*피드백 환영 합니다* 

소프트웨어가 기대한대로 동작하지 않는다면 어떻게 될까?

소프트웨어의 셀 수 없이 많은 특징 과 로직에 의해 방대한 양의 문제가 발생될 것이다.

그래서 소프트웨어개발 생명주기에도 "테스트" 단계가 들어가는 것이고,

또 이를 "유지 ,보수" 하는데에 많은 시간과 기술력을 투자하는 것이다.

소프트웨어의 개발, 유지보수, 운영시 테스팅의 역할

 

-       시스템이나 문서에 대한 엄격한 테스팅은 운영중 발생할 수 있는 문제 감소

 

-       소프트웨어 시스템의 품질을 높이는데 기여

 

-       계약 또는 법적 요구사항이나 특정한 산업 표준을 만족 시키기 위해 필요

이렇게 테스트 되어진 소프트웨어는 품질에대해 확신을 가질 수 있게된다.

"테스트 = 품질" 

결함이 극소수 이거나, 혹은 테스트 도중 결함을 확인하여 수정된 소프트웨어는 그만큼 품질에 확신이 들 것이다.

테스팅과 품질

 

-       기능적, 비기능적 소프트웨어 요구사항과 특성에 관련된 해당 소프트웨어의 품질을 , 발견된 결함(데이터)에 근거하여 측정 가능

 

-       테스팅으로 발견된 결함이 극소수이거나 없다면 소프트웨어 품질에 대해 확신을 가짐

 

-       올바르게 디자인된 테스트는 시스템의 전반적인 리스크 수준을 감소시킴

 

-       다른 프로젝트에서 발견된 결함의 근본 원인에 대한 이해를 바탕으로, 프로세스 개선, 동일 결함의 재발이 방지될 수 있어 , 차후 시스템의 품질 개선

(품질의 부연설명으로 기능적, 비기능적 소프트웨어 요구사항에 대해서는 다음에 포스팅 하려고한다.)

S/W 나 H/W , 올바르게 테스팅 하려면 기간을 어느정도로 측정 해야할까?

테스팅 기간

 

1. 리스크 수준을 고려하며, 비즈니스 제품 및 프로젝트 리스크, 시간과 비용 같은 프로젝트 제약사항을 고려해야한다.

 

2. 테스트된 소프트웨어나 시스템의 다음 개발로의 릴리즈 결정 또는 고객에게 넘겨주는 릴리즈 결정을 개발 프로젝트 관련자들이 내릴 수 

 

있도록 충분한 정보를 제공한다.

 

( 여기서, 릴리즈란 . 각 소프트웨어에는 우리말로 판(Version, Release)이라고 부르는 버전표시가 되는데, 이 버전이라는 것은 이 프로그램이 

 

얼마나 개선되었는가를 뜻하는 표시입니다. )

프로젝트 리스크의 수준을 고려하고, 제품 품질에 관해 조금만 더 신경을 쓴다면

기획 및 설계 단계에서 부터 목소리가 커질일은 없을 것이다.

여러 직무를 담당하고 있는 프로젝트 팀원끼리 좋은 커뮤니케이션을 형성 하고, 프로젝트를 진행할 수 있을 것이다.

*피드백은 언제나 힘이 됩니다.*

요즘 읽고 있는 책인데 흥미로운 구절이 있어 적어 보았다.

개발자를 위한 단위 테스트라는 책인데 아직 다 읽지는 못하고 초반에 테스트 관련 내용, 테스트 단위 개발의 필요성만 읽은 상태이다.

읽다가 버그 수정 비용의 증가라는 것을 따로 책에 구분에 놓았길래 흥미가 있어 몇자 적어본다.

<<버그 수정 비용의 증가>>

 

버그 수정 비용은 평균적으로 얼마나 될까? 런던에서 열린 ‘XP Day 2009 컨퍼런스’ 에서 마크 스트리에벡 ( Mark Striebeck) 은 구글에서 결함을 수정하기 위해 지연된 시간을 비용으로 계산해서 공개 하였다.

 

구글이 측정한 바로는 프로그래머가 버그를 만들자마자 즉시 수정한다면 $5 를 쓴 것이다. 같은 결함을 프로젝트 전체 빌드 때 발견하면 비용은 $50이 된다. 만약 통합 테스트까지 살아남으면 $500로 증가하여 시스템 테스트에 이르면 $5000까지 치솟는다.

 

이러한 수치만 보더라 하더라도 문제는 가능한 빨리 발견해야 한다는 건 이론의 여지가 없다.

 

$5 -> $50 -> $500 -> $5000

초기에 발견하지 못하면 1000배 가까이 손해가 발생된다. 만약 초기에 발견하고 완료를 했다면 $4995 는 

회사입장에서 회식비, 보너스로 들어갈 수 도 있는 적지 않은 돈이다.

시스템 테스트까지 발견되지 못한 버그는 어떤 것 들이 있을까?

* 피드백 환영 입니다 *