Around the embedded
SW테스트 엔지니어들의 코미티움(Comitium), 'SW TestER들의 모임'
"임베디드 산업의 Key, SW 테스터"
한보선 선임 연구원 YesCnC / 품질 검증팀 coolknightx@gmail.com
현재 4G(LTE/WiMax) System 검증 업무를 담당하고 있으며, 회원수 2560명이 가입한 'SW TestER들의 모임'을 '버터'라는 닉네임으로 운영하고 있다.
글│황은정 기자
SW(Software)의 결함은 그것이 어느 분야인지를 막론하고 기업에게 또는 국가에게 큰 손실을 가져다 준다. 사소하게는 가전제품의 SW 결함이 군사, 항공 분야 못지 않게 사람의 생명에 직결될 수 있는 문제이기 때문이다. 더욱이 전세계적으로 신기술의 도입으로 인해, 복잡해져 가는 HW(Hardware)를 제어하기 위해 SW 역시 규모가 커지고 복잡성이 높아지고 있다. 실제로 몇몇 글로벌 제조기업의 리콜 및 규제 등의 문제로 SW 제품의 품질과 신뢰도 향상이 거론되면서 임베디드 SW 테스팅이 주목을 받았고 HW 측면에서의 개발이 포화상태라는 전문가들의 의견이 주류를 이루기 시작했다.
하지만 이러한 국제적인 흐름에도 불구하고 국내 현실과 인식 수준이 부족한 것이 사실이다. 임베디드 SW 테스팅 관련 인력에 대한 수요는 높지만 전문적인 프로세스를 준용하는 기업을 찾아보기 힘들 뿐만이 아니라 테스터들에 대한 대우 역시 개선이 필요한 실정이다.
이에 본지에서는 관련 모임이나 클럽, 카페 중 회원 수 2560명(2011년 7월 15일 기준), 순수 SW 테스트 엔지니어들만의 카페인 네이버 'SW TestER들의 모임'의 운영자(버터)와 회원(꽃군, 잔다르쿠, 보니 등)들과의 만남을 통해 임베디드 SW 테스팅 동향과 테스터들의 애로 사항을 들어 보았다.
Q1커뮤니티를 설립하게 된 계기, 활동사항과 비전을 소개해 달라
버터│'SWTestER들의 모임' 매니저 '버터' 입니다. 저희 SWTestER는 소프트웨어 테스트의 모든 것에 대한 이야기 하고 활동 하고 있으며 주로 자격증, 회사, 이슈, 테스팅에 대한 것을 논의 합니다. 제가 커뮤니티를 만들게 된 계기는 아무도 이와 같은 커뮤니티를 만들지 않았기 때문입니다. 목마른 자가 우물을 판다고, 테스팅에 대해 궁굼한 것이 너무 많아서 이렇게 만들게 되었습니다. 때문에 매월 테스팅 캠프를 진행하고 있습니다. 개인적인 것, 이슈, 기술, 테스팅 기법에 대해서 서로 발표하고 논의 하는 오프라인 모임을 진행하며 전문 강사분을 초빙하여 관련 여러 강의를 듣기도 합니다. 부 운영자 꽃군님께서 수고해 주고 계시죠.
Q2소프트웨어 테스트 엔지니어란?
버터│저희는 일반적으로 하드웨어는 자물쇠, 소프트웨어는 열쇠로 표현하고는 합니다. 세상에는 다양한 하드웨어가 있고 하드웨어별 적합한 소프트웨어를 사용해야 합니다. 자물쇠와 열쇠도 마찬가지죠. 서로 맞는걸 사용해야 정상적으로 잠그고 열 수 있는 기능이 동작하니까요. 소프트웨어 테스트 엔지니어는 열쇠가 잘 만들어져 있는지 확인하는 일을 합니다. 열쇠를 이용해 자물쇠가 잠기고 열리는지는 물론이고, 열쇠가 부드럽게 들어가고 빠지는지, 적당한 힘으로 동작하는지, 열쇠를 많이 사용해도 제 모양을 유지하고 동작하는지, 물이나 녹에 오염 되었을 때도 동작하는지, 때론 열쇠의 모양은 어떤지, 이런 것들이 소프트웨어 테스트 엔지니어들의 기본적인 임무라고 생각합니다.
Q3임베디드 SW테스팅 시장의 최신 경향은 무엇인가
버터│클라우드 시장이 떠오르고 있다고 생각합니다. 클라우드 시스템은 온라인 서버에 저장된 것을 인터넷을 통해 다양한 디지털 기기로 서비스를 받을 수 있는 것이라고 볼 수 있습니다. 단순히 서버의 저장소를 사용하는 웹 하드의 개념이 아닌 서버를 가상 PC로 만들어 그 PC의 자원을 내 것처럼 활용하는 것이라고 보면 되겠습니다. 내 PC에 인터넷만 연결되어 있다면, 클라우드 시스템을 이용해 워드나 엑셀 같은 문서를 작성하고, 사진을 편집하거나 저장하며, 동영상을 보고 음악을 듣고, 개인 용도의 저장 공간 등으로 활용할 수 있습니다.
최근 클라우드 시스템이 각광받는 이유는 휴대 디지털 디바이스의 증가와 이동통신 시스템의 발전이라고 보여집니다. 많은 사람들이 이동하면서 스마트폰, 타블릿PC, 넷북 등을 이용해서 3G나 4G등과 같은 고속 이동통신망을 통해서 많은 자료를 주고 받고, 부족한 자원은 클라우드 시스템을 활용하고 있습니다. 이와 관련하여 임베디드 SW테스트 부분에 있어서 상호 호환성, 보안성, 강건성을 중점으로 테스팅이 이루어져야 할 것 같습니다. 클라우드 시스템은 새로 만들어진 것이 아니라, 기존의 존재하는 것들의 진화물을 테스트하는 것이기 때문입니다.
잔다르쿠│요즘에는 하드웨어와 소프트웨어의 경계가 참으로 모호해지고 있습니다. 디지털 컨버전스, 융/복합 등과 같은 단어들이 대세를 이루고 있죠. 기존에는 블랙 박스 단위의 사용자 인수 테스트가 대부분이었다면 최근에는 성능이나 부하에 대한 이슈가 증가하여 화이트 박스 단계의 요구사항들이 많이 생기고 있습니다. 따라서 최근에 그레이 박스 테스트가 업계 요구사항이 아닌가 싶습니다.
참고_ 그레이박스 테스트
블랙박스와 화이트박스 테스트의 중간 정도의 테스트이다. 화이트박스 테스트처럼 소스코드를 이해하고, 테스트 하는 것이 목적이 아니라 소스코드들을 통해서 기능을 이해하고 테스트를 진행하는 것. (참고 설명: 잔다르쿠)
Q4테스터들이 느끼는 임베디드 개발 OS별 테스트 환경
꽃군│제가 답변을 하는 것이 좋겠네요. 먼저 iOS는 개발은 쉽지만 로그 전체가 다 떨어지는 게 아니라는 단점이 있습니다. 다만 그만큼 안정성이 있는 OS입니다. 안드로이드의 경우, 로그가 굉장히 디테일하게 나오고 거의 Java log와 동일하게 나타나기 때문에 테스트 시 참고하고 이해하기가 용이합니다. 단, 에뮬레이터(Emulator)를 속 시원하게 돌리려면 굉장한 사양의 컴퓨터가 필요하지만 고가라는 점이 단점입니다. Windows Mobile은 아직 새로운 OS가 만들어지는 도중이라 플랫폼의 안정성 테스트부터 만들어가고 있는 것으로 보이며, 몇 가지 앱들이 나왔지만 실제로 개발해본 적은 없습니다. SDK 비싸서요.(웃음) 마지막으로 Linux Mobile의 경우, 개발은 어렵지만 Log나 기타 환경은 잘 되어 있습니다. 다만 디바이스에 올라가고 난 뒤에는 파일들을 관리하는 것이 쉽지 않고, 여차 하면 시스템이 다운될 수도 있습니다.
Q5임베디드 테스팅 기법의 ABC를 꼽는다면?
꽃군│"A, 자기 제품을 공부해라"라고 대답하고 싶습니다. 임베디드 제품은 PC의 제품군들처럼 볼륨이 크지 않습니다. 다만 다양하게 구성한 것이 게임이라고 해도 유저의 인풋(Input) 제한으로 몇 가지 패턴들로 구성되어 있고, 그것들이 반복될 뿐입니다. 아직까지 타블렛과 HTML5가 전면에 나서지 않았으므로, 현재로서는 볼륨이 크지 않다고 생각하면 됩니다. 그런 상태에서 자기 제품에 대해 정확히 모르고 있다는 것은 게으르다는 의미 밖에 되지 않습니다. 물론 B가 충족되어 있다면 말입니다. B가 안되어 있으면 이해 되는 사항이긴 하죠. 두 번째로 "B, 내부 문서들을 만들어라" 입니다. 다시 말하지만, 임베디드 제품은 그렇게 크지 않습니다. 단순 기능만 수 백 개인 RPG 게임 테스트와 비교한다면 조족지혈(鳥足之血)입니다. 가능한 아는 만큼, 정량적으로 추적 가능한, 혹은 지속적으로 리뉴얼(Renewal)이 가능하고 개선 가능한 테스트 문서 및 내부 문서들을 만드셔야 하고 후임자들이 오면 주저 말고 자신이 아는 모든 것을 알려줘야 합니다. 마지막 C로 꼽고 싶은 것은 "테스트의 기본기를 잘 익혀라" 입니다. 실제 Ready to Shipping 상태로 갈수록 임베디드는 템포가 굉장히 빠른데, 특히 대기업(S사, N사, C사, L사 등)에서 일한 사람들은 도저히 상상할 수 없게 돌아갑니다. 또한, iOS의 빅뱅 이후로는 시장의 요구가 너무 빠르게 바뀌어 Requirement 추적이 거의 불가능합니다. 그러므로 테스트의 기본기를 익히세요. "테스트 이론 잘 알면 디바이스 테스트 잘 하나요?" 라는 질문은 "국어 공부 안 해도 말만 잘하는데 국어 공부를 대체 왜 하나요?" 라는 말과 같은 어리석은 말입니다. 테스트의 기본기를 잘 익히고 수련할수록 테스트 속도도 빨라지고 현재 내부 개발팀 내에서 일어나는 일들 중 부조리한 점을 빠르게 알고 개선해 나아갈 수 있습니다.
Q6테스팅 시 직면하는 문제는 어떤 것들이 있는가
버터│개발자와의 마찰이 아닐까 싶습니다. 서로의 가려운 곳을 긁어 주는 것이 아니라, 서로의 아픈 곳을 때려주는 처지라 그런 것 같습니다.
북극성│"호미로 막을 것을 가래로 막지 마라" 단위 테스트 좀 하고 넘어 와주세요.
창자로줄넘기│일정이 빠듯해서 테스트 할 시간은 적은 반면, 요구하는 범위는 넓다는 점입니다.
버닝│저나 제 주변의 경우는 테스터 본인의 좋은 테스트 케이스를 도출하지만 자제 및 시료 부족으로 현실과 타협 할 경우가 많았죠.
보니│저 역시 빡빡한 일정이 문제라고 생각합니다. 또한 여러 가지 테스트 환경을 구축해야 된다는 것이 테스터로서 힘든 점입니다.
잔다르쿠│제일 힘든 부분은 아무래도 기업문화 부분이 아닐까 싶습니다. 테스트라는 부분에 있어 개발 주도적으로 프로젝트가 운영된다면 분명 품질 관련된 조직은 여러모로 부하가 발생할 것 같네요. 운영이나 품질이랑 같은 것으로 판단하는 대부분의 신생 내지는 무지한 업체의 경우에는 R&R이라는 것은 생각도 못할 테니까요. 또한 아무래도 형상관리가 아닐까 싶습니다. 임베디드의 특성상 하드웨어의 스펙 변경은 소프트웨어에 아주 큰 영향을 줄 수밖에 없죠. 그래서 설계나 하드웨어 디자인과 스펙 변경은 바로 소프트웨어 파트의 부하로 연결되고 있어 큰 문제가 될 것이라고 생각합니다.
Q7마지막으로, 테스터들이 바라는 업무 환경은 무엇인가
기뜨리│아무래도 상식선의 급여와 야근수당, 파트너쉽(업무참여 의견반영 등)이 좋은 회사에서 일하고 싶네요.
보니│테스터를 개발자 보조(Sub) 역할이 아닌 동등한 역할로 인식해 주는 것이 급선무 아닐까요?
잔다르쿠│저는 성취감이 고취될 수 있는 곳이라면 옮길 것 같습니다. 릴리즈나 퍼블리싱 단계에서 테스트 시간은 적게 주면서, 테스트 퀄리티에 대해 왈가왈부 하는 환경의 회사는 당연히 테스터들의 성취감이 추락하겠지요. IT업계가 발전하는 만큼 그에 대한 대우도 좋아져야 한다고 생각 합니다.
회원가입 후 이용바랍니다.
개의 댓글
댓글 정렬
BEST댓글
BEST 댓글
답글과 추천수를 합산하여 자동으로 노출됩니다.
댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
그래도 삭제하시겠습니까?
댓글수정
댓글 수정은 작성 후 1분내에만 가능합니다.
내 댓글 모음