361616의 등록된 링크

키자드에 등록된 총 66개의 포스트를 확인하실 수 있습니다.

Naver Blog

[자격증/ISTQB MAT] ISTQB CTFL-MAT 요약정리에 앞서..

다음의 이야기는 SQA 현업에 재직 중인 한 명의 사람이 올해 ISTQB CTFL (International Software Testing Qualifications Board Certified Tester Foundation Level) 과 ISTQB CTFL-AT (Agile Tester) 및 ISTQB CTFL-MAT (Mobile Application Testing) 자격증을 취득을 위한 공부를 하면서 느낀 점이다. CTFL과 AT는 이미 취득했고, MAT는 2023년 11월에 시험을 볼 예정이다. CTFL과 AT를 취득한 내가 다음으로 MAT 자격증을 취득을 도전하는 이유는 현재 모바일 App 관련 일을 주로 하고 있는 것이 첫 번째 이유이고, 두 번째로는 한글 시험이 있다는 것이다. 영어를 못 읽는 것은 아니지만, 전문용어들과 시험을 볼 정도로 빠르게 읽지는 못하기 때문에 한글 시험이 있는 것을 택했다. 아직 시험에 합격하지는 않았지만, 실러버스를 공부해 본 느낌으로는 실

원문보기 내부링크
Naver Blog

[자격증/ISTQB AI] Chapter 5. 기계학습 기능적 성능 측정지표 (ML Functional Performance Metrics) : Part-1

Chapter 5.1 혼동행렬(Confusion Matrix) 혼동 행렬 예시 혼동 행렬은 달리 표현될 수 있으나 항상 True Positive(TP), False Positive(FP), False Negative(FN) 그리고 Ture Negative(TN)의 네 가지 가능한 상황에 대한 값을 가진다. 혼동 행렬 기반 측정 지표 정확도(Accuracy) 정확도 = (TP + TN) / (TP + TN + FP + FN) * 100% 정확도는 모든 올바른 분류의 백분율을 측정한다. 정밀도(Precision) 정밀도 = TP / (TP + FP) * 100% 정밀도는 올바르게 예측된 Positive 비율을 측정한다. Positive 예측에 대해 얼마나 확신을 가질 수 있는지를 나타내는 척도이다. 재현율(Recall)(민감도) 재현율 = TP / (TP + FN) * 100% 재현율은 실제 Positive 중 올바르게 예측된 비율을 측정한다. Positive를 놓치지 않는 것에 대해

원문보기 내부링크
Naver Blog

[자격증/ISTQB AI] Chapter 6. 기계학습 - 신경망과 테스팅(ML - Neural Networks and Testing) : Part-1

Chapter 6.1 신경망(Neural Networks) 단층 퍼셉트론(Perceptron) 초기 인공 신경망은 생물학적 뉴런의 연결로 볼 수 있는 인간 뇌의 기능을 모방하기 위해 고안되었다. 단층 퍼셉트론은 인공 신경망 구현의 초기 사례 중 하나이다. 하나의 층(즉, 단일 뉴런)으로 구성된 신경망을 가지고 있고, 입력 값이 특정 클래스에 속하는지를 결정하는 분류기의 지도 학습에 사용할 수 있다. 다층 퍼셉트론(심층(Deep) 신경망) 현재 대부분의 신경망은 여러 개의 층으로 구성되지 때문에 심층 신경망으로 간주하며 또한 다층 퍼셉트론으로 간주할 수 있다. 심층 신경망은 세 가지 유형의 층으로 구성된다. 입력층 카메라로부터 얻는 픽셀 값과 같은 입력을 받는다. 은닉층 입력층과 출력층 사이에 위치하며, 노드라고 불리는 인공 뉴런으로 구성되어 있다. 출력층 외부에 결과를 제공한다. 심층(Deep) 신경망의 구조 인공 뉴런(노드) 한 층에 있는 뉴런들은 다음 층에 있는 뉴런들과 연결 되

원문보기 내부링크
Naver Blog

[봉사] 진접 광릉숲 대축제 한글 사랑 캠페인 - 2022년 남양주 청년봉사단 일곱 번째 봉사활동

지난번 이야기 지난번 남양주 청년 봉사단 이그나이트 봉사 이야기가 궁금하시다면 아래 글을 참고해 주세요~~! [봉사] 이그나이트(다산정약용도서관) - 2022년 남양주 청년봉사단 여섯 번째 봉사활동 지난번 이야기 지난번 남양주 청년 봉사단 중간 평가회 이야기가 궁금하시다면 아래 글을 참고해 주세요~~!... blog.naver.com 본론 이번에는 제가 2022년에 남양주 청년봉사단 활동을 하면서 두 번째(첫 번째는 다다음 글에 나옵니다^^)로 마음에 들었고, 2024년 현재에는 가장 애정이 가는 봉사 중에 하나인, 진접 광릉숲 대축제 한글 사랑 캠페인 봉사입니다. 지난번 중간 평가회 이후 가장 잘 된, 정말 청년 봉사단이 주도한 그런 기획 봉사가 아닐까 싶습니다. 그만큼 이번 편은 할 말이 많이 생각이 나네요. 글이 조금 길어질 수도 있습니다. 그럼 시작~ 진접 광릉숲 대축제 한글 사랑 캠페인은 주임님의 활기찬 공지와 함께 시작되었습니다.(그립습니다ㅠ) 진접 광릉숲 대축제는 남양주

원문보기 내부링크
Naver Blog

[자격증/ISTQB AI] Chapter 3. 기계학습 개요 (Machine Learning Overview) : Part-3

