[소프트웨어공학] 소프트웨어 품질보증,소프트웨어 테스팅 (SQA - Software Quality Assurance & SW Testing)

이미지출처 : www.secc.org.eg

소프트웨어 품질보증과 테스팅 (SQA - Software Quality Assurance & SW Testing)

Quality

- Small ‘q‘: 제품의 품질

- Big ‘Q’ : 제품을 개발하는 절차, 고객의 만족도 등을 고려한 품질

- 향상방법3가지


  # 사람에 투자

  # 프로세스에 투자 (효율이 좋다)
# 도구나 기법에 투자
- Software Engineering 에서 말하는 품질을 확보하기 위한 수단
# 소프트웨어 형상관리(SCM)
# 프로젝트 관리(PM)
# 데이터 관리(SQE)
- 관리 계획
1. 목적 & 범위
2. 프로젝트 내에서의 SQA 활동 계획
3. 양적 절차관리에 대한 계획
4. 결함방지를 위한 계획
소프트웨어 공학의 목적 - 많은 사람들이 함께 개발을
할 때 더욱 큰 효과를 내기 위함
구현 -> 설계 -> 분석 -> 테스팅 -> 유지보수 · 재사용성 (생산성, 품질)

효율적인 설계, 분석


- 일반성(Generality)과 향상성(Incrementality)고려 필요

- ‘무엇에 중점을 둘 것인가’ 고려 필요(Ex.Risk, Bussiness Value)

# Liner ->Incremental

# Rigid ->Flexible

# Monolitic-> Interactive



CMMI

1. INITIAL(실행)
2. REPEATABLE(관리) – 반복 가능	기본적인 프로젝트 관리
3. DEFINED(정의)	프로세스 표준화
4. MANAGED – 개량화 가능	정량적인 관리(수치화 시킴)
5. OPTIMIZING(5) 지속적인 프로세스 개선	체계적인 계획으로 overhead를 처리해야 한다.

 

유지보수 활동

- 수정되는 것(Corrective) : 20%

- 환경의 변화에 맞추는 것 (Adaptive) : 20%

- 잘 돌아가는 것을 더 완벽하게 만드는 것 (Perfective): 80%

프로세스 적용 시 성공 사례를 가지고 유연하게 적용해야 한다.

- 조직에 맞는지 검토 후 적용 가능성을 탐색

- Risk를 가지고 단계적으로 완화시키는 활동을 해야 한다.

 

Inspection

정의

- ‘무엇을개선할 수 있는가’를 찾는 활동 (WHAT)

- 사람에 대한 평가가 아니라 조직관점의 성능을 평가하는 것

- 조직의 문화를 바꾸는 것!

- 모호한 것을 명확하게 함

특징 & 방법

- 결함 발견 및 데이터 수집

- 산출물에 대한 전문지식 교환

- 해결안 지양(결함을 찾는데 주력)

-&Defect를 빨리 찾을수록 fix 비용

소요 감소

- Inspection의 데이터를 통해 업무에 집중 가능

- 테스팅은 결함의 존재 여부만 식별하는데 반해, 결함의 내용과 위치를 식별

- 코드 인스펙션은 컴파일이 문제없이 되었을 때

- 사전 준비를 철저히 하고 회의 시작

- 2시간이 넘지 않게 함

- 데이터를 수집하여 차후 inspection시history로 참고

# 데이터의 오염 (정보의 조작이 일어날 수 있다.)
팀 크기
- 인원은 3~7명이 좋다. (4명적절)
- Code Inspection시Producer를 제외한 2명의 Inspector가적절
-&Document Inspection시 2명보다많은 Inspector가 요구됨.
- Moderator는 Reader또는 Recoder를 겸임 할 수 있음.
단계
- Planning


# 역할 선정

# 일정 잡음, inspection 그룹만 참여하도록


# 일정에 Inspection 일정 계획을 task마다

추가.

# Code Inspection


  ## Unit Test 이전에 실시

- Overview

  # 검토 대상 산출물에 대한 설명


  # 산출물의 이전버전에 대한 Inspection이 실시된 적이 없는 경우

