QA

프로젝트 수행 중에 시도해 본 내용 중 프로세스 품질 향상으로 진행한 내용을 정리해 보았습니다. 기술 이야기는 아니고, 프로젝트 운영과 협업을 효과적으로 이끌어 내 보려던 내용입니다. 간단하지만 효율적이였던 본 사례를 응원해 준 동료가 있어서 내용을 정리해 봅니다. 그 동료는 작고 시맨틱한 리소스 [1] 로 효율적이고 효과적으로 작업하기를 좋아합니다. 프로젝트 현황판이란? 프로젝트를 오픈시킬 때까지는 여러 단계를 거치게 되죠. 다양한 요구사항들을 분석해서 설계하고 개발하고 테스트한 후 서비스를 오픈시키기 위해서는 각 단계별 담당자들 사이에 유기적이고도 효율적인 업무 진행 상황 파악이 필요합니다. 이러한 진행 상황 파악은 결국 서비스 품질을 향상시키는 위한 방향이 되고, 서비스 품질은 프로세스 품질을 기본적으로 가지고 있어야 합니다. 프로젝트 관리 도구에서 다양한 형태로 제공 받거나 일반 문서로 작성되기도 합니다. 기본적으로 프로젝트 진행 상황 파악이 필요한 이유는 각 단계별 담당자들이 업무 진행 현황을 시각적으로 공유 받고 이것을 바탕으로 개인 업무를 조율할 수 있게 하는 것이고, 프로젝트 이해 관계자들은 프로젝트 진행 상황을 한 눈에 보기를 원하기 때문입...

Druid에서 주로 발생하는 문제에 대해 Q&A 형태로 정리한 글입니다....

조용하던 사무실에 난데 없이 이런 고성이 터져 나옵니다. 필시 운영 중인 서비스나 배포된 앱에서 심각한 문제가 발생하였습니다. 이 프로그램 누가 만들었어!!! 이번 글은 최근 페이스북에 한 분이 질문하신"개발자가 실수로 버그를 만들었습니다. 여러분이 상사라면 어떻게 하시겠습니까?" 글에 대해 필자의 생각을 정리해 보았습니다. 이 버그는 개발한 너의 잘못이야? 특정 기능에 문제가 발생했을 때 그 기능을 개발한 개발자의 잘못으로 생각하는 팀도 있습니다. 설령 팀 구성원 또는 팀의 관리자는 그런 생각을 하지 않는다 하더라도 개발자 스스로가 그런 생각을 하는 경우도 많이 있습니다. 이런 개발자나 팀이 있다면 필자는 절대로 그런 생각을 할 필요가 없다고 말하고 싶습니다. 특히 개발자에게는 더 강조하고 싶습니다. 심지어 버그나 잘못된 구현에 대해 더 당당해야 할 필요가 있습니다....

페이스북 친구인 안영회님이 얼마전에 함께 했던 프로젝트의 어플리케이션 QA를 회고해 주셨습니다. 아래 내용은 페이스북에 올려 준 전문입니다. 나에겐 두 번의 훌륭한 QA 팀과 협업 경험이 있다. 첫번째는 한국에서 우리 팀에 QA 리더가 최문석 님일 때 모바일 애플리케이션에 대한 QA를 진행했던 경험인데... 이 글을 보니 남 얘기 같지가 않다. 구조 변경에 대한 두려움이 개발자들을 움츠러들게 하는 상황에서 신뢰를 형성하고 나니 과하게(?) 의지하는 형상이 문제가 되었던 경험도 있고, 오래 함께 일하니 기획회의 초반에 함께 참여해서 시너지를 냈던 경험이 있죠. 최문석 님이 읽으면 더 할말이 많을텐데. 이 참에 popit에 글 하나 쓰세요! (QA 관련 한글 컨텐츠는 생소할 정도로 드무니까요.) 두번째는 중국에서 현재 겪는 경험인데, 백화점 PoS 등과 같이 무선 네트워크와 물리적 장비 등의 특수성 때문에 QA들이 꼭 필요한 서비스 환경이죠. 그런데, 여기서 흥미로운 점은 QA들이 직무를 바꾸는 도전을 한다는 점입니다. 어떤 친구들은 gitlab이나 jenkins를 돌리고, slack과 연결하는 작업을 하는 수준도 있지만, 일부는 Product Owner...

QA에 대한 오해의 시선에 대한 경험과 이 이면을 살펴보는 글입니다....

Software 개발에 있어 QA 역할에 대한 정의 및 어떤 일을 하는지 소개하는 글입니다....