티스토리 뷰

XVIII02.pdf

원문 PDF

테스터로서 익혀야 되는 기술에 대한 아티클 입니다. 출처는 여기로 미국 캔자스 시티 QA모임이네요. 우리도 언젠가는 시도 별로 모임이나 협회가 결성되는 날이 올까요? ^^

Developing Your Skills as a Tester

by Jack Cook

Translated by 쥔장

당신의 사고나 능력의 범위를 확장하기가 항상 쉬운 것만은 아니다. 당장 십여개의 테스팅 프로젝트를 맡고 있으면, 당신의 관리자는 당신의 장기적인 커리어 목표보다는 현재 프로젝트의 마일스톤에 더 관심이 있을 것이다. 당신의 회사는 당신의 전문성을 높이도록 도와주기 보다는 제품의 출시 일자를 맞추기 위해 더 매진할 것이다.
따라서, 일반적으로는 좁은 틀을 벗어나 더 넓은 세상을 보거나 더 진일보 하기 위해 필요한 것들을 얻는 것은 당신의 몫이다.

이러한 것을 하기위한 한 가지 방법은 개발자의 경험을 가지는 것이다.

이게 당신의 소관을 벗어난 일이라고? 전혀 그렇지 않다. 그런 경험을 가지게 되면 더 훌륭한 테스터가 될 수 있을 것이라고 내가 보증한다. 소프트웨어 개발 영역으로 당신의 지식을 확장하는 것은 테스팅 스킬을 향상시키는 것 뿐만 아니라, 회사 안밖으로 당신의 가치를 높이게 될 것이다. 개발자와 (필요하다면 경쟁도 하면서) 함께 일하는 법을 알게되는 것은 당신의 경력과 자긍심에 도움이 될 것이며, 더 많은 직무 경험을 습득하게 한다. 자 이제 여러 가지 이득에 대해서 얘기해 보자.

신뢰

신뢰는 당신이 성공하는데 있어 매우 중요한 요소이다. 개발과 테스팅 두 가지 영역의 경험을 모두 가지도록 하라. 나는 개발자들이 일반적으로 어떤 방법을 통해 테스터가 개발 경험이 없는지 알아채는지 알고 있다. 옳든 그르든 간에, 이러한 인식은 존재하며, 개발자와의 신뢰를 구축하기 위한 목적으로 이용해야 한다.

당신이 지난 번에 갔던 "건물 시공 업체"에서 해당 분야의 전문가중 한 명과 집의 건축, 설비, 조경 또는 도배에 대해서 얘기했었다고 생각해보자. 당신은 그들의 설명을 열심히 들었다. 그런 다음, 그 내용에 대해서 논쟁을 하려고 그들의 업무 경험에 대해서 질문을 했고 그들이 전혀 경험이 없다는 사실이 명확해 졌다. 그들이 신용을 잃게 된건가? 당신은 그들 자신이 잘 알고 있는 내용을 말하고 있다고 아직도 확신할 수 있나? 그들이 단지 설명만을 했을 뿐이거나, 더 나쁜 경우는 내용을 그냥 지어낸 것일까?

당신은 경험이 있는 누군가를 찾고 있는 것이 아닌가? 개발자가 코드를 보면서 테스터가 발견한 버그에 대해서 얘기하고자 할 때도 비슷한 역학 관계가 발생한다.
만일 개발자가 코드 섹션을 당신에게 보여주는 경우, 당황한 기색없이 그것을 이해할 수 있어야 한다. 얼마나 자주 내가 개발자에게 의심스러운 부분의 코드에 대해서 질문을 했는지, 그들이 내게 코드를 설명하는 동안 문제를 찾게 되었는지 놀랄 지경이다. 이렇게 직접 대면하는 대화는 장래에 대단한 도움이 될 수 있는 좋은 관계와 신뢰를 구축하는 아주 좋은 방법이다.

동일한 언어로 말하기

소프트웨어 개발에 쓰이는 특수한 용어들은 항시 바뀐다. 심지어 테스팅 중에 있더라도 당신은 그것을 계속 알고 있어야 하는데, 개발자와 대화를 하려면 그들의 용어로 말해야 하기 때문이다. 당신은 객체, 클래스, 상속, 다형성, 확장 클래스, 변수, 구조, IDL(Interface Definition Language), API, orb, base class, relationships 같은 것들을 개발자가 쓰는 방식으로 사용할 수 있어야 한다.(모든 사람은 전문 용어에 대해서 많이 알고 있어야 하는데, 나는 예전에 오라클에 저장된 프로시저가 "코드"라는 사실을 개발자 조차도 이해하지 못했던 회사에 대해서 놀랐던 적이 있다.) 만일 개발자가 "개발자의 언어"로 말하기 시작할 때 우리의 표정에 생기가 없어진다면, 테스팅에 도움이 될 수 있는 중요한 방향키나 실마리를 놓치게 된다.

