본문 바로가기

분류 전체보기

 (130)
2022년 회고 우선 2021년 회고에서 2022년을 전망하고 결심한 내용을 얼마나 지키고 달성했는지 되돌아보자. ■ 내년은 올해 이루었던 변화와 업그레이드를 더욱 고도화 시켜서 새로운 스테이지를 안착시켜야 한다. → SDET 직군 신설 등으로 2022년에 어느 정도 가시화된 성과를 이룸 ■ 파이썬, SQL 등의 툴을 조금 더 잘 다룰 수 있도록 계속 공부해야겠다. → 진행하지 못함… / 개인적으로 공부할 수 있는 시간을 좀 더 안배했어야 했다. ■ 번역, 인프런과 같이 일상적인 루틴을 잡아줄 수 있는 활동을 지속해야 한다. → 번역서는 2권 출간 / 인프런의 경우 인프라나 Ops 관련 강의를 3개 정도 수강했으나, 제대로 정리를 하지 못했다. 어떤 것을 배우면 늘 정리하고 이를 통해 익히는 과정이 필요한데, 이 부분에..
살면서 처음 해본 좋은 일들 - 캐치볼과 오픈소스 contribution 1. 지난주 하율이와 캐치볼을 처음 했다. 대형 마트에 가서 야구 글러브 2개와 야구공을 사고, 포장도 제대로 뜯지 않은 채로 공원에서 볼을 던지고 받는 연습을 했다. 생전 처음 껴보는 글러브에 어색해 하기도 하고, 쉬운 공도 곧잘 받지 못해 떨어뜨리기는 했지만, 하율이가 아주 즐거워했다. 아직은 언더드로우로 사알짝 던지는 공만 주고 받을 수 있지만, 곧 잘 적응하리라 믿는다. 2. 이런 저런 이야기를 나누면서 아이와 캐치볼을 하는 건 아빠라면 한 번쯤 꿈꿔보는 일이 아닐까. 아니 적어도 내게는 이루고 싶은 꿈 중의 하나였다. 어릴 땐 야구 글러브라는 물건 자체가 참 귀한 것이기도 했고, 그 시절 ‘아빠와 캐치볼을 한다’는 건 외국 영화에서나 볼 법한 일이었다. 늘 엄하고 바쁘신 아버지와 캐치볼을 한다는..
[번역] 테스팅 업계에서의 34년 제임스 바크 James Bach 의 "34 Years in Testing"을 번역했습니다. 오랫동안 몸담아온 소프트웨어 테스팅 업계에 대해 그만이 가진 색깔로 진지하고 깊이 있는 질문을 던지는, 결코 가볍지만은 않은 글이었습니다. 이 글에서도 말하듯이, 모든 문제를 한 번에 풀어줄 정답은 없습니다. 이런 구루들이 제시하는 의견에 귀 기울이고 또 거기에 나만의 고민을 더해 테스팅의 세계를 조금이라도 더 나은 것으로 만든다면, 그것만으로도 충분히 의미가 있을 것 같습니다. 번역과 포스팅에 대해 저자의 승인을 받았습니다. Happy Testing! 지난 주 금요일, 즉 2021년 5월 21일은 내가 애플 컴퓨터의 테스터로 일을 시작한 지 정확하게 34년 되는 날이었다. 그 전에는 개발자로 일했었지만, 그날 이..
<시스템으로 풀어 보는 게임 디자인> 번역 후기 2020년 2월에 첫 문장을 번역한 다음 책이 출간되기까지 2년의 시간이 걸렸습니다. 제가 손이 아주 느리기도 하고, 일을 하면서 틈틈이 번역을 진행한다는 핑계로 다른 역자분들만큼 속도와 품질을 관리하지 못했습니다. 제 나름대로 가지고 있는 기준 중 하나가, ‘역자인 내가 내용을 제대로 이해하지 못하면 번역을 제대로 할 수 없다’여서 원 저자만큼 전문적인 역량을 가지지는 못하더라도 적어도 내가 번역하는 문장과 단어가 어떤 의미를 가지고 있는지는 충분히 알아야 기본적인 번역이 가능하다고 생각하고 있습니다. 이번 책을 번역하면서도 이나 등 원서에서 언급된 건축 관련 책을 구매해서 읽고, 언급된 다양한 에피소드들도 가급적이면 충분히 맥락을 이해할 수 있도록 다양한 소스를 찾아보며 이해했습니다. 게임 디자인이라..
2021년 회고 올해 첫 포스트가 연간 회고가 될 줄이야... 개인 더욱 많은 것을 기록하려고 노력한 한 해. 덕분에 사용하고 있는 3개의 메모 툴에 정리되지 않은 메모와 글들이 쌓여있다. 이걸 정리해서 블로그의 포스트와 같은 최종적인 형태로 퍼블리싱 하지 못한 것은 결국 게으름 탓이다. 최근 초벌 번역을 완료한 번역서가 출시되기 전까지 당분간 번역을 쉬기로 했다. 그 시간을 오롯이 개인의 역량 개발에 쏟으려고 했는데 가비지 타임만 쌓여간다. 아내가 그렇게 시간을 보내는 것도 의미가 있을 거라 말해준 것이 유일한 위안이 된다. 아이맥 + 맥북프로 업무 환경을 거의 셋팅한 것 같다. 테스트 위주의 업무를 조금만 벗어나도 결국 개발 툴을 사용할 수 밖에 없다. 아니, 테스트 자체가 이제는 개발 툴을 사용해서 수행되어야 하는..
[번역] 품질을 측정하지 말고 평가하라 제임스 바크(James Bach)의 "Assess Quality, don't measure it"을 번역했습니다. 아이러니하게도 이 글을 보기 며칠 전 셀원들에게 "측정될 수 없는 품질은 관리될 수 없다. 따라서 모든 품질 지표를 객관적으로 측정하고 표시해야 한다" 고 이야기 했었습니다. 이 글을 통해 좀 더 많은 인사이트를 얻고 유연하게 생각을 바꿀 수 있을 것 같습니다. 번역과 블로그 게시에 대해서는 원 저자의 승인을 받았습니다. Happy Testing! '품질을 어떻게 측정할 수 있는가'는 항상 인기있는 질문이다. 나의 답변은 무척 간단하지만 사람들이 그렇게 좋아하지는 않는 것 같다. "품질은 측정될 수 있는 것이 아니야. 하지만 논의되고 평가될 수는 있지. '측정'이 아니라 '논의'와 '평가'에..
스펙에 대처하는 QA의 자세 QA가 이슈를 발견하고 개발자가 이를 수정해 제품이나 서비스에 반영하는 과정은 다양한 커뮤니케이션을 통해 이루어 집니다. QA가 테스트를 수행하다가 이슈로 추정되는 증상을 발견하면 해당 증상이 이슈인지 아닌지 개발자 혹은 기획자에게 확인하는 과정을 거칩니다. 이 과정에서 QA가 개발자 혹은 기획자로부터 흔히 듣게 되는 답변 중에 아래와 같은 말이 있습니다. “이거 스펙(Spec)입니다.” ‘아니 이게 스펙이라니. 이렇게 발견하기 힘든 이슈를 어렵게 재현해 냈는데, 이게 스펙이라니. 이 문제가 그냥 라이브에 배포되면 사용자가 많이 불편해 할텐데!'라는 속마음을 뒤로하고 QA는 터덜터덜 자리로 돌아갈 수 밖에 없습니다. 자리에 돌아와 생각해보니 마음 한 켠에는 ‘수정하기 힘든 이슈라 수정하는데 시간은 많이 ..
[회고] 지나온 회사에서 배운 것들 어느 덧 소프트웨어 테스팅의 세계에 몸을 담근 지 17년의 세월이 흘렀다. 지나온 시간들을 반추해 보고 내게 소중한 가르침을 주었던 회사와 동료들을 한 번 돌아보는 것도 의미가 있을 것 같다. 전국이 월드컵의 열풍에 빠져 모든 사람들이 붉은 악마가 되었던 2002년의 가을, 나는 경기도 오산에 위치한 한 대기업의 PC 연구소에서 테스터로서의 첫 발을 내딛었다. 지금은 기억속으로 사라진 컴팩과 IBM 노트북의 소프트웨어/하드웨어 호환성을 검증하는 것이 내가 테스터로서 수행해야 하는 첫 미션이었다. IBM 노트북의 경우 일본에 위치한 야마토 연구소에서 가이드를 전달받아 테스트를 수행했다. 컴팩도 별도의 테스트 케이스를 제공하고 테스트 환경을 구축해 주었다. 그 당시에는 그저 결벽증에 가까운 외국인들의 업무 ..

티스토리툴바