Kori 8월 10일, 2022에 포스트됨 공유하기 8월 10일, 2022에 포스트됨 마르코 칸투 (Marco Cantu)의 "RAD Studio Quality Portal 2022 User Guide" 를 번역했습니다. (원문 작성: 2022년 7월, 최종 번역: 2022년 8월 10일) 엠바카데로의 퀄리티 포탈(Quality Portal)에서는 엠바카데로의 제품과 서비스에 대한 품질 이슈를 해소하고, 확인 하고, 추적할 수 있다. EDN 서비스 계정이 있는 사람은 여기에서 버그 리포트와 기능 요청을 만들고, 다른 고객이 만든 리포트를 보고, 의견을 달고, 본인에게 가장 중요한 리포트에 투표할 수 있다. 엠바카데로 담당자 역시 퀄리티 포탈(Quality Portal)에 참여한다. 따라서 퀄리티 포탈은 엠바카데로의 제품 개발팀과 제품을 사용하는 고객 사이를 영구적으로 연결하는 역할을 한다. 지원 및 유지보수 계약을 유지하고 있으며 긴급하게 문의 사항에 대한 대응이 필요한 개발자는 퀄리티 포탈이 아니라 지원(Support) 티켓을 이용하는 것이 좋다: 퀄리티 포탈(Quality Portal) 리포트는 지원(Support) 티켓과는 별개이다. 이 가이드는 개발자가 RAD 스튜디오 (델파이, C++빌더), 인터베이스 제품과 관련된 이슈 리포트를 하는 과정을 돕기 위한 문서이다. 이글은 아래의 글(들)을 대체할 수 있도록 업데이트 한 것이다. https://blogs.embarcadero.com/rad-studio-quality-portal-user-guide https://community.embarcadero.com/article/articles-support/171-rad-studio/16199-rad-studio-quality-portal-user-guide 목차 1 엠바카데로 퀄리티 포탈 (Quality Portal) 사용하기 2 커뮤니티 프로세스 3 퀄리티 포탈의 장점을 최대로 활용하기 4 버그 리포팅하는 방법 안내 4.1 구체적일 것(Be specific) 4.2 이슈 타입 (Issue Type) 4.3 요약 (Summary) 4.4 구성요소 (Component) 4.5 설명 (Description) 4.6 각 단계 (Steps) 4.7 기대한 결과와 실제 결과 (Expected and Actual Results) 4.8 리포트 격리하기 (Isolate reports) 5 중복 리포트 이해하기 (Understanding Duplicate reports) 6 퀄리티 포탈에 있는 필드(들) 해석 방법 (How to interpret some of the fields in QP) 6.1 상태 필드 (Status field) 6.2 해결 필드 (Resolution Field) 7 로그와 몇가지 팁 (Logs and Some More Tips) 1 엠바카데로 퀄리티 포탈 (Quality Portal) 사용하기 퀄리티 포탈 (Quality Portal) 사용하기 전에 먼저 EDN 서비스 계정이 있는 지 반드시 확인해야 한다. 만약 계정이 없다면 https://my.embarcadero.com 으로 가서 계정을 하나 만들어야 한다. 이 계정은 엠바카데로 제품을 등록할 때 사용하는 계정이기도 하다. (역자주, 퀄리티 포탈을 이용한다면 이미 엠바카데로 제품을 사용하고 있다는 것이고 그렇다면 이미 EDN 서비스 계정이 있다는 의미이다. 따라서 새로 만들지 말고 본인의 계정을 사용하도록 한다. 만약 계정이 기억나지 않는다면, 여기를 클릭하여 도움을 받을 수 있다.) EDN 서비스 계정을 이용하여 https://quality.embarcadero.com/ 에 로그인한다. 주의: EDN 서비스에 로그인 할 때에는 로그인명 대신 이메일주소를 사용할 수 있으나, 퀄리티 포털에서는 EDN 계정의 Login명을 사용해야 한다. (그리고, 대소문자까지 정확해야 한다) 로그인명은 EDN 서비스의 계정 정보에 있는 "login"의 값이다. 퀄리티 포탈의 계정을 생성하거나 비밀번호를 변경하려면 EDN 서비스의 계정 생성, 비밀번호 변경을 이용한다. 2 커뮤니티 프로세스 퀄리티 포탈은 서로 함께 지원하는 곳이므로, 다른 회원이 등록한 리포트에 대해 의견 달기와 투표를 할 수 있다. 개발자 커뮤니티는 퀄리티 포탈을 통해서 큰 영향력을 발휘할 수 있으며, 엠바카데로가 고객 요구사항의 우선 순위를 정하는 데 도움을 준다. 다른 사람이 리포트한 이슈를 "Watch(관심 항목으로 등록)" 할 수도 있어서 관심있는 이슈가 업데이트 될 때 알림을 받을 수도 있다. 이미 언급했지만, 한번 더 강조하고 싶은 점이 있는데, 엠바카데로는 이 퀄리티 포탈과 별개로 기술 지원 프로그램을 https://www.embarcadero.com/support 에서 운영하고 있다. 지원 프로그램 페이지에 접속하면 설치/등록에 대한 지원을 받을 수 있으며 (유지하고 있는 지원 등급에 맞는) 기술 지원 티켓을 활용할 수 있다. 긴급하게 문의 사항에 대한 대응이 필요한 개발자는 퀄리티 포탈이 아니라 지원(Support) 티켓을 이용하기 바란다. 3 퀄리티 포탈의 장점을 최대로 활용하기 퀄리티 포탈을 "올바르게" 사용하면 그 장점을 최대로 활용할 수 있다. 이제부터 버그 리포트, 기능 요청, 제안 등을 효과적으로 전달함으로써 전달한 버그, 기능 요청, 제안을 엠바카데로가 실제로 조치 하도록 만드는 기술들을 설명한다. 요컨대, 귀하가 퀄리티 포탈을 이용하는 이유는 귀하가 신경쓰고 있는 이슈를 엠바카데로에서 해소해 주기를 원하기 때문일 것이다. 이 가이드는 퀄리티 포탈을 통해서 귀하의 긍정적인 영향력을 최대화할 수 있는 다양한 방법을 설명한다. 4 버그 리포팅하는 방법 안내 (역자 주: 등록 방법만 알고 싶은 한국 개발자에게는 "제조사에 버그나 기능 개선 리포트 하기 (Quality Portal 사용 안내)"에 있는 설명이 훨씬 더 간단하고 알기 쉽다. 하지만, 등록한 리포트가 잘 처리되기를 원한다면, 이 문서에 있는 안내 사항을 꼼꼼히 읽고 활용하기를 적극 권장한다.) 퀄리티 포탈에 대해 처음 관심을 가지는 이유는 대부분은 버그 리포트를 하고 싶어서이다. 지금부터 버그 리포트를 효과적으로 생성하고 진행하는 명백하고도 세심한 방법을 설명한다. 버그 리포트 양식은 아래와 비슷하게 생겼다. 4.1 구체적일 것(Be specific) 버그 리포트가 효과적이도록 작성하라. 버그에 대한 설명, 그리고 어떤 일이 발생했는 지를 가능한 완전하게 설명하는 리포트가 되어야 한다. 버그가 발생될 때까지의 단계들을 기록하라. 버그가 수정되도록 만드는 가장 효율적인 방법은 해당 버그를 재현할 수 있는 테스트 케이스를 제공하는 것이다. 버그 리포트 하나 안에는 해당 버그와 관련된 모든 정보가 들어 있어야 한다. 재현할 수 있는 테스트 케이스가 있지만, 해당 코드를 공개하고 싶지 않다면, 비공개로 진행하는 방법을 안내받을 수 있다. 그러려면, 비공개로 진행하기를 바란다고 해당 리포트 안에 명시하기 바란다. 또한 코드인사이트(CodeInsight), 파이어닥(FireDAC) 등 일부 제품 영역인 경우에는 로그 정보 제공 등 추가적인 절차가 필요하다. 이에 대한 설명은 이 글의 가장 아래에 있는 "팁" 부분에서 있다. 황금률: 리포트 1개에는 이슈가 오직 1개만 있어야 한다. 4.2 이슈 타입 (Issue Type) Bug: 제품 상의 이슈 Documentation bug: 도움말 또는 제품 설명서 상의 이슈 Feature Request: 제품에 들어가기를 원하는 새 기능 알아둘 점, Feature Request는 진행 절차가 조금 다르다. 기능 요청이 등록되면, (품질 보증팀 즉 QA에게 전달되기 전에) 제품 관리자들이 사전 검증을 하고 나서 개발자를 지정하여 향후 버전에 들어 갈 수 있도록 연구하거나 구현하도록 한다. 상황에 따라, 우리는 등록 당시의 이슈 타입을 다른 타입으로 변경하기도 한다. 예를 들어, 버그 리포트를 해소하기 위해 상당한 기능을 추가해야 하는 경우도 있고 또는 고객의 버그 등록이 부정확한 경우도 있다. 4.3 요약 (Summary) 등록하는 리포드에 대해 간결하면서도 정확하게 설명하는 요약을 넣어라. "TButton이 작동하지 않음"은 좋은 제목이 아니다. "[안드로이드] 더블 터치하여 TButton을 작동시키려고 하면 에러가 발생함"이 더 좋다. 필요하다면, 이 제목 안에 괄호를 사용하여 이 리포트를 읽는 사람 누구나 해당 리포트를 이해할 수 있도록 하자. 요약이 좋으면, 어떤 문제인지 식별하는 시간이 짧아지고 이슈가 중복 등록되는 경우도 줄일 수 있다. 문제를 일반화하여 설명하지 않도록 하라. 다음과 같이 하면 안된다. XXX에 문제가 있음 XXX가 정상 작동하지 않음 좋지 않은 요약과 더 좋은 요약 사례: 좋은 않음: 개발툴에서 Access violation이 발생함 더 좋음: 빈 .pas 파일을 열면, Access violation이 발생함 좋은 않음: 푸쉬 알림(Push notification) 버그 더 좋음: 푸쉬 알림(Push notification) 갯수가 실제보다 하나 더 많음 4.4 구성요소 (Component) 해당 버그가 영향을 끼치는 부분을 지정한다. Install (설치) FireMonkey (파이어몽키) VCL C++ Compiler (see C++ Compiler / Linker bug submitting hints) C++ RTL Delphi Compiler (델파이 컴파일러) Delphi RTL (델파이 RTL) Linker (see C++ Compiler / Linker bug submitting hints) Database (데이터베이스) Debugger (디버거) IDE (개발 환경) Help and Doc (도움말과 문서) Demos (데모) 4.5 설명 (Description) 해당 이슈로 인해 발생된 모든 정보. 다음 중 해당되는 것을 모두 등록한다. 에러 메시지 (error message) 전문 호출 스택 (call stack) 전체 관련이 있다고 판단되는 경우, 귀하의 환경 (예: 안드로이드 버전, 윈도우 언어 로케일 설정) 버그가 눈으로 분명히 보이는 경우(예: UI 컨트롤이 올바로 표현되지 않거나 IDE의 레이아웃 이슈 등)에는 화면 스크린샷을 넣어서 리포트를 읽는 사람이면 누구나 알 수 있도록 한다. 관련이 있다면, 장비의 로그를 추가한다. 안드로이드의 logcat 결과물 등 에러 메시지 또는 호출 스택을 넣을 때는 {code} 또는 {quote} 태그를 앞뒤로 달아서 넣는다. 버그 리포트가 외부 정보를 근거로 한다면 (예: API 호출과 관련된 MSDN 페이지), 해당 정보가 있는 페이지 링크를 넣는다. 버그 리포트에 코드를 넣으려면, 해당 프로젝트에 첨부하거나 또는 Steps(단계) 영역에 추가한다. 리포트 안에 텍스트로 기입하려면, 반드시 {code} 태그를 사용한다. JIRA가 코드를 해석해서 엉망으로 만들지 않도록 할 뿐만 아니라 리포트의 가독성이 높아진다. 첨부 파일의 크기를 가능한 최소화 한다. 파일을 ZIP(압축)하고 여기에는 첨부한 코드를 컴파일한 결과물인 (DCU, EXE 등) 바이너리 파일을 포함시키지 않아야 한다. 써드-파티 프로그램을 사용해야 하는 포맷은 사용하지 않는다. 리포트 1개에는 이슈를 1개만 넣는다. 이슈가 여러개인 경우 각각 따로 리포트하고, 필요하면 각 리포트를 서로 링크를 이용하여 연결하라. 4.6 각 단계 (Steps) 이곳의 목표는 해당 버그를 재현할 수 있도록 그 방법을 알려주는 것이다. 간결 명료하게 하고 읽기 쉽게 하라. 중요한 것은 해당 버그를 재현할 수 있도록 안내하는 것이다. 목적에 이르기까지의 단계는 최소화하라. 알아둘 점: 에러 메시지 또는 호출 스택은 단계 (Steps) 영역에 넣지 말고, 설명 (Description) 영역에 기입해야 한다. 예를 들어, 설명 (Description) 영역에는 다음과 같이 기입한다 "내 안드로이드 장비에서 더블 터치하여 TButton을 작동시키려고 하면 다음과 같은 에러가 발생한다: [에러 메시지]". 단계 (Steps)에는 해당 이슈를 재현하는 방법을 따라하기 방식으로 설명한다. 4.7 기대한 결과와 실제 결과 (Expected and Actual Results) 단계 (Steps)를 기록할 때, 맨 뒤에는 기대한 올바른 결과가 무엇이고, 실재로 발생된 결과가 무엇인지를 반드시 명시해야 한다. 예시-좋지 않음: Expected: 애플리케이션이 죽지 않아야 한다. Actual: 애플리케이션이 죽는다. 예시-더 좋음: Expected: 애플리케이션에 XXX 메뉴가 나타난다. Actual: 애플리케이션에서 Access violation이 발생한다 (첨부된 스택-추적기록을 참조할 것) 4.8 리포트 격리하기 (Isolate reports) 이미 등록된 리포트에 이어지는 생각이 있을 때에는 새 리포트로 등록하는 건 어떨지 생각해보라. 기존 리포트에 그냥 의견을 다는 것보다 좋을 수도 있다. 왜냐하면 새로 추가된 이슈가 별도로 추적될 수 있고, 필요한 조치가 진행되는 결과를 가져오기 때문이다. 5 중복 리포트 이해하기 (Understanding Duplicate reports) “duplicate (중복)" 리포트 표시는 QA(품질 보증) 팀에서 한다. 중복된 리포트 중 하나는 "마스터" 리포트가 되고 다른 하나는 “duplicate (중복)" 리포트가 되는데, 더 정확하고 자세한 정보를 담고 있는 리포트가 "마스터"가 된다. 마스터 리포트가 이미 정해진 경우에도, 중복된 리포트가 새로 또 등록되면 어느 것이 "마스터"가 될 것인지 다시 판단하게 되므로 마스터 리포트가 바뀔 수도 있다. 어느 경우이든 중복된 리포트가 더 많으면, 해당 이슈에 대한 정보가 더 많다는 의미이므로 더 좋다. 먼저 리포팅되었다고 해서 무조건 "마스터" 리포트가 되는 것이 절대 아니며, 보다 정확한 리포트가 "마스터"가 된다. 전형적으로, "duplicate 중복"으로 지정된 이슈 리포트의 상태 필드 값은 "Resolved"이며, 해결 필드 값은 "Duplicate"이다. 중복된 리포트에는 "마스터" 이슈로 갈 수 있는 링크가 제공된다. "마스터" 이슈의 상태를 확인하고 업데이트를 "Watch(관심 이슈로 등록)"하는 것이 좋다. 6 퀄리티 포탈에 있는 필드(들) 해석 방법 (How to interpret some of the fields in QP) 퀄리티 포탈은 엠바카데로 내부 시스템과 동기화되므로, 우리 내부 절차를 의미하는 필드 이름을 사용한다. 따라서 외부에서는 필드의 의미를 명확히 알기 어려울 수 있다. 아래 표를 통해서 우리 내부 시스템과 동기화되는 필드 값이 정확히 무슨 의미인지를 이해할 수 있다. 6.1 상태 필드 (Status field) 값 설명 Reported 새 버그 리포트, 테스터가 검토할 필요가 있음 Open 버그가 오픈(Open)됨. 해소해야 할 필요가 있음. 내부적으로 작업이 진행되는 동안에도 계속 이 상태로 표시됨 Resolved 작업 완료 후 제품에 반영됨, 리포트한 사람이 검증하거나 해결 여부를 논의할 수 있는 상태임 Needs Feedback 추가 정보/단계가 필요함 Closed 버그 리포트가 종료 됨. 더이상 조치할 필요 없음 버그 리포트가 처음 등록되면 “Reported” 상태이다. 엠바카데로 QA(품질 보증)의 테스터가 엠바카데로 내부의 버그 추적 시스템에서 검증을 하고 나면 상태가 “Reported”에서 “Open”으로 진행된다. 작업이 완료되고 출시된 제품 안에 반영되고 나면, 이 상태는 “Open”에서 “Resolved”로 진행된다. 픽스(fix)가 제공된 경우에만 “Resolved” 상태로 된다. 즉 R&D 팀 내부에서 구현이 되었다고 해도 외부로 제공되지 않으면 “Resolved” 상태로 바뀌지 않는 다는 점을 알아두기 바란다. 6.2 해결 필드 (Resolution Field) 값 설명 Fixed 버그가 수정(fix)됨 Cannot Reproduce 제출된 버그가 제품의 새 버전에서는 재현되지 않음 Works as Expected 현재 설계된 대로 작동함 Duplicate 버그 리포트가 이미 등록된 (그리고 아직 Open 상태인) 이슈와 중복됨 (중복된 버그 #를 보기 바람) Test Case Error 리포트에 기록된 버그에 대한 설명이 맞지 않음 Needs More Info 더 많은 정보/데모/단계가 있어야 우리 팀이 재현할 수 있음 No Longer Applies 기능이 제거되었거나 버그가 더이상 유효하지 않음 Won’t Fix 구현 또는 수정을 하지 않기로 결정됨 이슈의 해결 필드가 Needs More Info로 반환되면, 해당 리포트의 상태 필드는 'Needs Feedback'으로 표시된다. 이 경우 리포트를 제출한 사람이 더 많은 정보를 추가할 수 있게 된다. 정보를 추가할 때에는 "Update Content” 버튼을 사용해야만 한다. ‘Update Content’를 통해 변경이 완료되면 상태는 다시 ‘Reported’가 되고 QA(품질 보증)팀에서 검증 작업을 다시 시작한다. "Update Content” 버튼은 이미 제출한 이슈를 정정할 때에도 사용할 수 있다. 위에 설명된 권장 사항을 반영하여 보다 많은 세부 정보 그리고/또는 컨텍스트 정보를 추가하여 설명을 명확히 전달하도록 하기 바란다. 재현 단계들을 추가/점검 해보는 것도 좋다. 스크린샷 첨부 그리고/또는 프로젝트 첨부 역시 도움이 된다. 짦고 핵심을 전달하는 비디오도 역시 도움이 된다. 7 로그와 몇가지 팁 (Logs and Some More Tips) 코드인사이트 (CodeInsight)의 LSP 엔진과 관련된 이슈인 경우, DocWiki의 해당 글의 맨 뒤에 있는 내용을 참고하라. LSP 로그에는 해석(parse)되는 소스 코드가 상당한 부분을 차지하는 경우가 많은데, 만약 이 로그를 그대로 첨부해야 할 이유가 있다면 로그 파일을 퀄리티 포털 리포트에 그대로 첨부하지 말고 바로 전달하는 방법을 엠바카데로에게 문의하기 바란다. 마찬가지로, 파이어닥(FireDAC) 이슈를 리포팅하는 경우라면 환경 데이터와 추적 로그를 제공해야만 한다. 그 방법은 이글에 설명되어 있다. 설치와 겟잇(GetIt) 패키지에 대한 리포트와 관련해서는 GetItInstall.log 파일 설정은 아래 레지스트리를 통해 다룬다. HKEY_CURRENT_USERSOFTWAREEmbarcaderoBDSxx.0CatalogRepository 이 경우 로그 파일가 들어 있는 폴더는 다음과 같다. C:UsersPublicDocumentsEmbarcaderoStudioxx.0 퀄리티 포탈의 텍스트 편집기에서 글 형식을 다루는 방법은 여기를 참고하라. https://blogs.embarcadero.com/rad-studio-quality-portal-user-guide/#Hints_and_Tips 마지막으로, 버그 리포팅하기 관련 권장 사항에 대한 좋은 자료를 소개한다. http://www.mozilla.org/bugs/bug-reporting.html 인용하기 이 댓글 링크 다른 사이트에 공유하기 더 많은 공유 선택 사항
Recommended Posts
이 토의에 참여하세요
지금 바로 의견을 남길 수 있습니다. 그리고 나서 가입해도 됩니다. 이미 회원이라면, 지금 로그인하고 본인 계정으로 의견을 남기세요.