Chapter 3.3 기계학습 종류 선택(Selecting a Form of ML) 적절한 기계학습 접근법을 선택할 때의 지침 선택한 기계학습 접근법에 충분한 훈련과 테스트 데이터가 있어야 한다. 지도학습의 경우 제대로 라벨링 된 데이터가 필요하다. 출력 라벨이 있으면 지도학습일 수 있다. 출력이 이산형(discrete)이면서 범주형(categrical)이면, 분류일 수 있다. 출력이 태생적으로 숫자형이고 연속형이면, 회귀일 수 있다. 주어진 데이터 세트에 출력값이 없으면, 비지도 학습일 수 있다. 문제가 유사한 데이터를 그룹으로 나누는 것과 관련된 경우, 군집화 일 수 있다. 문제가 동시 발생 데이터 항목을 찾는 것과 관련된 경우, 연관일 수 있다. 강화 학습은 환경과 상호작용이 있는 상황에 적합하다. 문제가 여러 상태의 개념과 관련돼 있고, 각 상태에서 어떤 결정이 이루어지는 경우, 강화 학습을 적용할 수 있다. Chapter 3.4 기계학습 알고리즘 선택과 관련된 요소(Fact

원문보기 내부링크
Naver Blog

[자격증/ISTQB AI] Chapter 4. 기계학습 - 데이터 (ML - Data) : Part-1

Chapter 4.1 기계학습 워크플로에서의 데이터 준비 데이터 준비에는 기계학습 구현 워크플로 전체 노력의 평균 43%가 들어가며, 기계학습 워크플로에서 가장 자원 집약적인 활동이라 할 수 있다. cf) 모델 선택과 구현에는 전체의 17%만 들어간다. 데이터 파이프라인 데이터 준비 단계는 데이터 파이프라인에 속한다. 원본 데이터를 입력받아 기계학습 모델을 훈련하거나 훈련된 기계학습 모델이 데이터를 예측에 사용 가능한 형식으로 출력한다. 데이터 준비 활동 데이터 수집(Data Acquisition) 식별(Identification) 훈련과 예측에 사용할 데이터 유형을 식별한다. ex) 자율 주행 자동차의 경우 레이더, 비디오, 탐지, 범위 지정 등의 데이터의 필요성 식별을 포함할 수 있다. 수집(Gathering) 데이터의 출력을 식별하고 데이터 수집 방법을 결정한다. 수집된 데이터는 다양한 형식일 수 있다. 라벨링(Labeling) 데이터 전처리(Data Pre-processing

원문보기 내부링크
Naver Blog

[봉사] 유기견 센터 청소 - 2022년 남양주 청년봉사단 두 번째 봉사활동

지난번 이야기 지난번 첫 번째 봉사가 궁금하다면 아래 글을 참고해 주세요~! [봉사] 유기견들을 위한 수제 간식 및 노즈워크 만들기 - 2022년 남양주 청년봉사단 첫 번째 봉사활동 지난 번 이야기 청년 봉사단의 시작이 궁굼하시다면 아래 글을 참고해주세요~! 간식 만들고 노즈워크 만드... blog.naver.com 다시 방문하게 된 남양주시 유기견 센터 저번에 유기견 수제 간식과 노즈워크를 전달하러 유기견 센터에 방문했었고, 이번에는 유기견 센터 청소를 위해 다시 한번 방문하였습니다. 그래도 한 번 와본 곳이라 그런지 조금은 익숙해졌는데요, 그때도 환경이 아주 깨끗하지는 못하다는 점을 알고 있었고 그래서 저희 남양주 청년 봉사단이 출동하게 되었습니다. 수백 마리의 유기견들은 정말 열약한 환경에서 살고 있었습니다. 시설은 전용 시설 같은 게 아닌, 주택 같은 곳을 개조하여 만들어진 느낌이었습니다. 실제 사람이 살 수 있게 부엌도 있고 화장실도 있고 있을 건 다 있었습니다. 아마도 사

원문보기 내부링크
Naver Blog

[봉사] 夜한 플로깅(호평동) - 2022년 남양주 청년봉사단 세 번째 봉사활동

지난번 이야기 지난번 유기견 봉사가 궁금하시다면 아래 글을 참고해 주세요~! [봉사] 유기견 센터 청소 - 2022년 남양주 청년봉사단 두 번째 봉사활동 지난번 이야기 지난번 첫 번째 봉사가 궁금하다면 아래 글을 참고해 주세요~! 다시 방문하게 된 남양주시 ... blog.naver.com 우리 동네는 우리가 치운다! 세상에는 다양한 종류의 봉사가 많습니다. 그중에서도 어쩌면 가장 쉽게 실천할 수 있는데, 하지만 그렇다고 대부분의 사람들이 개인적으로 하지는 않는 플로깅 봉사를 하게 되었습니다. 저도 플로깅 봉사는 학창 시절에 단체로 할 때를 제외하고는 따로 해보지 않았던 것 같은데요, 이번에는 남양주시 청년 봉사단과 함께 하게 되었습니다. 장소는 남양주시 호평동으로, 호만천 산책로와 가게들 거리의 쓰레기를 줍기 위해 평내호평역에서 모이게 되었습니다. 남양주시 자원봉사 센터의 주임님이 장갑과 비닐봉지, 그리고 마실 물을 준비해 주셨습니다. 각자에게 그것들은 분배하고, 청년 봉사단은 2

원문보기 내부링크
Naver Blog

[봉사] 마을 안전 학교(진접) - 2022년 남양주 청년봉사단 네 번째 봉사활동

지난번 이야기 지난번 플로깅 봉사가 궁굼하시다면 아래 글을 참고해 주세요~~!! [봉사] 夜한 플로깅(호평동) - 2022년 남양주 청년봉사단 세 번째 봉사활동 지난번 이야기 지난번 유기견 봉사가 궁금하시다면 아래 글을 참고해 주세요~! 우리 동네는 우리가 치운다!... blog.naver.com 비상 상황 시에는 이렇게! 이번에는 앞에서 했던 유기견, 플로깅과는 또 다른 유형의 봉사를 진행하게 되었습니다! 마을안전학교에서 보조 스탭역할로 봉사하는 것이었는데요, 저희의 역할은 각 부스들의 역할 안내와 체험 하실 분들의 대기표 관리, 그리고 정리등의 역할 이었습니다. 장소는 진접 장승 물놀이터에서 진행했습니다. 진접에 이런 물놀이터가 있는지 당시에 처음 알았습니다. 그 옆에는 엄청 큰 정글짐과 미끄럼틀이 있었던 것도 인상 깊네요. (사실 한 봉사단원이 그걸 올라가서 내려오며 찍은 사진이 기억이 납니다^^) 진접 장승 물놀이터 봉사는 9시 30분부터 13시까지 진행되었습니다. 부스는 리

원문보기 내부링크
Naver Blog

[봉사] 중간평가회(기획 봉사) - 2022년 남양주 청년봉사단 다섯 번째 봉사활동

지난번 이야기 지난번 마을안전학교 청년 봉사단 네 번째 봉사가 궁금하시다면 아래 글을 참고해 주세요~~! [봉사] 마을 안전 학교(진접) - 2022년 남양주 청년봉사단 네 번째 봉사활동 지난번 이야기 지난번 플로깅 봉사가 궁굼하시다면 아래 글을 참고해 주세요~~!! 비상 상황 시에는 이렇게!... blog.naver.com 남양주 청년 봉사단의 방향성 : 기획 봉사 이날은 사실 봉사는 아니고 봉사를 위한 단체 회의가 진행되었습니다. 회의는 2022년 8월 27일 토요일 9시 30분부터 12시 30분까지 진행 예정이었는데, 조금 길어져서 1시까지 진행되었습니다. 장소는 남양주시 자원봉사센터 1층 소회의실에서 진행되었습니다. 이날의 회의는 먼저 남양주시 자원봉사센터의 정진춘 센터장님의 말씀으로 시작되었습니다. 봉사에 관한 좋은 말씀들을 많이 해주실 뿐만 아니라 인생에 관한 좋은 말씀들도 해주셨던 게 기억에 남네요. 남양주시 자원봉사센터의 정진춘 센터장님의 말씀 시간 이후에는 전문 강사

원문보기 내부링크
Naver Blog

[자격증/ISTQB AI] Chapter 4. 기계학습 - 데이터 (ML - Data) : Part-2

Chapter 4.3 데이터 세트 품질 문제(Dataset Quality Issues) 품질 문제 <<---- 결함으로 연결될 수 있다. 잘못된 데이터 수집한 데이터가 부정확하거나(예 : 오류가 있는 센서에서 수집) 잘못 입력됨(예 : 복사-붙여넣기 오류) 불완전한 데이터 데이터 값이 누락될 수 있음(예 : 레코드의 특정 필드가 비어 있거나 특정 시간의 데이터가 누락되었을 수 있음). 불완전한 데이터의 원인은 보안 문제, 하드웨어 문제, 인적 오류 등 다양한 원인이 있을 수 있음. 잘못 라벨링 된 데이터 다양한 원인으로 데이터 라벨링이 잘못될 수 있음. 데이터 부족 사용 중인 학습 알고리즘에서 패턴을 인식하기에 데이터가 부족함(알고리즘에 따라 필요한 최소 데이터 품질이 달라질 수 있음). 전처리 되지 않은 데이터 데이터는 깨끗하고 일관된 형식을 가지며 원하지 않는 이상 값이 포함되지 않도록 전처리 되어야 함. 오래된 데이터 학습과 예측 모두에 사용되는 데이터는 가능한 최신 데이터이어

원문보기 내부링크
Naver Blog

[봉사] 이그나이트(다산정약용도서관) - 2022년 남양주 청년봉사단 여섯 번째 봉사활동

지난번 이야기 지난번 남양주 청년 봉사단 중간 평가회 이야기가 궁금하시다면 아래 글을 참고해 주세요~~! [봉사] 중간평가회(기획 봉사) - 2022년 남양주 청년봉사단 다섯 번째 봉사활동 지난번 이야기 지난번 마을안전학교 청년 봉사단 네 번째 봉사가 궁금하시다면 아래 글을 참고해 주세요~~!... blog.naver.com 자원봉사 우수사례 발표대회 "이그나이트" 2022년 9월 3일, 경기도 남양주시에 위치한 다산정약용도서관에서 이그나이트라는 행사가 열리게 되었고, 봉사자를 지원받게 되었습니다. 저는 당연히 봉사에 참여를 했습니다. 이 당시에는 이그나이트라는 행사를 처음 듣게 되었고 뭔지도 잘 모르는 상태였습니다. 일단 봉사를 한다고 하니 일단 참석을 투표했습니다. 정약용도서관 정약용도서관 정보 및 도서검색 제공 lib.nyj.go.kr 이그나이트를 간단히 소개하자면 "자원봉사 우수사례 발표대회"라고 할 수 있습니다. 2022년 남양주시에서 활동하는 자원봉사 단체 중에서 우수한

원문보기 내부링크
Naver Blog

[봉사] 2024년 남양주 청년봉사단 발대식

지난번 이야기 지난 2022년 청년봉사단 활동이 궁금하시다면 아래 글을 참고해 주세요~! [봉사] 2022년 남양주 청년봉사단 발대식 2022년 회상의 이유 안녕하세요. 네? 지금 2024년인데 2022년 글 잘못 올리신 거 아니냐구요? 아닙니다. 여... blog.naver.com 2024년 남양주 청년 봉사단 그 시작 2024년 새해가 된지도 어느덧 3개월이 가까이 지났습니다. 다들 새해가 되면 다짐이라던가 올해는 어떻게 살아야지~ 하는 계획 등을 구체적으로든 간략하게 든 세우실 텐데요, 저도 마찬가지였습니다. 그중 하나는 '올해도 청년 봉사단을 잘 해보자'였습니다. 참 두루뭉실하고 간략한 계획입니다. 하지만 저에게는 상당히 뜻깊은데요. 2022년 남양주 청년 봉사단을 시작하고 어느덧 3년이 되었기 때문입니다. 처음에는 그냥 해보자! 하던 것이, 봉사라는 따뜻한 마음으로 하는 활동과 그 안에서 새로 만난 인연들, 그리고 제가 20년간 살아온 남양주 같은 모든 것들이 단체에 애착을

원문보기 내부링크
Naver Blog

[자격증/ISTQB AI] ISTQB CTFL AI 자격증 정보 및 공부

저는 올해는 2024년 5월 21일에 있는 ISTQB AI(artificial intelligence) 자격증을 취득해 보고자 공부 중에 있습니다. 이미 실라버스 1회독을 마쳤고, 이제 2회독을 진행하려고 하는데요, 이쯤에서 ISTQB AI 자격증에 대한 정보와 제가 1회독을 하며 느꼈던 점 등을 적어보고자 합니다. 일단 ISTQB AI 자격증에 대해 알아보겠습니다. (주) STA 테스팅컨설팅이 인증 교육기관으로 진행하는 이 시험은 ISTQAB CTFL 자격증이 있어야만 시험이 가능합니다. 해당 자격증을 보유하고 있지 않다면, 제 다른 글을 먼저 살펴보시고, ISTQB CTFL을 취득하시고 오시는 것을 추천드립니다. https://blog.naver.com/361616/223315078536 ISTQB CTFL 요약 정리에 앞서... ISTQB CTFL(Foundation Level)은 이미 취득한지 1년이 지난 시험입니다. 그럼에도 요약 정리를 ... blog.naver.com I

원문보기 내부링크
Naver Blog

[자격증/ISTQB AI] Chapter 1. 인공지능 소개 (Introduction to AI) : Part-1

Chapter 1.1 인공지능의 정의와 인공지능 효과 (Definition of AI and AI effect) 인공지능(AI ; Artificial Intelligence) 정의 : 엔지니어링 된 시스템이 지식과 기술과 습득, 처리, 적용할 수 있는 능력. 인공지능의 정의는 변화하고 있으며 시대에 따라 다르다. 인공지능 효과 어떤 요소를 가져야 인공지능인가에 대한 인식의 변화 Chapter 1.2 약인공지능, 강인공지능, 초인공지능 (Narrow, General and Super AI) 약인공지능 시스템(Narrow) 제한된 환경에서 특정 작업을 수행하도록 프로그래밍 되어 있다. 현재 이런 형태의 인공지능은 널리 사용되고 있다. 게임 플레이 시스템, 스팸 필터, TC 생성기, 음성 도우미 등 강인공지능 시스템(General) 인간과 유사한 일반적인(광범위한) 인지 능력을 갖추고 있다. 인간처럼 환경을 추론하고 이해할 수 있으며 그에 따라 행동할 수 있다. 2021년 말까지 강인공지

원문보기 내부링크
Naver Blog

[자격증/ISTQB AI] Chapter 1. 인공지능 소개 (Introduction to AI) : Part-2

Chapter 1.7 서비스형 인공지능 (AI as a Service(AIaaS)) 머신러닝 모델과 같은 인공지능 컴포넌트는 조직 내에서 개발하거나, 외부에서 다운로드하거나, 웹 서비스(AIaaS)로 사용할 수 있다. 인공지능 기능의 일부는 시스템 내에서 제공하고, 일부는 서비스로 사용하는 하이브리드 접근 방식도 가능하다. 기계학습을 서비스로 사용하는 경우, 웹을 통해 기계학습 모델에 접근할 수 있으며 데이터 준비와 저장, 모델 훈련, 검증, 튜닝(tuning), 테스팅, 배포에 대한 지원도 받을 수 있다. Chapter 1.7.1 서비스형 인공지능 계약 서비스형 인공지능 계약 일반적으로 가용성과 보안 책무를 정의하는 서비스 수준 계약(SLA ; Service Level Agreement)을 포함한다. 이런 SLA는 보통 서비스 가동 시간과 결함 수정을 위한 응답 시간을 포함하지만, 기계학습의 기능적 성능 메트릭(정확도 등)을 정의하는 경우는 거의 없다. 서비스형 인공지능은 구독 형

원문보기 내부링크
Naver Blog

[자격증/ISTQB AI] Chapter 2. 인공지능 기반 시스템 품질 특성 (Quality Characteristic for AI-Based Systems) : Part-1

Chapter 2.1 유연성과 적응성 (Flexibility and Adaptability) 유연성(Flexibility) 시스템이 본래의 시스템 요구사항의 일부가 아닌 상황에서 얼마만큼 사용될 수 있는가 하는 정도. 적응성(Adaptability) 의도와는 다른 하드웨어나 변화하는 운영 환경 등의 새로운 상황에 맞게 제품을 수정하려고 할 때의 중요성. 유연성과 적응성 모두 다음과 같은 상황에 유용하다. 시스템 배포 시 운영 환경을 완전히 알 수 없는 경우. 시스템이 새로운 운영 환경에 대처할 거라고 기대되는 경우. 시스템이 새로운 상황에 적응할 거라고 기대하는 경우. 시스템이 언제 동작을 수정해야 하는지 결정해야 하는 경우. 인공지능 기반 시스템의 유연성과 적응성 요구사항에는 시스템이 적응해야 할 환경 변화에 대한 세부 사항이 포함되어야 한다. 이런 요구 사항은 시스템이 스스로 적응시키는데 사용할 수 있는 시간과 자원에 대한 제약 조건(예 : 새로운 유형의 개체 인식에 시스템이 적

원문보기 내부링크
Naver Blog

[자격증/ISTQB AI] Chapter 2. 인공지능 기반 시스템 품질 특성 (Quality Characteristic for AI-Based Systems) : Part-2

Chapter 2.5 윤리 (Ethics) 윤리(Ethics) 행동을 통제하는 수용된 신념 체계, 특히 도덕에 기반한 체계. 윤리적이라 여겨지는 것은 시간이 지남에 따라 변할 수 있고 지역이나 문화에 따라서도 변할 수 있다. 한 지역에서 다른 지역으로 인공지능 기반 시스템을 배포할 때 이해관계자 간의 가치관 차이를 고려해야 한다. 2019년 경제협력개발기구(OECD)가 발표한 국제 표준인 '인공지능 권고안' 인공지능은 포괄적 성장, 지속가능한 개발, 웰빙을 이끌어 인간과 지구에 도움이 돼야 한다. 인공지능 시스템은 법치, 인권, 민주적 가치, 다양성의 가치를 존중하고 공정한 사회 보장을 위해 필요한 적절한 보호 장치를 포함해야 한다. 결과를 사람이 이해할 수 있고 이의를 제거할 수 있도록 인공지능 전반에 대한 투명성이 있어야 한다. 인공지능 시스템은 수명이 다할 때까지 견고하고 보안이 확보된 안전한 방식으로 기능해야 하며 잠재적 위험은 지속적으로 평가돼야 한다. 인공지능 시스템을 개

원문보기 내부링크
Naver Blog

[자격증/ISTQB AI] Chapter 3. 기계학습 개요 (Machine Learning Overview) : Part-1

Chapter 3.1 기계학습 종류 (Forms of ML) Chapter 3.1.1 지도 학습 지도 학습 알고리즘 훈련 단계에서 라벨링이 된 데이터를 가지고 기계학습 모델을 만든다. 라벨링 된 데이터는 일반적으로 한 쌍(페어)의 입력 값으로 구성되며(예 : 강아지 이미지와 라벨 "강아지") 훈련 중 알고리즘을 입력 데이터(예 : 강아지 이미지)와 출력 라벨(예 : 강아지 또는 고양이) 사이의 관계를 추론하는 데 사용된다. 기계학습 모델 테스팅 단계에서는 학습에 사용하지 않은 새로운 데이터 세트를 훈련된 모델에 적용해 결과를 예측하게 된다. 출력 정확도 수준이 만족스러우면 모델을 배포한다. 지도 학습으로 해결되는 문제 분류 입력을 미리 정해진 몇 개의 클래스 중 하나로 분류해야 하는 문제에 사용된다. ex) 이미지에서 얼굴을 인식하거나 물체를 감지하는 것. 회귀 기계 학습 모델이 회귀 분석을 사용해 어떤 숫자를 예측해야 하는 문제에 사용된다. ex) 습관에 관한 입력 데이터를 기반으