# 한명의 Engineer가 산출물을 작성한 경우

  # 새로운 기술이 도입되거나, 복잡도가 높은 경우
- Preparation


  # Checklist, Rule Set(코딩 규칙등)과 같은 도구를 사용해

대상 산출물의 완전성과 시정대상 여부 및 적절성을 판단

  # 이 과정을 거치지 않는다면 Walkthrough.


  # 일반적인 규칙에 어긋나는 것들(타이핑 에러, 스펠링 틀림, 포멧이상 등)은 Typo list로 제공

  # Reader와 Recorder에게 매우 중요한 단계


  # 미팅의 2.6배정도 시간이 소요

  # Defect를 많이 발견하기 위해 여러 번 검토 하는

것이 좋다.

- Meeting


  # 정리하는 시간.

  # Inspection Summary Report 작성
- Rework


  # 각종 보고서를 가지고 최종 산출물 작성

  # 시간의 제약을 두어야 함

- Follow-up


  # 프로세스 수행이 적절히 이루어 졌는지 검증하는 단계

- Causal Analysis


  # Process Brainstorming 단계





역할

- Reader(Presenter) : 산출물에 대해서

설명하는 역할

- Recorder : Defect, 이슈 및 기타 내용을 기록하는 역할을 수행함


- Verifier : 최종확인 작업

- Producer : 산출물 작성자
- Moderator : Inspection 총괄
성공적인
Inspection 을 위해
- 관리자들에게 약속을 받음
- 데이터 수집 및 분석
# 알맞은 수집 양식을
작성 하는 것이 중요


- 훈련



Inspection
Metric

- Defect.Density : 산출물의 품질을 평가함.

[Defects.Found.Total /Size.Actual]  Inspection 대상 산출물의 단위당 발견된 Defect수
- Defect.Corrected.Total : Defect당 평균 Rework Effort를 계산


[Defect.Corrected.Major + Defects.Corrected.Minor] Correct된 (Major+Minor) Defect

- Defect.Found.Total : Inspection의 효과성(Effectiveness)과 효율성(Efficiency)을 평가

[Defects.Found.Major + Defects.Found.Minor] 발견된
(Major+Minor) Defect


- Effort.Inspection : 근무 시간 또는 금액으로 Inspection의

전체 비용을 계산함.

[Effort.Planning + Effort.Overview + Effort.Preparation + Effort.Meeting +
Effort.Rework] Inspection을 수행하는데 투입된 Effort 합계
- Effort.per.Defect : 프러덕트 Life-Cycle의
Inspection 이후 단계에서 발견되는 Defect의 처리 비용과, Inspection에서 발견된 Defect의 비용을 비교함.


[(Effort.Planning + Effort.Overview + Effort.Preparation + Effort.Meeting)/Defects.Found.Total]

Defect를 발견하는데 투입된 전체 근무 시간의 평균

- Effort.per.Unit.Size

: 프로젝트에서 발생하는 산출물들을 Inspection하는데 소요되는 비용을 견적

[Effort.Inspection / Size.Actual] Inspection 산출물의 기본 단위당 투입된 시간의 평균값
- Percent.Inspected : Inspection Planning의 정확도를 평가


[100*Size.Actual / Size.Planned ] 실제로 Inspection을

수행한 산출물에 대한 계획 대비 비율

- Percent.Majors : Inspection의 초점이 Major Defect인지 Minor Defect 인지 판단

[100 * Defects.Found.Major / Defects.Found.Total] 전체
Defect중에서 Major Defect의 비율
- Rate.Inspection : 향후의 Inspection Effort를 계획하는데 사용
[Size.Actual / Time.Meeting] Inspection
Meeting 시간당 수행된 산출물의 평균 분량
- Rate.Preparation : 향후의 Inspection Effort를 계획하는데 사용


[Size.Planned / (Effort.Preparation / Number.of.Inspectors)] Inspector들이 Preparation의 단위 시간당 처리한 산출물의 평균 분량

