<3> 소프트 스킬이 필요한 이유
QA for Beginners
QA의 관점이란
어느 조직이든 주니어일 때는 주어진 일을 잘 수행하기만 하면 되는 업무를 맡는다. 그리고 시니어로 갈수록 프로젝트 단위, 팀 단위, 조직 단위의 관리를 요구받는다. 즉, 전자는 나무를 볼 줄 알아야 하고, 후자는 숲을 볼 줄 알아야 하는 것이다. QA도 마찬가지다. 다른 점이 있다면, QA는 특히 다른 조직보다도 숲을 보는 능력을 단기간에 요구받는다.
이제 막 QA에 뛰어들어 TE 롤을 수행할 때에는 나무 분석을 잘하기만 하면 된다. 결함인지 아닌지를 판단하고, 그 밖의 결함이 더 있는지 방법을 바꿔보며 다시 해보는 집요함이 중요하다. 그런데 이 정도의 업무를 수행하는 데에는 경험의 차이가 있을 뿐, 특별한 지식이나 자격이 필요하지 않다. 다시 말해 내가 아니어도 쉽게 다른 누군가로 대체할 수 있다는 것이다. 채용 웹사이트에서 QA 주니어 포지션을 찾아보면 80%는 신입 또는 2년 이하의 경력을 보유한 사람을 원한다. 나머지 20%는 2년 안팎인 3년 혹은 1년의 경력을 주니어로 쳐준다. 이 말은, 당신이 테스터 수준의 능력 만으로 살아남을 수 있는 최대 기간은 고작 3년이라는 뜻이다. 이직할 생각도 없고, 커리어 욕심도 없으며, 능력을 키워야 할 필요성을 못 느끼겠다면 조바심을 갖지 않아도 된다. 하지만 당신의 통장은 당신의 몫까지 조바심을 갖고 있을 것이다.
숲을 보는 능력이란 것은 관점을 가져야 한다는 것을 뜻한다. 어떤 명세가 있다고 할 때, 이를 보는 기획자, 개발자, QA의 관점은 다르다. 예를 들어 무료 일러스트 나눔 커뮤니티의 다운로드 프로그램에서 여러 파일을 다운로드할 때, 특정 구간에서만 전체 진행 상태의 표기를 ‘진행 중’으로 표기하려 한다고 하자. 그러면 각 담당자들은 다음과 같이 받아들일 가능성이 높다.
기획자
진행 상태가 낮은 구간과 높은 구간에서는 구체적인 진행률을 보여주는 것이 좋겠다. 사람들의 인내심이 크지 않다는 걸 고려했을 때, 10~90 구간은 구체적인 진행률을, 나머지는 약간의 재미를 넣어 0~10은 ’ 택배 상차 중…‘, 90~100 구간은 ’택배 하차 중…‘이라는 문구를 보여주자.
개발자
다운로드 프로그램에서 다운로드를 시작할 때 파일의 전체 개수를 체크해서, 개별 항목들의 진행률을 종합한 전체 진행률의 산식을 구현하고 이 산식으로 도출된 값이 0~10 또는 90~100일 때만 특정 문구를 보여주도록 하자.
QA
다운로드 중 일부 파일이 취소되거나 실패하여 목록에서 제외되면, 진행률도 즉시 갱신될까? 새로 다운로드할 파일이 목록에 추가된다면? 진행률이 마이너스 또는 100이 넘는 값으로 노출될 수 있을까? 진행률이 100이 되었는데도 ’택배 하차 중…‘이라는 문구를 보여주면 어색하지 않을까?
이처럼 기획자는 기능을 구체적으로 정의하고, 개발자는 기능이 동작할 수 있는 상황을 가정하고, QA는 기능이 동작하지 않는 상황을 가정한다. QA의 관점을 갖기 위해 어떤 것이 필요할지 보이는가?
QA에게 필요한 것
이론적인 공부도 물론 필요하다. 하지만 QA는 AI와 같은 신기술이 시간 단위로 쏟아져 나오는 분야가 아니기에, 관심을 갖고 일주일만 공부해도 실무에서 쓰이는 용어나 기법들을 못해도 50% 이상은이해할 수 있다. 문제는 소프트 스킬이다. 이것은 지식의 영역이 아니다. 경험의 영역이고 이해의 영역이며 추상의 영역이다. 특히 개인적으로 QA에게는 인사이트(insight, 통찰력), 커뮤니케이션, 히스토리 관리가 가장 중요한 능력이라고 생각한다. 위의 예시에서도 보았듯, 위와 같은 의심을 하기 위해서는 인사이트가 필요하며, 과거에 등록된 이슈나 관련 논의가 이루어진 적이 있었는지 히스토리 검토가 필요하고, 이해관계자와 논의하기 위한 커뮤니케이션 스킬이 필요하다. 능숙하게 다루는 순간 강력한 무기가 될 이 세 가지에 대해 나의 생각을 말해보겠다.
인사이트
인사이트를 구성하는 요소는 세 가지가 있다. 이해, 경험, 상상이다. 세 요소를 적절히 조합했을 때본인만의 인사이트로 예측과 판단을 할 수 있다. 놀랍게도 지식은 인사이트를 구성하는 핵심적인 요소가 아니다. 지식은 인사이트로 도출된 의견에 대해 객관적인 근거를 더해줄 뿐이다. 개인적으로 QA는 기획의 관점과 개발의 관점을 모두 갖고 있어야 한다고 본다. 그리고 기획과 개발 부분에서 인사이트를 키우기 위해서는 다음의 관점이 필요하다고 생각한다.
기획
프로덕트의 방향과 목표
기획자나 PM(Product Manager, 프로젝트 총괄 리더라고 이해하면 된다)의 역할이 아니냐고 반문할 수도 있다. 그러나 QA가 이것을 이해하는 것은 중요하다. 어떤 것을 ‘꿰뚫어 본다’는 것의 의미는, 흐름과 본질을 파악하고 있다는 의미이다. 우리가 출시하려는 프로덕트의 목표가 무엇이고, 어떤 가치를 제공할 것이며, 이를 위해 어떤 의도로 이번 빌드를 릴리스하려 하는지를 이해하면 기능들의 필요성, 효율성 등을 따져보고 개선할 대상을 특정하기가 분명해지기 때문이다. 즉, 가치판단이 용이해진다.
현재까지의 히스토리
흐름을 이해하는 키는 역시 히스토리이다. 대부분 백지상태의 새로운 프로젝트보다는 어느 정도 안정화된 프로젝트에 투입되는 경우가 많기 때문에, 지금까지 어떤 기능들이 변경되고 추가되었는지를 먼저 파악해야 한다.
이번 기획의 의도
당장 눈앞에 놓인 QA 대상이기 때문에 가장 이해의 필요성이 와닿을 것이다. 무엇을 개선하려 하고 왜 변경되는지에 관심을 두어라. 기능이 수정되거나, 추가되거나, 삭제된다면 잠재 결함 또한 그렇게 될 수 있다.
앞으로의 개선 계획
Confluence Wiki나 Figma와 같은 기획/디자인 툴, 또는 리뷰를 하다 보면 앞으로의 일정에 대해서도 어느 정도 알게 될 것이다. 이것을 프로덕트 방향성의 척도로 삼아라.
개발
코드 구조
개발자의 도움을 받아도 되고, 본인이 틈틈이 파악해도 좋다. 코드 구조를 볼 수 있는 팀에 속해 있다면 대강의 구조를 이해하는 것이 큰 도움이 된다. 기획서의 기능을 구현하는 데 어떤 애로사항이 있을지 예상할 수 있으며, 이를 공수 산정 또는 결함 예측의 근거로 삼을 수 있기 때문이다. 또한 여건이 된다면 Whitebox Testing과 같은 테스트를 하는 데에도 큰 도움이 된다.
이슈 히스토리
어떤 결함을 발견했다면 BTS에서 기존에 동일한 내용으로 이슈가 등록된 적이 있었는지 확인하고, BTS가 구축되지 않았다면 구축하기 전까지 별도로 이슈 히스토리 관리를 하는 것이 좋다. 어느 순간부터 이슈의 경향성을 발견할 수 있을 것이고, 경향성이 보이는 순간 Exploratory Testing의 폭도 넓어질 것이다. 경향성이 존재하는 이유는 다음의 소프트웨어 원칙이 적용되기 때문이다.
결함은 집중된다.
기능 동작
기획에 명시된 부분은 아니지만 B/E에서 직접 처리해 주거나, Beta 환경에서만 적용되는 부분이 있다. 테스트앱을 재로그인할 때 꼭 초기화 버튼으로 앱을 초기화해주어야 한다거나, 한 번 메시지를 보내면 5분 후에 다시 보낼 수 있는 등이 그러한 경우다. 여기에는 의도적인 검증 시간 단축 추구 또는 코드 구조 상 한계 등 다양한 원인이 있는데, 이러한 부분들을 파악하고 있으면 추후 결함 여부를 판단할 때 유용하게 작용한다.
태생적으로 통찰력이 부족하다고 느낀다면, 위의 예시들을 적용하여 본인만의 경험 데이터베이스를 쌓아가라. 경험 하나하나가 나만의 통찰력을 갖게 한다.
커뮤니케이션
생각이 동기화되는 기계가 발명되어 상용화되지 않는 한, 커뮤니케이션의 필요성은 사라지지 않을 것이다. 좋은 커뮤니케이션이란 목적이 분명하고, 핵심을 요약할 수 있어야 하며, 이를 빠르게 공유할 수 있는지에 달려있다고 생각한다.
커뮤니케이션을 할 때는 얻고자 하는 것을 얻기 위한 분명한 목적이 있어야 한다. 밥을 먹으면서, 버스를 타고 가면서, 술자리에서 나올 법한 주제를 다루는 것이 아니다. 우리에겐 대화 자체를 즐기며 모든 가능성에 대해 토론하는 열린 결말이 필요한 것이 아니라, 단 하나의 결론이 필요하다.
”텍스트 필드에 숫자 입력이 가능할까요?“
라는 질문을 받았다면, 뭐라고 대답할 것인가?
“네, 숫자 입력 가능합니다.”
또는
“아뇨, 문자도 입력 가능합니다.”
와 같은 답변을 하지 않을까? 그렇다면 이 문자는 어떤 문자를 말하는 것일까? 숫자와 문자 외에는 입력이 불가능할까? 다시 질문할 내용이 한두 가지가 아니다. 그 이유는 분명한 목적을 가진 질문이 아니기 때문이다. 숫자 입력을 물어보는 근본적인 이유가 무엇인가? 숫자 입력 여부 자체가 궁금한 것보다는, 유효성을 어느 정도까지 받고 있는지를 확인하려는 것이 아닐까? 이번엔 다음과 같이 질문해 보자.
“텍스트 필드에서 어떤 값들에 대해 입력이 가능할까요?”
또는
“텍스트 필드에서 유효성 체크를 어디까지 하나요?”
어떤 답변이 떠오르는가?
“숫자, 문자, 그리고 … 의 입력이 가능합니다.”
와 같은 답변을 하지 않을까?
친절한 기획자라면 여기에 특수문자, 공백, 공란, 심지어는 보안성에서도 확인을 도와줄 것이다. 단, 친구와 채팅을 할 때처럼 짧은 글로 말을 이어가는 습관을 버리고, 장문이 되더라도 한 번에 말을 전달해라. 대뇌 생리학자들의 실험에 의하면 인간이 연속적으로 집중력을 유지할 수 있는 시간은 60~90분이며, 그중에서도 뇌의 활동이 가장 활발한 시간은 처음의 10분이라고 한다. 그리고 업무 중에는 수많은 회의, 알림, 동료들의 요청 등으로 방해받아, 이 60~90분의 시간조차 장담할 수 없다. 간단히 말해, 상대방은 당신과의 대화에 집중력을 낭비하며 많은 시간을 소비할 수가 없다는 말이다. 하나의 글에 의미 있는 최대의 정보를 담아 전달하라.
정확한 질문이 정확한 대답을 유도할 수 있고, 정확한 질문은 그 목적이 분명할 때 떠오른다. 이 질문을 함으로써 어떤 대답을 기대하는지를 분명히 하고, 기대하는 답변을 듣기 위해 내가 하려는 질문이 적절한지를 재고해 보라.
질문을 다듬는 약간의 노력을 들였을 뿐인데 한 번의 질문으로 90% 이상의 원하는 답을 얻었다. 단순 산술로 질문 1개 당 소요되는 시간이 일정하다고 가정한다면, 비효율적인 4개를 효율적인 질문 2개로 줄이기만 해도 50%의 시간을 절약하는 셈이다. 이 절약한 시간은 QA의 시간뿐 아니라 조직 전체의 시간이 되어, 조직 전체의 효율성을 증대시킬 수 있다.
정리
커뮤니케이션을 하고 난 뒤에는 논의한 내용을 정리해야 한다. 복잡한 사안을 논의할수록 확실하게 매듭을 지어야 한다. 그렇지 않으면 논의를 시작한 처음부터 가장 마지막의 대화 이력을 복기해야 하며, 상대방이 나와 다르게 이해했을 수도 있기 때문이다. 이렇게 되면 추후 이 주제와 연관된 다른 주제를 논의할 때, 근거로 들기가 어려워진다.
따라서 대화의 마무리가 ‘해결되었어요’, ‘확인해 주세요’와 같이 애매한 말로 끝났다면 반드시 아래의 내용을 정리한 뒤 상대방과 이해관계자(이를 알아야 할 동료들)에게 공유하라.
무엇을 확인했는지 정리하기(또는 현재 확인한 재현 결과를 정리하기),
앞으로 이 내용으로 인지하겠다는 것을 분명히 밝히기
이 내용을 알아야 할 이해관계자들에게 공유하기
공유의 목적은 내가 올바르게 이해했는지를 확인받고, 나와 이해관계자 모두가 같은 내용으로 이해했는지를 확인하기 위해서이다. 영화 아바타에 나오는 나비족이나 스타크래프트 1의 프로토스처럼 인간도 정신을 공유하는 능력이 있었다면 이런 번거로운 과정을 거치지 않아도 되었을 것이다. 하지만 우리는 독립적으로 사고하는 존재이기에, 다른 사람도 나와 똑같이 이해하고 있는지를 확인하기 위해서는 반드시 말이나 글로써 표현해야만 한다. 정확하고 간결한 표현으로 논의 결과를 정리하고 팀 전체에 공유하여 모두가 같은 내용을 인지할 수 있도록 하라.
히스토리 관리
히스토리의 대상은 다양하다. 앞에서 정리한 내용을 메모하는 것도 히스토리고, 해결된 이슈를 닫을 때 확인 내용을 구체적으로 작성하여 코멘트를 남기는 것도 히스토리다. 이렇게 명문화하고, 어떤 방식으로든 추후에 다시 찾아볼 수 있게 보관하면 그것이 곧 히스토리 관리다. 이렇게 해야 하는 이유는 근거를 마련하는 데 도움을 주며, 나의 기억력을 보완하고 인사이트를 향상해 주기 때문이다.
예를 들어 직전 버전에서는 로그인이 완료되면 팝업이 노출되었지만, 이번 버전부터는 팝업이 제공되지 않는 개선점이 배포된다고 하자. 그런데 이 내용이 기획서에는 없고, 기획자가 로그인과 관련된 이전 버전 이슈의 코멘트에만 언급했었다. 그리고 이번 QA기간에 확인 시 팝업이 노출되지 않아 이슈로 등록했더니 개발자는 기획서에 없는 내용이라며 이슈가 아니라는 코멘트를 남겼다.
이런 상황에서 히스토리 관리를 전혀 하지 않았다면 어떨까? 기억은 어렴풋이 나는 것 같은데, 어디에서 얘기했는지 모르겠고, 기획서 상으로 없는 내용인 것은 맞고… 근거가 없는데 무턱대고 개발자에게 만들어달라고 할 수도 없는 노릇이다. 물론 기획자를 불러 확인을 부탁하면 되지만, 언제까지 기획자를 부를 수는 없을뿐더러, QA에게도 기획 내용을 꼼꼼하게 챙기지 못한 책임이 어느 정도 있다는 것을 부정할 수는 없을 것이다.
그러므로 추후에 확인해야 할 내용이나 숙지가 필요하다고 판단되는 경우에는 해당 스레드의 링크를 별도 메모해 두거나 리마인드 알림을 설정해 두는 등 본인만의 히스토리를 구축하고 언제든 참고할 수 있도록 관리하는 것이 좋다.
숲을 보는 관점
결함 발견 능력이나 지식적인 면은 너무 도외시하고 당연한 이야기만 장황하게 늘어놓았다고 생각할 수도 있겠다. 하지만 하드 스킬만큼이나 소프트 스킬은 중요하다. QA의 효용성을 증명할 때 하드 스킬이 기술적인 면을 부각하는 데 중요한 역할을 한다면, 소프트 스킬은 효율적인 면을 부각해 팀의 윤활제 같은 역할로써 필요하다는 인식을 갖게 하는 데 중요한 역할을 한다.
그러나 QA 직무에 발을 들인 지 얼마 되지 않았다면, 하드 스킬의 경우 ISTQB Syllabus와 같이 배울 수 있는 경로가 많지만 소프트 스킬의 경우는 그렇지 않을 것이다. 인터넷상에서 접한다 하더라도 너무 장황해서 QA 업무 방식에 어떻게 적용할지 난감해져서, 결국 사수 또는 동료의 업무 방식을 유심히 관찰하거나, 구전동화처럼 전해 듣거나, 몸으로 직접 겪으며 능력이 오르는 경우가 많다. 일찍 숲을 보는 관점을 길러 본인만의 노하우를 가진다면 본인의 업무도 능숙해지고, 조직 전체의 효율성도 향상할 수 있을 것이다.
본인만의 소프트 스킬을 무기로 팀에서 꼭 필요한 존재임을 증명하는 QA로 성장하길 바란다.