원문보기 내부링크
Naver Blog

[봉사] 2022년 남양주 청년봉사단 발대식

2022년 회상의 이유 안녕하세요. 네? 지금 2024년인데 2022년 글 잘못 올리신 거 아니냐구요? 아닙니다. 여러분이 보신 글자가 맞습니다. 2024년 2월에 2022년 3월에 있었던 일을 끄집어내어 써보고자 합니다. 갑자기 왜 2022년 글이나 쓰고 있나 싶지만, 나름의 이유가 있습니다. 일단 2024년 남양주 청년봉사단 3기 발대식이 2월 24일로 잡혔습니다. 2022년에 남양주 청년봉사단이 처음 생겼는데요, 저는 초기 멤버로써 지금까지 계속 활동하고 있습니다. 생각해 보면 참 많은 일들이 있었습니다. 좋을 친구들을 만났고, 좋은 경험, 좋은 봉사 혹은 새로운 봉사활동을 했습니다. 그렇게 시간이 빠르게 흘러 어느덧 2024년 봉사단도 3기를 맞았습니다. 이번에 담당자분이 바뀌셔서, 1기 2기 같은 기수제를 안 한다고 했지만, 저는 그냥 이렇게 부르는 게 편하니까 이렇게 하겠습니다. 아무튼 봉사를 이렇게 하고 있는데, 남는 건 사진뿐이라고 하죠? 그런데 정말 사진만 남는다는

원문보기 내부링크
Naver Blog

[자격증/ISTQB AI] Chapter 3. 기계학습 개요 (Machine Learning Overview) : Part-2

Chapter 3.2 기계학습 워크플로 (ML Workflow) 목표 이해(Understand the Objectives) 비지니스 우선순위와 부합하도록 배포할 기계학습 모델의 목적에 대한 이해와 이해관계자 합의가 이루어져야 한다. 개발하는 모델에 대한 기준을 정의해야 한다. 프레임워크 선택(Select a Framework) 목표, 인수, 기준, 비지니스 우선순위를 기준으로 적합한 인공지능 개발 프레임워크를 선택해야 한다. 알고리즘 선택과 구현(Select & Build the Algorithm) 기계학습 알고리즘은 목표 인수 기준, 사용 가능한 데이터를 포함한 다양한 요소를 기반으로 선택해야 한다. 알고리즘은 직접 코딩할 수도 있지만, 미리 작성된 코드 라이브러리에서 가져오는 경우가 많다. 그런 다음 모델 훈련을 위해 필요하다면 알고리즘을 컴파일한다. 데이터 준비와 테스트(Prepare & Test Data) 데이터 준비는 데이터 수집과 데이터 전처리 및 특성 엔지니어링(feat

원문보기 내부링크
Naver Blog

[봉사] 유기견들을 위한 수제 간식 및 노즈워크 만들기 - 2022년 남양주 청년봉사단 첫 번째 봉사활동

지난 번 이야기 청년 봉사단의 시작이 궁굼하시다면 아래 글을 참고해주세요~! 2022년 남양주 청년봉사단 발대식 서론 : 2022년 회상의 이유 안녕하세요. 네? 지금 2024년인데 2022년 글 잘못 올리신 거 아니냐구요? 아닙... blog.naver.com 간식 만들고 노즈워크 만드는 게 자원봉사라고? 자원봉사라는 것은 사실 상당히 주관적인 부분입니다. 조금 과장하자면 그냥 이건 자원봉사다~라고 하면 자원봉사가 되는 느낌이랄까..? 저는 유기견 자원봉사를 한다고 하길래 당연히 유기견 센터 같은 곳에 가서 센터 청소해 주고 강아지들 산책시켜주고 그런 것만 생각했는데, 제 갇혀 있는 생각을 깨주고 "청년봉사단 좋은데?"라는 생각을 처음으로 가질 수 있도록 해준 그런 봉사였던 것 같습니다. 재미와 보람을 동시에 남양주 청년봉사단은 베이킹 스튜디오인 다산에 위치한 릴리클래스에서 모이기로 했습니다. 봉사를 하는데 요즘 유행하는 일일 클래스 수업을 듣는다고 하여 신기했습니다. 저희 집에서

원문보기 내부링크
Naver Blog

[자격증/ISTQB AT] Chapter 2. 기본 애자일 테스팅 원칙, 프로세스 : Part-1

Chapter 2.1 전통적인 테스팅과 애자일 접근법의 테스팅 차이 애자일 모델은 테스팅과 개발 활동이 통합되어 있다. 애자일 모델은 프로젝트 산출물, 용어, 다양한 테스트 레벨에서 사용되는 시작 및 종료 조건, 도구의 활용 및 독립적인 테스팅을 효과적으로 구현하는 데 있어서 기존 모델과 다르다. 애자일 모델은 조직에 따라 수명 주기 구현 방법이 다르다. Chapter 2.1.1 테스팅과 개발 활동 애자일 수명주기는 전통적인 수명주기보다 매우 짧다. 애자일 수명주기 완료 시점에 동작하는 SW가 필요하다. 테스팅 활동은 반복 주기를 진행하는 동안 지속적으로 수행해야 한다. 어떤 경우, 잔존 결함 혹은 다른 형태의 기술 채무를 해결하기 위해 주기적으로 반복 주기를 강화(Hardening) 하거나 안정화(Stabilization) 시키기도 한다. 가장 좋은 방법은 모든 기능이 시스템과 같이 테스트되고 통합되어야만 완료되었다고 간주하는 것이다. 혹은 이전 반복 주기에서 남겨진 결함들을 다음

원문보기 내부링크
Naver Blog

[자격증/ISTQB AT] Chapter 2. 기본 애자일 테스팅 원칙, 프로세스 : Part-2

Chapter 2.1.5 독립적 테스팅을 위한 조직 구성 옵션 1) 개발 팀에 포함된 테스트 팀 독립성이 부복하여 객관적인 평가를 하지 못할 수 있음. 2) 개발 팀 밖의 독립적인 테스트 팀 장점 공정하고 객관적인 평가 제공이 가능하다. 결함을 효과적으로 발견 가능하다. 단점 시간이나 제품의 새로운 기능에 대한 이해가 부족할 수 있다. 비지니스 이해관계자와 개발자 사이의 관계에서 문제가 발생할 가능성이 있다. 3) 장기적인 관점에서는 독립되고 분리된 테스트 팀 운영, 프로젝트 시작 시점에 각 테스터들을 애자일 팀에 할당 테스트 팀은 독립성을 유지하면서도 제품에 대해 깊이 이해할 수 있으며, 다른 팀 멤버들과도 강력한 관계 유지가 가능하다. 전문적인 역량을 가진 테스터들을 애자일 팀에 할당하지 않고, 이들이 보다 장기적이거나 반복 주기와 별개로 수행하는 태스크 즉, 자동화 테스트 도구 개발, 비기능 테스트 수행, 테스트 환경 및 데이터 구축 및 지원, 하나의 스프린트에서 완료할 수 없

