The life is REAL

박현준 님의 블로그에 소개된 "QA: Things I underestimated when I started my career in software development"라는 글을 읽고 공감하는 바가 많아 번역해 봤습니다. 이 글에 언급된 내용들이 모두 어느 시기까지 하면 완성되는 것이 아니라, 필요하다고 판단되면 주니어든 시니어든 끊임없이 더 잘하려고 노력해야 할 부분들이라 생각됩니다. 번역과 블로그 포스트에 대해서는 원 저자의 승인을 얻었습니다. Happy Testing!!! :) 안녕하세요 여러분, 올해는 제가 소프트웨어 개발 분야에서 다양한 QA 포지션을 거치면서 보내는 15년째 되는 해입니다. 이번에는 제가 캐리어를 시작할 때 과소평가했던 것들을 여러분과 공유해 보려 합니다. 우선 이 글에서 다루..

올해 첫 포스트가 연간 회고가 될 줄이야... 개인 더욱 많은 것을 기록하려고 노력한 한 해. 덕분에 사용하고 있는 3개의 메모 툴에 정리되지 않은 메모와 글들이 쌓여있다. 이걸 정리해서 블로그의 포스트와 같은 최종적인 형태로 퍼블리싱 하지 못한 것은 결국 게으름 탓이다. 최근 초벌 번역을 완료한 번역서가 출시되기 전까지 당분간 번역을 쉬기로 했다. 그 시간을 오롯이 개인의 역량 개발에 쏟으려고 했는데 가비지 타임만 쌓여간다. 아내가 그렇게 시간을 보내는 것도 의미가 있을 거라 말해준 것이 유일한 위안이 된다. 아이맥 + 맥북프로 업무 환경을 거의 셋팅한 것 같다. 테스트 위주의 업무를 조금만 벗어나도 결국 개발 툴을 사용할 수 밖에 없다. 아니, 테스트 자체가 이제는 개발 툴을 사용해서 수행되어야 하는..

제임스 바크(James Bach)의 "Assess Quality, don't measure it"을 번역했습니다. 아이러니하게도 이 글을 보기 며칠 전 셀원들에게 "측정될 수 없는 품질은 관리될 수 없다. 따라서 모든 품질 지표를 객관적으로 측정하고 표시해야 한다" 고 이야기 했었습니다. 이 글을 통해 좀 더 많은 인사이트를 얻고 유연하게 생각을 바꿀 수 있을 것 같습니다. 번역과 블로그 게시에 대해서는 원 저자의 승인을 받았습니다. Happy Testing! '품질을 어떻게 측정할 수 있는가'는 항상 인기있는 질문이다. 나의 답변은 무척 간단하지만 사람들이 그렇게 좋아하지는 않는 것 같다. "품질은 측정될 수 있는 것이 아니야. 하지만 논의되고 평가될 수는 있지. '측정'이 아니라 '논의'와 '평가'에..

유니티 블로그에 올라온 How to test unity in a week? 를 번역했습니다. 우연하게 접한 글의 제목이 제 호기심을 크게 자극했습니다. '유니티 엔진처럼 방대한 기능을 가진 앱을 어떻게 1주일만에 테스트할 수 있지?'라는 호기심어린 질문에 재미있는 답이 되었던 글입니다. 다만 유니티 내부에서 업무에 사용하는 단어들을 정확하게 알 수 없어 나름대로 최대한 독자들이 한 번에 이해할 수 있는 단어로 바꾸는데 오랜 시간이 걸렸습니다. 혹시라도 유니티 직원 분이 보신다면 적절한 단어를 알려주셔도 좋을 것 같네요. :) 이 밖에도 유니티는 자사의 웹페이지를 통해 스스로의 QA 프로세스와 산출물, 이들을 통해 얻은 인사이트를 다양한 형태로 공유하고 있습니다. 여러모로 생각하고 배울 점이 많은 곳이니 ..

가마수트라에 올라온 "Do we even need QA at the start of a Project?"를 번역했습니다. 프로젝트 초기부터 QA가 필요한 이유에 대해 개발이나 사업 등 다양한 부서의 입장에서 한 번 고민해보고, 왜 QA가 처음부터 프로젝트에 참가해야 하는지에 대해 충분히 공감할만한 설명을 하고 있습니다. QA는 버그만 찾아내는 사람이 아닙니다. 이 일을 하는 사람을 테스터로, 그 보다 고급(?)스러운 일을 하는 사람을 QA로 구분하는 것도 개인적으로는 바람직하지 않다고 생각합니다. QA는 테스트 업무를 기반으로 본인이 담당한 프로젝트의 품질을 높이기 위해 필요한 다양한 업무를 수행하는 사람들입니다. 어떤 일을 해야 한다고 정해진 것도 없고, 하지 말아야 한다고 정해진 것도 없습니다. 유관..