I Love Salsa~~

소프트웨어 개발 모델

특성

V-모델(순차적 개발 모델)

1. 요구사항 정의 및 분석 2. 시스템 설계 3. 구현 4. 테스팅 등 일련의 단계(과정)을 통해서 소프트웨어 시스템을 개발하는 폭포수 개발 모델(Waterfall model)에 근간을 두고 있다. 테스트는 한번에 진행되는 것이 아니고, 각각의 개발 단계별 테스트 레벨로 진행된다. 위와 같은 쳬계로 개발 단계의 요구사항 분석, 논리 설계, 물리 설계, 프로그램 코딩 등의 4단계의 개발 활동으로 이루어진다. 이어 V-모델에서 제시하는 테스트 레벨은 컴포넌트(단위) 테스팅, 통합 테스팅, 시스템 테스팅, 인수 테스팅으로 분류된다. 소프트웨어 개발 기간 중에 개발 산출물(Work products - 비지니스 시나리오 또는 유즈케이스, 요구 사항 명세, 설계 문서나 코드)로 테스트 레벨에서 테스트 베이시스(Basis)가 된다.

V-모델에서 테스팅 개념

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

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

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

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

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

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

주석 :

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

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

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

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

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

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

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

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

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

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

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

1. 기획 시 유입된 결함

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

2. 설계 시 유입된 결함

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

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

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

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

5. 마무리 부족

6. 팀간 의사소통 부족

7. 코딩 실수

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

주석 :

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

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

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

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

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

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

- 개발 설계 문서

- 인터페이스

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

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

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

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

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

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

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

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

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