원문보기 내부링크
Naver Blog

[자격증/ISTQB AT] Chapter 3. 애자일 테스팅 방법, 기법 및 도구 : Part-1

Chapter 3.1 애자일 테스팅 방법 테스팅 실천 방법들은 미리 테스트를 작성하고, 초기 결함의 예방, 발견 및 제거에 초점을 맞추고 적절한 테스트가 적절한 시간에 올바른 테스트 레벨의 활동으로 수행되는 것을 보장한다. Chapter 3.1.1 테스트 주도 개발, 인수 테스트 주도 개발, 행위 주도 개발 1) 테스트 주도 개발(TDD ; Test-Driven Development) 자동화된 TC에 맞추어 코드를 개발하는 방법 TDD의 테스트는 주로 단위 테스트 레벨 위주지만, 통합/시스템 레벨에서도 가능하다. 개발자가 명확하게 정의된 예상 결과에 초점을 맞출 수 있도록 해준다. 작성된 테스트는 테스트 자동화와 지속적인 통합에 사용된다. TDD 프로세스 테스트(코드)를 추가한다. 테스트 코드는 구현되어야 할 기능에 대해 프로그래머의 개념을 확인하기 위한 작은 코드이다. 테스트를 실행한다. 코드가 존재하지 않기 때문에 테스트는 실패한다. 코드를 작성하고 테스트가 통과할때까지 계속 테

원문보기 내부링크
Naver Blog

[자격증/ISTQB AT] Chapter 3. 애자일 테스팅 방법, 기법 및 도구 : Part-2

Chapter 3.1.4 테스터의 역할(IN 스크럼 생명 주기) 팀워크 교차 가능팀 각 팀 구성원이 팀에 다양한 기술 영역을 제공한다. 이 팀은 테스트 전략, 테스트 계획, 테스트 설계, 테스트 실행, 테스트 평가 및 시험 결과 보고를 함께 진행한다. 자기 조직화 팀에 최소 한 명 이상의 테스터를 포함하는 것이 이상적이다. 공간 공유 테스터는 개발지 및 제품 책임자와 같은 공간에서 함께 일한다. 협업 테스터들은 다른 구성원들과 공동 작업을 수행한다. 위임 필요한 경우 설계와 테스트에 관한 기술 결정은 제품 책임자 및 다른 팀과 협력하여 팀 전체가 만든다. 헌신 테스터는 질문과 기대와 고객과 사용자의 요구사항과 관련하여 제품의 동작 및 특성을 평가하기 위해 최선을 다한다. 투명성 개발 및 테스트의 진행 상황을 애자일 상황판에서 볼 수 있다. 신뢰 테스터는 테스트 설계 및 실행 전략에 대한 신뢰를 확보해야 한다. 이는 종종 테스트 프로세스에 대한 정보를 이해관계자에게 제공함으로써 만들어

원문보기 내부링크
Naver Blog

[자격증/ISTQB AT] Chapter 3. 애자일 테스팅 방법, 기법 및 도구 : Part-3

Chapter 3.3 애자일 프로젝트의 테스트 기법들 Chapter 3.3.1 인수 조건, 적절한 커버리지, 테스팅을 위한 기타 정보 프로젝트의 초기 요구 사항을 백로그 우선순위에 따라 사용자 스토리에 기재한다. 초기 요구 사항은 짧고 일반적으로 미리 정의된 형식을 따른다. 비기능 요구사항 역시 중요하며, 이들은 고유의 사용자 스토리 혹은 다른 기능 사용자 스토리에 연결하여 명세를 작성할 수 있다. 비기능 요구사항은 미리 정의된 형식이나 ISO 25000과 같은 국제 표준 또는 특정 산업 표준을 따를 수 있다. 테스트 베이시스에 포함 가능한 항목 사용자 스토리 이전 프로젝트의 경험 해당 시스템에 이미 존재하는 기능 및 품질 특성 코드, 아키텍처, 디자인 사용자 프로파일(컨텍스트, 시스템 설정 및 사용자 행동) 현재 및 과거 프로젝트의 결함 정보 결함 사전의 결함 분류 적용되는 표준 품질 리스크 인수 기준에 반드시 포함되어야 할 주제 기능 동작 특정 설정에서 입력된 사용자의 행위에 대

원문보기 내부링크
Naver Blog

[자격증/ISTQB AT] Chapter 3. 애자일 테스팅 방법, 기법 및 도구 : Part-4

Chapter 3.3.2 인수 테스트 주도 개발 적용하기 ATDD(Acceptance Test Driven Development)는 테스트 우선 접근법이다. TC들은 해당 사용자 스토리를 구현하기 전에 작성된다. 사용자 스토리를 분석/논의하고, 개발자, 테스터 및 업무 대표자가 요구사항을 작성하는 워크숍을 진행한다. 사용자 스토리의 모든 불완선정, 모호성, 오류가 이 과정에서 보관된다. TC를 생성한다. 모든 사람이 참여하거나 테스트 팀에 의해 개별적으로 진행한다. TC 작성 방식과 관계없이, 비지니스 대표자와 같은 제3자가 TC를 검증한다. TC는 사용자 스토리의 특정한 특성을 기술하고 있는 예제들이며, 애자일 팀이 해당 사용자 스토리를 정확하게 구현하도록 도움을 준다. 예제와 테스트는 동일한 대상을 지칭하며, 대부분 동일한 의미로 사용된다. TC 생성 작업은 기본적인 예제와 개방형 질문에서 시작한다. 통상적으로, 첫 번째 테스트는 예상했던 대로 실행되면 동작 단계에서 예외 또는

원문보기 내부링크
Naver Blog

[자격증/ISTQB AT] Chapter 3. 애자일 테스팅 방법, 기법 및 도구 : Part-5

Chapter 3.4 애자일 프로젝트를 위한 도구들 모든 수준에서 자동화된 테스트 및 관련된 테스트 아티팩트를 관리할 필요가 있으므로 애자일 팀에서 형상 관리 도구는 중요하다. Chapter 3.4에서 설명하는 다음의 도구들은 팀 협업 및 정보 공유를 보장하기 위해 사용된다. Chapter 3.4.1 작업 관리 및 추적 도구 스토리 및 스토리와 관련된 개발 및 테스트 작업을 기록하여 스프린트가 진행되는 동안 태스크가 누락되지 않도록 한다. 각 태스크에 팀 구성원의 공수 추정치를 기재하고 사용자 스토리를 구현하기 위해 필요한 공수를 자동으로 계산함으로써, 효율적인 반복 주기 계획을 수립하도록 한다. 동일한 사용자 스토리와 연관된 개발/테스트 작업을 묶음으로써 해당 스토리를 구현하는데 필요한 팀의 전체적인 공수를 파악하도록 한다. 개발자 및 테스트의 작업 완료 상태를 태스크에 반영함으로써, 각각의 스토리, 반복 주기 및 전체적인 릴리즈 진행 상태의 스냅샷을 제공한다. 지리적으로 분산된

원문보기 내부링크
Naver Blog

[자격증/ISTQB FL] Chapter 5. 테스트 관리(Test Management) : Part-1

테스트 조직과 독립성(Test Organization and Independence) 테스트 조직의 독립성 수준은 해당 조직의 테스트 요구사항과 테스트 대상 제품의 특성, 요구되는 품질 수준, 프로젝트 조직 수준 등을 고려하여 적절하게 조정. (테스트 조직의) 독립성의 장점 결함을 보는 시각, 결함을 발견하는 방법이 개발자와 달라 상대적으로 객관적이다. 개발 단계에서 작성된 명세와 구현 산출물을 객관적으로 검증할 수 있다. 테스트 전문가로서 결함을 효과적이고 효율적으로 찾아내는 전략적 접근이 가능하다. 테스팅 프로세스 평가를 통해 테스팅을 개선할 수 있다. (테스트 조직의) 독립성의 단점 독립성 수준이 강하면 강할수록 개발 및 제품 관련 정보로부터 고립될 가능성이 높아진다. 독립적 테스트를 마지막 체크포인트로 활용한다면, 프로젝트의 병목으로 작용할 가능성이 있다. 개발자가 품질에 대해 책임을 지지 않으려고 할 수 있다. 의사소통 비용이 증가하며, 개발자-테스터 간의 적대적 형성 가능

원문보기 내부링크
Naver Blog

[자격증/ISTQB FL] Chapter 5. 테스트 관리(Test Management) : Part-2

테스트 제어(Test Control) 테스트 진행 보고서나 수집된 메트릭을 근거로 테스트가 계획대로 수행 되도록 가이드 하거나 정정하는 활동. ex) 테스트 우선순위 / 일정 조정 등 테스트 완료(Test Completion) 테스트 자산 및 테스트 환경을 보존하고, 테스팅 활동에서의 교훈을 찾아내어 이해관계자와 공유하기 위한 목적으로 실행. 형상 관리(Configuration Management) 프로젝트나 전체 수명주기에 걸쳐 시스템이나 SW(컴포넌트, 데이터, 문서)의 상태로 그대로 보전(Integrity), 보호(Umbrella) 하고 유지. 리스크와 테스팅(Risk and Testing) 리스크(Risk) 이벤트, 위험 요소(Hazard), 위협(Threat) 혹은 상황의 발생 가능성과, 발생했을 경우의 바람직하지 못한 결과 즉, '잠재적인 문제'로 정의. 리스크 수준 의도하지 않은 이벤트가 발생할 가능성 + 그 영향(해로운 결과)의 정도. 레이놀즈(Reynold)의 리스크

원문보기 내부링크
Naver Blog

[자격증/ISTQB FL] Chapter 5. 테스트 관리(Test Management) : Part-3

인시던트 관리(Incident Management) 목적 : 테스트에서 발견한 이슈(Issue)에 대해 추가적으로 수행해야 할 일에 대해 보고하고 이를 추적하기 위함. 인시던트(Incident) 발견되어 분류되는 시점부터 수정되고 확인될 때까지 추적되어야 할 대상. 프로세스 수립 및 분류 규칙 반드시 포함. 인시던트 리포트(Incident Report) 신규 테스트 실행에서 발생한 이슈, 즉 실제 결과와 기대 결과 사이의 불일치를 작성. 기 발생된 결함에 대한 재테스트인 경우는, 인시던트 리포트의 상태(Status)를 변경. 인시던트 리포트의 목적 개발자와 프로젝트 관련자에게 문제점을 식별하고, 격리하고, 필요하면 정정하도록 피드백을 제공. TL에게 시스템의 품질 또는 테스트 진척을 추적할 수 있는 정보 제공. 테스트 프로세스 개선(Test Process Improvement)에 대한 아이디어 제공. 릴리즈 조언(Release Advice) 다음번 테스트 레벨 및 양산 단계, 유지