- Rework.per.Defect : Inspection의 Benefit을 판단하기 위해, 프러덕트 Life-Cycle의

Inspection이후 단계에서 발견된 Defect를 처리하는데 소요되는 비용과 비교


[Effort.Rework / Defects.Corrected.Total] 1개의 Defect를

처리하고 검증하는데 필요한 시간의 평균값



결함 발견하는데 소요 시간

- 테스팅 : 4 hours / fault

- 인스펙션 : 1 hour / fault



Peer Review의 3대

장벽

지식(Knowledge), 변화 거부 (Resistance to Change), 조직 문화 (Culture)



Testing

제한된 테스트 케이스를 가지고, 신뢰성을 높인다.(테스트는 100% 될 수 없다.)

- Error : 사람이 한 실수

- Fault : Error로 인해 발생된 문제점

Correct -> Reliable -> Safe -> Robust

 

Test Planning

- ‘무엇을 테스트 할 것인가’(WHAT)

- ‘테스트를 어떻게 할 것인가’(HOW)

- 설계, 개발 단계에서 진행하는 것이다.



Testing Techniques

Structural (Whitebox)

Test – 코드를 보는 테스트

Coverage
- Statement Coverage : 모든 라인을 거쳐 가는지 확인
- Path Coverage : 가능한 모든 길을 확인
- Branch Coverage : 조건문의 양쪽 가지를 다 통과하는지 확인
- Condition Coverage : 조건이 True일 때 , False일 때를 모두 확인

Functional(Blackbox) Test
- 문서(코드 이외에 알 수 있는 모든 정보들) 위주의 테스트
- Equivalence Partitioning : 비슷한 그룹으로 나눔
- Boundary Value Coverage : 경계를 기준으로 확인


  # 경계 -> 경계안 -> 경계밖 -> 중간 -> 겹치는 경계

- Special value
Coverage : 알려진 값을 기준으로 확인

Testing Phases
Unit Testing – 모듈 중심

Integration Testing – 인터페이스 중심

System Testing –환경 고려

Regression Testing – 버전 변경 시 바뀐 부분이 제대로 바뀌었는지 확인을 위해

Non-Functional Testing도 고려해야 한다.



대량의 데이터를 처리할 때 유용한 툴

- 정규 표현식(Regular Expression)

- Flex (The Fast Lexical Analyzer)

 

TimeTracker

- 실제 일하는 시간을 체크하여 업무 효율을 증가 시킬 수 있다.

 

도표

Control Chart – Control 영역을 설정하여, 품질을 관리 할 수 있다.

Pareto Chart – 가장 높은 Bar가 전체적 문제 해결을 위해 가정 공헌도가 큼을 의미


Run Chart – 시간의 순서에 따라서 데이터의 변동 상태를 보여준다.

Scatter Diagram – 상관관계를 볼 때 사용

 

용어정리

80-20 Rule - 20%의 부분에서 80%의 문제가 발생한다

Heuristics – 경험적 지식

GQM(Goal, Question& Answer, Metrics)

- Goal을 달성하기 위한 질문과 답변을 통하여 기준이 되는 데이터를 찾는 것

FAULT 

- ERROR(Review 시점에 발견한 것) + DEFECT(Review시점 이후에 발견한것)

PMO(Project Management Office) – Project의

전체적인 일정을 수립하고, 지켜가야 할 원칙을 설정하고,

Project 성공을 위한 수행전략을 수립하고, 전체적인 예산과 인력을 관리

SQA(Software Quality Assurance) – 세팅된 프로세스를 가지고, 잘 따라가고 있는가를 관찰하는 그룹 [감사]

EPG(Engineering Process Group) – 조직의 프로세스의 개선을 위한 그룹 [재정]

COQ(Cost Of Quality) - Review, Rework, Etc / Total Effort

COPQ(Cost Of Poor Quality) - Rework / Total Effort


QPM – Process Control + Process Improvement : Use Statistical techniques

      =>

Stable Process + Capable Process

LOC(Line Of Code)

ReqB(Requirement Book)

