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

23 Comments

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

  • Test Tools List:
  • Testing Contractors and Consultants List
  • Testing Courses List
  • Testing Conferences List
  • MS Visual C++ 개발팀의 QA팀 활동 내역 – 그들은 최고 일 수밖에 없다.

    13 Comments

    최근 MS VC++ 라이브러리 개발팀의 테스트 자동화에 대해서 소개해 드렸습니다.

    이 번엔 MS VC 컴파일러 개발팀의 QA팀에 대해서 소개해드리겠습니다.
    이 전 포스트와 마찬가지로 Visual C++ Team Blog에 게시된 내용입니다.

    먼저 두괄식으로 정리를 하면 다음과 같습니다.
    ■ QA (Quality Assurance)팀 일원들이 자신의 일을 자랑스럽게 여긴다.
    SQA (Software Quality Assurance)팀은 우리가 잘 알고 있지만 행하지 않는 Software Testing의 해야 할 일들을 그 어떤 조직보다 체계적으로 잘 수행하고 있다.

    글을 쓴 사람은 Smile Wei로 VC++ 컴파일러 팀 내에 있는 QA 팀 (SDET)에 3개월 반 전에 합류했고 VC 컴파일러에 대한 QA일을 하고 있습니다.

    그는 자신의 포스트를 쓴 목적이 (위에서 정리한 것과 같이)
    Microsoft, 특히 VC 팀에서일하는 것을 좋아하느냐? (정확히는 QA팀)
    VC 팀의 QA팀에서는 매일 무슨 일을 하느냐?
    에 대한 답변을 위해서 글을 쓴다고 합니다.

    1. Microsoft, 특히 Visual C++ 컴파일러 팀에서일하는 것을 좋아하느냐? (정확히는 QA팀)
    이에 대한 답변으로 Smile Wei는 (당연하겠지만) QA 일을 하는 것을 사랑하고 자랑스럽게 생각합니다.
    그리고 “일반적으로 QA 엔지니어가 개발자보다 기술적으로 떨어진다는 생각을 여기서는 하지 말라” 라고 단호하게 이야기 합니다.
    흔히 생각하는 메뉴얼 테스트나 단순한 테스트 input을 넣은 코드 베이스의 (like unit test) 테스트를 하는 일이 아니란 것입니다.
    VC 컴파일러의 테스트니 당연히 테스트 input은 소스 코드이고 (이 것만으로 일반적인 테스트와는 구분될 것입니다), 테스트는 x86, amd64또는 ia64의 여러 형태의 머신에서 수행되고 수많은 컴파일러 옵션을 조합해서 테스트를 수행한다고 합니다.
    즉, 동일한 테스트 케이스도 다른 머신, 다른 수행 환경 (컴파일러 옵션 등)에서 성공되기도 하고 실패하기도 하며 그것의 원인을 분석하는 것도 힘든 작업이라고 합니다.
    그래서 QA팀에서는 테스트 input을 만들 때 내부에서도 고민을 많이 하지만 개발자와도 많은 논의를 한다고 합니다.

    그래서 이와 같이 기술적으로 난이도 높은 (일반 개발자가 하기 힘든)일을 하는 것이 자랑스럽다고 하고 자기 주변의 개발자들이 한 주 씩 끙끙거리며 버그를 찾는 것을 자신이 쉽게 찾아 내는 것에 대해서 희열을 느낀다고 합니다.

    ※ [제 생각]잠시 생각해보면, 제 주위 뿐만 아니라 많은 사람들이 테스팅을 하든 테스트 기법을 연구든, 테스트 도구를 만들든 “테스트”와 관련된 일을 하는 것을 이와 같이 자랑스럽게 생각하는 것을 본적이 없습니다. 저도 마찬가지 이구요.
    그 이유는 무엇일까요? 바로 (기술적) 전문성이 다른 분야에 비해 떨어져 보인다고 생각하기 때문일 것입니다. (일용직 아르바이트 또는 신입 사원에게 테스트를 맡기는 국내의 현실을 보면 당연하겠죠) 하지만 테스팅 (도구이든 기법이든, 행위든)이라는 분야가 그렇게 기술적 도메인 지식이 얕은 곳은 결코 아닌 것 같습니다. 이에 대해서는 다음에 포스팅 하겠습니다.

    2. VC 팀의 QA팀에서는 매일 무슨 일을 하느냐?
    (저는 이 부분이 무척 궁금했는데, 역시 기대 이상으로 멋진 부분들이 많았습니다)

     
    Smile Wei는 그가 VC 컴파일러 팀의 QA팀으로 다음과 같은 7가지 정도의 일을 매일 수행한다고 합니다.

    Image Software tests1. 버그 분석
    말 그대로 테스트 수행 후 발견된 버그에 대해서 분석한다고 합니다. 그리고 예상하시는 것 처럼 MS에서는 Daily Testing 이 프로세스로 정착되어 매일 테스트가 수행되고 그에 대해 결과를 분석한다고 합니다. 물론 이를 위해 거의 대부분 테스트 자동화가 되었겠죠. (예전 저의 포스트에서 소개해드린 것처럼) 이 일이 최고 우선순위라고 합니다.

    2. 테스트 케이스 수정과 Regression 테스트 케이스 작성
    기존 작성되어 있는 테스트 케이스의 수정 뿐만 아니라 새로운 Regression (회귀) 테스트 케이스 작성을 의미하는데, 특이한 것은 Double Assurance Mechanism 이라는 프로세스 입니다.
    개발자가 버그를 수정하고 자신의 테스트 케이스로 수정확인을 하고 QA팀에게 전달하면 QA팀에서는 좀 더 복잡하고 다양한 테스트 케이스를 수행해서 수정이 올바르게 되었는지 한 번 더 확인하는 것입니다.
    앞에서 설명했듯이 다양한 환경과 컴파일러 옵션으로 더 복잡한 테스트 케이스를 이용해 수정된 부분이 올바르게 동작하는지 regression 테스트로 확인하는 것입니다.
    즉, side effect가 발생했는지 확인하는 프로세스입니다.
    누구나 알고 있는 것이지만 일정이나 인력을 핑계로 하지 않는 것을 실제로 잘 행하고 있는 것 같습니다.
    실제로, 이와 같은 활동으로 인해 Smile Wei가 가지고 있는 테스트 케이스는 약 20,000개이고 이 것은 컴파일러 팀의 QA팀이 가지고 있는 10개의 test suite (test case의 집합) 중 하나라고 합니다. 하지만 이 것은 VC++ 컴파일러 팀이 가지고 있는 것이고 VC++ 라이브러리 개발팀이나 IDE 팀, 릴리즈 팀, Visual Basic 팀, C# 팀들도 이와 같은 팀들도 각각의 테스트 케이스를 확보하고 있다고 하니 놀랍습니다.
    아무튼, 상상을 초월하는 테스트 케이스들이 매일 수행되어진다고 합니다. 물론 테스트 자동화 없이는 불가능 할 것입니다.

    3. QFE (Quick Fix Engineering) 확인
    QFE는 흔히들 말하는 hotfix (필수 업데이트. e.g. 윈도우 필수 업데이트)에 대한 검증 작업입니다.
    QFE 또한 2차에 걸쳐서 수행된다고 합니다.
    QFE 프로세스를 살펴보면,
    지원 팀 (support team)에서 고객으로부터 버그 리포트를 수집하고 버그를 확인 후 개발팀에 버그 리포팅을 합니다. 개발팀은 버그를 수정 후 QA 팀에게 수정 여부를 알려 QA팀의 테스트가 시작되는데, 1차는 hotfix에서 버그를 발견한 고객에게 수정된 hotfix를 전달하기 전에 테스트를 수행하는 것이고 2차는 버그를 발견한 고객이 버그 수정을 확인 후 최종 릴리즈를 위해 전체 테스트를 수행하는 것이라고 한다.
    (버그 수정 후 QA팀이 테스트를 수행하고 버그 발견 고객이 버그 수정이 올바르다고 확인하면 최종 릴리즈를 위해 전체 테스트를 다시 수행하는 프로세스입니다.)
    고객과 직접적으로 관련된 일이기 때문에 QFE 확인은 최고의 우선 순위를 가지는 작업이라고 합니다.

    4. 크로스 팀 테스트 지원 (cross-team test support)
    글을 읽을 수록 MS의 QA팀은 테스트에 강박 관념을 가진 것 같습니다 (좋은 뜻).
    VC 컴파일러 팀의 테스트 케이스를 다른 팀에게 제공하는 작업을 의미합니다. 예를 들어 Smile Wei는 최근 Visual Studio 2008 설치 프로세스를 위해 릴리즈 팀에게 자신의 테스트 케이스를 그들이 수행할 수 있게 제공했고 또한 라이브러리 팀을 위해 VS 2008 MSDN 테스트를 수행해줬다고 합니다. 두 작업을 통해서 몇 가지 버그를 발견했다고 합니다.
    흔히 개발자가 자신의 관점에서만 테스트를 하기 때문에 제 3자의 다른 각도에서 테스트를 하는 것이 필요하다고 하고 그것을 위해 다른 조직 (QA팀)에서 테스트 케이스를 작성하고 테스트를 합니다. 이 것을 넘어 MS에서는 각 QA팀 간에도 서로 테스트 케이스를 공유해서 좀 더 다양한 뷰에서 테스트를 강도 있게 수행하고 있습니다.

    5. 내부 테스트 도구 개발
    (이 일은 제가 하는 일과도 유사합니다만..)
    위에서 거론 한 것처럼 MS는 모든 제품에 대해서 매일 테스트를 수행하고 각 테스트 수 십만개 또는 수 백만개의 테스트 케이스를 수행합니다. 이 것을 위해서는 당연히 테스트 수행, 결과 수집, 결과 비교와 같은 모든 테스트 과정이 완전 자동화 되어야 할 것입니다. 이 것을 위해 아주 많은 테스트 도구들이 사용된다고 합니다.
    MS에서는 각 연구원들이 여러 형태의 내부 테스트 도구를 개발해서 테스트 효율성을 높이는 것을 독려하고 그 중 몇 몇 도구는 모두 부서 또는 MS 전체에서 채택해서 사용하게 하기도 한답니다.

    6. 새로운 기능에 대한 테스트 케이스 작성
    현재 VS 팀은 VS2008의 차기 버전을 준비하고 있다고 합니다. QA팀은 모든 새로운 제품 및 기능에 대한 테스트 활동에 참여합니다.
    또한 테스트 프로세스가 제품 개발 주기의 코드가 완료되기 훨씬 이전의 초기에 시작된다고 합니다. 즉, Waterfall 모델이 아닌 애자일 (Agile) 모델을 채택하고 있습니다. 누구나 알고 있는 “버그를 발견한 시점이 제품 개발 주기 후 반부로 갈 수록 비용은 훨씬 더 많이 증가”한다는 사실을 직접 실행해 옮긴 것입니다.

    7. 기타
    이 외에도 캠퍼스 리크루팅, 신입 사원을 위한 교육 자료와 비디오 작업, 면접 등을 수행합니다.

    정말 많은 일을 하는 것 같습니다.
    중요한 것은 Software Testing에서 흔히 말하고 Testing 분야에 조금이라도 관심이 있거나 관련 일을 하는 사람이면 누구나 알고 있는, 그렇지만 여러 가지 핑계로 행하지 않는 것을
    MS의 QA팀은 체계적으로 수행한다는 것입니다.

    우리는 성공하는 사람들의 위인전을 너무나 많이 읽고 심지어 그 방법도 머리 속에 다 알고 있지만, 여러 가지 현실과 그 것으로 만든 자신 (조직) 만의 핑계로 행하지 않습니다.
    성공하는 사람들은 그 명백한 방법을 행동으로 옮긴 사람이겠죠? MS처럼