소프트웨어 개발 프로세스의 기본 개념 중 하나는 소프트웨어 개발 수명 주기 모델을 의미하는 SDLC 모델이다.

SDLC는 프로젝트가 시작순간부터 시작되는 연속적인 프로세스로, 개발에서 완전히 제거되는 순간부터 종료된다. 

여러개의 개발방법에 따라 SDLC 모델에서 진화하였는데 그 중 장 오래된 폭포수모델(Waterfall Model)에서부터 최근 애자일 모델(Agile Model)까지 다양하다. 어떤 종류의 모델을 선택했든지 간에, 각각의 모델은 모든 소프트웨어 개발 회사에서 사용하는 기본 단계를 가지고 있다. 각각의 SDLC 모델과 차이를 이해하는 것이 중요하므로 각 모델별로 확인해보자.

이번 포스팅은 테스터 <> 개발자간의 역할분리에 대한 내용이다.

개발자와 테스터를 분리해야할까? Why..?

개발자도 자신이 만든 코드를 스스로 테스트케이스(TC)를 만들고 테스트 수행에 참여할 수 있다.

하지만, 개발하면서 그에 대한 리소스 투입시간이 말처럼 쉽지가 않다

이에 전문적인 테스트 리소스에 의한 독립적인 시각의 제공 등 추가적인 이점을 얻기 위해서이기도 하다.

<프로젝트 오픈일정이 다가올수록..개발자는 우왕자왕>

이에, 개발자로부터 멀리 멀리 독립적인 테스터일수록 결함과 장애를 찾아내는 데 더 효과적일 수 있게 해준다.

예를 들면 테스팅의 독립성 정도(★)를 오름차순으로 아래와 같이 볼수 있다.

1. 개발자 자신이 테스트 : ★

2. 개발조직 내에 다른사람이 테스트 : ★★

3. 독립적인 테스트 팀과 같은 다른 조직의 일원 혹은 테스터 : ★★★

4. 다른 조직이나 회사(아웃소싱) : ★★★★

개발자가 아닌 다른 테스터에 의해 결함이나 오류 발견시 긍정적으로 의사소통이 되지 않는 다면 감정적으로 변할 수 있어,

현명하게 전달할 수 있는 좋은 대인관계 역시 필요하다.(다투지 말고 사이좋게 지내자..)

전체 테스트과정 중 테스팅을 효율적으로 실행하기 위해 계획..설계 등 활동을 구성해야한다.

논리적으로 순차적이나 테스트 제어는 모니터링으로 간주하여 중복되거나 동시에 발생할수 있기 때문에 주요활동을 조정해야한다.

1. 테스트 계획과 제어 단계

테스트 계획은 테스트 목표와 임무를 달성하기 위해 명세사항을 정의하는 활동이다.(말 그대로 계획하는 단계.)

테스트 제어는 계획대비 진행상황을 비교하는 활동으로 진행상태를 보고하는 것을 포함한다.

2. 테스트 분석과 설계

테스트 분석과 설계는 테스트 조건 및 테스트 케이스(TC)로 변환하는 활동이다.

Ex) 테스트 케이스(TC)

3. 테스트 구현과 실행

테스트 구현과 실행은 테스트 실행을 위해 테스트케이스(TC)를 순서에 따라 결합하여 테스트 프로시저를 명세화하고

테스트 환경 구축 및 테스트를 실행하는 활동이다.

Ex) 테스트 프로시저 = 테스트 케이스(TC) 실행순서

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

말 그래도 테스트가 어느정도 실행되었는지 평가하는 활동..

5. 테스트 마감활동

완료된 테스트 활동에서 데이터를 수집하여 경험과 정보를 활용..혹은 테스트를 통해 얻어진 교훈분석

1.1.1 SW 시스템관점에서의 테스팅 필요성

SW 시스템은 비즈니스에서 소비자제품에까지 생활의 많은 부분에 사용되고 있다.

간혹 사용하다가 제대로 동직하지 않는 경우를 접해보았을 것인데..이는 금전적 시간적 손실, 비즈니스의 이미지 손상을 물론 심하게 부상이나 사망에 이르기까지 정상적으로 동작하지 않는 SW는 심각한 문제를 일으킬 수 있다.

1.1.2 SW 결함의 원인

인간이 직접 프로그램 및 무너를 작성시 결함(결점,버그)을 만드는 오류를 범할수 있다.

이 처럼 시스템에 의도된 것과 다르게 행동되는 것을 장애라고 하며, 모든 결함이 장애를 일으키진 않는다.

결함원인

 - 시간적 압박

 - 복잡한 코드

 - 기반환경의 복잡성

 - 기술이나 시스템의 변경

 - 수 많은 시스템 상호간의 연동

장애(결함에 의해서뿐만 아니라 환경적인 조건에 의해서도 발생)

 - 방사선,

 - 자기

 - 전자기장,

 - 물리적 오염

1.1.3 SW 개발,유지보수,운영에서의 테스팅의 역할

발견하지 못한 시스템 또는 문서의 결함을 체계적인 테스팅을 통해 출시 전 발견하고 수정한다면

추후 운영환경내에 발생하는 결함들의 risk를 줄이는데 기여하며 SW 시스템 품질향상

1.1.4 테스팅과 품질

테스팅을 통해 SW 기능또는 비기능적 요구사항과 품질특성(기능성,신뢰성,사용성,효율성,유지보수성,이식성 등) 관련품질 측정이 가능하다. 테스팅으로 발견된 결함이 없거나 극소수시 SW의 품질에 대한 확신(confidence)을 가질수 있다.테스트가 성공적으로 완료되면 전반적인 리스크 수준은 감소하며, 결함을 찾는다면 결함이 수정될 떄 SW 품질은 향상된다.

품질을 높이기 위해서는 이전 프로젝트를 통해 많은 테스트 경험과 정보를 확보해야하며,

다른 프로젝트에서 발견된 결함의 근본 원인에 대한 이해를 바탕으로 프로세스를 개선할 수 있고 결함의 재발을 방지함으로써 차후 시스템의 품질을 개선할 수 있다.

1.1.5 테스팅 얼마나 해야 충분한가?

적절한 테스팅 정도를 파악하기 위해서는 기술적인 내용,안정성 비즈니스 리스트, 시간, 비용과 같은 프로젝트 제약사항을 고려.