소프트웨어 개발 모델 특성
V-모델(순차적 개발 모델) 1. 요구사항 정의 및 분석
2. 시스템 설계
3. 구현
4. 테스팅

등 일련의 단계(과정)을 통해서 소프트웨어 시스템을 개발하는 폭포수 개발 모델(Waterfall model)에 근간을 두고 있다.
테스트는 한번에 진행되는 것이 아니고, 각각의 개발 단계별 테스트 레벨로 진행된다.

위와 같은 쳬계로 개발 단계의 요구사항 분석, 논리 설계, 물리 설계, 프로그램 코딩 등의 4단계의 개발 활동으로 이루어진다.
이어 V-모델에서 제시하는 테스트 레벨은 컴포넌트(단위) 테스팅, 통합 테스팅, 시스템 테스팅, 인수 테스팅으로 분류된다.

소프트웨어 개발 기간 중에 개발 산출물(Work products - 비지니스 시나리오 또는 유즈케이스, 요구 사항 명세, 설계 문서나 코드)로 테스트 레벨에서 테스트 베이시스(Basis)가 된다.

 

V-모델에서 테스팅 개념

개념 의미
테스트 레벨의 의미 앞서 설명한 V-모델에서 제시한 각각의 테스트 레벨은

1. 독립적이여한다.
2. 다른 테스트 계획과 전략으로 진행해야 한다.
3. 수행하는 주체(조직)이 달라야 한다.
4. 적용하는 테스트 기법의 종류와 형태가 상당 부분이 달라야 한다.
5. 별로의 보고를 진행해야 한다.
6. 서로 종송성을 지니기 때문에 하나의 테스트 레벨에서 다른 테스트 레벨로 전달되기 위한 종료 및 시작 조건을 갖춰야 한다.
개발 초기 단계에서 테스팅을 수행한다는 의미 1. 개발 산출물을 리뷰(Review) 형태로 검토하면서 결함을 발견하는 정적 테스팅을 의미한다.(정적 테스팅 기간동안 테스터는 테스팅 관점에서 테스트 케이스를 만들면서 결함을 발견하여 리뷰에 기여 할 수 있다.)
2. 이때 발견한 결함은 동적 테스팅에서 발견할 수 있는 결함과는 다른 종류의 결함들이다.
정적 테스팅의 설계 기법은 결정 테이블 테스팅, 상태전이 테스팅, 유즈케이스 테스팅 등을 활용할 수 있다.
3. 개발 초기의 테스팅으로 개발 후반부에서 발생 가능한 테스팅 비용을 줄일 수 있다. 또한 개발 초기에 발견된 결함은 수정 비용이 비교적 저렴한다.
결함 예방 차원에서의 테스팅이 의미하는 바 위와 같이 "개발 초기 단계에서 테스팅"으로 개발 산출물을 리뷰하거나 조기에 테스트를 설계함으로써 소프트웨어의 결함을 사전에 예방하는 효과를 얻게 된다.
V&V(Verification and Validation)의 의미 베리피케이션과 밸리데이션은 소프트웨어 개발 수명주기의 모든 단계엥서 수행될 수 있다.
Verification은 개발 단계의 산출물이  그 단계의 초기에 설정된 조건을 만족하는지 여부를 검증하는 프로세스를 의미한다.(리뷰를 통해서 검증하거나, 테스트 레벨의 목적에 맞는 동적 테스닝을 통해서도 검증할 수 있다.)
Validation은 개발 중에 또는 개발단계 막바지에 명시된 또는 명시되지 않았지만 사용자의 관점에서의 요구사항이 만족하는지를 평가하는 프로세스를 의미한다.
Posted by 테리
:

테스터들은 인도된 제품에 대하여 문제점들을 찾아야 한다. 그러다보니 어쩔 수 없이 개발자와 사소한 의사 다툼이 발생이 될 수 밖에 없다.

다음은 그런 사항을 사전에 개선할 수 있는 내용이 있어 적어 봅니다.

 

1. 다툼보다는 협력으로 시작한다. 즉, 더 나은 품질의 시스템을 개발하고자 하는 공통적인 목표를 모든 사람에게 주지시킨다.

2. 소프트웨어를 개발한 "사람"에 대한 비평을 배제하고, 중립적이고 사실에 근거한 제품의 결함만을 전달하려고 노력한다.(예로 객관적이고 사실적인 인시던트 리포트를 작성하고 발견한 사항을 리뷰 한다.)

