ISTQB ) 테스트 심리학, 테스팅의 독립성에 대해 알아보자.

테스팅의 독립성 4가지

1. 개발자가 테스트를 설계하는 경우. (낮은 수준의 독립성) >> 자기가 만든 코드를 자기가 테스트 하는 경우엔 실수가 최소화되겠지?? 내가 만든 거라 에러를 잘 피할 수 있음.

2. 개발팀 내 다른 조직의 인력이 테스트를 설계하는 경우. >> 동료가 테스트 해주면 내가 한것 보단 독립성이 높겠지만 비슷비슷해.

3. 사내 다른 조직의 인력이 테스트를 설계하는 경우. (별도의 테스트 팀) >> 여기부터 독립성이 조금 높아짐. 아예 다른 팀이 하니까 조금더 까다롭게 테스팅하게 되지.

4. 다른 조직 또는 기업의 인력이 테스트를 설계하는 경우. (외부기관 인증) >> 외부업체에선 테스트한거 이기 때문에 가장 독립성이 높음.

>> 문제로 나오면 나열하는 문제로 나올 텐데 "독립성이 높은 것부터 나열하세요"라 하면 4,3,2,1 반대로면 1,2,3,4 생각하면 돼. 

테스트의 제약

▶ 관리자나 테스터가 테스팅에 대하여 단편적인 지식만 가지고 있음. 
▶ 부족한 인력과 자원으로 인해 테스팅에 대한 투자여력이 없음.
▶ 테스팅을 투자가 아닌 불필요한 비용으로 간주함.
▶ 의사결정권자나 프로젝트 관리자가 테스팅에 대한 인식이 부족함.

>> 전부 이러면 안 돼.

 

소프트웨어 테스팅에 대한 오해 >> 틀린 답으로 정확하게 파악하고 있어야 돼.

▶ 시간, 인력이 부족해서 테스팅을 제대로 못한다.
▶ 테스트는 완벽하게 수행될 수 있다.
▶ 테스트는 그리 어려운 작업이 아니다.
▶ 아무나 테스트를 수행할 수 있다.
▶ 프로그램이나 시스템이 잘 수행될 수 있음을 보여주는 것이다. >> 이건 개발자가 하는 거!!
▶ 테스트는 개발 이후의 작업이다. >> 초기 or 동시!!!
▶ 개발 일정에 따라 테스트는 생략될 수 있다. >> 생략 절대 ㄴㄴ

>> 계속 얘기하지만 여기도 전부 이러면 안 돼.

 

* 알기 쉬운 소프트웨어 공학 배우 유튜브 찾아서 한번 봐봐.

 

테스트의 심리학 (>> 도덕적 태도에 대해 말하고 있는 거야. 문제에서 긍정적인 게 답이겠지.)

▶ 개발자와 테스팅 엔지니어 분리 >> 각자의 활동에 집중.

▶ 테스팅 독립성(-> 단계가 오를 수록 독립성이 높아짐)

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

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

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

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

- 명확한 테스팅의 목표 설정은 테스팅을 성공적으로 수행하는데 있어 중요

▶ 테스팅 진행하는 동안 결함을 식별하는 과정

- 작성자에 대한 비판으로 오해될 소지 존재 (야 너 뭐 이따위로 테스트했어! >> 이러면 안 돼)

 >> 호기심, 전문적인 비평, 비판적인 시선, 세밀한 것에 주목하는 태도, 개발자 또는 개발팀 동료와의 원활한 의사소통, 그리고 결함을 유추해 내는 경험 필요.

- 오류나 결함, 장애가 긍정적인 방법으로 의사소통 된다면, 테스트와 개발자 간에 발생할 수 있는 감정 악화를 피할 수 있다. (명세화시킨 문서로 이야기하고, 전문적 비판을 하면 만족도 높아지겠지.)

- 테스터, 테스트 리더 사이 >> 좋은 대인관계 필요..

- 결함 정보

 >> 결함 발견 -> 시간과 비용 절감 및 리스크 요소 줄임

▶ 테스터의 역할

- 다툼보다는 협력으로 시작 -> 공통적인 목표를 모든 사람에게 전달

- 소프트웨어를 개발한 사람에게 비평을 배제하고 중립적이고 사실에 근거한 제품의 결함만 전달하려고 노력한다.

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

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

▶ 최근 소프트웨어는!

- 전통적인 컴퓨팅 영역 탈피 >> 가전, 무선단말기, 산업기기, 휴대폰, 자동차(ESU) 분야, AI분야

- SW개발 프로세스 품질의 중요성과 함께 SW 결함을 사전에 진단하고 정상 동작여부를 시험하는 테스팅의 중요성 부각

 >> 전체 개발비의 40~60% 이상의 테스팅 비용(개발 < 테스팅 비용)(유지보수비용이 많이 든다.)

 >> 하지만 기존 개발자들은 테스팅에 소극적 -> 하위레벨 테스트 부족. (컴포넌트, 통합테스트)

- 품질에 대한 인식 높아져 기대 수준 높아짐 -> 리스크 관리 필요.

 >> 체계적인 테스팅을 위해서는 테스트의 우선순위 중요.

 

소프트웨어 테스팅을 제약하는 요소

▶ 테스트에 대한 문제점

- 테스터가 테스팅에 대해 너무 단편적으로 알고 있는 것은 체계적인 테스팅을 제약하는 요인.

 >> 개념과 연관성 이해

 >> 리스크 기반 테스팅 접근법, 테스트 기법, 테스트 커버리지

 >> 이론을 실무에 적용하는 노력 필요 (이론과 실무를 골고루 알고 있어야 된다!)

- 의사결정권자와 매니저의 테스팅에 대한 인식 부족 (테스팅은 언제나 해야 돼!)

 >> 임시방편

 >> 테스트 자동화 도구의 중장기적 계획 or 테스트 프로세스 정립 필요

- 테스팅을 투자가 아닌 불 필요한 비용으로 인식

 >> 테스팅은 개발보다 더 확실한 ROI(Return On Investment - 투자자본수익률) 활동

(얼마나 효율적으로 투자가 이루어진 건지??)

 

테스팅 분야의 매력

▶ 테스팅 분야의 전문가

- 체계적인 지식 체계를 갖는 전문 분야

 >> 기존적인 컨셉과 테스트 전략, 계획, 설계 기법, 테스트 케이스 작성, 결함관리, 지원도구, 정적 테스트 기법, 비기능성 테스팅 테스트 프로세스 관리, 기반 설비 및 환경, 메트릭과 리포팅 등의 분야 포함.

- 테스팅 분야는 넓고 다양함.

 >> 자동화 도구에 대한 전문적 기술

 >> 보안성 테스트, 신뢰성 테스팅 분야 전문가

 >> 테스팅 컨셉, 기법 및 관리 방법을 소프트웨어 종류별 최적화하여 적용

- 테스팅 필요성 급증

- 테스팅 분야에서 연령 제한(X), 경험 중시