깍돌이

안녕하세요 깍돌이입니당~ 

저희집 가훈 중 하나가 시간은 만드는 것이다 라는게 있는데 그래서 어머니께서는 시간이 없다라는 말을 별로 안좋아하십니다.

그럼에도 불구하고 ㅜㅠ 정말 시간이 없네요  막 엄청 부지런한 성격이 아닌가봐요... 해야될게 많지만 하고싶은것도 많아서

자꾸 뒤로 미뤄지게 되네요 그러다보니 평소에 작업하던 내용들을 포스팅 하는것도 있지만 중간중간 생각들을 정리 하려고 합니다.   자동화관련된 이야기를 많이 하게 될거 같습니다. 또한 관련에서 경험에 기반된 케이스가 많기 때문에 양해 부탁드립니다.   첫회사는 QA만 120명이 넘는 회사였고 현재는 작지만 많아지고 있는 상태 입니다.

첫번째로 하고 싶은 말은 Expected Result에 속지 마라입니다.

아마 QA에서 자동화을 하게 되는 상황이나 지켜보는 상황들이 존재 합니다. 저 연차 QA 일때 코드 조금 짤줄 알았던 ( 우물안 개구리였죠 ) 저는 맡은 제품에 API 들을 자동화하면 대충 5500건이 넘어가는데 (당시에 1인 QA) 코드 단으로 하는건 그냥 코드단에서 자동화 하면 쉽지 않을까? 하고 타자가 빠른 저는 며칠 걸리지않아 해당 API 를 자동화 했습니다.

API의 몸통이 되는 코드가 제품 안에 이름이 있었고 파라미터는 공용되는것들이 많아 공통 파라미터로 받는 Result가 같은 포맷이였기에 

let apiFncName = getGrepAPINameList();
// 공통 파라미터 설정
let commonparam = ''
apiFncName.reduce((prev,curr,index,item))=>{
      // 함수 이름 꺼내서 
      // 실행 ( 공통 파라미터  ) 
      // 결과 이상없을 경우
      
      // test_result.push(curr.name, result, test_result);
},0);

와 같은 형태로 동작이 가능한 구조였기 때문에 적은 코드로 많은 다량의 API 들을 호출할수 있었고 ( JS가 1급 함수여서 가능했던 작업 같습니다. - C였다면 함수 포인터까지 가야되지만 그러면 머리가 많이 아팠을 듯 )

여기서 핵심은 짧은 기간내에 5500개의 API 자동화를 한게 아닙니다.  QA로 일한다면 "테스트" 의 목적을 두면 안됩니다. 필요없는 단순 Test Case 100건 보다 평소에 많은 생각과 구조에 대한 연구가 된 하나의 Test Case 가 제품 릴리즈 시에는 빛을 발하게 된다고 생각합니다. 

위의 5500개의 자동화 케이스를 만들고 돌릴 경우 99% 는 Stdout에서 pass로 발생합니다. 1%의 에러도 내가 생각하지 못하였던 예외처리 였습니다.

그럼 거의 API 들을 많이 커버했을까? 그렇지 않습니다. 단순 API 에 대한 커버는 이루어졌지만 해당 자동화 케이스는 위에 말했던 100개의 단순 케이스일 뿐입니다. 그렇기 때문에 추후 발생하는 API 이슈들을 많이 잡아내지 못했습니다. 개인적으로 UI 포함 7천개의 케이스를 돌리고 있던 나는 다시한번 돌아보는 계기가 되었으며 철 없던 저 연차의 시간이 그렇게 지나갔습니다. 그리고 자동화 테스트의 결과는 Expected Result 가 pass 와 fail의 결과를 만들게 되는데 expected Result 또한 담당하는 QA가 작성하게 됩니다.  이로 인해서 너무나 주관적인 견해가 들어가게 됩니다. 그러면서 많은 부류들도 같이 발생합니다.

1. 처음에 생각 했던 대로 진행 ( 쉬운 케이스 부터 얼른 얼른 전체 틀 구조 ) 

자동화 케이스는 기본적인거부터 하는 경우가 많기 때문에 정말 호출 및 결과만 보는 케이스를 작성하고 회사에 보고시

