개알 Part 1. 소프트웨어 테스팅의 기초

1.1. 소프트웨어 테스팅이 왜 필요한가?

 

1.1.1. 소프트웨어 시스템 관점에서 테스팅의 필요성

• • 소프트웨어가 올바르게 동작하지 않는 경우
    -> 금전적인 손실, 시간 낭비, 비즈니스의 이미지 손상, 부상이나 사망 등등 -> 다양하고 심각한 문제 발생
    
    
  • 테스팅의 필요성 : 소프트웨어 시스템의 문제를 최소화하기 위해!!

 

1.1.2. 소프트웨어 결함의 원인

• • 오류(Error) -> 결함(Defects or Bug) -> 장애(Failure)
    
    
  • 결함은 장애의 원인이 되지만, 모든 결함이 장애를 일으키는 것은 아님
    
  • 결함의 원인
    • 시간적인 압박
    • 복잡한 코드
    • 기반환경(Infrastructure)의 복잡성
    • 기술이나 시스템의 변경
    • 수많은 시스템 상호간의 연동 등등
      
      
  • 장애 발생 원인
    • 결함
    • 환경적인 조건(방사, 자기, 전자기장, 물리적 오염)
      -> 소프트웨어 조건을 변경
      -> 소프트웨어 실행에 영향 미칠 수 있음

 

1.1.3. 소프트웨어의 개발, 유지보수, 운영 시 테스팅의 역할

• • 개발에서의 테스팅의 역할
    • 결함들을 릴리즈 전에 발견하고 수정
      -> 운영 환경 내에 발생하는 결함들의 리스크(위험)를 줄여줌
      -> 소프트웨어 시스템의 품질 향상에도 도움을 줌
      
      
    • 소프트웨어 개발과정에서 개발 초기의 요구사항 분석 단계부터 테스팅 시작(-> 리뷰, 정적분석 - Part 3)
      
      
    • 각각의 개발 단계에 대응하는 테스트 레벨에 따른 테스팅이 이루어짐
      -> 개발과정에서 소프트웨어의 품질을 높임, 고객에게 전달된 이후 결함이 발생할 가능성 최소화
      • 컴포넌트(단위) 테스팅, 통합 테스팅 : 개발조직이 중심이 되어 수행
      • 시스템이 갖춰진 이후의 테스팅 : 개발조직의 지원 -> 독립성을 가진 테스트 조직을 중심으로 수행
      • 인수 과정에서의 테스팅 : 최종 소프트웨어 사용자가 인수
        
        
  • 운영에서의 테스팅의 역할
    • 기존에 운영하던 시스템이 유지보수 활동으로 변경(Modification) 및 단종 or 환경이 변했을 경우
      -> 변경된 시스템의 대상, 환경에서의 운영 테스팅이 요구
      -> 변경으로 야기될 수 있는 결함, 그로 인해 발생 가능한 장애를 예방
      
      
  • 계약상(법적) 요구조건들 or 산업에 특화된 표준들을 만족시키기 위해 필요
    
    

1.1.4. 테스팅과 품질

• • 테스팅으로 발견된 결함이 극소수 or 없다면? (전제 조건 : 테스트 설계 및 실행이 정상적으로 실행)
    -> 소프트웨어의 품질에 대한 확신(Confidence)을 가질 수 있음
    
    
  • 올바르게 설계된 테스팅
    -> 시스템의 전반적인 리스크 수준을 감소
    -> 테스팅으로 결함을 찾아냄 + 발견된 결함이 수정 = 소프트웨어 시스템의 품질 향상
    
    
  • 품질 보증(Quality Assurance)의 관점에서 품질을 높이기 위해서?
    • 이전 프로젝트를 통해 많은 테스트 경험과 정보를 확보해야 함
    • 다른 프로젝트에서 발견된 결함의 근본 원인에 대한 이해
      -> 프로세스 개선 -> 결함 재발 방지 -> 시스템의 품질 개선

 

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