문제가 가진 영향력을 평가하기

문제가 어디에 있을까? 수정에 따른 영향력은 무엇이 있을까? 다시 한 번, 개발자와 테스터의 눈을 통해서 현상을 보게되면, 두 가지 관점 사이의 접점을 볼 수 있게 된다. 당신이 수정의 영향력을 평가하기 위해 코드를 들여다 보게 되면, 수정이 라이브러리, 기본 클래스 또는 "Common" 코드에 영향을 미친다는 사실을 알게 될 것이다. 때때로 개발자들은 그들이 선호하는 기능이나 함수에 미치는 영향만을 살펴보고, 커다란 재테스트 이슈를 발생시킬 수 있는 "Common 코드"의 변화를 인식하지 못한다. 개발 영역에 대해서 잘 이해하고 있는 테스터라면 수정에 대해서 가장 잘 알고 있을 수 있으며, 특히 테스팅 싸이클의 후반부에서 테스트가 필요한 수정에 따른 부수적인 영향력을 잘 알게 된다.

문제를 찾는데 도움을 주기

만일 당신이 기능적인 이슈를 구별하고 문제에 영향을 미치는 코드를 바로 지적할 수 있다면 개발팀의 동료는 당신을 가치있게 평가할 것이다. 당신이 자연스럽게 코드를 검토하고 친숙하다면, 문제가 존재하는 영역을 찾아 낼 수 있을 것이다. 이것은 개발자의 시간을 줄여주게 되는데, 그들이 문제를 재현하지 않아도 되기 때문이다.
(나는 개발자와 친밀하게 일하기를 권한다. 수정이 되었을 때 바로 테스트가 될 수 있도록 준비하라. 이것은 테스트나 릴리즈 과정을 빠르게 할 뿐만 아니라, 개발자와의 신뢰를 쌓도록 해준다.)

문제를 잘못 지적하지 않도록 하라

당신이 코드를 이해하고 있다면 혼란을 피할 수 있다. 나는 테스터가 문제를 발견하고, 그들이 생각하기에 문제의 코드를 만들었을 것으로 보이는 개발자에게 가서, 약간의 논쟁을 한 후 누군가 다른 사람의 문제를 발견하는 것으로만 끝내는 것을 아주 많이 보아왔다.

나는 Rod로 불렸던 테스터와 일했던 기억이 있다. 그는 대단한 경력을 가지고 있었는데, 디자인과 개발 경험 뿐 아니라, 하드웨어와 소프트웨어 아키텍쳐의 경험을 가지고 있었다. 어떤 어플리케이션을 테스트 하던 중에 그는 테스트 스위트를 초기화 했고, 문제를 찾아냈다. 개발자로서의 그의 만족감은 높아서, 개발자에게 문제를 얘기하기 전에 코드를 점검해 보기로 마음먹었다. 결국 수정해야 하는 코드를 찾아 냈다. 저장된 프로시저로 부터 어떤 값을 리턴해야 하는 코드를 찾았기 때문에 그는 DB 관리자에게 얘기했고 DB 관리자가 변경된 프로시저로 테스팅 DB를 업데이트 하지 않았다는 사실을 발견했다. 그는 업데이트를 요청했고 이후로 모든 것이 정상으로 작동했다.

여기서 시간이 절약되었다는 점을 주목하라. 우리가 보기에는 개발자가 문제를 확인했을 경우 Rod보다 시간이 네 배나 더 들었을 것으로 추정되지만, Rod는 문제를 해결하는데 2시간 정도 밖에는 걸리지 않았다. Rod와 그 개발자의 사이의 신뢰는 상승했다. 사실 나는 Rod에게 코드를 테스트 해보라고 요청했다! 그것이 당신이 원하는 친분관계인 것이다.

코드 또는 테스트 스위트의 크기가 변경되었을 때 알아 채기

당신이 개발자가 하는 것처럼 어떻게 코드를 보아야 하는지 알게 될 때, 코드의 변경이나 코드 상태에 대해서 잘 알 수 있게 된다. 소스 코드 제어 툴을 이용해서 소스 코드를 보면, 실제적으로 어떤 것이 변경되었는지 알게 된다.(가끔 버그만으로는 모든 변경 사항의 영향을 설명할 수 없을 때도 있다.) 나는 개발자가 "소소한" 문제를 수정했지만 대단히 심각한 변경을 초래한 것을 보아왔다. 단지 리포팅 툴에만 의존한다면, 무언가 중대한 변경 사항을 놓칠 위험성이 존재한다. 물론 개발자가 변경 사항에 대해서 조언해 주어야 한지만 이러한 프로세스는 테스트되지 않아서 놓칠 가능성이 있는 변경 사항을 줄일 수 있게 한다.