SPMP(Software Project Management Plan)

SCMP(Software Configuration Management Plan)

SQMP(Software Quality Assurance Plan)

CMMI(Capability Maturity Model Integration)

 

Reference

Peer Reviews in Software, Karl

E.Wiegers,  Addison-Wesley

Computer based software inspection

 

———————————————————————

4일간의 Software Quality Assurance & SW Testing 교육

재미있는 이야기가 많았다.

by 月風

Tags : 소프트웨어 테스팅, 소프트웨어 품질 보증, 소프트웨어공학, IT, Software Quality Assurance, software testing, SQA, testing

• 재미있게 읽으셨나요?
  광고를 클릭해주시면,
  블로그 운영에 큰 도움이 됩니다!

객체지향이란? 객체지향분석및설계 1장 요약 (OOA&D Chapter1 Summary)

이미지출처 : jdjua.com

This chapter show process that how to written gorgeus software for Rick’s guitar shop.

이 장은 릭의 기타가게를 위한 멋진 소프트웨어가 작성되는 과정을 보여준다.


Great software in 3 easy steps

멋진 소프트웨어를 만드는 3스텝


1. Make sure your software does what the customer wants it to do.

당신의 소프트웨어가 무엇을 하기를 고객이 원하는지 확실히 하자.

2. Apply basic OO principles to add flexibility.

유연성을 증가시키기 위해 기본 OO 원칙들을 적용하자.

3. Strive for a maintainable, reusable design.

유지와, 재사용이 가능하도록 설계하는것에 최선을 다하자.


Don’t create problems to solve problems.

문제을 해결하기위해 새로운 문제들을 만들어 내지 말자.


Please make basic functionalities before trying to do too much design for not being a waste.

버려지는 것들을 줄이기 위해, 방대한 설계를 하기전에 제발좀 기본적인 요구사항을 먼저 만들자. (step1 -> step2)


Use a textual description of the problem you’re trying to solve,

to make sure that your design lines up with the intended functionality of your application.

너의 어플리케이션의 의도한 기능들에대해 설계할 것들을 늘어놓기 위해서,

문제를 해결하려고 할때 글로 적어놓자.


matched Object Type - 완소 객체 유형

1. Object should do what their names indicate.

객체는 그의 이름이 의미하는 행동을 해야한다.

2. Each Object should represent a single concept.

각 객체는 단일 행동만 묘사해야한다.

3. Unused properties are a dead giveaway.

사용하지 않는 속성들은 객체에 안에 들어있어야할 근거가 없다.


Encapsulation allows you to group your application into logical part.

캡슐화는 당신이 만든 어플리케이션을 묶어서 논리적 부분으로 넣을 수 있다.


Delegation - 위임

The act of one object forwarding an operation to another object,

to be performed on behalf of the first object.

한 객체의 행위에 대해 다른오브젝트에게 운영권을 넘겨주어, 첫째 객체를 대신하여 수행하도록 하는것.


Customers are satisfied when their apps WORK.

고객들은 그들의 어플리케이션이 작동할때 만족한다.

Customers are satisfied when their apps KEEP WORKING.

고객들은 그들의 어플리케이션이 계속 작동할 때 만족한다.

Customers are satisfied when their apps can be UPGRADED.

고객들은 그들의 어플리케이션이 향상 가능할 때 만족한다.

Programmers are satisfied when their apps can be REUSED.

프로그래머들은 그들의 어플리케이션이 재사용가능할 때 만족한다.

Programmers are satisfied when their apps are FLEXIBLE.

프로그래머들은 그들의 어플리케이션이 유연할 때 만족한다.


Reference : Head First Object-Oriented Analysis & Design


———————————————————————–

This book gives me clear sight that can see the mountain behind the mist.

이 책은 나에게 안개뒤에 가려진 산을 볼수 있게 해주는 선명한 시야를 확보해 주었다.

by 月風

Tags : 객체지향, 객체지향분석및설계, 기술, 방법론, 소프트웨어공학, 이론, 책, IT, OOAD

