테스팅에 참여하는 것은 외부에 유출해서는 안되는 기밀정보나 특권정보를 접하게 되는데,

엔지니어를 위한 ACM과 IEEE의 윤리강령을 갖추고 있다고 한다..별로 중요하지는 않는듯..

가볍게 읽고 넘어가도 될 것 같다.

1. 공공성 – 공공의 이익을 위해 행동

2. 고객과 고용주 – 공공의 이익과 부합하면서 고객과 고용주의 이익을 최우선으로 행동

3. 제품 - 제공하는 결과물이 최상의 전무가적 표준을 충족

4. 판단 – 전문적인 판단을 함에 있어서 위상과 독립성을 유지

5. 관리 – 테스트 관리자 및 리더는 SW 테스팅 관리에 대해 윤리적 접근을 취하도록 지지하고 장려

6. 전문성 – 공공의 이익에 부합하는 전문 직업인으로서 위상과 평판을 선도

7. 동료 – 동료에게 공정하고 협조적이며, SW 개발자와 협력을 도모

8. 자기자신 – 테스터의 전문 직업관련 평생학습에 참여하며 직업 관행에 윤리적 접근 방식을 취해야 함

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. 테스트 분석과 설계

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

Ex) 테스트 케이스(TC)

3. 테스트 구현과 실행

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

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

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

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

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

5. 테스트 마감활동

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

1.2 테스팅이란 무엇인가? 에서는 테스팅이란 무엇인가..를 보았는데 요약하자면

테스팅 활동은 테스트 전과 후로 나뉘며 결함을 찾아내는것..

그리고 디버깅과의 차이점을 보면 될것 같다.

이번 포스팅은 테스팅의 7가지 원리를 보면 아래와 같다고 한다.

컴퓨터 발명 후 약 40여년간 아래의 원리에 대해 가이드라인 역할을 해오고 있다고 하네요..

원리1 - 테스팅은 결함이 존재함을 밝히는 활동

SW 테스팅에 대해 결함을 찾아 위험을 감소하는데 의미를 두고 있는데..

만약 결함을 못찾는경우!!!

이런 경우라도 SW 결함이 없다고 100% 증명할 수는 없다고 봐야한다.

버그는 반드시 있는법

원리2 - 완벽한 테스팅은 불가능

매우 간단한 SW를 제외하고는 모든 가능성에 대해 테스팅은 불가능에 가깝기 떄문에,

완벽한 테스팅보다는 리스크분석과 우선순위를 토대로 테스팅하는데 집중해야 한다.

원리3 - 테스팅을 개발 초기에 시작

뭐 당연한 이야기이지만 개발 수명주기 중 초기단계에서 테스트 활동을 하면 초기에 결함이 발견하여 위험에 방지 할수 있다.

원리4 - 결함집중

테스팅에 대한 리소스는 SW의 각 모듈별로 추정되는 기능과 차후 관찰된 결함 밀도에 따라 분배해야하는데, 보통 대다수의 결함은 소수 특정 모듈에 집중되어 결함이 발생되는 경우가 많다고 한다.

원리5 - 살충제 패러독스(Pesticide paradox)

살충제 패러독스란 테스트 케이스로 동일한 절차를 반복 수행하면 새로운 결함을 찾을수 없다! 라는 걸 의미한다.

말 그대로 A와 B중 A에 대한 모듈을 100번 반복해서 테스팅을 모두 완료하였다라고 볼수 없으며,

A와 B를 혼합하여..그리고 B에 대한 모듈도 동일하게 테스팅을 해야 잠재적인 결함을 발견 할 수 있다.

따라서 테스트 케이스를 작성한데 이 부분에 대해 고려를 해야한다.

원리6 - 테스팅은 정확(Context)에 의존적

SW 종류에 따라 테스팅도 영향을 받는다.

원리7 - 오류 부재의 궤변

개발이 완료된 시스템이 사용자의 필요와 기대에 부응하지 못하고 사용성이 현저히 낮다면 결함을 찾고 수정하는 과정은 아무 소용이 없다. 말 그대로 사용하는 사람이 없는데 테스팅을 해보았자 무슨소용이 있는가? 라는 원리이다..

앞선 포스팅에서는 테스팅이 필요한 이유에 대해 정리해보았다.

요약하여 말하자면 인간에 의해 작성된 프로그램 코드 또는 문서를 작성하는 과정에 발생한 결함(결점,버그)을 발견, 품질수준에 대한 자신감 획득,의사결정을 위한 정보제공, 리스크(위험)을 줄이는데 기여하는 것!

그 과정에서 테스팅이란 무엇인지 확인해보자~

테스팅(testing) 활동은 테스트를 수행하기 전 or 후로 나뉘는데 아래와 같다고 한다.

1. 테스트 계획/제어
2. 테스트 조건(test conditions)의 선택
3. 테스트케이스의 설계/수행
4. 결과점검
5. 테스트 완료조건의 평가
6. 테스트 프로세스와 테스트 대상 시스템애 대한 보고
7. 테스트 단계 완료 후에 행하는 마무리(Finalizing) 또는 마강 활동 종료와 같은 일련 활동

개발 수명주기중 초기에 이런 사고과정과 활동은 결합을 방지하는데 도움이 되며,

개발 기획단계에서 요구사항 명세서 등..  문서리뷰와 식별 역시 코드에 결함을 사전예방할수 있다.

테스팅에 관점이 다양한 이유는

SW의 결함을 찾아내고 수정하기 위해 다양한 장애상황을 만들어야 하기 때문에 목적이 다양하다.

테스팅은 디버깅(debugging)과 근본적으로 구분되는 개념인데 차이는 다음과 같다.

디버깅 = 벌레잡기..버그잡기로 보믄될려나..?

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 테스팅 얼마나 해야 충분한가?

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