소프트웨어 테스트 자동화 - '테스팅 전문가들의 생생한 사례연구 스토리로 익히는'을 읽고 나서 6/6

 

소프트웨어 테스트 자동화 국내도서 저자 : 도로시 그레이엄(Dorothy Graham),마크 퓨스터(Mark Fewster) / 황영석,성찬혁,여용구역 출판 : 에이콘출판사 2013.12.23 상세보기

 

 

01. 테스트 자동화를 유지하고 있었던 웹마스터 툴과 관련하여 새로운 툴의 선택 또는 유지보수 여부를 결정해야만 했던 이유

 테스트 자동화를 유지하고 있었던 웹 마스터 툴과 관련하여 새로운 툴의 선택 또는 유지보수 여부를 결정해야만 했던 이유는 다음과 같다.

 

 

 

 

웹 마스터 툴은 몇 해 동안 어떤 형태로든 테스트 자동화를 유지하고 있었다. 오랜 기간 동안 구글에서 지배적인 룰은 테스트플랜트사의 상업 테스팅 패키지인 에그플랜트다. 웹 마스터 툴을 포함하여 많은 팀이 에그플랜트를 사용했다.

2009년 초 내가 구글에 왔을 때 팀은 선택의 기로에 있었다. 유저 인터페이스는 프론트엔드의 나머지 부문도 포함해서 대대적인 점검을 막 마친 상황이었다, 각 자동화 테스트는 유저 인터페이스의 기능에 묶여서 작성됐기 때문에 초기에 개발된 모든 자동화는 더 이상 동작하지 않았다. 예를 들면 자동화 테스트는 링크와 헤더 텍스트 같은 엘리먼트뿐만 아니라 폐이지 내에서 엘리먼트의 상대적인 위치까지 검증을 했다. 공통 라이브러리에 일부 비트를 저장할 수는 있었지만 수천 라인에 이르는 테스트 관련 코드의 순서는 유지할 수 없게 됐다. 내가 구글에 와서 해야만 했던 첫 번째 주요 결정은 계속 나아가기 위해 무엇을 해야 하는가 였다. 에그플랜트를 계속 사용하면서 현재의 라이브러리를 모두 재 작업해야 할까? 아니면 완전히 새로운 룰을 가지고 처음부터 다시 시작해야 할까?

테스팅에 관한 한 나는 완전 초보자였다. 구글에 입사하기 전에는 어면 종류의 테스트 업무도 해본 적이 없었으며 테스트는 학교에서 배우는 것과는 완전히 다른 업무 였다. 한 술 더 떠서 구글 내에서는 다양한 불에 대해 비교 분석한 데이터는 거의 없었다. 각 툴을 사용하는 방법이 기술된 충분한 양의 문서가 있긴 했지만，어떤 툴이 웹 마스터 룰에 가장 적합할지에 대해 명확하게 그림이 그려지는 문서는 없었다.