원문보기 내부링크
Naver Blog

[자격증/ISTQB FL] Chapter 6. 테스트 지원 도구 : Part-1

지원하는 테스팅 활동에 따른 테스트 도구의 분류 1) 테스트 관리 지원 도구(Tool for management of testing and tests) 테스팅 전반과 테스트 프로세스 관리를 지원. 테스트 계획, 설계, 실행, 리포팅, 테스트 프로세스 개선 등의 활동 지원. 1-1) 테스트 관리 도구(Test management tools) 테스트 진척도 그래프 특정 시점의 단순한 진척 보고 형태가 아닌, 프로젝트 진행 시간에 따라 계획 대비 진행 상황을 알 수 있는 추세 그래프 형태로 구성. 앞으로의 전개 예측이 가능하다. 1-2) TPMS(Test Process Management System) 테스트 계획 및 리스크 기반 테스트 전략 수립, 테스트 설계, TC 관리, 결함 관리 및 추적, 테스트 리포팅 등의 테스트 프로젝트 전반의 활동을 지원하는 도구. 1-3) 인시던트 관리 도구(Incident management tools) 결함이나 장애, 인지된 문제와 불일치 등을 포함하는

원문보기 내부링크
Naver Blog

[자격증/ISTQB AT] Chapter 1. 애자일 SW 개발 : Part-1

Chapter 1.1 애자일 SW 개발 기본 Chapter 1.1.1 애자일 SW 개발과 애자일 선언 애자일 선언 프로세스와 도구보다 개인과 그 개인들 간의 상호작용을 중시한다. 완벽한 문서보다 작동하는 SW를 중시한다. 계약의 협상보다 고객과의 협업을 중시한다. 계획을 고수하기보다 변화에 대한 대응을 중시한다. 애자일 12 원칙 1. 우리의 최우선 순위는 가치 있는 SW를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다. 2. 비록 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다. 3. 작동하는 SW를 자주 전달하라. 두어 주에서 두어 개월의 간격으로 하되 더 짧은 기간을 선호하라. 4. 비지니스 쪽의 사람들과 개발자들은 프로젝트에 걸쳐 날마다 함께 일해야 한다. 5. 동기가 부여된 개인들 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 자원을 주고 그들이 일을 끝내리라고 신뢰하라. 6. 개발 팀

원문보기 내부링크
Naver Blog

[자격증/ISTQB AT] Chapter 1. 애자일 SW 개발 : Part-2

Chapter 1.2 애자일 접근법 애자일 접근법 실천 방법 1. 사용자 스토리 도출 2. 회고 3. 지속적인 통합 4. 개별 반복 주기 5. 전체 출시 계획 Chapter 1.2.1 애자일 SW 개발 접근법 익스트림 프로그래밍(XP ; eXtreme Programming) 켄트 백(Kent Beck)이 처음 시작하였다. TDD(Test Driven-Development)를 강조한다. XP의 5가지 가치 1. 의사소통 2. 단순성 3. 피드백 4. 용기 5. 존중 XP의 14가지 원칙 1. 인간성 2. 경제성 3. 상호 이익 4. 자기 유사성 5. 개선 6. 다양성 7. 반성 8. 흐름 9. 기회 10. 잉여 11. 실패 12. 품질 13. 아기 걸음 14. 책임 소재 XP의 13가지 실현법 1. 함께 앉기 2. 전체 팀 3. 정보를 제공하는 작업 공간 4. 열정적인 작업 5. 짝 프로그래밍 6. 스토리 7. 주 단위 분기 8. 사분기 주기 9. 여유 10. 10분 빌드 11. 지속

원문보기 내부링크
Naver Blog

[자격증/ISTQB AT] Chapter 1. 애자일 SW 개발 : Part-3

Chapter 1.2.2 사용자 스토리 공동 작업(User Story) 사용자 스토리(User Story) 고객에게 가치를 줄 수 있는 기능을 쉬운 언어(비지니스 언어)로 설명한 것이다. 개발자, 테스터 및 업무 대표자 관점의 요구사항들을 모두 수집하여 작성한다. 기능의 버전 공유는 요구사항이 작성되는 동안 비공식적인 리뷰를 통해 수행이 가능하다. 사용자 스토리는 기능 및 비기능 특성을 모두 해결해야 한다. 각각의 스토리는 이러한 특성에 대한 인수 기준을 가지고 있어야 한다. 이러한 조건은 업무 대표자, 개발자와 테스터 간의 협의에 의해 정의되어야 한다. 인수 기준은 개발자와 테스터에게 기능의 확장된 비전을 제공하고 업무 대표자는 유효성을 검증하기 위한 기준을 제공한다. 인수 기준이 충족되었을 때 작업이 완료된 것으로 간주한다. 사용자 스토리의 공통 저자는 브레인스토밍과 마인드 매핑 등의 기술 사용이 가능하다. 테스터는 INVEST 기법 사용이 가능하다. Independent : 독

원문보기 내부링크
Naver Blog

[자격증/ISTQB AT] Chapter 1. 애자일 SW 개발 : Part-4

Chapter 1.2.5 출시와 반복 주기 계획 1) 출시 계획 프로젝트 시작 단계에서 수립 제품의 출시 계획을 의미. 상위 레벨의 리스크 분석을 수립한다. 종종 프로젝트 시작 몇 개월 전에 수립된다. 이 단계에서는 새로운 백로그를 정의하거나 기존 백로그를 재정의하는 활동을 실행하며 이 과정에서 작은 사용자 스토리들을 모아 큰 사용자 스토리로 만들기도 한다. 모든 반복 주기에 대한 테스트 접근법과 테스트 계획을 위한 기초를 제공한다. 출시 계획은 상위 레벨 수준의 계획이다. 출시 계획에서 업무 대표자는 팀과 공동으로 출시에 대한 사용자 스토리를 설정하고 우선순위를 정한다. 이 사용자 스토리에 기반하여 프로젝트 리스크와 품질 리스크를 식별하고 상위 레벨 수준에서 공수를 추정한다. 출시 계획이 완료되면 첫 번째 반복 주기를 위한 계획을 수립한다. 출시 계획은 프로젝트 진행에 따라 변경될 수 있다. 내부 요인 배포 능력, 속도, 기술적인 문제 등 외부 요인 새로운 시작과 기회, 새로운 경

원문보기 내부링크
Naver Blog

[자격증/ISTQB FL] Chapter 4. 테스트 설계 기법 : Part-2

명세 기간 기법 - 동등 분할(Equivalence partitioning) 입력값/출력값 영역(Input/ouput space)을 유한개의 상호 독립적인 집합(Mutual disjoint subset)으로 나누어 수학적인 등가 집합을 만든 후, 각 등가 집합의 원소 중 대푯값을 선택하여 TC를 도출하는 방식. ex) 입력값, 출력값, 시간 관련 값 등에 적용 가능. 모든 테스트 레벨에서 사용 가능. 모든 테스트 유형에서 사용 가능. 약한 동등 분할 테스팅(Weak) 각 등가 집합에서 하나의 대푯값만 선택하는 테스팅. 강한 동등 분할 테스팅(Strong) 각 등가 집합의 모든 조합을 고려한 테스팅. 동등 분할 기법으로 설계된 TC는 같은 특성을 가지면서 같은 방식으로 처리된다고 판단하는 모든 등가 집합에서 대표 입력값을 적어도 하나씩 테스트했다는 것을 보장함. 명세 기반 기법 - 경곗값 분석(Boundary value analysis) 동등 분할의 경계에서 결함이 발견될 확률이 높기

원문보기 내부링크
Naver Blog

[자격증/ISTQB FL] Chapter 4. 테스트 설계 기법 : Part-3

명세 기반 기법 - 유즈케이스 테스팅(Use case Testing) 유즈케이스 기본 개념 유즈케이스(= 시나리오) 액터(=유저 혹은 시스템)와 액터 사이의 상호작용(시스템 유저에게 결괏값을 제공)을 표현 각각의 유즈케이스는 그 유즈케이스가 성공적으로 수행되기 위한 전제 조건(Precorditions) 보유. 각각의 유즈케이스는 후속 조건(Post conditions - 관찰 가능한 결과와 시스템의 마지막 상태)을 가지면서 종료된다. 유즈케이스는 대게 주류 시나리오(Mainstream seenario = 기본 흐름 ; Basic or Main flows)와 대체 흐름(Alternative brances or Alternative flow)으로 구성됨. 기본 흐름과 대체 흐름 각각의 유즈케이스는 자세하게 표현하기 위해 유즈케이스 상세(Use case description)를 가짐. 액터와 유즈케이스, 유즈케이스 상세와의 관계 유즈케이스는 시스템이 실제 사용되는 방식에 기반하여 프로세스

원문보기 내부링크
Naver Blog

[자격증/ISTQB FL] Chapter 4. 테스트 설계 기법 : Part-4

구조 기반 기법(Structure-based technique) = 화이트 박스(White-box) SW나 시스템의 구조(Structure)를 중심으로 테스팅 컴포넌트 레벨의 구조 구문(Statement), 결정(Decision) 또는 분기문(Branch) 등 코드 그 자체. 통합 레벨의 구조 한 모듈이 다른 모듈을 호출하는 관계를 도식화한 콜 트리(Call tree) 등. 시스템 레벨의 구조 메뉴 구조, 비지니스 프로세스 혹은 웹페이지 구조. (코드) 커버리지(Coverage) 커버리지 간에는 포함관계 존재. 시스템 또는 SW 구조가 테스트 스위트에 대해 테스트된 정도 백분율(%)로 표시. ex) 100% 결정 커버리지. <-- 코드의 구조 중 모든 결정 포인트(Decision Points) 내의 전체 조건식이 참/거짓 값 모두를 갖도록 테스트 된 것을 의미. 1. 구문 테스팅과 커버리지(Statement testing and coverage) 구문 테스팅 구문 커버리지를 늘리기

원문보기 내부링크
Naver Blog

[자격증/ISTQB FL]] Chapter 4. 테스트 설계 기법 : Part-5

