테스트 프로세스를 구축하려는 이유?테스트 프로세스 이론의 모든 내용을 실무에 모두 적용하는 것은 불가능합니다. 다만, 우리는 이론에서 현실에 잘 맞는 프로세스를 선택하여 가장 효과적이고, 효율적으로 테스트를 수행하기 위해 선택을 할 뿐입니다.  잘 맞는지는 해보지 않고는 알 수 없으며, 적용 후에는 후회보다는 좀 더 나은 프로세스를 만들기 위해 노력해야 합니다. 핏이 잘 맞는 프로세스 내에서 최고의 서비스 혹은 제품을 만들 수 있다는 점을 참고하시어 아래 내용들을 읽어 보시기 바랍니다. 기업 내에서 실제 테스트 프로세스 적용을 계획하고 계신다면 아래 서비스를 이용해 주시면 친절히 상담해 드리도록 하겠습니다. QA 및 테스트 프로세스 구축, 정립, 확립해 드립니다 | 100000원부터 시작 가능한 총 평점..

Jira는 프로세스 관리 및 커뮤니케이션 도구이다.Jira 시스템 관리자로 업무를 수행한지 벌써 10여년이 되어갑니다.그동안 개인적으로 Jira를 효율적으로 활용하기 위해 고민도 많이하고 구현도 많이 했는데요. 이번 크몽에서 테스트 프로세스, 나아가 품질 프로세스를 구축하기 위해 시작한 여정을 정리해 보았습니다. 해당 블로그는 회사에서 운영중인 블로그에 작성하였으며, 이력을 남기기 위해 큐레이션 합니다.  크몽에서 만들어가는 Jira를 활용한 프로세스 구축은 저에게 또 하나의 도전이 될 것 같습니다. [2022년] OO의 Jira 사용기 : 극대화 편Jira 사용성 개선 계획기존에도 Jira를 잘 사용하고 있었지만 좀 더 잘 사용해보고자 하는 의견이 많았습니다. 그래서 간단하게 Task를 정리하여 계획을..

Jira 개념 알기(3분 컷)Jira대한 기본 개념은 아래와 같습니다.JIRA 사용의 시작은 이슈 생성 = 내가 할 일을 만드는 것JIRA는 ALM(Application Lifecycle Management) 도구(이슈 관리 도구 X)앞으로 계속 연재하다보면 나올 개념을 잠깐 언급하면 ✨ 할 일은 곧 Jira에서 Backlog(백로그)라는 용어로 사용하게 된다. 사실 Backlog는 할 일로 단순한 의미는 아니지만 아직 처음 시작하는 우리에게는 어려운 의미를 깊게 알 필요없습니다. 앞으로 자연스럽게 알게 될 것입니다. Jira에서 이슈를 해결해 나가는 것은 매우 중요한 일입니다. 이슈를 해결한다고 하면 대부분 소스코드를 작성하거나 수정해서 해결해 나간다고 생각할 수도 있는데 이것은 Jira 시스템에 대한..

Overview지라(JIRA)라는 이름의 유래는 고지라라는 일본식 이름에서 따왔다고 합니다.아틀리시안에 따르면, 190개의 국가에 150,000명의 고객이 지라를 사용하고 있습니다.  Jira는 190 개국 180,000명 이상의 고객이 이슈 추적 및 프로젝트 관리에 사용하고 있으며, 버그 추적 및 프로젝트 관리를 위해 특정 시점에 Jira를 사용한 조직 중에는 Fedora Commons, Hibernate 및 Jira와 Bugzilla를 모두 사용하는 Apache Software Foundation이 있습니다.Jira에는 경쟁 업체 Bugzilla에서 마이그레이션 할 수 있는 도구가 포함되어 있고, Jira는 4 가지 패키지로 제공됩니다.- Jira Work Management는 일반적인 프로젝트 관리..