회사에서는 더많은 케이스를 돌리는걸 보고싶어하여 고도화 할시간은 갖지 못하고 계속 저 위에 케이스를 넣게 됩니다. 이 경우는 언젠간 터질지 모르는 시한 폭탄이라고 생각합니다. 오류는 잡지 못하는 자동화 가 되는 수순을 밟게 됩니다.

 2. 어려운거 부터 하는 케이스

복잡한 케이스를 놓치는 경우가 많아서 복잡한 케이스를 우선적으로 하고 그다음에 전체 구조를 고도화 하자라는 목표로 작성시 어찌 보면 Test Case 1건 1건은 공을 들였기에 오류를 잡아 낼수있는 케이스가 될수 있습니다. 하지만 이 경우도 문제가 되는 케이스가 있습니다. 너무 TC에 공들인 나머지 자동화 의 구조를 생각 하지 못하였던 경우입니다. 위에 보고할때 그래도 좀 있어 보이게 해야되는데  공들인 TC가 남아있는데  이걸 아무리 말해도 다른 분들이 이거를 알아주는 경우는 많이 못 보았던거 같습니다.

1,2번 모두 아주 지극히 많은 케이스 중 몇개일 뿐입니다.  시작하려다가 안하는 케이스도있을 거고 tool 선정 하다보니 안되는 케이스도 있을거고 처음부터 내가 간단하게 개발을 해서 하겠다는 케이스등 여러 케이스가 있지만 공통되는 경우는 테스트의 결과에 대한 pass fail은 작성한 QA 의 expected result 입니다.

createServerAPI 

서버를 생성하는 API 입니다. 해당 API 는 생성할때 필요한 생성 값( 파라미터 ) 를 받아서 서버 생성 요청을 넣고 ( VDI ) 방금 request를 보낸 client에게는 바로 서버의 Info( 정보 ) 를 Response로 던집니다.

API 를 자동화를 하려고 할때 Expected Result를 이렇게 하는 경우도 있습니다. 해당 API 주소로 HTTP Method를 request를 보낸후에 response를 받고 Pass 로 표시할수 있습니다.

이경우는 반쪽짜리 케이스라고 볼수 있습니다. createServerAPI는 FE와 BE간의 요청을 전달하는 역할을 하고 "실제 생성"은 VDI를 통해서 이루어지기 때문입니다. Unit Test 를 하는게 아니기 때문에 QA입장에서는 사용자가 쓸수 있는가 정도 까지 생각을 해봐야 합니다.  API 를 테스트하는 것이 아닌 API 의 품질보는 방향에서는 Expected Result가 확연하게 달라질 필요가 있습니다.

1. API Requeset ( 생성 파라미터 ) 

2. API Response 확인 

3. API Request ( 서버 리스트 혹은 상태를 가져오는 API 확인 ) 

4. 생성이 되지않았을 경우 Polling 하여 확인 

5. 생성이 되었다면 Pass로 종료 생성이 되지않았다면 QA가 지정한 Condition Timeout까지 Polling 해당 시간초과시 내부적으로 해당 오류와 함께 오류 리포트

업무를 하다보면 API 테스트에 대해서 간단하게 생각 하시는 사람들이 있습니다. 직군과 사람들 간의 차이로 인해 발생하는 것으로 "테스트"의 관점을 두고 생각 하냐 "품질"의 관점을 두고 생각 하냐에 따른 차이인거 같습니다.

테스트의 관점을 둔다면 API 자동화 테스트는 소위 말하는 "노다지" 입니다.  작성하기도 쉽고 그걸 보여주기도 쉽고 테스트 시간도 적절하고 하지만 품질 관점에서의 API 자동화 테스트를 추가로 한다면 (본업이 있기에) 기존 Test Case를 가지고 Test Plan 을 짜듯이 사용자 입장에서 정상이라고 느껴지는 지점과 그에 대한 Expected Result에 대해 많이 고민해야 합니다.

내가 아닌 누군가가 자동화를 했다고 할 경우 리뷰를 해야하는 경우가있다면 잘돌아가나만 보는게 아니라 Expected Result를 무엇으로 기준을 했냐가 중요합니다.  현재 상황에 따라서 위와같이 못한다고 해도 중요하다고 하는 부분의 경우 Expected Result를 다시 한번 다듬어 볼 필요는 있는거 같습니다.

이부분에 대해서 기술 포스팅은 추후에 꼭 하도록 하겠습니다.

감사합니다.