경험 기반 기법(Experience-bacsed technique) 이전에 테스터가 다루었던 유사 애플리케이션이나 기술에서의 경험, 직관, 테스터의 기술 능력으로부터 TC를 추출해낸다. 테스터의 경험에 따라 효율성 및 효과성의 정도가 매우 달라질 수 있다. 보통 공식적인 테스트 기법 적용 후 경험 기반 기법을 적용한다. (찾을 수 있는 결함의 종류가 각기 다르기 때문이다. 탐색적 테스팅 접근법(Exploratory testing approach) TC 작성의 시간을 최소화하고 TE의 발견적인(Heuristic) 지적 능력을 최대한 활용하여 테스트를 수행하는 것. 테스트 설계 기법이 아니라, 접근법이다. 탐색적 테스팅은 애드혹(Ad hoc) 테스팅, 게릴라(Guerrilla) 테스팅, 직관적(Intuituve) 테스팅과 유사한 개념의 테스팅이지만, 정해진 임무(Tasks)와 목표(Objectives), 결과물(Deliverables)이 존재한다는 측면에서 다르다, 테스트 설계, 테스트

원문보기 내부링크
Naver Blog

[자격증/ISTQB FL] Chapter 4. 테스트 설계 기법 : Part-6

고급 설계 기법(Advanced test design techiques) 명세 기반 기법 - 분류 트리 기법(Classification Tree Method - CTM) SW 일부 또는 전체를 트리(Tree) 구조로 분석 및 표현하고 이를 바탕으로 TC를 도출하는 기법. 트리를 그려주는 도구(Classification Tree Editor : TC를 자동으로 수행하지는 못하지만 테스트할 조합(TC) 선택을 용이하게 지원)의 지원을 받을 수 있음. 분류 트리 기법의 장점 테스트 아이디어를 트리 구조로 시각화하여 TC를 설계하므로 의도한 대로 TC 도출 가능. 시각적으로 보면서 트리 구조 끝단의 조합을 통해 TC를 작성하므로 일부분만 테스트를 진행한다거나 중복된 테스트 수행을 피할 수 있음. 복잡한 시스템 혹은 애플리케이션의 일부 또는 전체를 테스팅 하는데 적합함. 개발 설계를 체크하는 용으로 사용이 가능하며, 조기 테스트 설계(Early test design)에 활용할 수 있다. TC

원문보기 내부링크
Naver Blog

[자격증/ISTQB FL] Chapter 4. 테스트 설계 기법 : Part-7

경험 기반 기법(Experience-based technique) 오류 추정(Error guessing) 테스터가 테스트 대상 시스템을 완전히 이해하고 있다는 전제로 하며, 식별된 취약점에 기반한 테스트. 테스트의 마지막 단계에서 사용. 결점 공격(Fault attack) 가능한 오류를 모두 나열하고 이런 유형의 결함 또는 오류를 공격할 수 있다. 체크리스트(Checklists) 테스트하거나 평가해야 할 내용과 경험을 나열해 놓은 것. 테스트 경험과 노하우를 정리하고 목록화하여 다음 테스팅에서 해당 내용을 누락 없이 검증하는 것을 목적으로 작성. 테스트의 효율적 진행이 가능하지만, 효과성을 보장하지는 않는다. 정적 테스트 기법의 주요 도구이다. 공식적인 테스팅을 보완하는 용도로 사용한다. 종류 일반 체크리스트 기능(블랙박스) 체크리스트 시스템 요소 체크리스트 방법론적 접근법(Methodological approach) - 특성 테스팅(characteristics Testing) 국제

원문보기 내부링크
Naver Blog

[자격증/ISTQB FL] Chapter 1. 소프트웨어 테스팅의 기초 : Part-2

제 생각에 Chapter 1.2는 중요하지 않다고 생각하여 실라버스를 정리할 때 제외하였습니다. 필요하신 분들은 따로 찾아보시길 바랍니다. Chapter 1.3 테스팅의 7가지 원리 (Seven Testing Principles) 1. 테스팅은 결함이 존재함을 밝히는 활동이다. 결함을 줄일 수는 있지만, 결함이 없다고 증명할 수는 없다. 2. 완벽한 테스팅(Exhaustive testing)은 불가능하다. 무한 경로 : 한 프로그램 내의 내부 조건이 무수히 많을 수 있음. 무한 입력값 : 입력이 가질 수 있는 모든 값의 조합이 무수히 많음. 무한 타이밍 : GUI 이벤트 발생 순서에 대한 조합도 무수히 많음. 3. 테스팅을 개발 초기에 시작한다. (Early testing) 4. 결함 집중(Defect clustering) 결함들은 소수의 특정 모듈에 집중되어 발생하는 경향을 보인다. 5. 살충제 패러독스(Pesticide paradox) 지속적인 살충제 살포로 내성이 생긴 벌레가

원문보기 내부링크
Naver Blog

[자격증/ISTQB FL] Chapter 2. SW 수명주기(Life Cycle)와 Testing : Part-1

Chapter 2.1 SW 개발 모델 Test Basis SW 개발 기간 중의 개발 산출물(Work Products) ex) 유스케이스, 요구 사항 명세, 설계 문서, 코드 등 마스터 테스트 계획 전체 테스트 레벨을 망라하는 테스트 계획 정적 테스팅(Static) 개발 산출물을 리뷰(Review) 형태로 검토하면서 결함을 발견 TC 생성 ex) 결정 테이블 테스팅, 상태 전이 테스팅, 유스케이스 테스팅 Verification(확인, 조회, 증명, 검사) 개발 단계의 산출물이 그 단계의 초기에 설정된 조건을 만족하는지를 검증하는 프로세스 개발 '초' 위주(모든 단계에서 수행 가능) 인스펙션 & 동적 테스팅으로 검증 Validation(확인, 검증) 개발 단계 말에 명시된 혹은, 명시되지 않았지만 사용자의 관점에서의 요구사항이 만족하는지를 평가하는 프로세스 정적 & 동적 테스팅으로 검증 1. V-모델 V-모델 예시 순차적 개발 모델로 개발 시작과 동시에 테스팅 진행. 소프트웨어 개발 프

원문보기 내부링크
Naver Blog

[자격증/ISTQB FL] Chapter 2. SW 수명주기(Life Cycle)와 Testing : Part-2

Chapter 2.2 테스트 레벨 (Test Levels) 각각의 테스트 레벨은 서로 독립적이며, 종속성을 지녀야 한다. 1. 단위 테스팅(Unit Testing) = 컴포넌트 테스팅(Component Testing) 테스트가 가능한 (최소) 단위로 나누어진 SW 내에서 결함을 찾고 그 기능을 검증. 정황과 시스템에 의존적이면서도 시스템의 다른 부분에서 격리하여 독립적으로 수행해야 함. 스텁(Stub) / 드라이버(Driver) / 시뮬레이터(Simulator)의 필요 가능성이 있음. 특정 비기능 테스트를 포함. ex) 리소스 관련 테스팅, 강건성(Robustness) 테스팅 등 Code를 중심으로 수행. 개발 환경(디버깅 툴 등)의 자원 필요. 구조 기반(White-box) 테스팅이 주된 방식. 단위 테스팅의 목적 경로(Path) 확인 모든 오류 처리 경로(Error handling Path) 확인 컴포넌트 내의 인터페이스 확인 Local Data, 경곗값 확인 2. 통합 테스팅(

원문보기 내부링크
Naver Blog

[자격증/ISTQB AT] ISTQB CTFL - AT(Agile Tester) 요약정리에 앞서... + 합격 후기

ISTQB CTFL - AT(Agile Tester)는 반년 전쯤에 취득한 시험입니다. 거의 턱걸이로 합격했던 시험인데, 사실 이 시험은 현재 시험이 종료되었습니다. 2023년 11월 21일 시험을 마지막으로 시험이 종료되었고, Foundation Level(CTFL) 4.0 버전에 병합되는 것으로 결정되었다고 합니다... ㅠ(겨우 땄더니!!!) 아무튼 병합되었다고 하더라도, 제가 Agile Tester에 대해서 공부했다는 사실과 합격했다는 사실은 변함없이 증명해 주는 자격증입니다. 또한 Agile Testing 분야의 상위 버전 자격증 취득 시에 이 자격증이 도움이 되니, 만약 제가 더 공부를 하게 된다면 쓰임새가 있을 것으로 보입니다. Agile Tester에 대한 자세한 내용을 궁금하신 분들은 요약정리를 참고해 주시면 좋을 것 같습니다. ISTQB CTFL - AT 시험 종료에 관한 자세한 사항은 아래 KSTQB 공식 블로그를 참고해 주시면 될 것 같습니다. ISTQB CTFL

원문보기 내부링크
Naver Blog

[자격증/ISTQB FL] Chapter 2. SW 수명주기(Life Cycle)와 Testing : Part-3

Chapter 2.3 테스트 유형 (Test Types) 테스트 유형(Test Types) 테스팅 하는 목적 및 품질 특성을 염두에 두고, SW 시스템을 검증하는 일련의 테스트 활동 1. 기능 테스팅(Functional Testing) 문서화되어 있거나 테스터가 알고 있는 기능과 특징, 그리고 그것들과 특별한 시스템과의 상호 운용성을 고려하여 수행하며, 모든 테스트 레벨에서 수행 가능. 여기서 '기능'이란, 시스템이 수행하는 그 '무엇'을 의미. 주로 명세 기반 기법(Specification-Based Technique) 이용. <기능 테스팅의 부특성> 적합성 정확성 준수성 보안성(Security testing) 악의적인 코드(바이러스)와 같은 외부로부터의 위협을 감지해 내는 것과 관련 있는 기능 확인. 상호 운용성 테스팅(Interoperability) 하나 또는 여러 개의 명시된 컴포넌트나 시스템이 서로 상호 작용하는 SW 제품의 능력 평가. 2. 비기능 테스팅(Non-funct

원문보기 내부링크
Naver Blog

[자격증/ISTQB FL] Chapter 3. 정적(Static) 기법 : Part-1

정적 기법 SW를 실행하지 않고 테스팅 하는 기법. 장애(Failures) 자체보다는 장애의 원인(결함) 발견에 중점. ex) 리뷰, 정적 분석 리뷰(Review) 코드를 포함한 SW 개발 및 테스트 산출물을 검토하고 테스팅 하는 방법(수동적 기법). 개발 산출물의 누락(omissions)과 같은 결함 발견 리뷰의 장점 조기 결함 발견 및 수정 개발 생산성 향상 개발 시간 단축 테스팅 비용 및 시간 감소 생명주기 전체에 걸침 비용 감소 결함 감소(품질 향상) 커뮤니케이션 향상 공식적 리뷰의 단계(Hpase of a formal view) (공식적) 리뷰 활동에 대한 계획은 테스트 계획서에 해당 내용 명시. 1. 계획 활동 참가 인원을 선정하고 역할을 할당. 인스펙션과 같은 보다 공식적인 리뷰에서는 시작 및 종료 기준(Entry and exit criteria)을 정의. 어떤 부분의 문서 및 코드를 리뷰할 것인지 정함. 2. 시작(kick-off) 문서를 배포. 리뷰의 목표, 절차 및

원문보기 내부링크
Naver Blog

[자격증/ISTQB FL] Chapter 3. 정적(Static) 기법 : Part-2

리뷰의 유형(Type of Review) 1. 비공식적인 리뷰(Informal review)의 특징 공식적인 절차 없음. 페어(Pair) 프로그래밍에 의한 리뷰이거나 기술 선임자가 설계와 코드를 리뷰하는 것일 수 있음. 선택적으로 문서화할 수 있음. 리뷰하는 사람에 따라 성과 좌우. 주요 목적 저렴한 방법으로 일정 수준의 성과 달성. 2. 기술적 리뷰(Technical review)의 특징 문서화되고 정의된 프로세스 존재. 관리자 없는 동료 검토 형태로 수행 가능 중재자(Moderator)가 미팅을 주도 미팅 전 사전 준비 단계 필요 (선택적) 체크리스트, 리뷰 리포트, 발견한 인시던트 리스트, 관리자 참여 활용. 실무에서는 공식적 또는 비공식적일 수 있음. 공식적인 경우 문서화 필수. (성공적으로 진행되는 경우) 검토자에 관계없이 일관되고 정량적인 효과 도출 가능. 주요 목적 기술적 문제 해결, 토론, 의사결정, 대안 평가, 결함 발견, 명세서 또는 표준과의 적합성 검토. 3. 워

원문보기 내부링크
Naver Blog

[자격증/ISTQB FL] Chapter 4. 테스트 설계 기법 : Part-1

테스트 설계 진행 방식은 테스트 정황(Contexst)에 따라 달라진다. 테스트 조건(Test Condition) 하나 이상의 TC로 확인 가능한 항목이나 이벤트. ex) 트랜잭션(Transaction), 품질 특성, 구조적 요소 등. 테스트 케이스(Test Case) 특정 테스트 조건을 확인하기 위해 작성. ex) 입력값의 묶음 + 실행 사전 조건 + 수행 절차 + 기대 결과 + 실행 사후 조건 등등. 테스트 프로시저(Test Procedure) 수동 테스트 스크립트. 효율적인 테스트를 위한 TC 수행 순서. Test Case를 순차적으로 나열한 것. 테스트 스크립트(Test Script) 자동화된 테스트 프로시저. 테스트 실행 도구를 사용하여 테스트를 수행한다면 사용. 테스트 실행 스케줄(Test Schedule) 작성된 테스트 프로시저와 자동화된 테스트 스크립트를 언제 누가 수행할 것인지. TC의 목적 목표하는 보장성을 만족하는 최소한의(최적의) TC로 가능한 많은 결함을 발견