다이어그램을 활용하여 워크플로우 세팅하기지난 글까지 이슈가 무엇인지 알아보았고, 작업 흐름(Workflow)을 왜 만들어야 하는지에 대해서 알아보았습니다. 그리고 작업 흐름에서 가장 중요한 것은 다양한 작업의 흐름을 통합(카테고리화)하는 것이라고 말씀을 드렸습니다. 그럼 다양한 작업의 흐름을 카테고리화가 되었다는 가정하에 아래의 스텝을 따라 해 보시기 바랍니다. 작업 흐름을 만들고, 커스텀 페이지를 만들어서 작업 흐름에 따라 트리거(팝업)가 어떻게 발생하는지에 대해서 설명을 드리겠습니다. 트리거(팝업)의 활용이 왜 필요한지도 꼭 알아야 합니다. JIRA 데이터를 통해 보고서를 작성하기 위한 데이터 정제를 위해서 꼭 필요한 작업이기도 합니다. JIRA를 국문으로 설정했을 때는 업무 흐름으로 표시되고 있기 ..

너무 많은 내용은 피로감이 늘어날 뿐이다테스트 요청서는 테스트를 수행하기 위해 꼭 필요한 문서입니다. 테스트 요청서는 테스트에 필요한 정보를 모아놓은 문서이며, 테스트의 범위를 결정하기도 하는 중요한 문서입니다. 또한, 테스트가 완료되었을 때 필요한 정보를 통해 이후 작업을 수행할 수도 있습니다. 오늘은 테스트에 꼭 필요한 테스트 요청서에 대해서 간단하게 알아보려 합니다. 그리고 테스트 요청서에 필요한 정보를 Confluence에서 JIRA 데이터를 어떻게 가져오는지도 간략하게 설명드리도록 하겠습니다. Confluence에 테스트 요청 양식 만들기 No.구분옵션 여부상세 설명1프로젝트명필프로젝트의 이름을 작성.2담당 개발 부서필담당 개발 부서명을 작성3담당 개발 파트옵담당 개발 파트를 작성4담당 개발장옵..

심플한 VOC(Voice Of Customer)프로세스VOC(Voice Of Customer)를 관리하는 이유는 CS(Custormer Service)의 만족도를 높이기 위함입니다.VOC를 관리하기 위해서는 그에 맞는 프로세스가 필요한데요.간단하게 설명하면 VOC 영역은 회사와 고객 간의 커뮤니케이션을 이야기합니다. JIRA에서는 젠데스크를 통해 ITSM(IT Service Management) 구축이 가능하며, ITSM을 구축하게 되면 SLA(Service Level Agreement)를 관리할 수 있게 됩니다. 회사마다 SLA를 관리하는 방법은 다를 수 있으니 참고만 해주시면 되고, 아래 내용은 보편적인 시스템의 방식으로 ITSM과 JIRA가 구분된 시스템 내에서의 VOC 관리 프로세스를 글로 작성해..

테스트 프로세스 글로만 작성해보기"QA = 테스트"라고 생각하시는 분들이 간혹 있습니다.결론은 "QA ≠ 테스트"가 맞습니다. QA(품질 보증)을 테스트라고 생각하면 아주 큰 오산입니다. 테스트는 품질 보증을 하기 위한 하나의 수단일 뿐입니다.제품이나 서비스의 상태를 확인하기 위한 방법이 테스트(결함을 찾기 위한 행위)인 것입니다. 다른 말로 풀이하면 테스트 방법은 수 없이 많으며, 우리는 100%로 확인하지 못하는 소프트웨어를 최대한 결함 없이 출시하기 위해서 각양각색의 테스트를 통해서 확인 활동을 하는 것입니다. 그것이 바로 테스팅이라는 활동입니다.  QA라는 단어는 아주 포괄적인 단어이고, 어떤 회사에서는 포지션명이 될 수도 있고, R&R이 될 수도 있으며, 직함, 직책이 될 수도 있습니다. QA는..