당시 구글 내에서 사용하던 몇 가지 주요한 툴이 있었는데, 가장 두드러지게 사용 서 하는(구글 엔지니어가 상당히 기여하고 있는) 툴은 오픈소스 프로젝트인 쉘레늄과 주요 팀에서 사용하는 TAU(Test Automation Unit)이라는 사내 툴, 서드 파티 툴인 에그 플랜트였다. 그리고 시장에 출시된 다양한 상용 테스트 툴이 있었다. 하지만 상대적으로 수준도 낮고 경험도 적은 엔지니어인 나는 이러한 툴 중에 하나도 구글에 도입할 수 있는 위치가 아니었다, 이 둘 중 하나라도 조사해보기 위해 귀찮게 조르는 것 조차 하지 않았다. 대신 다른 구글 엔지니어가 이미 사용해본 툴을 사용하기로 결정했다.
어떤 툴을 선택해야 할지 몰라서 주위에 물어봤다. 내가 시애틀 사무실에서 일하기 때문에 물어본 대부분의 테스터는 그 곳에서 근무하고 있었고, 그들 대부분은 정도의 차이는 있지만 에그플랜트를 사용해본 경험이 있었다. 전반적으로 다른 두 종류의 구글 툴에 관한 피드백은 매우 부정적이었던 반면 에그플랜트에 대한 피드백은 아주 중립적이었다. 주요한 문제는 다음과 같았다.
• TAU를 개발하고 유지 보수한 프로젝트는 종료되는 과정에 있었다. 구글은 전체적으로 TAU에서 멀어져 가고 있었다. TAU는 C++로 개발되었는데, 이 툴을 사용한 테스트 작성은 너무 힘들다는 공감대가 형성되고 있었다.
• 셀레늄은 셀레늄 팜에 크게 의존했다. 셀레늄이 모든 종류의 다양한 브라우저와 운영체제의 조합으로 테스트를 지원했기 때문에 구글은 이들 조합으로 구성된 장비의 풀을 유지해야만 했다. 셀레늄 팜이 이 요구를 충족시켰다. 테스트하는데 원도우 XP와 인터넷 익스플로러 7이 실행되는 장비가 필요하다면 셀레늄 팜에 요청하게 되고, 팜은 테스트를 실행할 수 있는 장비의 주소를 알려 주게 된다, 문제는 셀레늄 팜이 매우 과도하게 사용되는 상황이었다. 그래서 가까스로 어떤 장비를 확보하더라도 해당 장비에서 실행되는 모든 테스트는 매우 불안정했다. 그리고 대부분은 장비가 할당되기를 기다리다가 그냥 시간이 초과 되곤 했다.
이런 상황으로 볼 때 내 결정은 단순해 보였다. 조사를 통해 알게 된 부정적인 면뿐만 아니라 에그플랜트 내에 상당히 큰 규모의 공통 구글 코드베이스를 이미 가지고 있었고, 다양한 운영체제와의 상호작용, 브라우저 실행, 기타 등을 하곤 했다. 에그플랜트를 이전부터 너무 많이 사용해왔기 때문에 적정한 수준의 가치를 제공해왔어야 한다고 생각했다. 그러나 투자 대비 효과를 실제로 계산해서 확인해본 적은 없었다. 나중에서야 이 점이 실수였음을 깨달았다. 그런데도 팀 내 다론 핵심 관련자와 매니저와 미팅을 하게 됐고 에그플랜트로 진행하기로 결정했다. 우리의 목표는 지속적으로 웹 마스터 툴의 릴리즈 주기를 줄여나가는 것이었고 에그플랜트가 이를 가능하게 할 것으로 생각했다. 웹 마스터 툴의 네 다섯 가지 기능에 대해 수동 테스트 명세를 자동화하는 것부터 시작하려고 했고，이것이 잘 되면 좀 더 많은 부분에 에그플랜트를 사용하는 방안을 검토하려고 했다. 아직은 이 네 다섯 가지의 기능을 자동화하는 데 얼마나 오랜 시간이 걸리고 고통스러울지에 대해 감을 잡을 수 없었다.

 

02. 웹 마스터 툴이 비교적 긴 QA 시간이 필요한 이유

 

 웹 마스터 툴은 왜 비교적 긴 QA 기간이 필요했을까? 구글에서의 개발 프로세스가 상당히 엄격함에도 불구하고, 여전히 최종 제품에서는 버그가 발견됐다. 그 결과 모든 메이저 릴리즈에 앞서 수동으로 UI를 살펴보는 것이 테스터의 책임이었다. 우리는 웹 마스터 툴의 모든 주요 기능에 대한 테스트 절차를 기술한 스크립트가 있었다. 수동 테스터는 스크립트를 따라 구글이 지원하는 모든 주요 브라우저에서 UI를 살펴봤다. 테스터에게는 각 주요 브라우저에 대한 책임이 있을 뿐만 아니라 국제화를 위한 제품 테스트도 해야 했다. 당시 웹 마스터 툴은 23개의 언어를 지원했고 심지어 히브리어와 아랍어처럼 문장을 오른쪽에서 왼쪽으로 읽는 언어까지도 정확하게 표시해야 했다.

 

 

---

 

 

 

 

03. 에그플랜트의 개념/자동화 시도/사용포기

 1. 에그플랜트의 개념은 다음과 같다.

에그플랜트는 이미지 분석 코어를 사용하는 테스트 패키지이다. 아이디어는 간단하다. 실제 유저 인터페이스의 이미지와 기대하는 이미지를 비교해서 사용자가 정의한 허용 범위 내에서 서로가 유사한지를 본다. 유저 인터페이스는 반드시 웹 페이지일 필요는 없다 운영체제에서 실행되는 무엇이든 될 수 있다. 반드시 이미지 분석을 사용해서 모든 것을 테스트해야 한다. 두 개의 문자열을 비교하는 것 같은 단순한 작업을 완료할 때조차도, 테스터는 에그플랜트가 기대하는 텍스트의 인 메모리 이미지를 생성하고，화면에서 이를 찾는 코드를 작성한다.
실제 에그플랜트 코드는 센스톡 언어로 작성되며, 작업할 때 맥에서만 실행된다. 기능 동작을 위해서 에그플랜트 테스트는 맥에서 실행되고, 테스트 대상 시스템에서 실행 중인 에그플랜트 서버로 원격 프로시저 콜을 연결한다. 우리의 케이스에서는 테스트 대상 시스템은 대다수가 사용하는 윈도우였고 웹 마스터 툴 사이트의 테스팅 인스턴트로는 파이어폭스나 인터넷 익스플로러의 인스턴스에서 테스트를 실행하려고 했다.

2. 에그플랜트 자동화 시도는 다음과 같다.

자동화 시도는 완전히 실패했고，6개월 뒤에는 모든 코드를 폐기해야만 하는 상황에 처하게 됐다. 6개월의 기간 동안 에그플랜트의 가치에 대해 정기적으로 논의했으나，논의 기간이 완전히 끝날 때까지도 모든 걸 폐기하고 새로운 툴로 다시 시작할지에 대한 결정을 내리지 못했다. 에그플랜트가 중요한 문제점을 가지고 있다는 사실은 이미 알고 있었지만(최소한 우리가 툴을 사용하던 방식 에서는), 이미 너무 많은 시간을 쏟아 부었던 모든 작업을 포기한다는 건 정말 내키지 않았다. 그래서 결국 악순환에 빠져들게 됐다. 고생하며 작업한 모든 것을 폐기하는 건 원치 않았고，결국엔 다 갖다 버려야 했던 쓸모 없는 코드를 작성하는 데 더 많은 시간을 허비하게 됐다.

3. 에그플랜트 사용 포기는 다음과 같다.

내가 구글에 입사하기 전 약 2년 동안 웹 마스터 툴에 에그플랜트가 사용됐지만，에그 플랜트가 실제로 팀에 많은 도움이 되지 않는다는 사실을 마지막까지 깨닫지 못했다. 이 기간의 대부분을 수동 테스트한 테스터는 테스트가 통과되는 동안에 자동화 테스트를 실행하려고 했으나, 자동화 테스트를 신뢰하진 않았다. 이미 자동화 테스트에서 커버된 기능을 포함해서 모든 항목을 손으로 다시 테스트했다. 이 기간 동안 애그플랜트를 사용하는 것에 대해 팀의 잘못은 없었다. 브라우저 자동화를 위해 이보다 더 좋은 방안은 없었기 때문이다. 결국 2009년 말 이 툴을 사용하지 않기로 결정했는데, 가장 큰 이유는 강력한 경쟁상대가 등장했기 때문이다.

 

 

 

04. QA 리그레션 테스트 자동화와 관련된 자동화 프레임워크

- 스크립트 실행
- 모듈의 고려 사항 3가지
- 스크립트 실행 

 1. 프레임워크의 모듈은 다음과 같다.