3. 다른 인원이 어떻게 느끼는지, 왜 그렇게 반응하는지 이해하도록 노력한다.

4. 상호간에 의사소통 했던 것을 상대방이 정확하게 이해했는지 확인한다.

 

주석 :

음, 개발자 입력에서 보면 1번, 2번, 4번이 중요한 듯하다.

공통된 목표 의식과 개발자가 아닌 제품의 관점으로 접근하며, 의사소통이 정확하게 전달이 되었는지가 중요한 듯 하다.

Posted by 테리
:

다음의 순서대로 테스팅의 독립성은 높아진다.

1. 테스트 대상 소프트웨어의 개발자가 설계한 테스트(독립성 낮음)

2. (개발팅 내의) 다른 인원이 설계한 테스트

3. 다른 그룹의 독립적인 테스트 팀의 인원, 또는 테스트 전문가(사용성 또는 성능 테스트 전문가 등)가 설계한 테스트

4. 다른 조직 또는 다른 회사의 인원이 설계한 테스트(외부적인 조직에 의한 인증, 아웃소싱)

 

3번, 4번의 차이점을 확실히 느껴보았다.

4번의 경우는 억울할 때도 가혹 있었다.

 

테스티의 독립성이 보장되어야 보다 나은 소프트웨어로 발전이 될 것이다.

Posted by 테리
:

다음과 같은 결함 유형이 있다(지적 유형?)

1. 기획 시 유입된 결함

- 요구사항의 표준 미준수, 테스트 불가능, 불명확, 불완전, 불일치, 기타 결함

2. 설계 시 유입된 결함

- 설계의 표준 미준수, 테스트 불가능, 불명확, 불완전, 불일치, 인터페이스 결함, 기타 결함

3. 코딩 시 유입된 결함(연관 변수 파악 부족, 예외 사항 고려 부족 등)

- 코드의  표준 미준수, 불완전, 불일치, 인터페이스 결함, 데이터 결함, 기타 결함

4. 테스트 부족으로 유입된 결함

5. 마무리 부족

6. 팀간 의사소통 부족

7. 코딩 실수

"마무리 부족으로 유입된 결함" 유형이 상대적으로 많다면 개발 과정에서 마무리하는 절차를 별도로 가지거나 품질 보증자가 마무리가 제대로 되도록 감시하는 활동을 강화하는 등의 개발 프로세스 개선을 고려해야 한다.

 

주석 :

"마무리 부족으로 유입된 결함" 유형을 참 많이 내었으며, 이런 유형을 많이 경험해 보았다.

결론은 자신과의 싸움에서 진 것이다.(지속적인 테스팅이 필요함)

Posted by 테리
:

다음은 테스트 분석과 설계에 필요한 내용들이다.

1. 테스트 베이시스(Test basis) 리뷰

- 요구사항 명세서(Requirement Specification)

- 아키텍처(소프트웨어 구조)

- 개발 설계 문서

- 인터페이스

2. 테스트 대상 아이템 또는 제품, 명세, 동작과 구조의 분석을 통해 테스트 상황을 식별하고 우선 순위 선정

3. 테스트 케이스 설계와 우선순위 선정

- 공식적인 테스트 기법(Formal test techniques)을 활용한 테스트 케이스(Test cases) 도출

4. 비공식적인 테스트 기법으로 테스트 케이스 추가 도출 및 보완

5. 테스트 상황과 테스트 케이스에 필요한 테스트 데이터 식별

6. 테스트 환경 구축에 대한 디자인과 요구되는 기반 시설(Infrastructure) 및 도구(Tools)의 식별

 

1번, 3번, 5번 등은 전달 또는 수집하였으나, 나머지는 처음 듣는 작업임.

Posted by 테리
:

테스팅에서 결함 심각도의 기준을 살펴본다.

결함 기준
치명적 결함_Critical Defects 하드웨어 또는 소프트웨어 장애, 시스템 중지, 시스템 잠기(접근 불가), 데이터 손실 또는 변조
주요 결함_Major Defects 기능 상실, 잘못된 기능, 주요 기능 오동작
일반 결함_Average Defects 불완전한 기능, 사소한 기능 오작동, 잘못된 인터페이스
사소한 결함_Minor Defects 타이핑 에러, 사용자 불편, 스크린 표준의 위반, 좋지 않은 인터페이스
개선 사항(Enhancement) 에러는 아니지만 개선이 필요한 사항

 

일반 결함이 있는지는 오늘 처음 아는 사실임.

Posted by 테리
: