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

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는 일반적인 프로젝트 관리..

심플한 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 관리 프로세스를 글로 작성해..

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

Jira를 추천하는 이유?IT에서 일하고 있다면 Jira에 대해서 한 번쯤 들어 보셨을 겁니다. 개발자던 QA이던 구인 공고 단골 Job Description이기도 합니다. 보통 기업 혹은 개인이 JIRA를 사용한다고 하면 BTS(Bug Tracking System)로 많이 사용을 하고 있습니다. 하지만 JIRA Software는 단편적으로 BTS로만 사용하기에는 너무도 아까운 시스템이기 때문에 버그 트래킹뿐만이 아니라 실제로 실무에서 확장성 있게 어떻게 적용을 해야 하는지에 대해서 말씀드리고, 어느 부분부터 적용하는 것이 효율적인지에 대해서 말씀드리려 합니다. 😅 아래 글은 필자가 경험한 10여 년 간의 경험을 바탕으로 작성되었으며, 정답은 아닙니다.조금이라도 아래와 같이 적용을 생각해 보셨거나 하고..

테스트 결과 보고서와 품질 보고서는 다르다✔ 결함 우선순위는 개발자가 결함을 해결해야 하는 순서이고, 심각도는 결함이 제품 작동에 미치는 영향의 정도입니다.✔ 결함 우선순위는 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 테스트(주요 변경 내용: 테스트 절차 추가 , 결함관리 및 결함유형 추가 , ..