QA에 대해서

QA의 정도와 업무 방식에 대해 다른 회사는 어떻게 하고 있나 궁금하여
게임 회사에서 웹/플랫폼 QA직군으로 재직중인 친구와 문답한 것을 적는다.

Q.
개발자들이 CI(continuous integration) 단계에서 적용하는 test code랑 QA랑 어떤 기준으로 분리되어있는지 예시가 좀 궁금해

A.
기획/사업쪽에서 일 만듦 > 2. 개발 요청 > 3. 개발 > 4. PM쪽에서 QA 필요 여부 판단해서 QA 요청 > QA 진행 /// 이렇게라서 개발 입장에서 내부 테스트랑 QA를 어떤 기준을 두고 분리하고있진 않을거임
QA할때보면 내부테스트 아예 안하고 주는 경우가 대부분이라서 우리 회사 웹 개발자들이 애초에 테스트를 고려하고 있는지 자체도 잘 몰르겠고

Q.
QA리스트 작성은 누가 담당하고 있고, 어떤 식으로까지 구체적으로 작성하고, 어떤 원칙으로 작성하는지도 궁금해. 지금 내가 고민되는게 커버리지를 높이려면 끝도없이 높일 수 있으니 어느 수준으로 설정할지가 명확하지 않거든.

A.
PM은 그냥 이 프로젝트가 QA가 필요할까 안해도될까를 판단해서, ‘이번에 이런이런 프로젝트를 하는데(기획서 전달해주면서) 이런 일정으로 큐에이 해주세요’ 정도로 요청을 줌.
그럼 우리 부서에서 이게 어떤 프로젝트고(구체적으로 모르니까), 그 일정으로는 어느정도까지 테스트할 수 있고, 영향도를 어디까지 파악해야되는지 등등을 정리해서 계획을 짬. 여기서 계획이라는거는 테스트케이스(pass/fail 찍을 체크리스트, 환경이나 예외상황들에 대해서 확인이 필요한 부분, 비용이 든다면 비용 어떻게 할건지, 사용자 공개 되는 시간이 언제고 등등 정도.
그래서 이걸 큐에이 시작하기 며칠전에 유관부서 전체에 메일로 보내면, 기획쪽에서 뭔가 우리가 잘못생각한게 있으면 말해주고 개발자들이 이런이런 부분도 영향이 잇을 수 있어서 테스트항목에 추가해줬으면 좋겠다던가 이런걸 말해줌
어디까지 구체적인지는 보통 가용 일정으로 그때그때 차이가 많이 나는데 기본 기조는 ‘변경된 내용(이번에 업데이트 또는 수정된 내용) + 그거로 인해 영향 받는 범위’ 를 보는건데, 가용 일정에 따라서 후자에 대한 범위가 천차만별로 차이가 남. 일정이 아무리 부족해도 전자를 빼는 경우는 없고 도저히 전자를 다 볼 수 없는 일정으로 온다면 뭔가 다른 협의 절차(상급자들한테로 의사결정이 한도끝도 없이 올라간다든가, 그렇게 해서 오픈 일정을 미룬다든가, 그냥 감안하고 오픈할테니 그럼 그 일정에 가능한 범위만 보라고 협의를 한다든가 등)가 진행되는데 보통 이런경우는 없고 후자 케이스의 범위를 조절하면 일정에 맞출 수 있게됨

Q.
개발-QA-배포 진행과정의 pipeline은 어떤식으로 이루어져있는지도 궁금해!

A.
우리 회사는 개발 환경이 망 단위로 분리되어있는데 일단 sb>rc>stage>라이브 라고 보면 되는데, sb는 샌드박스망이라고 하는데 여기가 개발망이라서 개발자들이 개발하는 환경이고, 개발이 완료되면 rc(릴리즈 캔디데이트)에 배포를 함.
개발하고 알씨망에 배포해쥬면 우리가 알씨 큐에이를 하고 결과 메일을 발송해서 이상이 없으면 스테이지망에 배포하고, 스테이지망에서 또 큐에이를 하고, 거기서 이상없으면 라이브(일반 사용자들이 보는걸 라이브라고 표현) 배포를 하는 식. 라이브와 스테이지는 거의 유사한 환경으로 셋업되어있어.

Q.
중복해서 두 번 한다 정도로 생각하면 되겠네
rc에서 특별 기능만 수합해서 stage에 올릴테니까 개발자입장에서는 다른 코드가 가능한거고 실사용자가 접근할수있냐 없냐의 차이인거지?

A.
웅 같은 체크리스트로 두번 하는거긴 한뎅 첫번째 목표는 여튼 rc는 테스트 환경이니까 실제 라이브 환경에서 테스트 또 한다는 점이고 두번째는 rc에서 미처 발견 못한 이슈를 라이브 오픈하기전에 잡자 이런 느낌으로 두번한다고 보믄댐

Q.
발생가능한 모든 사이드이펙트를 다 고려해서 다양한 유저시나리오를 다 체크할 것 같다고 예상되는데, 그렇게 할 경우 QA담당자들은 완전 생노가다..를 하는게 또 아닐 것 같다는 생각까지 번져서 QA작업자들이 업무 프로세스 자동화 효율화를 위해서 어떤 원칙이 있을 것 같다는 생각이 들었거든? 그걸 좀 물어보고싶어! 너의 경우에 어떻게 하고있는지

A.
뻔한 얘기긴 한데.. 우리가 하는 테스트 중에서 단순반복적이거나, 단순반복이 아니더라도 잘 변하지 않는 영역은 자동 테스트로 전환한다는게 기조인듯..

우리는 개발 조직이 아니니까, 자동화를 하기 위해서 공수가 너무 많이들거나 그 자동테스트 툴, 스크립트 유지보수에 시간이 많이 들어가는건 또 주객전도 되는 일이잖아.

그래서 자동테스트를 해보겠다며 모든 업데이트 되는 프로젝트들과 새로 개발되는 플젝들(계속 변경되고 어디서 어떤 새로운 이슈가 나올지 모르는 작업들)을 자동화하려고 시도하진 않구 우리 서비스에서 업데이트되지않더라도 항상 잘 되고있어야되는 기능들을 프로세스화 해놓고 걔네들을 반복 수행 하는(모니터링)느낌의 업무 영역들을 자동화 한다든가 예를 들어 무언가 업데이트 되진 않았더라도, 우리가 정기점검을 하니까 그때 모든 서버들이 다 내려갔다 올라오잖아. 그 과정에서 가끔 뭔가가 안떴거나 이상이 생길 수 있어서 우리 서비스들의 기본 기능을 한번씩 도는 테스트를 만든다든가 (이것도 서비스가 많으니까 사람이 하려면 수요일 오후 내내 해야되는 작업이라) 자동화 원칙이라면 대충 이 정도 있는듯

Q.
결국 QA는 개발과 구분되어야한다는 점에서(또다른 개발을 야기해서 QA를 낳는 기형적 구조를 탈피해야한다는 점) 자동화는 보수적으로 취한다 라고 볼수 있네?

A.
보수적이면서도 가끔은 아니기도 한게, 어디서 어떤 이슈가 나올지 모르는 상황이 많으면 사실 사람이 직접 테스트하는게 베스트잖아. 그래서 사람이 안해도 되는 테스트는 최대한 다 자동화 전환을 하는 것이 중요하게 여겨져. 사람이 안 해도 되는 테스트'만' '예외없이' 자동화해라.

Q.
자동화하는 것은 혹시 애용하는 툴이나 라이브러리가 있니?

A.
울팀은 그냥 파이썬 스크립트+셀레니움으로 쌩으로 짜고, 다른팀은 uipath라고 rpa 툴 같은거나 암튼 뭐 툴은 가지각색으로 저마다 자기쓰고싶은거 쓰느듯