• • 적절한 테스팅의 정도를 파악하기 위해서?
    • 리스크(Risk) 수준을 고려(-> 리스크 - Part 5)
    • 프로젝트 제약 사항(기술적인 내용, 비즈니스, 제품, 프로젝트 리스크, 시간, 비용) 고려
      
      
  • 테스팅은 프로젝트 이해관계자들이 릴리즈 결정을 내릴 수 있도록 충분한 정보를 제공해야 함

 

1.2. 테스팅이란 무엇인가?

• • 전통적인 테스트 개념
    • 응용 프로그램 or 시스템의 정상 작동 여부 확인
      
      
  • 현재 테스트 개념
    • 사용자의 기대 수준과 요구 사항에 맞게 구현, 동작 확인
      -> 결함 발견
      -> 개발 프로젝트의 리스크(Risk) 정보를 정량적 수치로 의사결정권자(프로젝트 관리자 등)에게 전달
      
      
  • 일반적인 테스팅의 목적
    • 남아있는 결함 발견
    • 명세 충족 확인
    • 사용자 및 비즈니스의 요구 충족 확인
    • 결함 예방
      
      
  • 부가적인 테스팅의 목적
    • 품질 수준에 대한 자신감(Confidence) 획득과 정보 제공
    • 비즈니스 리스크를 감소시키는 정보에 근거한(Well-informed) 조언 제공(발견된 결함 기반의 수치적 데이터 활용)
    • 개발 프로세스 점검, 이슈 제기
    • 논리적 설계의 구현 검증(Validate)
    • 시스템과 소프트웨어가 적절히 동작함을 확인
      
      
  • 관점에 따른 테스팅의 목적
    
    • 개발과정에서의 테스팅 : 결함 찾아내고 수정하기 위해서 가능한 많은 장애(Failure) 상황 만듦
    • 인수 테스팅 : 예상된 대로 시스템이 동작하는지 확인, 요구사항에 맞는 확신을 얻는 과정
    • 품질 평가를 위한 테스팅 : 특정 시간에 시스템을 출시(Release)하는 것의 리스크를 개발 프로젝트 관련자(Stakeholders)에게 전달
    • 유지보수 테스팅 : 리그레션 테스팅(Regression testing / 개발 과정에서 변경 작업이 일어나는 경우 새로운 결함이 유입되었는지 확인) 과정 포함
    • 운영 테스팅 : 시스템의 특성(신뢰성, 가용성 등)을 평가
      
      
  • 테스팅 vs 디버깅
    • 테스팅 : 결함을 발견하기 위한 활동
    • 디버깅 : 결함의 원인을 밝히고, 코드를 수정하는 개발 활동
      -> 이후 확인 테스팅(Confirmation testing) 수행
      -> 결함이 제대로 수정되었는지 확인
      
      

1.3. 테스팅의 일반적인 원리

• 원리 1 - 테스팅은 결함이 존재함을 밝히는 활동이다.
  • 테스팅은 소프트웨어에 잠재적으로 존재하는 결함을 줄일 수는 있지만,
    결함이 전혀 발견되지 않은 경우라도 해당 소프트웨어에 결함이 없다고 증명할 수는 없다.
    (완벽한 테스팅이 불가능하기 때문!!)
    
    

 

• 원리 2 - 완벽한 테스팅(Exhaustive testing)은 불가능하다.

• • 일반적으로 완벽한 테스팅이 불가능한 이유
    • 무한 경로
    • 무한 입력값
    • 무한 타이밍
      
      

• • 테스트 대상의 리스크 분석을 토대로 테스트 활동 >>>> 완벽한 테스팅
    
    
• 원리 3 - 테스팅을 개발 초기에 시작한다.
  • 개발 초기에 테스팅할 때의 이점
    • 개발 초기부터 준비된 테스트 케이스 -> 테스트 레벨별로 실행 -> 전체 테스팅 기간 단축
    • 코딩에서의 재작업 줄임 -> 개발 기간 단축
    • 개발 후반부에 발견될 결함 예방
      
      
  • 요르돈 법칙(Snowball Effect, 눈동이 법칙) : 개발 초기에 테스팅 하지 않으면 비용이 커진다.
    
    