• 재미있게 읽으셨나요?
  광고를 클릭해주시면,
  블로그 운영에 큰 도움이 됩니다!

[소프트웨어공학] 객체지향이란? 객체지향 정리 (OO - Object Oriented Summary)

이미지출처 : www.restafari.org

객체지향 (Object Oriented)

inheritance - 상속

when one class extends another class to reuse or build upon the inherited class behavior.

재사용이나 상속되는 클래스의 행동들을 바탕으로 새로운 클래스를 만들때.

avoid duplicating and repeating code. 코드의 중복이나 반복을 피할 수 있다.

superclass - the class being inherited [부모클래스 - 상속이 되는 클래스]

subclass - the class that is doing the inheritance [자식클래스 - 상속을 한 클래스]

polymorphism - 다형성

when a subclass cam substitute for its superclass

자식클래스가 부모클래스를 대체할때.

superclass can have the self or sub, but sub can have only sub or his sub.

슈퍼클래스는 자기자신이나 자식을 인스턴스로 가질 수 있지만, 서브클래스는 상위클래스를 인스턴스로 가질 수 없다.

encapsulation - 캡슐화

Encapsulation protects data from being set in an improper way.

캡슐화는 잘못된 방법으로 설정하는것으로 부터 데이터를 보호한다.

With it, any job that the class does on the data are preserved, since the data can’t be accessed directly.

캡슐화된 데이터를 사용함으로써, 데이터에 직접 접근할 수 없게 하여, 어떤 작업(계산이나,수정등)으로부터 데이터를 보호한다.

Also known as information hiding, or separation of concerns.

정보은닉이나, 역할을 나누는것으로 알려져 있다.

———————————————————–

written someting for known clearness is good.

대충알던것을 명확히 알기 위해 한번 써보는건. 괜찮은 일이다.

by 月風

Tags : 객체지향, 방법론, 소프트웨어공학, 이론, IT, Object Oriented

• 재미있게 읽으셨나요?
  광고를 클릭해주시면,
  블로그 운영에 큰 도움이 됩니다!

[소프트웨어공학] 테스트 주도 개발(TDD), TDD 워크샾 다녀옴~ (TDD - Test driven development workshop)

이미지출처 : www.doolwind.com

‘편히 요양이나 좀 하고 올까’ 하는 마음도 약간 있었지만..

막상 가보니 생각보다 빠듯해서 그럴 여유는 없었다.ㅋ

워크샾에서 얻은것은..

무엇보다, 좀 더 다양한 방향으로 사고를 할 수 있게 되어서, 좋았다.

=============================================

워크샵중 느낀점, 강의중 언급된것들 정리..

=============================================

* KISS(Keep It Simple, Stupid) < 단순한 것이 좋은것이다.>

* We = CT (일효율 = 집중도*시간 )

* What > Why > How (무엇을 하는 함수인가?)

* Refactoring

o Naming (유의어 사전을 참조- 접두사 접미사로 나눔)

+ 클래스명에 ~er 접미사를 붙이는 것은 좋지 않다.

o PSP - paper shell programing



* CAT Computer Automation Test

o selenium

o Firebug

o Jemmy: Java Swing tester

* 문제가 익숙할때 연역법, 익숙하지 않을때 귀납법 으로 접근.



* Unit Test

o 테스트도 리펙토링이 필요하다.

+ Ex) Spiral array

o 테스트 하고싶은것 만큼만 테스트 해야 한다. 

(테스트 하고 싶은 부분보다 많은부분을 테스트하면 안된다!!)



* Pair Programing

o 대화는 코드를 추상화 시키고 코딩은 코드를 구체화 시킨다.

* TDD

o Known-UnKnown > (Top-Down|Bottom-Up)

o PBI - Programming by Intention

o GBC - Green Bar Cycle

by 月風

Tags : 개발방법론, 소프트웨어공학, 이론, 테스트 주도 개발, IT, TDD, Test driven development

• 재미있게 읽으셨나요?
  광고를 클릭해주시면,
  블로그 운영에 큰 도움이 됩니다!