프로토타이핑 (Prototyping)

Jan 28

alonesComputerScience/SE/SQA , , , , No Comments

예전보다 더, 아이폰 앱 기술데모, 프로토타이핑, Feasibility 확인을 위한 구현 등이 많아지고 있는데, 아래 강의를 요약하신 하이컨셉님의 포스트가 눈에 들어와서 포스팅해본다.

한 번 더 요약하면, “프로토타입은 머리속에 든 것은 상대와 소통하기 위한 “수단”임을 명심하자” 정도가 아닐까 한다.

아줌마~ “기민 (Agile)” 추가~ 요 정도? ㅋㅋ

어떻게 프로토타입을 만들고, 사람들에게 영향을 미칠까?

  • 당신의 첫 번째 시도는 아마도 잘못될 것이다. 이를 고려하여 예산을 만들고 디자인 하라
  • 유용한 수준의 산출물을 하루에 끝낼 수 있도록 한다. 그래야 초점을 맞추고 범위를 정할 수 있다.
  • 적당한 수준의 스케치면 된다. 계획했던 모든 것을 채우려 하지 말라.
  • 당신은 문제를 이해하는 것과 동시에 솔루션을 제시하면서 이를 반복하라.
  • 당신의 코드는 나중에 던져버려질 것으로 생각해라. 대신 후에 리팩터링할 준비를 한다.
  • 저작권/지재권 따지지 말고 자유롭게 개념이나 코드 등을 빌려라
  • 만들어진 프로토타입으로 스토리를 만들어낸다. 프로토타입은 기능의 집합이 아니다.

테스트 케이스를 평가하는 뮤테이션 테스트 (Mutation Testing)

Sep 06

alonesComputerScience/SE/SQA , , , , , , , , 3 Comments

테스트 케이스가 얼마나 잘 작성했는지 평가하는 것은 “보통 얼마나 많은 결함을 찾았나?” 또는 “커버리지 (Coverge)가 얼마나 되나?”를 통해서 평가 받을 수 있을 것이다.

그리고 또 하나 Mutation Testing을 통해서도 평가 받을 수 있을 것이다.
원본 프로그램을 수정 한 Mutant를 테스트 케이스를 수행해서 수정된 부분으로 인해 실패한 테스트 케이스가 있는지를 통해서 테스트 케이스가 얼마나 테스트를 잘 하고 있는지 평가 할 수 있다.

즉, c = a+b; 라는 코그를 c = a-b; 수정 후 테스트 케이스를 돌려 실패한 테스트 케이스가 있는지 확인하는 것이다.

보통 생성한 총 Mutant 분에 테스트 케이스가 실패해서 Mutant임이 밝혀진 Killed Mutant 수인 Mutant Scroe로 테스트 케이스 수준을 평가한다.

Mutant Score = # of Killed Mutant / # of Total Mutant

Ref
[1] Mutation Testing 관련 Papers http://ise.gmu.edu/~ofut/rsrch/mut.html
[2] Mutation Testing 소개 PDF http://agile.csc.ncsu.edu/testing/MutationTesting.pdf

Software Test 관련 도구를 총 망라한 사이트

Jul 27

alonesComputerScience/SE/SQA , , , , 23 Comments