• 원리 4 - 결함 집중(Defect clustering)
  • 출시 전 대다수의 결함들은 소수의 특정 모듈에 집중되어 발생 -> 대부분 운영상의 장애를 초래
  • 일반적으로 결함이 집중될 수 있는 모듈
    • 자체적으로 복잡한 구조를 가지고 있는 모듈
    • 소프트웨어 or 시스템의 다른 부분 / 다른 모듈과 다량의 복잡한 상호 작요을 하는 모듈(복잡한 인터페이스)
    • 개발 난이도가 높거나 최신 기술을 사용한 모듈
    • 기존에 개발된 것을 재사용하지 않고 새롭게 개발한 모듈
    • 크기가 큰 모듈
    • 경험이 미흡한 개발팀에서 개발한 모
      
      
  • 파레토 법칙 : 소프트웨어 테스트에서 오류는 80%는 전체 모듈 20% 내에서 발견된다.
    
    
• 원리 5 - 살충제 패러독스(Pesticide paradox)
  • 동일한 테스트 케이스로 동일한 테스트를 반복적으로 수행 
    -> 나중에는 더 이상 새로운 결함을 찾아내지 못한다.
    -> 테스트 케이스를 정기적으로 리뷰, 개선할 필요가 있음
    
    
• 원리 6 - 테스팅은 정황(Context)에 의존적이다.
  • 정황과 도메인(분야)에 따라 다르게 테스팅을 진행
  • 모든 테스팅에서 변하지 않는 사항
    • 테스트 주요활동에 대한 테스트 프로젝트 계획
    • 표준적인 기법 적용(Technique)
    • 독립적 테스트 환경(Environment)
    • 효율적/효과적 테스트 팀 조직(Organization)
    • 정식 리포팅(Formal reporting) 등등
      
      
• 원리 7 - 오류-부재의 궤변(Absence-of-errors fallacy)
  
  • 결함을 모두 발견하여 제거하였다고 하더라도 품질이 높다고 볼 수 없는 경우?!
    • 개발된 시스템이 사용자의 필요와 기대에 부응하지 못하고 사용성이 현저히 낮은 경우
    • 사용자 또는 비즈니스의 요구를 충족 못하는 경
      
      
• 소프트웨어 테스팅은??
  • 결함이 존재함을 밝히고, 
  • 사용자와 비즈니스의 요구사항에 따라 테스트 대상 제품이 개발되었는지 확인하고, 
  • 완벽한 테스팅이 불가능하므로 리스크 기반으로 결함이 집중되어 있을 만한 곳을 예측하여 
  • 가능한 개발 초기부터 테스트를 수행해야 함!
  • 테스트 수행 시 테스트 정황(테스트 대상 제품의 특성, 테스트 요구사항 등등)을 반영하여 테스트를 설계하고, 
  • 이로부터 도출한 테스트 케이스는 지속적인 보완과 추가를 통하여 
  • 더 많은 결함을 발견할 수 있도록 함!
    
    

1.4 테스트 프로세스의 기초

• 테스트 프로세스의 주요 활동

테스트 계획과 제어(통제)
테스트 분석과 설계 테스트 베이시스 검토 ※ 테스트 베이시스 ex) 개발 중간산출물 등등 테스트 설계 및 구현의 기반 테스트 계획단계에서부터 필요, 설계 시에는 반드시 요구 테스트 상황/요구사항/데이터 식별 테스트 기법 할당 테스트 용이성(testablilty) 평가 ※ 테스트 용이성 변경된 소프트웨어의 테스트를 가능하게 하는 소프트웨어 제품의 능력 테스트 환경 구축	테스트 목적/목표 설정 및 대상 연구 ※ 대상? 소프트웨어 늦어도 실제 테스트를 실행하는 단계에서 반드시 필요 테스트 전략 개발 리스크 분석 전략 수립 테스트 완료 조건 테스트 추정 조직 구성 테스트 계획 활동 테스트 관리 및 제어 리포팅(모니터링) 리포팅 계획/설계 진행 리포팅
테스트 구현과 실행 테스트 케이스 명세화, 우선순위 선정, 데이터 생성, 프로시저 작성 선행 테스팅 (재) 테스팅 실행 (결과 기록) ※ (재) 테스팅 수정 활동이 성공적이었는지를 검증하기 위해, 마지막으로 실행했을 때 실패되었던 테스트 케이스를 다시 실행 기대 결과와 비교
테스트 완료 조건(Exit criteria)의 평가와 리포팅 완료 조건의 달성 여부 확인 최종 테스트 보고서 작성
테스트 마감 활동 산출물 확인 테스트웨어 보관 -> 유지보수 조직에 이관 ※ 테스트웨어 : 테스트 프로세스 동안 생성된 산출물 테스팅에 사용되는 문서, 스크립트, 입력값, 예상 결과, 시작과 마무리 절차, 파일, 데이터베이스, 환경 + 모든 추가적인 소프트웨어 or 유틸리티 포함 테스트 프로세스 평가(심사) 및 개선 사항 제안 테스트 프로젝트를 통해 얻은 교훈을 분석

 

