문성준의 단단해지기

오랜만에 10번째 에피소드입니다.

오늘은 일하면서 들어본 이상한 단어와 웃픈 에피소드에 대해서 말해보려고 합니다.

#1 아삭하게 해주세요.

제가 아웃소싱에서 일할 때였습니다.

고객사에서 급한 일감이 들어왔는데요.

언제까지 해야 하는지 물어봤는데

돌아온 대답은 "아삭하게"였습니다.

아삭하게? 뭘 아삭하게 하라는 거지?

어느 지역 사투리지??

야무지게 하라는 건가???

평소 사투리를 쓰시던 분이셔서 

어느지역 사투리인지 검색을 하다가

ASAP이라는 단어를 검색하고 

깊은 탄식을 내뱉은 적이 있습니다.

As Soon As Possible

빨리빨리 / 가능한 (최대한) 빨리라는 뜻입니다.

본래 1900년대 중반에 미군에서 사용되던 단어이고,

미군에서 퍼져 보통 사람들 사이에도 적잖게 사용되는 단어라고 합니다.

에이에스에피라고 하거나 글자를 그대로 읽어서 에이쌥, 아삽이라고 읽기도 합니다.

사람마다 다르게 말한다고는 하지만

 다만 영어권 원어민이 “아삽”이라고 읽는 경우는 없다고 합니다.

즉, 고객사에서는 가능한 빨리 업무를 수행해 달라고 했었지만

저는 야무지게 하라는 뜻으로 이해했던 그런 해프닝이 있었습니다!

#2 tl;dr로 말씀드릴게요~.

오늘 있었던 일입니다.

앱 배포 때 minor 한 버그를 포함시켜야 할지 말지를 논의하고 있었습니다.

제가 답변 내용을 크게 보지 않고

변경점이라는 포인트에 집중하다 보니 

어떤 의미인지 다시 여쭤봤습니다.

저는 tl;dr이

채팅으로 대화를 했기 때문에

한/영 키를 잘못 누른 상태에서 입력하신 줄 알았습니다.

역시나 검색해 보니 

아래와 같이 나왔습니다.

TL;DR

TL;DR, 풀어서 "too long; didn't read"(너무 길어서 읽지 않았다)라는 뜻입니다.

응답이 되는 어떠한 텍스트가 그 길이 때문에 무시되고 있다는 것을 말하는 인터넷 속어입니다.

인터넷에서 글이 지나치게 길어 이를 비난하거나 글을 줄이는 것을 조언하기 위해 쓰는

'생략'과 흡사한 단어입니다.

즉, 두괄식으로 요점만 말해주겠다.라고 이해할 수 있겠습니다.

TL; DR로 한번 표현을 해보면

TL;DR : 이번 배포에 포함시키지 말죠! 
(뒤의 내용~~~ )

이런 식으로 응용해 볼 수 있겠네요.

오늘은 일하면서 처음 들어본 생소한 단어에 대해서 

재밌게 풀어보는 시간을 가졌는데요

일할 때 처음 듣는 단어라고 너무 거부감을 가지거나 놀라지 마시고

적극 활용한다면 지식도 얻고 업무처리도 빠르게 할 수 있습니다.

그럼 이만!

2019년 3월 7일에 작성한 제 게시글 중 가장 인기가 많은 게시글 중 하나인 

https://ddanx2.tistory.com/96

실무에서 쓰이는 ad-hoc testing, 그리고 random testing에 관련된 글이 있습니다.

이때는 QA 경력이 1년차일때, QA 보다는 Tester에 가까운 입장에서 쓴 글이었습니다.

그러나 지금은 하나의 part를 관리하는 part manager 로써 Ad-hoc testing에 관한 제 생각을 써보려고 합니다.

그때 제가 Ad-hoc testing에 대해 마지막으로 제 생각을 적었는데요 한번 보겠습니다.

이때 제가 쓴 글을 하나하나 분석해보겠습니다.

제 생각은 프로젝트의 테스트 케이스 수행을 마무리 한 단계에서 예상치 못한 결함을 도출할 때는 Ad hoc, Random testing 둘 다 진행해도 좋다고 생각됩니다.

이 때는 Ad-hoc testing의 매력을 느끼지 못한 상태에서 단순 사전적 의미로 분석하고 제 생각을 적었었는데요.

사실 이때는 Tester의 입장에서 작성해서 둘 다 진행해도 좋다고 썼습니다. 

두 가지 테스트 방법을 동일선상에서 생각했기 때문이죠.

그러나 적재적소에 맞는 Testing 방법이 있습니다. 본인이 판단하기에 Ad-hoc Testing이 필요한 경우에는 Ad-hoc testing을 진행하면 되고, Random Testing 이 필요한 경우에는 Random Testing을 진행하면 됩니다.

다만 제가 하고자 했던 말의 요점은 Ad-hoc Testing 안에 Random Testing 이 포함된다고 느꼈기 때문에 저런 워딩이 나왔다고 생각됩니다.

