1.1 테스팅이란 무엇인가?
소프트웨어 테스팅은 소프트웨어의 품질을 평가하고, 운영 중 소프트웨어 장애의 발생 가능성을 줄이는 하나의 방법이다.
소프트웨어 테스팅이란 다양한 활동을 포함하는 프로세스이며 테스트 실행(결과 확인 포함)은 많은 활동 중 하나이다.
테스트 프로세스는 테스트 계획, 분석, 설계, 테스트 구현, 테스트 진행 상황 및 결과 보고, 테스트 대상 품질 평가를 포함한다.
테스팅 활동에는 테스트 대상 컴포넌트나 시스템을 실행하는 동적 테스팅과 테스트 대상 컴포넌트나 시스템을 실행하지 않는 정적 테스팅이 있다.
따라서 요구사항, 사용자 스토리, 소스 코드와 같은 작업 산출물에 대한 리뷰 역시 테스팅에 포함된다.
테스팅은 요구사항, 사용자 스토리, 그 외 및 기타 명세의 verification(검증)과 시스템이 운영 환경에서 사용자 또는 기타 이해관계자의 요구를 만족시키는지 확인하는 validation(확인)이 포함된다.
테스팅의 일반적인 목적
- 요구사항, 사용자 스토리, 설계, 소스, 코드 등과 같은 작업 산출물 평가에 의한 결함 예방
- 명시된 모든 요구사항이 충족됐는지 검증
- 테스트 대상의 완성 여부 확인과 사용자와 기타 이해관계자의 기대치 대로 동작하는 지 확인
- 테스트 대상의 품질 수준에 대한 자신감 획득
- 부적절한 소프트웨어 품질의 리스크 레벨 감소로 장애와 결함을 발견
- 이해관계자가 테스트 대상의 품질 수준을 결정하는 데 필요한 충분한 정보 제공
- 계약/법률/규제 요구사항이나 표준의 준수 및 테스트 대상이 이러한 요구사항이나 표준을 준수하는지 확인
단위테스트 시 코드의 커버리지를 높이는 테스트를 많이 해야함 유일하게 코드커버리지를 높이는 목적의 테스트를 할 수 있다. 테스트 접근법은 화이트 박스 테스트를 통해서....
테스트와 디버깅
애자일 개발 모델(cross functional사상) 이런 사상에서 테스터가 디버깅을 직접해야하는 경우도 있다.
지속적 통합 continuous integration : 만들자마자 단위테스트가 끝나자마자 통합하는 것
장점: 통합테스트를 전략을 따로 만들지 않아도 된다.통합 순서가 정해져 있기 때문
다만 어떤 것부터 개발할 지 고민해야한다(통합순서랑 같기 때문)
장점이자 단점인 것 : 더 정교한 통합테스팅을 할 수 없는 가능성이 있다. 하지만 효율적이어서 시장에서 좋아하고 많이 한다. 테크니컬 테스트라 개발자들이 많이하기도 하고 테크니컬 테스트가 가능한 테스터들이 하기도 한다.
반복 테스트량이 많다. -> 자동 리그레션테스트가 됨 그래서 자동화 테스트를 추구함.
테스트는 왜 필요한가?
테스트기법을 잘쓰고 전문적인 테스트를 하게 되면 소프트웨어의 품질이 높아진다.
품질 보증- 작업절차준수여부, 작업산출물의 적절성
품질 제어 - 품질 컨트롤, 품질 수준을 달성하기 위해 테스팅 하는 할동
주로 현장에 가면 품질관리는 품질보증이다 품질제어는 테스팅.
거짓음성, 거짓양성
자동화도구로 테스팅하는 경우 거짓음성,양성이 많다.
결함에는 미발견결함, 불편함만 주는 결함, 장애를 일으키는 결함이 있다.
외부적환경이슈로 생기는 결함은 fix대상이 아니다.
완벽한 테스팅은 불가능하다.
타이밍, 로직, 데이터를 모두 테스팅한다는 것은 어렵다.
리스크가 없다면 테스트자체를 할 필요가 없다. 리스크비용만큼만 테스팅비용에 들어가기에.
리스크비용이 0이면 테스팅할 이유가없다.
시프트레프트 - V모델
조기테스팅 -테스팅설계,플랜을 할 수 있다. +리뷰
결함집중 때문에 탐색적테스트기법이 나옴.
예전에 결함이 나왔는지 관리하는 것도 방법
정황에 의존적이다.
테스트 전략 , 투입공수, 테스트 방법등이 달라진다.
오류부재는 궤변
사용자의 니즈
사용자가 원하는 걸 이해하고 있고 말해줄 수 있다면 테스터의 부가가치가 높아질 것이다.
특정도메인에서 전문가가 되면 가능....
순서흐름에 맞게, 일에 진입하기 위한 사전조건, 일이 끝났음을 알수있는 산출물(테스트웨어)가 있으면 테스트 프로세스.
테스트 계획 - 테스트 "목적, 목표, 범위"를 먼저 알아낸다.(정황이해),개발모델,개발환경등을 알아둔다, 테스트베이시스가 어떻게 되는지 존재유무,완성도(뭐뭐 주는지 요구사항명세서, 설계서 어쩌고 저쩌고.. -> 정황이해......
정황파악 -> 리스크(장애발생가능성X손실) 분석 -프로젝트리스크, 프로덕트 리스크 둘 다 분석해야함 (테스트를 얼마나 해야하는 지) ->
전략수립 -> 공수예측(맨먼스,맨데이로 측정) ->
도큐멘테이션화(테스트계획서작성 + 일정 수립 + 산출물도 정의)->이해관계자들에게 보여준다.
공수추정이 수정되면 테스트정황부터 수정된다(목적, 목표, 범위등)
테스트 모니터링과 제어
테스트 진척률, 결함제거률, 결함발견현황을 통해 모니터링한다.
테스트 제어할때 일정등이 바뀔 수 있지 목적등이 바뀌면 안된다.
중간중간 완료보고서(진행상황보고서)
차이가 나는 것을 명시해줄 필요가 있다.(정보)
테스트를 중간에 중단하는 이유는 테스트를 할 의미가 없을 때(결함이 존나많음), 화면이 존재하지않아.등 테스트데이터가 준비되있지 않을 때
