깍돌이

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

기술 포스팅은 아니고 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도 있고 밀접한 관계로 일을하기 때문에 일을하면서 내가 이 제품의 담당자이며 관련자다 라는 책임을 가지고 이슈없는 배포 깔끔한 배포가 이루어질수 있도록 더욱 노력해야 할 것입니다.