그러나 기간이 촉박한 프로젝트에서는 모든 Testcase를 수행한 이후 Ad hoc testing 만 진행하는 게 맞다고 생각됩니다.
기간이 촉박하고 일정을 미룰 수 없을 때, Random testing을 통해 임의의 값을 입력하여 결함을 찾아냈을 때
결함 보고까지의 범위를 측정하는 시간이 많이 소요된다고 생각합니다.

이 부분을 작성한 이유는 제가 업무를 할 때 1~2달 사이의 프로젝트 업무를 많이 진행하였습니다.

3일 정도의 기획서 리뷰 기간을 가진 후 5일 정도 Testcase를 작성했습니다.

명세 기반의 Testcase를 작성하다 보면 느끼는 점이 많은데요.

사실 명세서는 유저의 요구사항이나, 유관부서의 요구사항이 반영되어있다고 하더라도 

소프트웨어의 품질을 높이는 데에는 한계가 있습니다.

어떻게 보면 사용설명서 같은 느낌으로 정해진 Step과 정해진 Result 가 나오기 때문입니다.

그래서 정해지지 않은 Step으로 진행하였을 때 소프트웨어 특성상 예기치 못한 Result 가 나오기 때문에

Ad-hoc testing을 진행해야 한다고 생각했던 것 같습니다.

그리고 이 생각을 뒷받침하는 근거로 실제 제가 근무하는 환경에서 Ad-hoc testing으로 나온 critical 한 이슈가 많았기 때문에 더욱더 그렇게 생각한 것 같네요.

그리고 Random testing의 정의를 봐도 일정이 촉박하면 테스트 케이스를 설계하여 문서화할 시간도 없다고 생각됩니다.
그래서 Ad hoc testing 만 단독으로 진행할 때는 프로젝트의 규모가 작아야겠죠..?

이 부분의 생각은 3년이 지난 지금 많이 바뀌었습니다.

2019년에 간과했던 부분은 Ad-hoc Testing을 진행할 때, Tester 나 QA 엔지니어의 역량이라는 필수 요소를 배제했었던 점이 가장 크게 작용했는데요.

Ad-hoc testing을 매력적으로 보는 이유는 보이지 않는 "역량"에 따라 결과물이 달라지기 때문입니다.

Part manager가 된 지금 QA Team을 구성할 때 제일 먼저 보는 것이 구성원의 경력입니다.

예를 들면,  신입직원, 1년 차, 3년 차, 5년 차 총 4명의 테스터가 있다고 한다면, 저는 신입직원, 5년 차의 Ad-hoc testing 의 결과에 주목할 것입니다.

왜 신입직원의 testing 결과를 주목할 것이냐 의문을 가지실 수 있는데요.

Testing 경력이 얼마 없기 때문에 고정관념이 없고, 예외적인 시도에 대해 열려 있기 때문입니다.

그리고 5년차의 Testing을 주목하는 이유는 베테랑 테스터의 실력을 믿기도 하는 것이지요.

물론 경력이 테스팅 역량을 대변해 줄 수 있는 수단은 아니지만 위험성을 줄일 수 있기 때문에 업무 분배에 참고하고 있습니다.

그래서 제가 하고 싶은 말은

"역량"이 높은 사람은 일정이 촉박해도 Testcase 나 CheckList 설계가 가능하며 동시에 Testing 도 무사히 마칠 수 있습니다.

그래서 Ad-hoc Testing 만 단독으로 진행할 필요가 없다고 생각이 바뀌었습니다.

아래 관련 게시글을 보면서 더 이어나가겠습니다.

https://ddanx2.tistory.com/125

제가 Flow Chart 기반으로 Test Case를 작성하는 방법에 대해 공유한 적이 있습니다.

주로 기획문서가 없는 소프트웨어에 대해 Testing을 진행할 때 사용하는데요.

옛날에는 기획문서가 없는 소프트웨어에 대해 Ad-hoc Testing으로만 진행될 수 있다고 말했지만

이제는 역으로 기획문서가 없어도 소프트웨어를 보고 Flow Chart를 작성할 수 있고, 그 Flow Chart 를 기반으로 Test case , Scenario 등 여러 문서를 작성할 수 있는 실력을 갖추었습니다.

그래서 2019 년과는 다르게 Ad-hoc Testing 만 단독으로 진행할 필요가 없다고 말하고 싶습니다.

결국 지금 와서 생각해보면 2019년의 제 QA 역량과, 2022년의 제 QA 역량이 다르고 그만큼 성장했기 때문에 생각이 바뀌었다고 볼 수 있습니다.

이제 또 3년 뒤에 저는 해당 글을 다시 가지고 와서 2025년에 작성하는 Ad-hoc testing에 대한 나의 생각 이런 식으로 포스팅을 할 수도 있겠네요.

아무튼 밤에 두서없이 쓴 글이긴 하지만 읽어주셔서 감사합니다.