본문 바로가기

분류 전체보기

[번역] 품질을 측정하지 말고 평가하라 James Bach의 "Assess Quality, don't measure it"을 번역했습니다. 아이러니하게도 이 글을 보기 며칠 전 셀원들에게 측정될 수 없는 품질은 관리될 수 없다. 따라서 모든 품질 지표를 객관적으로 측정하고 표시해야 한다 라고 이야기했었습니다. 이 글을 통해 좀 더 많은 인사이트를 얻고 유연하게 생각을 바꿀 수 있을 것 같습니다. 번역과 블로그 게시에 대해서는 원 저자의 승인을 받았습니다. Happy Testing! 품질을 어떻게 측정하는가는 항상 인기있는 질문이다. 그 질문에 대한 나의 답변은 무척 간단하지만, 사람들이 그렇게 좋아하지는 않는다. "그만둬! 품질은 측정될 수 있는 것이 아니야. 하지만 논의되고 평가될 수는 있지. 측정 대신 이 부분에 집중하는 것이 좋아" 내 .. 더보기
스펙에 대처하는 QA의 자세 QA가 이슈를 발견하고 개발자가 이를 수정해 제품이나 서비스에 반영하는 과정은 다양한 커뮤니케이션을 통해 이루어 집니다. QA가 테스트를 수행하다가 이슈로 추정되는 증상을 발견하면 해당 증상이 이슈인지 아닌지 개발자 혹은 기획자에게 확인하는 과정을 거칩니다. 이 과정에서 QA가 개발자 혹은 기획자로부터 흔히 듣게 되는 답변 중에 아래와 같은 말이 있습니다. “이거 스펙(Spec)입니다.” ‘아니 이게 스펙이라니. 이렇게 발견하기 힘든 이슈를 어렵게 재현해 냈는데, 이게 스펙이라니. 이 문제가 그냥 라이브에 배포되면 사용자가 많이 불편해 할텐데!'라는 속마음을 뒤로하고 QA는 터덜터덜 자리로 돌아갈 수 밖에 없습니다. 자리에 돌아와 생각해보니 마음 한 켠에는 ‘수정하기 힘든 이슈라 수정하는데 시간은 많이 .. 더보기
[회고] 지나온 회사에서 배운 것들 어느 덧 소프트웨어 테스팅의 세계에 몸을 담근 지 17년의 세월이 흘렀다. 지나온 시간들을 반추해 보고 내게 소중한 가르침을 주었던 회사와 동료들을 한 번 돌아보는 것도 의미가 있을 것 같다. 전국이 월드컵의 열풍에 빠져 모든 사람들이 붉은 악마가 되었던 2002년의 가을, 나는 경기도 오산에 위치한 한 대기업의 PC 연구소에서 테스터로서의 첫 발을 내딛었다. 지금은 기억속으로 사라진 컴팩과 IBM 노트북의 소프트웨어/하드웨어 호환성을 검증하는 것이 내가 테스터로서 수행해야 하는 첫 미션이었다. IBM 노트북의 경우 일본에 위치한 야마토 연구소에서 가이드를 전달받아 테스트를 수행했다. 컴팩도 별도의 테스트 케이스를 제공하고 테스트 환경을 구축해 주었다. 그 당시에는 그저 결벽증에 가까운 외국인들의 업무 .. 더보기
[번역] 수동 테스팅 vs. 자동 테스팅, 정답은? 최근 회사에서 QA 인턴분들의 과제 발표회가 있었습니다. QA 업무와 관련된 도서를 읽고 실제 업무와 연관된 내용들을 정리하고 발표하는 자리였는데 가장 많이 언급된 단어 중 하나가 바로 테스트 자동화였습니다. 도메인을 가리지 않고 최근 소프트웨어 테스팅 업계에서 뜨거운 화두가 되고 있는 단어라고 할 수 있을 것 같네요. 우연히 링크드인에서 접하게 된 "Testing, It's About the Results"를 오랜만에 번역해서 포스팅해 봅니다. 단어는 그것을 사용하는 사람의 의식의 단면을 표현해 준다고 하죠. 흔하게 사용하는 업계의 단어들이 그 업계의 의식을 대변해 준다고 보아도 무방할 것 같습니다. 이 글을 읽고 나서 나를 포함한 SQA들이 너무 자동화라는 화두에 매몰되어서 더 중요한 것들을 놓치고 .. 더보기
[번역] 1주일 안에 유니티 엔진을 테스트 하는 법 유니티 블로그에 올라온 How to test unity in a week? 를 번역했습니다. 우연하게 접한 글의 제목이 제 호기심을 크게 자극했습니다. '유니티 엔진처럼 방대한 기능을 가진 앱을 어떻게 1주일만에 테스트할 수 있지?'라는 호기심어린 질문에 재미있는 답이 되었던 글입니다. 다만 유니티 내부에서 업무에 사용하는 단어들을 정확하게 알 수 없어 나름대로 최대한 독자들이 한 번에 이해할 수 있는 단어로 바꾸는데 오랜 시간이 걸렸습니다. 혹시라도 유니티 직원 분이 보신다면 적절한 단어를 알려주셔도 좋을 것 같네요. :) 이 밖에도 유니티는 자사의 웹페이지를 통해 스스로의 QA 프로세스와 산출물, 이들을 통해 얻은 인사이트를 다양한 형태로 공유하고 있습니다. 여러모로 생각하고 배울 점이 많은 곳이니 .. 더보기
[번역] 제리 와인버그의 마지막 고민 소프트웨어 공학의 거장인 제럴드 M. 와인버그가 운명했습니다. 많은 사람들이 그를 추모하고 그의 생전 업적을 기렸습니다. 그와 절친한 동료이자 역시 소프트웨어 테스팅의 탁월한 거장인 제임스 바크 역시 그의 블로그에 제리를 기억하고 추모하는 글을 올렸습니다. 제리 와인버그를 추모하는 여러 글들 중에서도 바크의 이 글이 가장 제 마음에 와 닿은 것 같습니다. 한 분야의 거장이면서 또 한편 따스한 지혜를 가진 구루로서의 일면이 구구절절 잘 보이는 것 같네요. 저 역시 제리가 남긴 어록과 글, 책을 읽고 공부하면서 많은 것을 배울 수 있었습니다. 바크의 이 글을 읽으면서 전문가로서 그를 닮는 것뿐만 아니라, 인생의 선배로서 제리처럼 나이들어 갈 수 있다면 좋겠다는 생각을 했습니다. 제임스 바크에게 번역과 포스팅.. 더보기
[번역] 왜 소프트웨어 테스팅이 DevOps의 핵심인가 TechWell Insights에 올라온 "Why Software Testing is Key to DevOps"를 번역했습니다. 최근 CI/CD가 보편적으로 적용되면서 DevOps가 소프트웨어 업계의 핫이슈로 떠오르고 있습니다. 기존 테스팅 업무에만 치중하던 QA에게는(물론 그렇지 않은 QA들도 많습니다만) 업무의 외연을 확장할 수 있는 좋은 기회라고 생각됩니다. 이 글에서는 다양한 툴을 통해 신속한 빌드의 배포를 추구하는 DevOps에서도 이처럼 품질이 중요한 키워드라고 소개하고 있습니다. 간단한 테스팅 자동화를 통해 어떻게 DevOps에서 코드 품질을 보장할 수 있는지 고민해 보는 계기가 되길 바랍니다. 번역 및 포스팅에 대해서는 원 저자의 승인을 받았습니다. Happy Testing. 다양한 조직에.. 더보기
[번역] 정말 프로젝트를 시작할 때부터 QA가 필요할까 가마수트라에 올라온 "Do we even need QA at the start of a Project?"를 번역했습니다. 프로젝트 초기부터 QA가 필요한 이유에 대해 개발이나 사업 등 다양한 부서의 입장에서 한 번 고민해보고, 왜 QA가 처음부터 프로젝트에 참가해야 하는지에 대해 충분히 공감할만한 설명을 하고 있습니다. QA는 버그만 찾아내는 사람이 아닙니다. 이 일을 하는 사람을 테스터로, 그 보다 고급(?)스러운 일을 하는 사람을 QA로 구분하는 것도 개인적으로는 바람직하지 않다고 생각합니다. QA는 테스트 업무를 기반으로 본인이 담당한 프로젝트의 품질을 높이기 위해 필요한 다양한 업무를 수행하는 사람들입니다. 어떤 일을 해야 한다고 정해진 것도 없고, 하지 말아야 한다고 정해진 것도 없습니다. 유관.. 더보기