깍돌이

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

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

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

자꾸 뒤로 미뤄지게 되네요 그러다보니 평소에 작업하던 내용들을 포스팅 하는것도 있지만 중간중간 생각들을 정리 하려고 합니다.   자동화관련된 이야기를 많이 하게 될거 같습니다. 또한 관련에서 경험에 기반된 케이스가 많기 때문에 양해 부탁드립니다.   첫회사는 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를 다시 한번 다듬어 볼 필요는 있는거 같습니다.

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

감사합니다.

안녕하세요 깍돌이입니다. 오늘은 되게 오랜만에 작성을 하게되네요

기술 포스팅은 아니고 QA를 일하면서 항상 재밌지만 매번 힘든 경우가 있게 되는데요 마음을 다시 잡기 위해서

도 있고 해당 고찰 시리즈(?) 를 작성 하고 몇달뒤에 나는 얼마나 후회했던 점을 많이 수정하고 보완하였는지

판단하고 싶어졌습니다.      

다시 한번 인사드립니다. 안녕하세요 이제 5년차 Software QA 로 일을하고 있는 깍돌이 입니다. 

벌써 올해 5년차가 되었지만 아직도 제 자신이 보기에 부끄러울정도로 부족함이 보입니다.  

6년차 부터는 고연차라고 생각 하고 자기 자신을 다져서 튼튼하게 만들어야 될 것 같습니다.

버그 & 이슈 

QA로 일하면서 즐거운(?) 점도 버그 이지만 완전 정 반대로 힘들어지는 경우도 버그 입니다.(저는 그렇습니다.)

이슈를 찾아서 개발자에게 전달 할 때 가 즐거운 게 아니라 다른 분들이 생각하지 못한 이슈를 찾아 낼 때가 그렇습니다.

이러다 보니 모든 케이스를 열린마인드로 바라보는 것도 좋은 거 같습니다.  그래서 TC를 안쓰고 테스트하는 Ad hoc testing(애드훅) 테스트의 경우에 TC에서는 나오지않던 이슈들이 도출되기도 합니다.

QA가 하는 여러 활동 중 에는 많은 사람들이 대표적으로 알고 있는 테스트 활동이 있습니다.  간단하지만 간단하지 않은 활동이죠 해당 활동들을 간단하게 하지 않기 위함과 그로 인하여 제품의 품질을 높이기 위한 추가 활동들이 수 없이 있습니다.   

Test Case

개인적으로 QA의 자산이라고 생각하며 Test Case가 탄탄해야 제품의 품질 을 끌어올릴수 있다고 생각합니다.

철없을 시절에는 1건이라도 자동화가 우선이지! 라는 착각을 했지만  탄탄한 Test Case가 없다면 자동화도 무의미 합니다. 제대로된 자동화를 하기 위해선 많은 공수가 들기도 하는데 Test Case가 물렁 거린다면 그 이후에 작업들도 다 무용지물이 되는건 한순간입니다.

TestCase는 매우 꼼꼼하게 작성합니다. 말 그대로 자산이고 또 다른 QA (담당하지않은) 가 왔을 때 확인하는 시간은 좀 걸리겠지만 제품에 대한 이해가 조금 부족해도 수행 할수 있도록 작성되어야 합니다.  개발자들 을 예로 들면 주석이 꼼꼼하게 달려 있는거랑 비슷하겠네요

TC가 빈틈없이 작성되어있다면? 물론 빈틈없이 모든 케이스를 작성해서 배포시간내에 테스트가 가능하다면 이보다 더 좋을순 없습니다.  하지만 모든 케이스를 다 넣게 되면 TC의 거대화가 진행되면서 필요없는 TC활동이 생기게 되며 이는 비효율적입니다.  또한 배포의 형태에 따라 TC를 매번 Regression Test (회귀 테스트) 를 진행할수는 없는 노릇입니다. 

QA도 Release Plan (배포계획) 에 따라서 Test Plan ( 테스트 계획 ) 을 작성하는데 이 또한 근거가 되는 것은 Test Case 입니다.  그래서 특정 여러 배포에 따라서 Check List라는 형태로 간소화하여 Major 기능들 위주로 확인할 수 있습니다.

Check List 

매번 Regression Test (회귀 테스트 ) 를 돌릴수 없기 때문에 기본적으로는 Release Plan 에 따른 Test Plan 을 짜야 하지만 때로는 Check List 로 작성하여서 최소한의 리스크로 확인 하는 경우도 있습니다. 해당 제품에 대한 메이저 기능들 (절대로 안되선 안되는 ) 이죠 물론 케이스가 조금 응용됐을 때도 안되는 케이스도 어느정도 고려를 해야합니다. 

개인적으로는 Test Case를 작성하고 -> Check List 형태로 간소화하여 사용하기도 합니다.

반대로 Check List로 만든 후에 Test Case 로 정밀화 하기도 합니다.

고찰

버그에 대한 고찰을 이야기하다가 여기까지 왔었네요. 정기 릴리즈 시기가 와서 배포 대기를 하고 있었습니다.

왠지 모르게 이번 배포는 자꾸 2%가 찜찜 하더군요 

배포 중에 하드한 이슈들도 찾고 잘 처리하여 마무리 를 하였습니다. 하지만 배포후에 이슈가 생겼고 

해당 이슈는 QA를 거친 제품에 대한 이슈였습니다.

아주 특이한 케이스였으면 "와 이런 케이스도 있을 수 있구나"  싶었지만 "특별" 하지만 "특이" 한 이슈는 아니였습니다.

다른 분들은 어떨지 모르겠지만 저는 해당과 같은 상황이 닥쳤을 때가 가장 QA하면서 힘든 상황이였습니다.

어떠한 면에서는 현실이 아니길 기도하기도 했습니다. 하지만 이슈가 발생했던건 현실이였죠.. 

어떤 분들은 "자동화를 해라" 라는 부분에서 스트레스를 받지만 저는 공부하면서 자동화하고 자신의 기술 습득의 향상이 되는 부분이라 하는 만큼 결과도 보여지고 매우 좋아하는 요구사항입니다.

하지만 위와 같이 배포 후 이슈가 1건이라도 발생했을 경우 ( 자잘한 이슈가 아닌 사용성 문제가 있는 ) 에는 QA로써의 책임감에 따라서 정신적으로 많이 힘들었던 기억이 있습니다. 물론 최근에도 비슷한 경험을 하고 멘탈이 조금 씩 나가지만 소 잃고 외양간 고치라는 말처럼 그러다보니 최소한 2번은 절대 발생하지 않겠다 는 생각으로 발생했던 이슈들은 전부 체크리스트에 넣고 시간이 오래걸려도 해당 부분은 추후에 볼수 진행하면서 구멍을 메꾸려고합니다. 

QA는 자기 제품 혹은 자기가 맡은 모듈에 따라서 책임감을 어느정도 가지고 있어야 한다고 생각하고 있습니다.

개발은 개발팀에서 하겠지만 결국 제대로된 상품이 되기위한 Flow 중 QA라는 Flow도 있고 밀접한 관계로 일을하기 때문에 일을하면서 내가 이 제품의 담당자이며 관련자다 라는 책임을 가지고 이슈없는 배포 깔끔한 배포가 이루어질수 있도록 더욱 노력해야 할 것입니다.