1.4.1. 테스트 계획과 제어(통제)(-> Part 5)

• • 테스트 계획 수립

• • • 테스트 목표와 임무(Mission)를 달성하기 위해 면밀히 확인하고, 필요한 활동을 정의
    • 테스팅의 제어와 모니터링 활동으로부터 받는 피드백(Feedback) 반영
    • 주요 작업 (Tasks)
      • 테스트 범위(Scope)와 테스트를 위한 리스크에 대한 결정, 테스팅의 목적에 대한 식별
      • 테스트 범위 : 다른 시스템과의 인터페이스 정도, 관련 품질 특성, 호환성(Compatibility) 테스팅 범위, 커버하고자 하는 테스트 레벨 등등
      • 리스크 기반 테스트 전략 : 각각의 테스트 레벨에 대해 대상 제품이 충족해야할 품질 수준 및 특성, 기술적 어려움, 비즈니스 리스크를 고려한 테스트 전략 수립
      • 테스팅 목적 : 품질 요구 수준, 테스트 레벨 별 목적(결함 발견, 요구 사항 충족 등등), 커버하고자 하는 품질 특성(기능성, 효율성, 신뢰성, 유지 보수성 등등) 등등
      • 테스트 정책의 실현과 테스트 전략의 구현
      • 테스트 정책 : 조직 구조 형태 및 인력 구성/자격, 중점 테스트 타켓과 테스트 레벨, 테스트 프로세스 개선 방향, 고객 및 이해관계자와의 관계 등등
      • 테스트 접근 방법에 대한 결정 : 테스트 기법 및 테스트 베이시스 포함여부, 테스트 아이템, 커버리지, 테스팅에 참여할 팀의 식별과 팀간 의사소통(Interfacing), 테스트웨어 등등
      • 테스트에 필요한 리소스의 결정 (조직, 인원, 테스트 환경 등등)
      • 테스트 분석과 설계 작업의 일정관리
      • 테스트 구현, 실행 및 평가의 일정관리
      • 테스트 완료 조건의 결정
        
        
  • 테스트 제어
    • 계획 대비 실제 진행 상황을 비교하는 지속적인 활동
      = 진행 상태(계획과의 차이, 계획과의 일치 정도 등등)를 보고
      = 테스트 프로젝트의 목표 및 임무를 달성하기 위해 계획과의 차이에 대해 조치를 취하는 것
    • 프로젝트 내내 테스팅 활동을 모니터링 하여야 함
    • 주요 작업 (Tasks)
      • 테스트 결과에 대한 측정과 분석
      • 테스트 진척 상황, 테스트 커버리지와 완료 조건의 모니터링과 문서화
      • 테스트 계획과의 차이를 교정하는 활동
      • 테스팅의 진행과 변경에 대한 의사 결정 활동

 

1.4.2. 테스트 분석과 설계

• • 일반적이고 추상적인 테스팅 목적 -> 실제적이고 구체적인 테스트 상황(Test conditions)과 테스트 케이스로 변환하는 활동
  • 주요 작업 (Tasks)
    • 테스트 베이시스(Test basis) 리뷰
      • 요구사항 명세서(Requirement Specification)
      • 아키텍처(소프트웨어 구조)
      • 개발 설계 문서
      • 인터페이스
    • 테스트 대상 아이템 or 제품, 명세, 동작과 구조의 분석을 통해 테스트 상황을 식별하고 우선 순위 선정
    • 테스트 케이스 설계와 우선순위 선정
      • 공식적인 테스트 기법(Formal test techniques)을 활용한 테스트 케이스(Test cases) 도출
    • 비공식적인 테스트 기법으로 테스트 케이스 추가 도출 및 보완
    • 테스트 상황과 테스트 케이스에 필요한 테스트 데이터 식별
    • 테스트 환경 구축에 대한 디자인과 요구되는 기반 시설(Infrastructure) 및 도구(Tools)의 식별

 

