문성준의 단단해지기

더위에 지쳐 무기력 해져 있을때,

이대로 있으면 더욱 무기력해질까 싶어 "50000\" 을 주고 신청한 CSTS 자격시험!!

CSTS는 SW 테스트 전문가 자격증이다.

자세한 설명은 TTA 홈페이지에 나와있다.

TTA 아카데미 ( https://edu.tta.or.kr/) 에서 신청할 수 있습니다.

개인적인 능률도 올리고, 직무적으로도 도움이 될 것 같아 신청을했다.

신청하고 놀다보니 10일도 안남았다...

물론 첫술에 배부르면 좋겠지만 (정보처리기사때 쓴 맛을 너무많이 보았기때문에...)

아무튼 열심히 해보려고 한다.

good luck!

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

 테스트 프로세스 주요활동 에는 아래와 같이 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번의 테스팅을 진행해야 하지만 사전 테스팅을 진행함으로써 제품 전반적인 이슈에 대해 파악하는 것이 더 효율적일지도 모른다는 내 개인적인 생각이다.

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

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

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

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

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

 

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

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

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

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

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

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

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

총 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 는 

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

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

* 피드백 환영 입니다 *

테스팅을 하다보면 오류가 발생하게 된다.

오류의 원인으로는 무엇이 있을까?

1.     인간의 실수 – 소프트웨어 또는 시스템 코드에 결함을 야기

2.     주변 환경에 의한 결함 – 전자파, 자석 , 공해 , 자연현상 등과 같은 주변 환경의 영향으로 소프트웨어 또는 시스템이 사용하는 하드웨어에 영향을 주어 오류 발생

위와 같이 오류도 상황에 따라 다양한 이유로 발생하기 때문에 이를 분류해 줄 수 있는 용어가 필요하다.

<<테스팅 용어>>

-       오류 (error) : 잘못된 결과를 만드는 사람의 행위(사람의 실수에 의한 에러)

-       결함 (Defect, Bug,Fault) : 에러에 의해 발생한 것 , 에러가 실제로 코드에 구현된 것 , 소프트웨어 상의 Error 를 일으킬 수 있는 징후 ,요구 기능의 부정확한 처리 , Failure 의 원인

-       장애 (Failure) : 예상과 다르게 동작하는 소프트웨어의 의도하지 않은 결과, 결함을 가진 SW 실행 시 발생 ( 단, 모든 결함이 장애로 가지는 않는다)

이러한 이유로 소프트웨어가 올바르게 작동 되지 않는 경우 이로 인한 피해가 크다.

피해로는 아래와 같은 이유가 있다.

1. 금전적 손실

2. 시간 낭비

3. 비지니스의 이미지 손상

4. 부상 or 사망

테스트 후의 결과는 곧 신뢰성과 밀접한 연관관계를 가지고 있다.

아니 거의 동일하다고 본다. 

추가적으로 이건 내 경험이지만, 같은 팀이여도 못믿는 경우가 생긴다.

QA 팀이지만 본인부터 실수가 많아버리면 제품이나 고객사에게도 큰 영향을 주기때문에 

내가 직접 보고 경험한 것 만으로 보고를 해야한다고 생각된다.

*피드백 환영입니다.*