Test and Analysis Activities within a Software Process

: Test & Analysis 와 개발 프로세스는 함께 움직여야 한다! (개별적 NO!)

Learning Objectives

• Development Processs에서 Quality의 역할 이해하기
• Quality process 의 큰 그림 그리기
• quality process의 특징 'visibility, anticipation of activities, feedback' 이해하기

1. Software Quality and Process

1. Quality

• 소프트웨어가 본래 의도한대로 기능들이 얼마나 잘 작동하는지의 정도
• 개발의 끝에 추가되는 것이 아니라 project planning부터 꾸준히 열심히 해야한다.
• inter-dependent , 절대적X, 다차원적, constriants에 종속적

2. Testing == lifestyle

• test는 testing execution만 말하는 것이 아니라, 앞 단계에서 부터 지속적으로 일어나는 것이다.
• input, expected-output으로 Test case만듬
• software test와 analysis가 철저히 합쳐진 것이 software process의 특징이다.

3. Quality process

: 적절한 dependability(SW product quality)를 보장하고, project의 스케쥴, product의 usability등을 고려한다. (project planning 시 quality level을 정해서 레벨이 높으면 해야 될 것이 많다. quality process 할 것 많음)

• 목표 : 프로그램이 잘 작동하게 dependability를 "보장"해주기

• Framework

  • V&V Technique 고르기 (cost-effective하게)
  • other important goals(business/marketing) 과의 trade-off

  

  • early visibility 발전시키기

    → 현재 시점에서 지금처럼 하면 걔 퀄리티가 우리가 원하느 수준을 확보할 수 있을까?

    ex) Quality activity가 가능하면 빨리 배치되어야 함

    • Design test case들 가능하면 빨리
    • Analysis technique를 실제 코드 생성 전에 실행

    ex) design 혹은 code에서 발견한 fault들은 진짜 reliability하지 않지만, 'Proxy'하게 또 빨리 fault를 찾을 수 있다는 점에서 의미가 있다.

2. V&V Plan (#48)

• V&V activity의 objective(목적), scope(범위)
• 가능한 문서와 아이템들
• 테스트 되어야 하는 items (target)
• 테스트 될 feature과 테스트 되지 않을 feature
• analysis and test activities
• 어떤 staff가 할 것인지
• constraints(제약조건)
• Pass and Fail 기준
• 스케쥴
• deliverables (output,결과물)
• hardware and software requirements
• risks and contingencies (위험성)

SQA가 하는 일

1. Development 계획 내려옴
2. product feature & Quality level 등 고려
3. 이미 존재하는 Quality process 중에서 select + Tailoring(수정)
4. 누가 뭘 할지 staff배정
5. 프로젝트 끝날 때까지 계속 care

3. Quality Goals

1. Product Quality

: Goals of SW Quality engineering

@ Internal qualities(개발자용)

• maintainability, flexibility, reparability, changeability

2. Process Qualitiy

   @ External qualities(고객용)

• Usefulness:

  -usability,performance, security, portability, interoperability(고객노력없이도 잘 잘동되도록)

• Dependability:

  -Correctness, reliability(고장X) , safety(안전) , robustness(어떻게든 동작)

  1. Correctness

  : 정해진 기준 (specification)에 따라 정확히 동작하는가

  2. Reliability

  : 유저가 SW를 얼마자 믿고 의지할 수 있는가

  • failure가 얼마나 자주 일어나는지
  • 유저에따라 상대적일 수 있다.

  

  3. Robustness

  : 요구 사항에 명시되어 있지 않은 예상치 못한 상황에서도 합리적으로 작동하는가

  4. Safe

  : undesirable 상황을 잘 대비했는지(preventing)

  참고 : https://velog.io/@allocproc/소프트웨어-품질-mtk5coqesy

  (시험) 해석

  

  • Reliable O, Correct X: 실패가 드물게 일어난다.=실패 거의 없음 (잘 돌아가긴 하는데spec대로 돌아갈지 모른다)
  • Correct O, Safe X, robust X : Spec이 부적절하다. (spec에 맞게 작동하는데 safe하지 않고 이상하게 작동함)
  • Safe O, Correct X : 짜증나는 실패가 발생할 수 있다. (correct하지 않으므로 짜증나는 실패 발생 가능) = 안전하게 돌아가긴 하는데 spec 에 맞게 동작하지 않는다.
  • Robust O, Safe X : 아주 위험한 실패가 발생할 수 있다.

4. Analysis

1. Inspection technique (Review)

• 어떤 document에도 적용 가능
• 시간이 많이 소요되고, re-inspecting시에 비용이 비싸다.

2. Automatic static analysis

• static code analysis
• 사람X 기계적인 분석으로 cost-effective

3. Testing

• Test generation → 테스트는 코드로부터 독립적으로 생성된다.

Summary

• V&V는 planned되고 monitored되어야 하는 복잡한 것이다.
• 좋은 quality process는 basic principle을 기반으로 한다.
• 목표