블로그 이미지
Welcom Back Tatter. 머샤머샤

카테고리

분류 전체보기 (140)
테터 (1)
悲歌 (12)
Lost & Found (1)
IT (126)
Total
Today
Yesterday
관련 동영상 보기

형상관리 솔루션 실루엣을 개발하면서 다양한 환경의 사용자분들을 만나게됩니다.

버그트레킹 시스템의 진화에 관한 토론등에서도 느낄 수 있지만, 사용자(특히 개발자 혹은 관리자)들이 선호하는 UI는 시스템의 기능에 절대적인 도입 포인트가 되기도 하고, 때에 따라서는 해당 솔루션 개발팀의 의지를 반영하기 도합니다.

Base Camp. 팀이 말하는 Rich Client에 대한 굳은 의지신념에서 살짝 느껴지는 장인정신이랄까요?

일반적으로 기업에서 정해진 품질관리 프로세스 (변경요청 부터 시작되는 ....)는 개발도구와는 조금 별개로 취급되고는 합니다.

상용이거나, 공개되어 있는 IDE에 연동되는 프로세스제품(예를 들어서 Bugzilla)를 사용하지 않는 이상은, 개발자가 IDE상에서 직접 회사의 프로세스에 자신의 작업결과물을 반영하는 등의 작업은 할 수 없겠지요.

개발은 개발 따로 하고, 개발이 완료된 상태에서 테스트 할  테스터(그나마 테스터라도 제대로 있으면 다행)에게 테스트 해 보라고, 전화, 메신저로 테스트 환경을 알려주거나, 혹은 오프라인으로 어찌 어찌 연락을 해야 하는 상황이 우리 주변에서 흔히 볼 수 있는 상황입니다.

Eclipse IDE (혹은 Visual Studio라도)상에서 테스트 빌드를 하고, 그 결과물이 정상일 때 자동으로 테스터에게 테스트를 요청 할 수 있도록 한다면, 개발자들의 잡무를 줄이고 개발업무에만 집중 할 수 있을 것입니다. :)

개발자게 개발을... 형상관리는 개발자를 옭아매는 통제시스템이 아니라, 개발의 보조수단. 도움이 되는 유틸리티가 되어야 한다.

이것이 실루엣팀의 고집이자. 신념입니다. :)
Posted by 머샤머샤
, |

Package를 개발하는 회사의 QA팀은 상당히 고달픕니다.

준비해서 테스해야 하는 환경이 이론상으로 따져도, 거의 무한대 이기 때문에.

OS만 해도, WIn-XP, 2000, 2003 + Vista인데, 이것을 한글, 영문은 물론이고, 서비스팩에 설치되는 테스트 환경(DBMS, 개발 툴 등등)까지 하니까. 거의 좌절입니다.

실루엣팀만 하더라도, 넉넉한 하드디스크를 확보하고, 매번 필요한 VMware Image를 만들거나, 보관하고 있습니다만 이것에도 한계가 있습니다.

처음 만들어진 Clean환경이 보관되어 있어야 하고, 그 Image를 복사해서 개인 개발자나 QA들이 사용을 하다보면, 이 사용한 내력이 무시못하게 필요하고,

개인별로 사용한 Image를 다른이름으로 복사해서 다시 보관하고..God!

이런 고민을 해결 해 주는 제품이 VMWare Lab Manager인데, 가격이 그렇게 비싸지도? 싸지도 않습니다.

구매의 필요성을 절실히 느끼고 있습니다만, 아직 평가판 테스트도 ...

WorkItem으로 잡아놓고 > 누군가에게 할당을 해 주어야 할 것 같습니다.

이 VMWare Lab Manager야말로, 진정한 ALM제품군에 속하지 않을까 생각해 봅니다. ^^;

Posted by 머샤머샤
, |

Ship It 57 Page에 나오는 주옥같은 이야기 입니다.


단위 테스트(Unit Test)

  • 단위 테스트는 개별 클래스나 객체를 테스트하기 위해 고안되었습니다
  • 단위 테스트는 독립형이고 일반적으로 작동시키기 위해 다른 클래스나 객체가 필요하지 않습니다.
  • 단위 테스트의 삶의 유일한 목적은 한 뭉치의 코드 내에 논리가 적절히 작동하는지 확인하는 것입니다.

기능 테스트(Functional Test)

  • 기능 테스트는 제품 전체의 적절한 동작(또는 기능)을 테스트하기 위해 작성됩니다.
  • 기능 테스트는 제품 전체 또는 한 제품 내의 주요 하부 시스템을 다룰 수 있습니다.
  • 기능 테스트는 시스템 내에 많은 객체를 갖습니다.

성능 테스트(Performance Test)

  • 제품이 (또는 중요 하부 시스템이) 얼마나 빨리 작동할 수 있는지 측정 합니다.
  • 이런 테스트를 하지 않고선, 어떤 코드 변경이 제품의 반응속도를 향상 시켰는지, 퇴보 시켰는지 말할 수 없습니다.

부하 테스트(Load Test)

  • 부하 테스트는 수많은 클라이언트나 파워 유저 집단이 큰 부하를 걸었을 때 제품이 어떻게 작동하는지 모의 실험 합니다.
  • 성능 테스트와 마찬가지로, 이런 종류의 테스트를 하지 않고선 코드 베이스가 향상됐는지 퇴보됐는지 객관적으로 말할 수 없습니다.

스모크 테스트(Smoke Test)

  • 스모크 테스트는 가벼운 테스트이고, 제품의 중요 부분을 작동 시키기 위해 조심스럽게 작성되어야 합니다.
  • 빨리 실행되면서도 제품의 적합한 부분을 작동시키기 때문에 스모크 스트를 사용하게 됩니다.
  • 그 기본적인 아이디어는 기본 기능을 호출했을때, "연기가 나는지", 즉 실패하는지 알아보기 위해 제품을 돌려보는 것입니다.
  • 스모크 테스트는 CI시스템과 함께 사용하기에 아주 좋습니다.

통합 테스트(Integration Test)

  • 통합 테스트는 제품 라인의 다양한 부분이 서로 잘 협력하는지를 살펴 봅니다.
  • ...
  • 통합 테스트는 데이터베이스와 같이 제품이 의존하는 컴포넌트의 새 버전을 검증하는데 흔히 쓰입니다.

가짜 클라이언트 테스트(Mock Client Test)

  • http://www.mockobjects.com/
  • About Mock Objects, a technique for improving the design of code within Test-Driven Development
  • 가짜 클라이언트 테스트는 클라이언트의 관점에서 테스트를 만들기 위해 사용됩니다.
Posted by 머샤머샤
, |

최근에 달린 댓글

최근에 받은 트랙백

글 보관함