"코드"를 어떻게 작성하는지 알게되면 문제를 피할 수 있게 되거나 필요 이상으로 테스트 하는 것을 방지할 수 있게 한다. 예를 들어 보겠다. 한 기능을 담당하는 함수가 한 범위의 숫자를 받아들이는데, 일반적으로는 이 숫자들이 동치 클래스의 방법으로 구성된다는 가정을 할 수 있고, 따라서 당신은 경계 조건값과 중간값 중 하나만 테스트 하게 될 것이다. 따라서, 테스트 케이스는 7가지가 되는데, 최소값-1, 최소값, 최소값+1, 중간 값, 최대값-1, 최대값, 최대값+1 이다. 코드가 만들어 낼 수 있는 모든 변화들을 이해하기 위해서는 어떻게 코드가 작성되었는지 알아야 하며, 당신은 테스트 케이스를 다섯개로 줄이거나 모든 값들을 테스트 해야 할 수도 있다. 이것이 정말로 가능하냐고? 물론 그렇다!

테스트의 자동화

특히 개발 경험은 자동화 테스트에 가치가 있는데 대부분의 시스템은 자동화를 위해서 특정한 유형의 프로그래밍을 요구한다. 대부분의 소프트웨어 시스템은 아주 약간의 인간의 개입이 필요한 자율적인 프로세스로 구성되어 있다. 이런 시스템의 테스팅은 프로세스가 올바르게 동작하고 있는지 확인하기 위해서 항상 프로그램을 작성해야
한다. 개발 경험은 자동화 툴이 사용하는 "언어"에 대해서 쉽게 배울 수 있도록 해준다.

리더쉽

역사적으로, 리더쉽의 기회들은 개발 경험이 있는 테스터에게 더 많이 주어진다. 당신은 테스팅 디자인을 보조하거나, 테스트 케이스/시나리오를 리뷰하고, 테스트 코드를 리뷰하며, GUI가 없는 소프트웨어를 테스트 할 수 있게 조언하는 과정을 통해 테스터를 관리 할 수 있다.

개발 경험을 얻기

새로운 전문적인 스킬을 개발하는 가장 손쉬운 방법은 관리자를 지원하는 것이다. 그것에 도전하기 전에 당신이 이루고자 하는 것과, 그 이유 그리고 어떻게 이루려고 하는지에 대해서 머리 속으로 그려본다. 왜 이런 것이 회사에 도움이 되는지에 대해서 설명할 수 있어야 한다.(예를 들어, 업무 영역이 넓어 지면 테스팅이 향상 될 수 있다던지...) 만일에 관리자가 당신을 지원한다면 그대로 진행하면 된다. 그렇지 않다면, 다른 방법을 찾아야 한다. 어떤 쪽이던 간에 당신이 테스팅 커리어를 쌓길 원한다면, 개발 경험을 추구하는 것은 값어치가 있을 것이다.

나의 팀에서 일하는 사람들은 이해를 높이기 위해서 해당 소프트웨어를 작성한 개발자에게 질문하고, 몇 개의 과정을 수강하며(야학이나, 내부 강의 또는 교육 센터), 테스트 그룹 내부에서 테스트 툴을 만드는 것 같은 소규모의 프로젝트에 투입되며, 결국에는 제한적인 기간 동안이지만 개발 조직에서 일하는 방식이다.
마찬가지로 당신이 몇가지 방법론들에 다소 친숙해졌다면, 개발자 컨퍼런스에 참석하는 것도 역시 도움이 된다. 개발자와 같이 앉아서 그들이 하는 토의에 참석하고 회의에서 무언가 발언하는 것은 매우 가치가 있는 일이다.

훌륭한 테스트 프레임워크를 디자인할 수 있고, 툴을 개선하거나 개발해서 테스트 팀의 퍼포먼스를 개선하며, 어떻게 개발자가 소프트웨어를 만드는지 이해하면 당신이 테스트 팀과 회사에 매우 가치가 있는 존재가 될 것이라는 점을 고려하라.
나는 이러한 능력을 보유하고 있는 선임 관리자를 알고 있는데, 같은 경력을 가진 개발자보다 더 많은 급여를 제공했었다. 이러한 다양한 경험을 가진 인원은 일자리를 찾기가 더 쉬운데, 그러한 경력이 다양한 일자리를 선택할 수 있게 한다. 숙련된 테스터/개발자가 되려면 몇가지 분야에 집중할 필요가 있고, 2-3년의 경력을 쌓아야 한다. 하지만, 당신이 이러한 길로 접어들었다면, 당신이 생각한것 보다 더 빨리 당신의 가치가 상승하게 될 것이다. {끝}

댓글
댓글쓰기 폼
공지사항
Total
394,963
Today
7
Yesterday
27
«   2018/11   »
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  
글 보관함