각 편집기，다이얼로그, 공용 오브젝트 등은 각 모듈을 받는다. 각 모듈 내에는 모듈 내의 오브젝트간 소통에 쓸 함수가 생성된다. 이 방식을 이용해서 어떤 편집기나 다이얼로그의 어떤 필드라도 스크립트를 빠르게 작성하여 다양한 확인작업을 할 수 있다. 예를 들면 경계 값 조건이나 특수 문자, 문자 대 숫자, 필수 필드 여부 등이다.
가장 큰 장애물 중 하나는 자동화 툴 내에서 타이밍 이슈를 줄이려는 시도였다. 이 이슈는 애플리케이션 내의 문제가 아니라 자동화 툴 자체 내의 타이밍 문제로 인해 많은 수의 스크립트가 불필요하게 실패하는 결과를 가져왔다. 이를 해결하려면 WaitForReady라는 스크립트 내에서 참조하는 모듈을 생성했다,
컨트롤을 기다리는 서브루틴의 생성은 스크립트의 안정성율 가장 많이 개선하는 것 중 하나다. 자동화 룰 내에서의 타이밍 이슈를 없애거나 줄이기 때문이다. 혹시 우리가 이 해결 방식으로 제품 내의 버그를 가리고 있는 것이 아닌지를 확실히 하고자 제품 내의 타이밍 오류만을 따로 찾기 위한 또 다른 테스트를 수행한다.
이 모듈화 방식은 이전 자동화에서 사용했던 방식과 비교할 때 유지보수 오버헤드를 극적으로 줄일 수 있었다. 또한 이 방식으로 필요한 변경 사항을 적용하는 중앙 집중된 장소를 가지게 됐다. 모듈이나 함수 레벨에서의 변경덕분에 스크립트는 변경이 어디서 일어나는지 알 필요가 없게 되었고 변경으로 인한 아무 방해도 받지 않고 실행할 수 있게 됐다.

2. 모듈의 고려 사항 3가지는 다음과 같다.

- 모듈규칙
모듈과 함수 명명 규칙은 제품 모듈, 편집기. 다이얼로그，유틸리티 등을 쉽게 알아볼 수 있게 하여 테스터가 스크립트를 작성할 때 도움이 된다. 테스터는 단지 작업 대상 편집기나 다이얼로그의 이름만 알면 애플리케이션 모듈을 사용할 수 있기 때문이다.
-새로운 모듈
새로운 다이얼로그나 컴포넌트 등이 새로운 기능 프로세스를 거쳐 제품에 추가될 때 마다 새로운 모듈이 생성된다. 자동화 개발자는 모듈과 내부 함수를 개발하고 오브젝트가 소통할 수 있는 새로운 기능의 모든 오브젝트와 오브젝트를 조작할 수 있는 모든 방법을 파악해서 상호 작용하는 모든 속성을 개발한다. 자동화 개발자가 모듈이 완성되었다고 느끼면 이를 프레임워크에 체크인하여 스크립트 팀이 사용할 수 있게 한다.

-모듈의 이슈
모듈을 사용할 때 스크립트 개발자가 제대로 동작하지 않는 함수나 빠진 함수를 발견 하면 인시던트를 생성하고 적절한 사람에게 할당한다. 이 인시던트 보고 프로세스는 제품 개발 팀에 결함을 보고하는 데 사용하는 것과 같은 제품을 사용한다. 이 제품은 우리 회사가 판매하는 제품으로 우리 회사 제품의 결함을 보고하고 추적하고 할당하며 분석하기 위해 동일한 제품을 사용하는 것이다(예: 내가 만든 개밥 먹기: 도그 푸딩).

3. 스크립트 실행은 다음과 같다.

아홉 개의 서로 다른 시작 데이터 세트를 가진 1,300개가 넘는 스크립트가 있는 환경 에서 설정 값 변경이 가능한 스크립트를 사용해 테스트 환경에서 각 스크립트 실행 후에 사이트를 재설정하는 일은 필수적이다. 계획할 때 각 스크립트를 실행한 후 환경을 원래 상태로 되돌려놓고 변경된 데이터를 모두 지우는 방법을 잠시 고려했었다. 하지만 이 방식에는 문제가 있음이 곧 발견되었다. 스크립트를 실행하다가 처음으로 실패하면 테스트 환경은 알 수 없는 상태가 되고 다음 스크립트는 이전 스크립트가 중지된 상태에서부터 시작하기 때문이다. 이러한 상태를 피하려면 설정 값 복원 단계를 각 스크립트의 시작 부분으로 옮겨 각 스크립트가 이전 스크립트에 남긴 설정 값이나 데이터 상태를 원래대로 되돌려 놓게 했다.

 