1.4.3. 테스트 구현과 실행

• • 테스트 케이스를 조합하고, 테스트 실행에 필요한 다른 정보를 포함하는 테스트 프로시저(Test procedure) or 테스트 스크립트(Test script)를 명세화 하는 활동
    ※ 테스트 프로시저 : 테스트 케이스의 실행 순서
    ※ 테스트 스크립트 : 테스트 절차 명세. 특히 자동화된 것!
  • 주요 작업 (Tasks)
    •  테스트 케이스의 개발, 구현과 우선순위 선정
    • 자동화 테스트 스크립트 작성
    • 테스크 하네스(Test Harnesses) 준비
      ※ 테스트 하네스 : 테스트를 수행하기 위해 필요한 스텁(stubs)과 그 드라이버(drivers)로 구성된 테스트 환경
      ※ 스텁 : 골격만 있는 or 특별한 목적의 소프트웨어 컴포넌트를 구현한 것.
      ※ 드라이버 : 컴포넌트 or 시스템을 제어 or 호출하는 (실제) 상위 컴포넌트를 대체하는 테스트용의 소프트웨어 컴포넌트 or 툴
    • 효율적인 테스트 실행을 위해 테스트 수트(Test Suites, 테스트 케이스 묶음) 생성
    • 테스트 환경의 올바른 구축 여부 확인
    • 계획된 순서에 의거하여 수동 or 테스트 실행 도구 -> 준비된 테스트 프로시저를 수행
    • 테스트 수행 결과를 기록해두고, 테스트 중인 소프트웨어, 테스트 도구, 테스트웨어의 식별과 버전을 기록
    • 예상 결과와 실제 결과를 비교
    • 예상 결과와 실제 결과간의 차이에서 오는 불일치를 인시던트(Incidents, =이슈(Issues)) 또는 결함(Defects)으로 보고
      
      
    • 불일치의 원인을 알아내기 위해 실제 결과나 현상을 분석
      • 테스트 케이스 결함 : 테스트 실행의 실패(Fail)가 어플리케이션 결함이 아닌 테스트 케이스 자체의 결함때문에 생긴 경우
      • 테스트 정황(Context) 결함 : (스크립트, 시나리오 등) 테스트 수행상의 오류, 테스트 데이터 입력 오류
      • 어플리케이션 결함 : 테스트 대상 소프트웨어/하드웨어 결함, 진행 절차(Procedure) 상의 결함, 설치상의 결함, 코드상의 결함
      • 어플리케이션 정황 결함 : 사용상의 오류, 테스트 환경(OS, DBMS 등)과 관련된 소프트웨어 결함
        
        
    • 각각의 불일치를 조치한 결과를 확인하기 위해 테스트 활동을 반복
      • 수정을 확인하기 위해 이전에 실패한 테스트 실행 (Confirmation testing)
      • 수정으로 인해 새로운 버그가 추가 발생하지 않았는지, 변경되지 않은 부분에 수정 사항과 연관된 버그가 발생하지 않았는지 확인하는 테스트 실행 (Regression Testing)
        
        
    • 분류 가능한 결함 유형
      • 기획 시 유입된 결함 : 요구사항 표준 미준수, 테스트 불가능, 불명확, 불안전, 불일치, 기타 결함
      • 설계 시 유입된 결함 : 설계의 표준 미준수, 테스트 불가능, 불명확, 불안전, 불일치, 인터페이스 결함, 기타 결함
      • 코딩 시 유입된 결함 : 연관 변수 파악 부족, 예외 사항 고려 부족, 코드의 표준 미준수, 불완전, 불일치, 인터페이스 결함, 데이터 결함, 기타 결함
      • 테스트 부족으로 유입된 결함
      • 마무리 부족 
      • 팀간 의사소통 부족
      • 코딩 실수
        
        
    • 결함 심각도(Severity level) 분류
      • 치명적(Show stopper), 매우 심각(Fatal), 심각(No Workaround), 보통(Workaround), 경미(Cosmetic)
      • 치명적 결함(Critical Defects) : 하드웨어 또는 소프트웨어의 장애, 시스템 중지, 시스템 잠김(접근 불가), 데이터 손실 또는 변조
      • 주요 결함(Major Defects) : 기능 상실, 잘못된 기능, 주요 기능 오작동
      • 일반 결함(Average Defects) : 불완전한 기능, 사소한 기능 오작동, 잘못된 인터페이스
      • 사소한 결함(Minor Defects) : 타이핑 에러, 사용자 불편, 스크린 표준의 위반, 좋지 않은 인터페이스
      • 개선 사항(Enhancement) : 에러는 아니지만 개선이 필요한 사항
        
        
    • 모든 경우 결함 심각도가 가장 높다고 해서 가장 먼저 그 결함을 수정해야 하는 것은 아님
      
      
    • 결함 우선순위 표현
      • 즉시 해결(Resolve immediately), 주의 요망(Give high attention), 대기(Normal queue), 낮은 순위(Low priority)

 

