최근 들어 국내에서도 소프트웨어 테스터들에게 프로그래밍 소양을 요구하는 경우가 늘어나고 있다.
일부 회사에서는 개발 경력이 있는 테스터들을 우선해서 채용하기도 하는 모양이다.
개인적으로 테스터들에게 프로그래밍 능력이 필수는 아니지만, 최소한 코드를 읽고 해당 코드가 무슨 기능을 하는 것인지를 파악하고, 간단한 자동화 스크립트 정도는 작성할 줄 알아야 한다고 생각한다.
내가 그 수준이라는 이야기는 아니다. 나도 그 정도 수준이 되기위해 노력하고 있는 테스터 중의 한 사람일 뿐이다.
테스터들에게 프로그래밍 능력이 필요한가라는 문제에 대해, 팀 블로그에 같이 참여하고 있는 의한님(@OEHAN)이 소개해준 블로그 포스트 "Do testers need programming skills?"를 번역해서 올린다.
원 저자인 Peter L 님에게도 번역 및 포스팅에 대한 승인을 받았다.
테스터들에게 프로그래밍 스킬이 필요한가?
(Do testers need programming skills?)
Peter L
우리 소프트웨어 테스터들이 프로그래밍 스킬을 가질 필요가 있는가? 이 질문은 결코 새로운 것은 아니다. 이 질문은 이미 몇 년 동안 이렇게 저렇게 논의되어 왔던 것이다. 우리가 커뮤니티로서 이 문제에 대해 어떻게 해야 한다는 식의 합의점을 찾아야 하는 것인지는 잘 모르겠지만[1], 여기서는 일단 이 질문에 대한 나의 개인적인 의견을 개진해보자 한다.
이 질문에 한 마디로 대답한다면, ’아니오, 필요하지 않습니다. 하지만 분명 도움은 됩니다’ 정도로 할 수 있겠다. 테스터들이 최소한 코드를 작성할 수 있는 가장 기본적인 능력 정도는 가져야 한다는 생각에는 그럴만한 충분한 이유가 있으며, 여기에 대해 왈가왈부 할만한 논쟁거리는 없을 것 같다(만약 당신이 조금이라도 그렇지 않다고 생각한다면, 나는 충분히 그 이유를 들을 용의가 있다).
이 질문에 조금 더 길게 대답해보자. 서로 다른 수많은 종류의 테스팅이 존재하고 있으며 그 중 어떤 테스트는 강력한 코딩 스킬이 핵심적으로 필요한 항목 중의 하나다. 다른 테스팅의 경우에는 핵심적 이기까지는 아닐 수도 있다. 핵심적인지 아닌지의 여부는 많은 것에 따라 달라진다. 당신을 위해 테스팅 툴을 제작해주는 전문적인 툴 제작자가 있는가? 강력한 코딩 능력을 갖추고 있는 다른 팀원이 있어서 그를 당신의 업무에 투입할 수 있는가? 만약 그렇다면, 당신이 직접 코드를 작성할 수 없다는 것은 고민할 필요가 없는 문제다. 그럼에도 불구하고 여전히 직접 코드를 작성할 줄 알고, 다른 사람들이 작성한 코드를 이해하는 것이 가지고 있는 장점이 있다.
어떻게 코드를 작성하는지 알고 있는 것은 당신이 가지고 있는 테스트 스위트를 당신이 필요로 하는 대로(혹은 당신이 작업하는 방식에 맞추어 쉽게 응용할 수 있도록) 완벽하게 재단해서 사용할 수 있도록 해주거나, 일회성 스크립트를 다시 반복적으로 사용할 수 있도록 해 줄 것이다. 기본적인 정규 표현식에 대한 지식을 가지고 있는 것은 당신이 어떤 종류의 텍스트 편집 작업(text manipulation)이나 패턴을 찾아야 하는 작업을 수행해야 할 때(Awk와 Sed를 알고 있는 것도 도움이 된다) 큰 도움이 된다. 만약 당신에게 툴을 만들어주던 전문적인 툴 제작자가 교통사고를 당하거나, 당신에게 코딩과 관련해서 도움을 주던 사람이 아주 바빠서 당신을 도와주지 못한다면, 어떻게든 당신 스스로 이를 수행해야 할 것이다.
코드를 읽을 줄 아는 능력은 당신으로 하여금 프로그램이 수행하는 그 아래에서 무슨 일이 일어나고 있는지를 알게 해준다. 당신이 소스 코드를 체크아웃 할 수 있고 이를 제대로 읽을 수 있는 능력이 있다면, 당신은 당신이 수행하고 있는 테스팅을 변경시킬 가능성이 있는 사항들을 발견할 수도 있다. 이 코드에서 에러 리포팅은 어떻게 처리하고 있는가? 제대로 처리되지 않는 에지 케이스(edge-cases)를 발견할 수 있지 않은가? 이 질문에 대한 대답은 거의 대부분의 경우 ‘그렇다’이다. 그들이 사용하고 있는 난수 발생기(RNG; Random Number Generator)가 커스터마이징 된 것인가 아니면 프로그래밍 언어 자체에서 제공하고 있는 것인가? 아주 밀접한 관계를 가지고 있는 컴포넌트들이 유지보수(maintenance) 이슈나 테스트 용이성(testability) 이슈를 일으키지는 않는가? 이처럼 만약 당신이 다른 사람이 작성한 코드를 읽을 수 있다면, 당신이 물어보고 답할 수 있는 질문의 개수는 훨씬 더 많아질 것이다.
이는 또한 당신에게 적대적이거나 무관심한 개발자들이 당신을 신뢰하는 계기를 만들어 줄 것이다. 만약 당신이 그들의 언어로 이야기할 수 있고, 그들이 쓰는 말을 사용해 버그를 보고할 수 있다면, 일부 개념 없는 개발자들이 입에 담고 사는 “당신은 그저 테스터일 뿐이야!”라는 말을 입에서 쏙 들어가게 할 수 있을 것이다. 만약 당신이 프로그래머와 짝을 이룬다면, 그들이 운전을 하는 동안[2] 코드를 작성하고 그 길을 따라갈 수 있도록 해주는 유닛 테스트를 제안할 수도 있을 것이다(If you’re pairing with a programmer, you can code while they drive and you can suggest unit test that can help out along the way). 당신이 코드를 읽을 줄 안다면, 당신은 이미 작성되어 있는 유닛 테스트를 검토하고 그들이 정확하게 어떤 일을 수행하는지, 그리고 그것이 무엇을 체크하는지 알 수 있을 것이다. 이는 또한 당신이 이미 커버된 사항들을 점검하는데 드는 많은 시간들을 절약할 수 있도록 하고, 당신이 이미 점검한 사항들에 대해서 개발자들이 ‘네 우린 이미 그걸 점검했는데요’라고 말하는 것이 의미하는 바의 차이를 알 수도 있을 것이다.
이런 스킬들이 요구되는 곳도 있고 그렇지 않은 곳도 있다. 내가 알기로는 코딩 스킬이 없는 테스터들을 고용하지 않고, STE(Software Test Engineer)와 SDET(Software Development Engineer in Test)를 구별하는 수많은 회사들이 있다. 만약 팀이 소규모라면, STE/SDET를 구별하는 것은 정말 넘기 힘든 ‘머나먼 다리(bridge too far)’나 마찬가지다. 코드를 편집할 수 없다고 해서 테스터로서 실패한 것이 아니다. 랫팩(Rat Pack)[3]의 일부 사람들은 코더지만, 그렇지 않은 사람들도 있다. 나는 그들 모두가 영민한 테스터라고 생각한다. 코드를 작성할 줄 아는 것은 테스터가 가져야 하는 귀중한 소양 중의 하나일 뿐이다. 이를 가지고 있지 않다고 해서 당신의 가치가 하락하는 것이 아니지만, 이 능력을 가지게 된다면 당신이 가지고 있는 테스터로서의 다른 소양들이 더 밝게 빛나게 될 것이다.
만약 당신이 코딩에 경험이 없는 테스터라면, 그러나 배울 기회가 있다면, 나는 브라이언 매릭(Brian Marick)이 지은 『매일매일 루비로 작성하는 스크립팅; 팀을 위해, 테스터와 당신을 위해(Everyday Scripting with Ruby; for Teams, Testers and You)』[4] 를 읽어보기를 권장한다. 이는 아주 간단하게 코딩을 배울 수 있도록 하며(바로 스위치를 켜주는 것은 아니지만, 거의 이 수준에 가깝다), 아주 쉽게 접근할 수 있는 책이다.
[1] 역자 주: 원문의 필자인 Peter L(실명이 아닐 수도 있음)은 소프트웨어 테스터 커뮤니티인 RatPack의 필자이므로 커뮤니티의 입장을 정해야 하는 것인지를 물어보는 것으로 사료됨.
[2] 역자 주: Shmuel Gershon이 Michael Bolton에게 “모든 사람이 테스트를 할 수 있는지(anyone can test)” 물어보자 Michael Bolton이 “그 질문은 모든 사람이 운전할 수 있는지(anyone can drive)와 같다”라고 말했던 것에서 유래한 표현. 모든 사람이 운전할 수 있지만, 자동차에 대해서 잘 알지 못한다면 전문적인 운전 스킬이 향상될 수 없다. 애자일 개발 환경에서처럼 팀 구성원이 여러 가지 역할을 동시에 수행해야 할 경우, 프로그래머가 전문적이지 않은 테스트를 수행할 때(단순히 운전을 할 때) 테스터들이 코딩을 할 줄 안다면 코딩을 하고, 비전문적인 테스트 수행을 도와주기 위해 유닛 테스팅을 수행하도록 도와줄 수 있다는 의미로 해석된다.
[3] 역자 주: 원문 포스팅이 실린 해외의 팀 블로그 이름. http://www.testingratpack.com/
[4] 역자 주: 아마존의 해당 서적 링크 http://amzn.to/byQuzu
'QA' 카테고리의 다른 글
그림으로 보는 장애 발생 과정 (2) | 2011.01.31 |
---|---|
내게 테스팅이란 (6) | 2011.01.24 |
스타크래프트2 엔딩 크레딧으로 블리자드 QA 엿보기 (10) | 2010.08.21 |
리스크 기반 테스팅 - Part 1 (2) | 2010.06.21 |
리스크 기반 테스팅 - Part 2 (2) | 2010.06.21 |