05. 탐색적 테스트 자동화와 관련되어 테스트 자동화를 유연하게 만들기 위한 입력 버퍼 생성 방법 5가지

 탐색적 테스트 자동화와 관련되어 테스트 자동화를 유연하게 만들기 위한 입력 버퍼 생성 방법 5가지는 다음과 같다.

 

1. 임시 파임에 저장된 오류 메시지는 트랜젝션의 성공과 실패를 예측할 수 있는 유용한 테스트 오라클을 제공한다. 테스트 자동화는 기존에 사용하던 테스트 결과와의 비교에서 자유로워졌고 단순한 리그레션 테스트를 넘어설 수 있었다.

 

2. 데이터베이스 내의 트러블 티켓 정보는 성공적인 트랜잭션 버퍼의 내용을 근거로 확인될 수 있다. 값을 예상할 수 없을 때도 트러블 매니저가 할당한 타임스탬프를 사용하여 이 값이 트랜잭션이 실행되었을 시간과 비슷한지를 확인할 수 있다.

 

3. 테스트 자동화는 트러블 매니저의 동작을 탐색하기 위해 실제로 사용하는 툴이 되었다. 예를 들어 트러블 매니저가 긴 문자열을 잘 처리하지 못한 경우 버퍼 생성자를 수정하여 긴 문자열 값을 생성했다. 문자 인코딩이 문제를 일으켰을 때는 임의의 문자를 필드 값에 넣어 해결했다.

 

4. 테스트 설계는 이제 중요한 관심사가 되었다. 예를 들어 하나의 버퍼 내 에 있는 여러 오류를 테스트하는 좋은 방법은 무엇일까? 임의로 오류를 심는 것은 무성의한 것 같았다. 물론 완벽한 테스팅은 볼 가능하다는 것은 알았다. CreateTicket 트랜잭션에만 58개의 필드가 있었으며 이에 대한 오류의 조합은 예상할 수 있듯이 억만 개의 방법이 있었다. 다행히도 나는 페이와이즈 조합 툴을 알게 되었고 OATS(Orthogonal Array Testing Strategy)와 CATS(Constrained Array Test Syste) 두 가지 툴을 사용해 테스트가 필요한 조합의 수를 억만 개에서 243개로 줄일 수 있었다.

 

5. 테스트 생성이 유연하고 쉬워지면서 개발자가 키보드에서 손을 떼자마자 동적인 자동화된 테스트를 실행하는 것이 가능해졌다. 이 사실은 프로젝트 개발자와 내가 함께 일하는 방식에 광범위하게 영향을 끼쳤다.

 참고로 국내·외적인 환경변화로 인하여 기업과 행정부 등의 각종 조직들에게는 경제적 및 관리 운영상의 효율제고의 압박이 강화되고 있으며 지구적 차원의 경쟁격화로 기업과 정부가 새로운 도전과 기회에 대하여 더욱 생산적이고 과단성 있고 반응성 높게 대응할 수 있는 능력에 대한 요구가 갈수록 커지고 있습니다. 그리고 최근 조직의 정보 의존도는 지속적으로 높아가고 효율적인 정보의 수집, 가공 및 분배의 수준은 조직의 흥망을 좌우할 정도로 영향력이 커지고 있으며, 날로 양적, 질적으로 확대 심화되고 있는 정보처리 업무에 있어 비용절감을 통한 효율적 운영을 도모하는 방법을 모색하게 되었으며

 

이것의 결과가 아웃소싱 입니다.

 

 

저단가, 단기고용으로 인해 공사장 인부들이 중장비/동남아 사람들로 대체된것 처럼

 

테스트 업계도 자동화 도구/동남아 사람들(베트남/인도 등의 영어 가능한 고학력 테스터)들로 대체 될것입니다.

 

포크레인 기사처럼 테스트 업계에서 살아남으려면 자동화 도구를 사용할줄 알아야 할것입니다. 아니면 인력 사무소(아웃소싱) 사장/관리자가 되어야 겠지요