1.4.4. 테스트 완료 조건과 리포팅

• • 완료 조건(-> 5.2.3 완료 조건) 평가
    • 초기에 정의된 테스트 목표에 비해 어느 정도 실제 테스트가 수행되었는지를 평가하는 활동
    • 추가적인 테스트를 통해 목표를 달성할 것인지, 목표를 변경하여 완료할 것인지 결정
    • 각 테스트 레벨(Test level - 컴포넌트, 통합, 시스템, 인수테스팅)마다 수행되는 것이 원칙
    • 주요 작업 (Tasks)
      • 테스트 실행 결과(Test logs)가 테스트 계획에 명시된 완료 조건을 만족하는지 확인
        ※ 테스트 실행 결과 : 테스트의 실행에 대한 관련 세부항목의 시간 순서에 따른 기록
      • 추가적인 테스트가 필요한지, 명세된 테스트 완료 조건을 변경 해야 하는지에 대한 평가 수행
      • 이해관계자(Stakeholders)에게 배포할 테스트 요약 보고서 작성
        
        
  • 리포팅(-> 5.3.2 테스트 리포팅)
    • 진행보고와 릴리즈 조언 및 최종 보고 형태로 이루어짐
    • 수집한 결함 및 테스트 진행 관련 데이터를 가공, 메트릭(Metrics)으로 수치화하고 관련 정보를 표현하는 작업
    • 리포팅에 표현되는 내용
      • 발견된 결함과 미해결 결함의 추이 및 우선순위
      • 테스트 진척도
      • 리스크 및 메트릭으로 실증된 조언
      • 테스트 환경의 가용성
      • 테스트 커버리지, 결함 발견 효과성/효율성, 품질 평과 결과, 결함 상태별 결함 수, 소프트웨어 사이즈 대비 결함 수, 요구사항 별 테스트 일 수, 해결되지 않은 결함과 그 영향, 오랫동안 수정되지 않은 결함 분석 등등

 

1.4.5. 테스트 마감 활동

• • 완료된 테스트 활동에서 데이터를 수집, 테스트에서 발견된 사실 및 수치적 데이터와 함께 테스팅 경험과 테스트웨어를 종합하고 축적하는 활동
  • 테스팅이 얼마나 체계적으로 수행되었는지 평가, 향후 테스팅 개선을 위한 모범사례(Best practice)를 모델로 테스트 프로세스 심사(평가)
  • 주요 작업 (Tasks)
    • 테스트 결과 마감 : 예정된 산출물 확인, 인시던트 리포트(결함 리포트 포함) 종료, 해결되지 않은 추가 및 변경 요구사항에 대한 처리, 시스템 인수의 문서화
    • 테스트웨어, 환경, 기반설비(Infrastructure)의 차후 사용 대비를 위한 마감 및 보관
    • 테스트웨어를 유지보수 조직에 이관
    • 테스트 프로세스 심사(평가)(-> 5.7 테스트 프로세스 평가) 및 개선 사항 제안
    • 테스트 프로젝트를 통해 얻은 교훈 분석

 