원문보기 내부링크
Naver Blog

ISTQB MAT 합격후기

ISTQB CTFL MAT 합격!! 합격했으니 후기를 살짝 작성해보고자 한다. 일단 26점 정확히 커트라인으로 합격했다. 공부는 ISTQB FL 할 때보다는 적게 했으니, 합격에 일단 만족한다. 시험 난이도는 엄청 어려웠던건 아니었지만, 이번에는 헷갈린 문제들이 많이 틀린것으로 보인다. 자격증을 많이 따면서 항상 하는 생각이지만, 26점 합격이나 40점 합격이나 결국은 합격은 동일하기에 기분이 좋은것은 사실이나, 턱걸이로 합격하면 안도감이 가슴속에 차오른다. (그래서 공부를 합격할 정도로만 하자..) 시험장에는 30명 정도의 사람들이 같이 시험을 치뤘다. 자리는 2인 테이블 왼쪽에 앉아서 시험을봐서 넓었다. 자격증은 이쯤에서 멈추고 이제는 자동화 공부를 해보려고 한다. 일단 자격증 취득했으니 한동안 쉬었다가 진행할 예정이다!!! 후기 끝.

원문보기 내부링크
Naver Blog

[자격증/ISTQB MAT] Chapter 1. 모바일 시장 - 비지니스와 기술 분야 : Part-1

1.1 모바일 분석 데이터(Mobile Analytics Data) 모바일 애플리케이션 테스터가 숙지해야 할 사항 플랫폼 분포의 비지니스 영향 플랫폼당 애플리케이션 다운로드 OS 버전의 종류 및 분포 지리적 위치에 따른 분포 다양한 화면 크기 및 해상도 다양한 입력 방법 카메라 유형 모바일 분석 데이터는 목표 시장(target market)에 적합한 테스트 실행을 위한 디바이스 포트폴리오를 선택하는데 사용된다. 디바이스와 관련된 데이터 및 특수 기능(있는 경우)을 사용해 디바이스 유형별 테스트를 설계할 수도 있다. 1.2 모바일 앱 비지니스 모델(Business Models for Mobile Apps) 프리미엄 모델(Freemium) 애플리케이션은 보통 무료이지만 추가 기능이 필요한 경우, 사용자가 비용을 지불한다. 트랜잭션 기반 애플리케이션(Transaction) 트랜잭션당 정액 요금 또는 거래 금액의 백분율이나 이와 유사한 비용을 사용자에게 청구한다. 모바일 지갑과 같은 비지니

원문보기 내부링크
Naver Blog

Chapter 3. 모바일 애플리케이션의 일반적인 테스트 유형과 테스트 프로세스

3.1 모바일 애플리케이션에 적용 가능한 일반적인 테스트 유형(Common Test Types applicable for Mobile Applications) 3.1.1 설치성 테스팅(Installability Testing) 테스터는 아래와 같은 방법을 사용해 앱의 설치, 업데이트 및 삭제에 집중해야 한다. 애플리케이션 스토어(Application Stores) 사이드 로딩(Side loading : 앱 복사와 설치) 일부 운영체제는 App을 모바일 디바이스에 파일로 복사하여 설치하는 옵션을 제공한다. 데스크톱 애플리케이션(Desktop applications) 애플 아이튠즈(iOS) or 안드로이드 앱 인스톨러 고려해야 할 테스트 컨디션 내부 및 외부 메모리에 설치, 삭제 및 업그레이드(지원되는 경우) 삭제 중에 "앱 데이터 유지" 옵션을 선택한 후 앱을 다시 설치 이전의 앱 제거 시 "앱 데이터 보존(retain app data)" 옵션을 선택하지 않은 경우 앱의 재설치 설치/

원문보기 내부링크
Naver Blog

Chapter 3. 모바일 애플리케이션의 일반적인 테스트 유형과 테스트 프로세스

3.1.5 사용성 테스팅(Usability Testing) UX(User Experience) 디자인에서 앱을 사용할 플랫폼의 모양과 느낌을 고려해야 한다. 테스터는 사용되는 플랫폼의 모양과 느낌을 알고 있어야 한다. 다양한 휴리스틱 및 테스트 둘러보기를 사용해 테스트를 수행할 수 있다. 퍼소나(Persona)를 고려하는 것도 사용성 테스트에 유용하며, 사용성 랩을 사용할 수도 있다. 퍼소나(Persona : 페르소나) : 어떤 제품 혹은 서비스를 사용할 만한 다양한 사용자들을 대표하는 가상의 인물 사용성 테스트 중에서 확인된 결과는 대부분 결함이 아니라 결과일 뿐이다. 테스터는 결과를 이해관계자에게 설명할 수 있어야 한다. 만족스러운 사용성의 조건 명확하고 직관적이어야 한다. 사용자 실수를 허용할 수 있어야 한다. 말과 행동을 일관되게 유지한다. 플랫폼의 설계 지침을 준수한다. 각 화면 크기 및 유형에서 필요한 정보를 표시하고 접근할 수 있도록 한다. 3.1.6 데이터베이스 테스팅

원문보기 내부링크
Naver Blog

Chapter 3. 모바일 애플리케이션의 일반적인 테스트 유형과 테스트 프로세스

