Day_06. S/W Verification & Validation

V모델 – Verification & Validation
=검증 & 확인 의 방법론
=특정 s/w가 특정 목적에 부합 한다고 해서 결함이 없는게 아니다
=V&V 는 전체 S/W의 생명 주기에 적용된다
=목적 : 결함을 발견 하는 것 ( 해결이 아니다)
=SYSTEM 이 활용 가능한지 확인 하는것
==verification – 코드개발 완료까지 (검증)
==validation – 코드개발 완료부터 (확인)


검증 – verification
=특정 개발 단계에서 모든 요구사항을 충족 하는지 확인 하는 것
=static testing – Review, 요구사항 문서 , spec시트 , 산출물


확인 – validation
=최종 제품이 고객의 요구사항을 충족하는지 확인
=Dynamic testion – prototype source code


Static test
=결함의 예방이 최고
=발견한 결함의 발견 & 수정
=결함 충격의 감소
=개발자가 결과물을 review 해서 s/w결함을 발견


Artifacts inspection ( 요구사항/설계/코드/Test)
=실행하지 않고 문서로 Review
=Review 의 이유 – 가장 effective 한 것을 탐색한다
==요구사항 inspection을 하지 않으면 결함을 가지고 시스템을 만들기 시작하게 된다


Static test 방법
=Formal approach – technical review , inspection
=informal approach – 동료와의 workthrough , 동료 검토


Static test 3 method

Checklist based reading technique	체크리스트 기반 모든 유형의 결함을 다루지 못한다 잠재적 문제/결함을 생략한다 지속적 update가 필요
Defect based reading	결함의 유형에 집중 결함 분류 과정 =결함을 동료에 질문 - 체크리스트에 파생된 시나리오 작성 - 검토자에게 분배 – 탐지 Domain 지식이 매주 중요
Perspective based reading	발견한 defect 중복 최소화 다양한 stakeholder 관점에서 sw 문서 조사 역할에 의존하는 관점 식별

S/W Inspection
=early , quickly , cheaply – 에러 발생 시점에 가장 가까운 시기에 제기
=design / code 단계에서 실시하면 가장 좋은 효율이 나온다
==단계에 따라서 사용하는 기술이 모두 다르다
==inspection을 하고 test를 진행해야 한다
==90%이상의 비율에서 inspection의 효과가 가장 뛰어나다
=quality 와 test는 포함관계 , test는 품질안에 들어간다
=IEEE 기준은 매우 허들이 높아서 기간과 비용이 많이 든다


Dynamic test
=요구사항 검증을 통한 산출물과의 구조적 검증
=Error 가 없는 System 은 없다
=요구사항 검증 – 기능/비기능/정형/사용자 검증


Debugging
=Test 와의 차이점 – 노출된 결함의 제거
=inspection – 결과로 오류 원인 탐색
=deduction – 원인을 나열하고 사실을 규명
=backtracking – 오류 발견 시점에서 역행한다


Top – 4 TYPE of S/W Testing

Functional	Basic functions working well Easy navigation Error handling Accessibility
UI/UX	Usefulness Ease Accuracy Appeal
Security	Data protection Interface bugs and holes Admin access
Load	Response time Performance under various loads

낮은 품질의 이유
=낮은 품질은 그렇게 개발 되었기 때문이다


Test 의 속성
=TEST에 의존하면 안된다
==Test는 품질의 개선이 아닌 품질의 확인이다
==통상 Test는 개발의 5배 정도의 노력이 투입된다


Test 준비물

Process	Result의 통일성
Tool	상황에 맞는 Tool 을 따로 설정해라
Methology	Test 방법론 / 설계방식 – ex)test design
Standard	표준은 많으나 보통 ISO 29119를 사용

TDD – Test driven Development
=Code를 생성하기 전에 Test 하기
===??어떻게 진행하는가?

Step - 1	Code 작성전 test case 제작
Step – 2	Test에 해당하는 code 작성
Step – 3	제작된 code가 Test 잘 되는지 확인한다
Step – 4	Step – 1 으로 돌아간다