1.5. 테스팅의 심리학

• 테스팅의 독립성(-> 5.1.1 테스트 조직과 독립성)
  1. 테스트 대상 소프트웨어의 개발자가 설계한 테스트(독립성 낮음)
  2. (개발팀 내의) 다른 인원이 설계한 테스트
  3. 다른 그룹의 독립적인 테스트 팀의 인원 or 테스트 전문가(사용성 or 성능 테스트 전문가 등등)가 설계한 테스트
  4. 다른 조직 or 회사의 인원이 설계한 테스트(외부 조직에 의한 인증, 아웃소싱)
     ∴ 1 -> 4단계로 올라갈수록 독립성은 높아짐!
     
     
• 테스터가 의사소통 잘하는 방법
  • 다툼보다는 협력으로 시작 -> 더 나은 품질의 시스템을 개발하고자 하는 공통적인 목표를 모든 사람에게 주지시킴
  • 소프트웨어를 개발한 "사람"에 대한 비평을 배제, 중립적이고 사실에 근거한 제품의 결함만을 전달하려고 노력
  • 다른 인원이 어떻게 느끼는지, 왜 그렇게 반응하는지 이해하도록 노력
  • 상호간에 의사소통 했던 것을 상대방이 정확하게 이해했는지 확
    
    

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

• 개발 자체가 실제 소요되는 일정보다 짧은 기간 동안 부족한 인력과 리소스로 진행
  -> 테스팅에 대한 투자 고려가 어려움
• 관리자 or 테스터가 테스팅에 대해 너무 단편적으로 알고 있음
• 의사결장권자 or 매니저들의 테스팅에 대한 인식 부족
• 투자가 아닌 불필요한 비용으로 봄

 

1.7. 테스팅 분야의 매력

• 테스팅 분야 : 기본 컨셉, 테스트 전략/계획/설계 기법, 테스트 케이스 작성, 결함 관리, 지원 도구, 정적 테스트(Static test) 기법, 비기능성 테스팅, 테스트 프로세스 관리, 기반 설비 및 환경, 메트릭과 리포팅 등등
• 테스팅 커리어는 개발 분야 커리에 비해 상대적으로 연령 때문에 커리어가 제한되는 경우가 적음
• 개발 경험이 풍부하면서 테스팅을 전문적으로 배우고 경험한 인력에 대한 수요가 급증

 

1.8. 테스트 전문가

분류	기본 요건	추가 요건
기술능력	테스팅 수행 능력 테스트 (설계) 기법에 대한 이해 소프트웨어 공학에 대한 이해	테스트 계획 능력, 단위/통합 테스팅 가이드, 리포팅 능력, 테스트 프로세스에 대한 이해 도구 사용 능력 : 버그추적시스템, 다양한 테스트 자동화 도구, 정적분석 도구, 소스코드 관리시스템 등등 정적 테스팅(Static testing) 개발 : 코딩, 디버깅, 빌드, 프로그래밍 컨셉 - OOP 등등, 컴파일러, OS 등등) SQA, CMMI, ISO/IEC 15504 등에 대한 이해
습관	테스팅 할 부분에 대해 충분히 이해하려는 노력 다양한 테스팅 경험을 체계적으로 해보려는 노력	조용한 작업환경, 모범사례(Best Practice) 테스트 프로세스 준수 노력 자신의 테스팅 능력 평가 테스트 지원 도구 사용 조직내 테스트 표준화 노력 잘하는 테스터 또는 개발자와 협업하려는 노력
개인능력	커뮤니케이션 분석력 문서화	일정 업데이트 업무 처리 노력 예측 결함을 유추해 내는 경험
사고방식, 태도	주인의식, 열정적, 적극적, 긍정적, 호기심 전문적인 비평, 비판적인 시선 세밀한 것에 주목하려는 태도, 논리적	끈기 자기발전 욕망 끊임없는 스터디 개방적 태도