testingfaqs.org는 정말 방대한 도구 목록을 잘 카테고리화 해서 제공하고 있다. 아래와 같이 단위 시험 (Unit Test) 도구부터 커버리지, 성능 테스트, 결함 추적 (Defect Tracking) 등 카테고리를 나누고 있고, 각 카테고리마다 정말 많은 도구들이 소개되어있다.

  • Test Tools List:
  • Testing Contractors and Consultants List
  • Testing Courses List
  • Testing Conferences List

    • 소프트웨어 관련 직업 별 출산에 대한 생각

    Jul 13

    alonesComputerScience/SE/SQA , , 20 Comments

    출산에 대해서 각 소프트웨어 관련 직업 별 생각을 쓴 재미있는 글이 있어 포스트 합니다.

    ㅎㅎ 의미심장하군요.

    1) Project Manager is a Person who thinks nine women can deliver a baby in One month.

    2) Developer is a Person who thinks it will take 18 months to deliver a Baby.

    3) Onsite Coordinator is one who thinks single woman can deliver nine babies in one month.

    4) Client is the one who doesn’t know why he wants a baby.

    5) Marketing Manager is a person who thinks he can deliver a baby even if no man and woman are available.

    6) Resource Optimization Team thinks they don’t need a man or woman; they’ll produce a child with zero resources.

    7) Documentation Team thinks they don’t care whether the child is delivered, they’ll just document 9 months.

    8) Quality Auditor is the person who is never happy with the PROCESS to produce a baby.

    9) Tester is a person who always tells his wife that this is not the Right baby.

    10) HR is a person who thinks that a donkey can deliver a human baby if given 9 month

    BREW와 BREW PEK 관련 정보 (references)

    Jul 05

    alonesComputerScience/SE/SQA , , , , , , , 3 Comments

    QUALCOMM의 BREW와 BREW의 포팅을 검증하는 PEK (Porting Evaluation Kit)에 조사할 일이 있어서 이 것 저 것 찾아본 웹 페이지들 (pdf)을 정리한다.

    Layered Architecture와 그것을 위한 Test Framework (Test Tool과 Test Case 등)의 중요성을 이야기 한다.

    PEK는 BREW에 특화된 잘 디자인되고 실로 유용한 Test Framework으로 손색이 없는 것 같다.

    ※ pdf 파일들이 링크되어 있기 때문에 페이지가 열리는데 시간이 걸릴 수도 있다. 다운로드 받아서 Acrobat으로 보는 것이 편하다.

     사용자 삽입 이미지

    [1] What is BREW?

    http://www.developer.com/ws/brew/article.php/1454711

    Developer.com Wireless에서 BREW에 대해서 잘 설명해 둔 페이지다.

    [2] Binary Runtime Environment for Wireless

    http://en.wikipedia.org/wiki/BREW

    Wikipedia의 BREW에 대한 설명

    [3] Commercialization, PEK & Custom OAT Modules (2005)

    http://brew.qualcomm.com/bnry_brew/pdf/brew_2005/t102_abney_qualcomm.pdf

    PEK에 대한 설명과 OAT (PEK에 들어있는 function 검증 엔진과 test case)의 확장 법에 대해서 나와있다.

    [4] Writing an Efficient BREW Porting Layer (2006)

    http://brew.qualcomm.com/bnry_brew/pdf/brew_2006/tech601_%20kalyanakrishnan_brewlayers.pdf

    Vendor들이 BREW를 Handset에서 사용하기 위해서 실제 Handset API (dirver 정도?)과 BREW를 연결 시켜주는 BREW OEM을 작성한다. 이에 대한 설명을 하고 있는 문서

    [5] Application Commercialization: The Role of TRUE BREW Testing (TBT)

    http://brew.qualcomm.com/bnry_brew/pdf/brew_2006/tech801_toerien_applications.pdf 2006

    http://brew.qualcomm.com/brew_bnry/pdf/brew_2005/t601_johnson_qualcomm.pdf 2004

    BREW Application의 인증을 받기 위한 TREU BREW Testing (TBT)에 대한 설명이다.

    PEK가 BREW를 handset에 포팅 하고 제대로 동작하는지 검증하는 것이라면 TBR는 BREW기반으로 Application을 만들고 Application에 대한 검증을 받는 것이다.

    [6] Debugging BRW Porting Layer (June 2, 2005)

    http://brew.qualcomm.com/brew_bnry/pdf/brew_2005/t203_ambley_qualcomm.pdf

    BREW Debugging에 대한 설명이다.

    Older Entries