3.2 모바일 애플리케이션에 적용 가능한 추가 테스트 레벨(Additional Test Levels applicable for Mobile Application) 3.2.1 필드 테스팅(Field Testing) 실제 사용자의 예상 사용 시나리오에서 올바르게 동작하는지에 대한 필드 테스팅 필요 필드 테스팅에는 무선 인터넷/셀룰러 데이터와 같은 다양한 네트워크 통신 기술이 포함될 수 있다. 필드 테스트는 앱을 사용하는 동안의 기지국, 네트워크, 무선 인터넷 및 셀룰러 데이터 전환을 포함한다. 다양한 다운로드 속도와 신호 강도를 고려해 수행해야 하며 사각지대(blind spots)의 운영도 포함해야 한다. 경로와 전송 수단 및 테스트가 실행되는 시간을 계획해야 한다. 앱의 사용성도 필드 테스팅에서 다뤄야 하며, 온도 및 사용 시나리오 관련 유사 조건 등의 환경 요소가 포함되어야 한다. 3.2.2 애플리케이션 스토어 승인 테스팅 및 출시 후 테스팅(Testing for Applicatio

원문보기 내부링크
Naver Blog

Chapter 4. 모바일 애플리케이션 플랫폼, 도구 및 환경

4.1 모바일 애플리케이션을 위한 개발 플랫폼(Development Platforms for Mobile Applications) 통합 개발 환경(IDE : Integrated Development Environments) 등이 있다. 4.2 공통 개발 플랫폼 도구(Common Development Platform Tools) SDK(Software Development Kit)는 일반적으로 앱 개발 및 테스트에 도움이 되는 다양한 유틸리티를 제공한다. 유틸리티 : 스크린샷 생성, 로그 추출, 임의의 이벤트, 알림을 디바이스에 전송, 메모리/CPU 사용률 등을 말한다. SDK의 예시 : AVD(Android Virtual Device) 관리자, ADB(Android Debug Bridge), 안드로이드 디바이스 모니터 및 iOS 용 계측기(instruments) 등 4.3 에뮬레이터 및 시뮬레이터(Emulators & Simulators) 4.3.1 에뮬레이터 및 시뮬레이터 개요(O

원문보기 내부링크
Naver Blog

Chapter 5. 테스팅 실행 자동화

5.1 사용자 접근법(Automation Approaches) 사용자 에이전트 기반 테스팅(User-agent-based testing) 브라우저가 보낸 사용자 에이전트 식별자 문자열(user-agent identifier string)을 사용해 특정 디바이스의 특정 브라우저를 스푸핑(spoof) 한다. 모바일 웹 앱 실행에 사용할 수 있다. 디바이스 기반 테스팅(Device-based testing) 테스트 중인 앱을 디바이스에서 직접 실행하는 것이다. 모든 앱 유형에 적용할 수 있다. 애플리케이션 유형에 따라 해당 애플리케이션에 적합한 테스트 자동화 프레임워크가 결정될 수 있다. 모바일 웹은 데스크톱에서 일반적인 웹 애플리케이션 자동화 도구를 사용해 테스트할 수 있지만 네이티브 앱은 특정 도구가 필요할 수 있다. 5.2 자동화 방법(Automation Methods) 자동화된 테스트 개발을 위해 테스터는 애플리케이션의 그래픽 대상에 접근하고 상호작용하는 방법을 이해해야 한다. 또

원문보기 내부링크
Naver Blog

Chapter 6. 모바일 도메인 용어집

형상비(aspect ratio) 디스플레이나 이미지의 가로 세로 비율 비동기 통신(asychonous communication) 지속적인 흐름이 아닌 간헐적으로 데이터를 전송할 수 있는 통신 유형 AVD(Android Virtual Device) 안드로이드 가상 디바이스 블라인드 스폿(blind spot) 무선 통신 네트워크가 없는 위치 바이트 코드(byte code = p code = portable code) 효율적인 실행을 위해 SW 해석기가 설계한 명령어 세트 컴패니언 디바이스(companion device) 종속적 디바이스와 같이 동작하도록 설계된 컴퓨터 디바이스 DPI/PPI (Dots Per Inch / Pixels Per Inch) 인트당 도트(Dots) / 픽셀의 약어로 화면의 밀도를 도트나 픽셀로 나타내는 수치 에뮬레이터(emulator) HW의 동작을 모방하는 SW 애플리케이션 엔터프라이즈 앱(enterprise app) 대중적으로는 사용하지 않고 조직에서 내부적

원문보기 내부링크
Naver Blog

ISTQB CTFL 요약 정리에 앞서...

ISTQB CTFL(Foundation Level)은 이미 취득한지 1년이 지난 시험입니다. 그럼에도 요약 정리를 올리는 이유는, FL이 QA들이 가장 많이 취득하는 자격증 중 하나이며, 저 스스로도 내용을 복습해보자는 취지에서 비롯됩니다. ISTQB FL 합격 사진 ISTQB FL은 40점 만점 중 26점을 맞추면 되는 시험으로, 저는 30점으로 합격했습니다. QA 입문자들이 모두 취득하는 자격증이라고 만만하게 보다가는 큰 코 다칠 수 있는 시험으로, 단순 암기만으로는 시험 당락을 보장할 수 없습니다. 시험의 가장 큰 특징은 국어 시험 같다는 것으로, 쉽게 말해 말장난이 많기 때문에, 용어들에 대한 정확한 이해가 필요합니다. 저도 나쁘지 않은 점수로 취득 했지만 상당히 애매한 문제들이 있었던 것이 기억이 나네요. 시험은 한글 60분 / 영어 75분으로 저는 한글로 시험을 봤습니다. 7시 30분 시작 시험이었는데, 시작 전에 안내 방송등이 나오고, OMR과 시험지 등을 나눠준 후 타

원문보기 내부링크
Naver Blog

Chapter 1. 소프트웨어 테스팅의 기초

1.1 테스팅이란 무엇인가? (What is Testing?) 장애(Failure) 프로그램의 실행 결과와 요구사항에 명시된 결과에 (관찰 가능한) 차이가 있음을 의미하는 것 결함 / 환경적 요인에 의해 발생 결함(Defect) 장애의 원인 SW 내에 장애를 유발할 수 있는 문제 오류(Error) 결함이 생기게 한 개발자의 행위 결함은 장애의 원인이 되지만, 모든 결함이 장애를 일으키는 것은 아니다. 테스팅(Testing) 응용 프로그램 또는 시스템(구성요소를 포함해서)의 동작과 성능, 안정성이 사용자가 요구하는 수준을 만족하는지 확인하기 위해 결함을 발견하는 메커니즘이다. 결함을 발견하기 위한 활동 전통적인 테스팅 개념 응용 프로그램 또는 시스템의 정상 작동 여부 확인 현재의 테스팅 사용자의 기대 수준과 요구사항에 맞게 구현되고 동작하는지를 확인하고 이를 통해 결함을 발견, 최종적으로는 결함 데이터를 근간으로 개발 프로젝트의 리스크 정보를 정략적 수치로 의사결정권자에게 전달 테스팅

원문보기 내부링크
Naver Blog

Chapter 1. 모바일 시장 - 비즈니스와 기술 분야2

1.4 모바일 애플리케이션 유형(Types of Mobile Applications) 네이티브 애플리케이션(Native) 플랫폼 별 소프트웨어 개발 키드(SDK ; Software Development Kits), 개발 툴 및 플랫폼 별 센서와 기능을 사용해 개발되며, 이들은 공급업체에 의해 다운로드, 설치 및 업데이트된다. 이런 앱들을 지원하는 모든 장치에 대해 테스트가 필요할 수 있다. 일반적으로 보다 나은 성능을 제공, 플랫폼 기능을 완전히 활용하며 개발한 플랫폼에 대한 기대치에 부응할 수 있다. 개발 비용은 일반적으로 더 높고, 여러 플랫폼의 사용 및 다수의 디바이스에서의 설치 및 테스트 등의 추가 문제가 적용될 수 있다. 디바이스에 물리적으로 설치되므로 디바이스가 인터넷에 연결되어 있지 않아도 사용 가능하다. 브라우저 기반 애플리케이션(Browser-based) 모바일 브라우저를 통해 구동된다. 일반적인 웹 개발 기술과 브라우저를 사용하기 때문에 여러 플랫폼을 쉽게 지원할

원문보기 내부링크
Naver Blog

Chapter 1. 모바일 시장 - 비즈니스와 기술 분야 3

1.6 모바일 앱 테스트 전략 (Type Strategy for Mobile Apps) 일반적인 리스크 특정 지역의 디바이스 점유 정보 비즈니스 모델의 유형 모바일 애플리케이션 테스트 전략 수립을 위한 특정 리스크 결함이 있는 특정 디바이스를 포함한 다양한 모바일 디바이스 사내 또는 외부 테스트 랩을 통한 디바이스 가용성 애플리케이션 수명주기 동안 새로운 기술, 디바이스나 플랫폼의 등장 앱 데이터나 환경 설정 저장 등의 다양한 채널을 통한 앱 자체의 설치 및 업그레이드 애플리케이션에 영향을 줄 수 있는 플랫폼 문제 네트워크 범위나 앱에 영향을 미치는 글로벌 정황 다양한 서비스 제공 업체의 네트워크를 이용한 테스트 가능성 특정 테스트 레벨과 유형의 모바일 에뮬레이터, 시뮬레이터나 실제 디바이스 사용 다른 디바이스로 인해 발생하는 문제를 고려한 테스트 전략 단일 플랫폼 접근 방식 단일 유형의 디바이스, 하나의 OS 버전, 하나의 이동 통신사 및 하나의 네트워크 유형으로 범위를 줄인다.

원문보기 내부링크
Naver Blog

Chapter 2. 모바일 애플리케이션 테스트 유형

2.1 디바이스 하드웨어와의 호환성 테스팅(Testing for compatibility with Device Hardware) 2.1.1 디바이스 특성 테스팅(Testing for Devices Features) 테스팅을 위해서는 대상 디바이스의 우선순위 화가 필요 디바이스 포트폴리오 선택은 일반적으로 시장 범위, 비용 및 리스크 간의 절충이라 할 수 있다. 애플리케이션은 다양한 유형의 디바이스에 다음과 같은 특성과 함께 설치될 수 있으며, 이 기능들 중 어느 것도 애플리케이션 작동에 부정적인 영향을 미치면 안 된다. 서로 다른 종료 방법 서로 다른 탐색 방법 하드 및 소프트 키보드 사용 다양한 HW 종류 : 통신, USB, 블루투스, 카메라, 스피커, 마이크, 헤드폰 디바이스 기능은 시장을 구분하는 데 사용되며 시간이 지남에 따라 빠르게 변할 수 있다. 테스터는 디바이스와 사용자가 기대하는 기능을 명확히 이해해야 한다. 테스터는 디바이스 포트폴리오를 작성하고 이에 따라 해당 테스

원문보기 내부링크
Naver Blog

Chapter 2. 모바일 애플리케이션 테스트 유형

2.1.7 일반적인 인터럽트 테스팅(Testing for Typical Interrupts) 일반적인 인터럽트 음성 통화, 메시지, 충전기 켜기, 메모리 부족 및 기타 알림 등 사용자가 시작한 인터럽트 앱이 실행되는 동안 앱을 전환하거나 디바이스를 대기 모드로 설정하는 등의 작업으로 인해 발생한다. 앱은 앱 동작에 부정적인 영향을 주지 않으면서 위에서 언급한 모든 인터럽트를 올바르게 처리해야 한다. 앱은 인터럽트가 발생하더라도 상태, 데이터 및 세션을 유지하면서 계속 올바르게 동작해야 한다. 디바이스에 알림을 억제하는 '방해 금지' 차단 모드가 있는 경우 앱은 다양한 조건들에 맞게 사용되는지 확인해야 한다. 이 테스트는 오랜 시간 '방해 금지' 모드가 켜져 있다가 꺼지는 경우에도 수행해야 한다. 이로 인해 많은 알림이 한 번에 수신될 수 있다. 테스트는 앱 사용 중 인터럽트가 부정적인 영향을 미치지 않는지 확인하기 위해 인터럽트를 수신하는 경우를 설계해야 한다. (ex) 앱 사용 중

원문보기 내부링크
Naver Blog

Chapter 2. 모바일 애플리케이션 테스트 유형

2.2 디바이스 SW와 앱 상호작용 테스팅(Testing for App interactions with Device software) 2.2.1 알림 테스팅(Testing for Notifications) 앱이 포그라운드 또는 백그라운드에 있을 때, 특히 배터리 부족 상태에서 수신된 알림을 올바르게 처리해야 한다. 알림을 통해 앱 콘텐츠와 직접 상호작용할 수 있는 경우(즉, 앱 자체를 실행하지 않는 경우) 나중에 앱에서 사용자 상호작용을 제공해야 한다.(ex) 사용자가 알림에 응답하면 나중에 앱 내에서 이 응답을 확인할 수 있어야 한다.) 알림이 앱 접근을 허용한다면 알림에 해당 페이지에 대한 딥 링크가 포함된 경우 홈 화면 대신 앱에 상응하는 페이지가 열려야 한다. 2.2.2 빠른 접근 링크 테스트(Testing for Quick Access Links) 빠른 접근 링크 기능은 전체 앱을 시작하지 않고 홈 화면에서 App 기능의 하위 집합을 수행할 수 있다. 일부 기능이 특정 버전

원문보기 내부링크
1