문성준의 단단해지기

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

 테스트 프로세스 주요활동 에는 아래와 같이 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.     테스트 마감 활동 

 

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

총 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 팀이지만 본인부터 실수가 많아버리면 제품이나 고객사에게도 큰 영향을 주기때문에 

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

*피드백 환영입니다.*

<<테스팅의 일반적인 원리>>

1.     테스팅은 결함이 존재함을 밝히는 활동이다. 

 – 결함이 없다는 것은 증명할 수 없다.

2.     완벽한 테스팅(Exhaustive) 은 불가능 하다. 

 – 무한 경로, 무한 입력 값, 무한 타이핑, 리스크 분석과 결정된 우선 순위에 대한 테스팅을 집중

3.     테스팅을 개발 초기에 시작한다. 

 – 개발 시작과 동시에 테스트를 계획, 전략적으로 접근, Test case 를 도출하면서 문서상의 결함 발견

4.     결함 집중(Defect Clustering) 

 – 적은 수의 모듈에서 대다수의 결함 발견 ( 결함과 장애가 집중)

5.     살충제 패러독스(Pesticide Paradox) – 동일한 테스트를 반복적으로 수행하면 버그를 찾기 힘듦, 경험 기반 기법을 통해 테스트 방법을 다양화

 – 해당 기법을 다른 모듈 또는 시각에서 재적용시켜 테스트 케이스를 업데이트하는 노력

– 탐색적 테스팅(Exploratory testing), JIT 테스팅(Just-in-time-testing)등의 경험 기반 접근법을 통해 새로운 테스트 케이스를 추가하는 것이 필요

6.     테스팅은 정황(Context)에 의존적이다. (일의 사정과 상황)

 – 효율적, 효과적 테스트 팀 조직, 독립적 테스트 환경

7.     오류 – 부재의 궤변 (Absence – of – errors fallacy)

 – 사용자 요구사항에 맞지 않는다면 결함을 찾고 수정하는 것은 무의미, 결함을 모두 발견했다고 해도 품질이 높다고 할 수 없다.

*피드백 환영입니다*

브룩스의 법칙(Brooks'law)는 "지체되는 소프트웨어 개발 프로젝트에 인력을 더

하는 것은 개발을늦출 뿐이다" 라고 주장한 법칙이다.

그리고 브룩스는 "임산부가 아무리 많아도, 아이를 낳는 데에는 9개월이 걸린다" 라고 자신의 

주장을 표현하기도했다.

이 브룩스 법칙이 자주 인용되지만 

그의 저서 <맨먼스 미신>에 이 주장 위에 써있던 "극도로 단순화 해서 말하면" 이란 구문이 생

략되어 본뜻이 왜곡되어 전해지기도 한다.

-브룩스 법칙의 오해-

뛰어난 프로그래머와 일반적인 프로그래머 개인의 능력이 차이가 많이나기 때문에

매우 뛰어난 소수의 프로그래머를 이용하는것이 평범한 프로그래머를 고용하는 것 보다 생산성

이 높다는 것이다.

그러나 이것은 이론일 뿐이고 극소수 프로그래머만을 프로젝트에 투입하더라도 다양한 변수와 

환경적 조건이 적용 되어지기때문에 개발을 빨리 끝낼 수 있다고 말하는 것은 아니다.

-대표적인 해결책-

문제 전체를 소규모의 그룹이 맡을 수 있는 조각으로 나누고 , 상급 팀이 시스템 통합을 맡는 것

즉 , 트리 구조형식을 생각하면 될 것 같다.

하지만 이 또한 그룹 분배를 잘못하게된다면, 팀간의 의사소통비용이 더욱 늘어나게 되는 단점

테스트에서도 브룩스의 법칙이 적용될까?

100% 는 없다고 생각한다. case by case

예를들어 검증환경은 많지만 인원이 적은경우를 생각할 수 있다.

하나의 웹앱을 5개의 환경에서 검증한다고 할 때, 우수한 테스트 엔지니어 1명이 5개의 환경을 

모두 검증하는 시간과 5개의 환경을 파트를 나누어 평범한 테스트 엔지니어가 테스트를 하고 

우수한 테스트 엔지니어는 테스트 총괄담당하여 작업하는 시간을 비교한다면 그 무엇이 더 낫

다 를 판단할 수 가 없다.

하지만, 소프트웨어 테스트도 여러가지 skill 이필요하고, IT 산업의 다양해짐에 따라 

여러 분야를 테스트 해본 경력자가 확실히 프로젝트를 주도해 나아갈 수 있다.

실무를 하다보면 인원 추가가 필요한 시기가 있다. 인원 추가 시기에 어떤 인력을 투입하고 편

성하는 것은 프로젝트 매니저의 역량이라고 생각 되지만 인력 투입 후의 팀워크도 생각해 볼 필

요가 있다.

*피드백 환영합니다*