Jira의 워크플로우 = 프로세스지난 글까지는 이슈가 무엇인지에 대해서 알아보았습니다. 다시 요약하자면 JIRA에서 "이슈 = 해야 할 일"이고, JIRA에서 "프로젝트 = 이슈의 모음"이라는 점만 잘 기억해 주시면 아래의 내용을 이해하시는데 도움이 될 것입니다. 이 전 글을 읽어 보지 않으시고, 아래의 개념을 이해하려고 하시면 좀 어려울 수 있는 부분입니다. "난 JIRA의 이슈와 프로젝트에 대해서 조금은 알아" 하시는 분들은 자연스럽게 아래 글을 읽어 보시길 바랍니다.   [실무 - Chap.2] 지라(JIRA) 프로세스를 체계적으로 구축하기 위한 방법 공유!!시스템 활용을 위한 최소한의 공통 기능 정의이전 글에서는 JIRA를 도입하기 전에 무엇을 준비해야 하는지 알아보았습니다. 앞으로의 글은 JIR..

테스트 결과 보고서와 품질 보고서는 다르다✔ 결함 우선순위는 개발자가 결함을 해결해야 하는 순서이고, 심각도는 결함이 제품 작동에 미치는 영향의 정도입니다.✔ 결함 우선순위는 3가지 유형으로 분류되고, 심각도는 중요의 4가지 유형으로 분류됩니다.✔ 결함 우선순위는 스케줄링과 연관되고, 심각도는 기능 또는 표준과 연관됩니다.✔ 결함 우선순위는 버그를 수정해야 하는 시기를 나타내고, 심각도는 제품 기능에 대한 결함의 심각성을 나타냅니다.✔ 결함 우선 순위는 관리자 / 클라이언트와 협의하여 결정되며 결함의 심각도 수준은 QA 혹은 테스터가 결정합니다.✔ 결함 우선 순위는 비즈니스 가치에 따라 결정되는 반면 심각도는 기능에 따라 결정됩니다.✔ 결함 우선순위 값은 주관적이며 프로젝트 상황의 변화에 따라 일정 기간..

언제? 어느 시점에 테스트가 필요한가?소프트웨어 배포 생명 주기를 확인하고, 빌드 전 QA 혹은 테스터가 무엇을 해야 하는지 한번 생각해 봅시다. 개발 초기라고 하면 보통은 요구사항 분석부터 생각할 수도 있겠지만 이건 프로젝트 전체를 봤을 때 이므로 지금은 작게 한번 생각을 해보려 합니다. 개인적으로 생각하는 현실에서의 개발 초기는 배포 전 개발이 시작하는 때. 즉 이슈가 발생한 시점이라고 할 수 있습니다.  이슈가 발생하면 분석하고, 필요시 소스 수정으로 인한 변경 개발을 하게 될 텐데요. 이 시점들을 구분해 놓은 것이 아래 소프트웨어 배포 생명 주기 이미지입니다. Free Alpha프리 알파(Pre-Alpha)는 테스트 이전의 소프트웨어 프로젝트 기간 동안 수행되는 모든 활동을 가리킨다. 이 활동에는..

테스트 계획서 작성하기(마이피플.apk) NOTICE 본 문서의 내용은 LQDQ사의 자산으로 개인의 동의 없이 배포 또는 복사할 수 없습니다. 아래 모든 내용은 App의 Spec 문서 없이 저의 임의대로 작성 되었음을 알려 드립니다. 본 문서를 샘플로 사용하셔도 무방합니다.Copyright© 2020 LQDQ All Rights Reserved. 문서 변경 이력(가정) 날짜작성자버전내용 이정민Ver. 0.0Mypeople 테스트 계획서. 홍길동Ver. 0.1  김철수Ver. 0.2  김철수Ver. 1.1김영희 수석에게 최종 리뷰를 맡기기 위한 전체 검토 / 용어 뒷부분으로 이동 .  김영희Ver. 2.1전체적인 Review 테스트(주요 변경 내용: 테스트 절차 추가 , 결함관리 및 결함유형 추가 , ..