키자드에 등록된 총 242개의 포스트를 확인하실 수 있습니다.
AI 왈 제가 직접 계산할 때 실수가 잦은 작업들입니다. 날짜/시간 계산 — 유닉스 타임스탬프 변환, 시간대(timezone) 변환, 날짜 차이 계산 수학 계산 — 큰 숫자 산술, 복잡한 통계, 소수점 반올림 인코딩/디코딩 — Base64, JWT 페이로드 수동 디코딩 파일 용량/크기 변환 — bytes ↔ KB ↔ MB 단위 변환 이런 작업은 사이트나 도구 쓰시는 게 정확합니다. 타임스탬프: epochconverter.com JWT 디코딩: jwt.io Base64: base64decode.org 단위 변환: unitconverters.net
3회차 수업 호흡+발성. 음성이 어색한 이유.. 포물선 같은 높낮이가 없음. 영어, 일본어 확실하게 높낮이 있는데, 한국어도 있음. 발성 내 음에서 +-2 정도는 되어야 함. 말할 때는 자연스러운 포물선 높낮이를 해야 함. 자연스럽다는 건 미세하게 약 1단계를 넘어가지 않는 거처럼 들림. 높낮이는 음절별로 해야 한다. 이건 들어보면 아는데 글로 쓰려니 어려움. 음절 안에서 급격한 높낮이가 있으면 사투리가 된다. 여기서 안 되는 건 끝을 아래로 티 나게 내리기(말꼬리 흐리기), 되가져오기 등. 글로 표현이 안되는데 직접 들으면 안다. PREP이 모든 상황에서 써야 하는 건 아님.
IT 업계에서 '잠수함 패치'를 들어본적이 있을거다. QA를 하는 입장에서는 폭탄같은 존재이다. 테스트하지 않은 내역이 QA 인원이 모르게 배포가 되기 때문이다. QA가 몰랐다는 단순한 문제로 끝나지 않는다. 무엇을 배포할지(계획), 어떤 절차로 배포했는지(관리), 실제 무엇이 배포됐는지(이력)가 연결되지 않는 문제가 있다. 배포 통제의 기본 구조 - 릴리즈 계획 - 배포 관리 - 릴리즈 노트 이 3개가 연결되어야 배포 전, 배포 중, 배포 후의 흐름을 추적할 수 있다. 릴리즈 계획 배포 전에 날짜와 함께 어떤 것을 배포할것인지 목록화한다. 대부분 BTS에서 지원하는 티켓 연결기능을 이용하면 상태와 함께 관리할 수 있다. 릴리즈 계획이 없으면 QA는 배포 전에 테스트 범위를 확정할 수 없다. 배포 관리 배포를 실행하는 프로세스이다. 배포 절차, 배포 담당자, 승인 구조, 영향범위, 롤백방법, 책임자 등을 포함하는 관리 문서이다. 배포 관리가 없으면 배포 실패 상황에서 어떤 기준으로
테스트 중에 동기화 기능이 있다. 동기화를 이미 성공했고, 두번째 이후부터 어떻게 동작해야하는지 명확하게 나와있지 않다. 실제결과는 중복 키 오류가 발생했고, 리포팅해야하는데 기준이 없어 기대결과를 적기 어렵다. 동기화란? 사용자가 보통 생각하는 동기화는 '원본과 대상이 같아지는 것'이다. 시스템과 실제 구현은 다르다. 여러가지 방법이 있다. 설계 방식의 차이에 따라 달라진다. 삭제, 추가, 수정 데이터를 각각 어떻게 처리하는지 정의가 있어야 한다. 예제 예제와 함께 보면 이해가 빠르다. 동기화 성공한 초기 데이터 ID=1, Name=A ID=2, Name=B ID=3, Name=C 새로 동기화할 데이터 ID=2, Name=BB (업데이트됨) ID=3, Name=C (변경 없음) ID=4, Name=DD (추가됨) 사용자가 보기에는 무슨 값을 기준으로 중복 또는 갱신을 판단하는지 정확하게 알 수 없다. 키 값은 내부적으로 처리되어 화면에 안보여질수도 있다. 전체 갱신 (Full Re
정렬이 내 기대와 맞지 않게 나왔다. 내 기대가 기준이 될 수는 없다. 하지만, 비슷한 데이터를 처리하는 MS Excel, Atlassian Jira 등에서도 채택하는 방식을 굳이 거스를 필요는 없어 보인다. 사용자 경험(UX) 측면에서 명백한 비즈니스적 손해가 보이기 때문이다. 오름차순과 내림차순 오름차순은 순방향 정렬, 순차적으로 올라가는 거라 보면 된다. 0, 1, 2, ... a, b, c, ... ㄱ, ㄴ, ㄷ, ... 내림차순은 오름차순의 반대이다. 사전식 정렬 아래는 테스트했던 시스템에서 채택하는 정렬 방식이다. 오름차순 tami-208 tami-210 tami-4 내림차순 tami-4 tami-210 tami-208 컴퓨터 입장에서는 기본적인 방식이지만, 사용자한테는 생소할 수 있다. 문자열 전체를 왼쪽부터 문자 단위로 비교한다. 6번째에서 4,2,2를 비교하면 오름차순으로는 2,4. 내림차순으로는 4,2가 되어 위와 같은 결과가 나온다. 자연 정렬 오름차순 tami-
내가 모르는 남이 보는 부정적인 피드백이 없는데 어떻게 성장을 하나. 이 문제의 빠른 해결은 전문가한테 간다. 돈으로 해결한다. 녹음, 녹화 등 혼자서는 한계가 있다. 그래서 직접 상담과 맛보기 수업을 받았다. 상담 과정 예약+결제를 하고 확정된 날짜에 방문한다. 약 60분 정도 진행된다. 간단한 설문지를 작성한다. 내가 생각하는 개선점은 미리 생각한걸 적는다. 점수표 같은것도 있다. 설문지를 바탕으로 상담이 진행된다. 그리고 간단히 모의 면접 질문 몇 개를 하고 진단을 받는다. 가끔 면접에서 호의적인 회사에게 피드백을 요청하여도 대부분 부정적인 말은 안해준다. K-겸손이라고 한다.. 그리고.. 성대모사가 특기라면서 날 따라하는데.. 거울 치료 효과를 기대한다..^^ 무슨무슨 기법으로 말을 하라는데, 기본이다. 아는데 잘 안된다. 면접은 두괄식과 스토리텔링. 머리로는 두괄식이 항상 떠오르는데 막상 내뱉는건 아니다. 0교시: 보이스 트레이닝 맛보기 호흡법이였나 보이스 관련이였다. 비포
QA를 거치지 않은 항목이 릴리즈가 되었다. 릴리즈 노트 분석 결과, 약 76%가 QA 이전 단계에 있었다. PM이 확인해야 하는 단계에 있는 게 대부분이었다. QA의 역할과 릴리즈 기준 사이에 근본적인 의문이 생긴다. 저연차에서는 원래 이런 건가 넘어갈 수도 있는데 생각을 정리했다. 개인의 문제가 아니라 구조의 문제로 본다. 워크플로우는 있는데, 그 상태와 실제 릴리즈 기준의 연결점이 없다. 워크플로우 상태와 의미 워크플로우에는 완료 상태와 작업 대기 상태가 섞여있다. 실제 용어는 확인, 검토, 검수, 테스트 등 혼재되어 있는데 설명 편의를 위해 임의로 통일하겠다. new: 신규 ing: 작업 중 dev done: 개발자가 개발을 완료함. dev test: 테스트 서버에 배포가 완료되었고, 개발자가 확인해야 하는 상태. pm test: PM이 확인해야 하는 상태. qa test: QA가 테스트 서버에서 확인해야 하는 상태. op test: 운영 서버에 배포된 이후에, QA가 운영서
1회차 수업 생각나는대로 적은거. 핵심메시지만. 구조적. 짧고 굵게. 나무에 비유하면 가지 말고 기둥으로 말하기. 노트 활용. 그상황이되면 어떻게 될까 복기. 감정적인 사람 대응법: 그사람의 감정을 따라하지말고 되묻기. e.g. 제 질문이 뭐냐. 상대방 감정에 휘둘리지 말것. 대중적으로 말하기. 스피치 스타일 파악 및 전략. 망친게 있으면 다시 잘한 경험으로 덮기. 다른 사람 시선이 부담스러우면 시선을 멀리. 숙제 1. 자기소개 영상 셀프피드백 시각: 청각: 내용: 불필요한 대화에는 예의만 차림. 말끝을 명로하게 끝냄. 어색하다고 이것저것 말하지 말것. 불필요하게 찌르지 않음. 스몰톡 팁 오픈형 질문으로 바꾸기. 주어를 나로 바꾸고 상대방과 내용을 찾아감. 답변을 강제하지 않는 질문. e.g. 저한테는 더운 날씨인데 어떠세요? 숙제 2. 호흡법 숙제 3. 교재 셀프 스터디
2회차 수업 호흡 15초. 호흡이 짧으면 말하는데 숨을 헐떡임. 복식호흡해야함. 숨을 들이마시는데 배가 쪼그라드는게 자연스러운데.. 이러면 안 됨. 들이마시면 배가 빵빵하게 내뱉을때 배가 쪼그라들면서 길게 해야함. 서있거나 앉아있으면 복식호흡이 잘 안느껴지는데 누워서하면 잘 느껴짐. 발성은 호흡이 완성된 상태에서 내 음부터 찾기. 사람마다 음이 다른데 솔톤은 정답이 아닌가봄. 면접에 맞춰두괄식만 생각했는데 PREP 있음. 핵심메시지를 말해야함.
내 글 대부분은 면접자로 받은 면접 질문인데, 면접관 경험이 있다..! 가장 궁금해하는 면접 질문을 공유해본다. 합/불의 결정 95% 면접 중에 결정된다. 면접관이 다수이고 의견이 일치하지 않으면 지연될 수 있다. 단, 상급자의 영향력이 더 크다. 의외의 불합격 요인 자세한건 다음에.. 면접 질문 리스트 면접 질문 몇 가지를 체크리스트처럼 만들어 놓았다. 신입의 경우 거의 이 체크리스트 안에서의 질문을 한다. 경력직은 서류에 따라 맞춤형 질문을 한다. 이건 다른 블로거의 글에 자세히 적혀있다. 부록: SQA 면접 질문 공유 온전히 생각은 안 나지만, 몇 개 적어본다. 요즘엔 AI가 예상 질문을 잘 만들어준다. [1. 실무 이론 및 지식] * 탐색적 테스트와 애드혹 테스트 차이점을 설명해주세요. * 테스트케이스와 체크리스트의 차이점을 설명해주세요. * 확인 테스트와 리그레이션 테스트의 차이점을 설명해주세요. * 기능 테스트와 비기능 테스트의 차이점을 설명해주세요. * Verificat
테크니컬 라이터가 아닌 QA가 작성하는 매뉴얼 매뉴얼을 직접 작성하는 시대는 끝났다. 캡쳐+템플릿을 주고 AI가 초안을 주면 나는 검토한다. "저장 버튼을 누르면 저장됩니다." 같은 무의미한 매뉴얼인데, 이걸 AI 프롬프트로 품질 기준부터 바꿨다. 완벽한 건 아니지만 나의 역할은 작성자에서 검토자가 되었다. 기존에 작성된 매뉴얼 (나쁜 예시) 설명이 아닌 화면에 있는 정보를 반복하여 알려주는 거다. 정보로서 가치가 없다. "저장 버튼을 누르면 저장됩니다." → 버튼 이름과 기능이 동일, 설명 가치 없음. "삭제 아이콘을 클릭하면 삭제됩니다." → 사용자가 아이콘 모양과 텍스트만 봐도 알 수 있는 정보. "비밀번호 입력란에 비밀번호를 입력합니다." → 필드 이름이 이미 ‘비밀번호 입력란’인데 같은 말 반복. "로그인 버튼을 누르면 로그인이 됩니다." → 버튼 이름과 결과가 동일, 불필요한 설명. "인쇄 버튼을 누르면 인쇄가 시작됩니다." → 버튼 이름이 동작을 그대로 설명하고 있어 중
언제 되나요..? 3줄 요약 [원칙] 고객의 '무응답 불안'을 없애기 위해 1영업일 내 응답, 3영업일 간격 중간 공유, 변동 시 즉시 통보하는 Zero-Silence 정책을 도입한다. [기준] 기술적 심각도(Severity)와 비즈니스 우선순위(Priority)를 분리해 처리 순서를 정하고, 우선순위는 PM/PO 확정을 따른다. [행동] 업데이트할 내용이 없어도 3영업일마다 정기 상태 공유(Heartbeat)를 강제하며, 이를 보장하기 위해 내부 OLA(내부 응답 기준) 및 에스컬레이션 규칙을 운영한다. 고객 불만 사항 - 응답 지연 중 무소통 발생 원인 - 프로세스 공백: 내부적으로 “언제까지 회신/업데이트/ETA 공유” 해야 하는 기준(SLA/OLA)이 없음. 그리하여.. 만든 CS 가이드 1. 목표 - 신뢰 회복: 고객사의 '무응답에 대한 불안'을 해소 - 이상적 목표: 7일 이내 처리 - 현실적 목표: 3영업일 간격 중간 보고 + 일정 변동 시 즉시 공유 - 핵심 지표: 고
BTS/ALM 도구와 연동하는 발급이다. 어쩌다보니 발급할 일이 생겼다. 연동하는 곳에 직접 패스워드를 넣지 않고 토큰(PAT)을 발급받아 넣는다. 1. 우측 상단 프로필 아이콘 클릭 > Settings (설정) 클릭. 2. 왼쪽 메뉴 스크롤을 맨 아래로 내려서 Developer settings 클릭. 3. 왼쪽 메뉴에서 Personal access tokens > Tokens (classic) 선택. 4. Generate new token 클릭 > Generate new token (classic) 선택. 5. 토큰 정보 입력 및 생성. 5.1. Note에 용도(예: Jira Connection) 입력. 5.2. Expiration 만료 설정 입력. 5.3. Select scopes (권한 설정)에서 repo 체크박스를 체크드. (중요!) 5.4. 맨 아래 Generate token 초록색 버튼 클릭. 6. 발급한 토큰 정보 복사 및 저장. (매우 중요!) 깃랩도 이와 비슷하다.
내 경력의 절반 이상은 기획자 포지션이 없는 환경이었다. 소규모 중소기업이라 그런지 기획자를 따로 두지 않았고, PM이 일부 역할을 같이 하는 구조가 많았다. 문제는 PM과 기획자의 업무는 다르다는 점이다. 상세기획이 없으면 QA는 테스트만 어려운 것이 아니다. 무엇을 기준으로 기대결과를 어떻게 써야 할지 고민이다. 버그인지 개선인지, 수정 대상인지 아닌지도 애매해진다. 이건 버그가 아니라 기능이에요. 짤이 생각난다. 기획자가 없어서 생기는 문제 기획자 또는 상세기획이 없으면 테스트 베이시스가 충분하지 않다. 그러면 테스트 설계와 리포트 둘 다 어려워진다. 이럴 때 많이 등장하는 단어가 있다. "정상동작" 버그는 확실한데 기대결과를 명확히 모를 때 쓰는 마법의 단어이다. 권장하지 않는다. 상세 기획이 없으면 버그와 개선의 경계가 흐려진다 버그와 개선 상세기획이 없으면 기능적 오류와 UX/UI 개선의 경계도 흐려진다. - 버그: 기능적 오류이며 반드시 수정 대상 - 개선: 선택적 수정
현재 되는 앱 버전: 11.2601.2.0 ** OS 업데이트마다 차이 있을 수 있음. 윈도우 11.. OS 업데이트되었더니 어느 순간 자동 녹화 안 되었다. 자동 저장만 쓰던 나는 폭탄 같은 업데이트로 재현 영상을 여러 번 찍고 선택받은 순간만 저장 버튼을 눌러야 했다. AI에게 물었더니 여러 가지 답을 줬다. 설정, 권한, 스토리지, 드라이버, 업데이트 등등 1. Microsoft Store에서 최신 버전으로 업데이트 앱의 이름은 '캡처 및 스케치' 2. 캡처 도구 설정 확인 자동 저장: 켬, 경로 맞는지 이렇게 해도 안 되었는데 어느 순간 해결되었다.
업로드 테스트(용량 제한 검증)를 하다 보면 파일 사이즈 체크가 필요한 경우가 있다. 예를 들어 파일 업로드를 정확히 100MB까지 지원한다. 유효/무효 경곗값 테스트를 하면 아래와 같은 케이스가 나온다. 유효값: 104,857,600바이트 (100MB) 무효값: 104,857,601바이트 (100MB + 1byte) 명령어 한 줄로 바이트 단위로 정확하게 더미 파일을 만들 수 있다. 윈도우는 "test.exe"로 맥은 "test.dmg"로 만드는 방법이다. 생성 위치와 파일명은 적절히 변경한다. 윈도우 커맨드 명령어: fsutil 파일을 생성할 위치로 이동한다. cd D:\blog\naver\tami 100MB 생성 (104,857,600 바이트) fsutil file createnew test.exe 104857600 100MB + 1byte 생성 (104,857,601 바이트) fsutil file createnew test.exe 104857601 - 관리자 권한으로 명령 프
MS Office 엑셀 기준이다. xlsx 파일을 내보내기 기능을 테스트하다 알았다. 엑셀에서 하나의 셀에 저장 가능한 글자수는 공백 포함 32,767자이다. 셀 저장 기준: 32,767자 32,767자 초과 입력해서 내보내기 테스트를 해본다. 초과된 글자에 대해 대부분은 잘린다. 별 말 없으면 앞의 32,767자까지 나오는지 확인하면 된다. 간략하게 끝.
RDP > 옵션 표시 > 로컬 리소스 탭 > "클립보드" 항목 체크 RDP > 옵션 표시 > 로컬 리소스 탭 > 자세히(M)... > "공유할 드라이브" 항목 체크 > 확인 USB, 외장하드 등 원격 접속 중에 공유가 필요하다면 "나중에 연결할 드라이브" 항목에 체크한다. 주소를 입력하고 연결한다. 탐색기에서 확인하면 앞에서 선택한 드라이브가 보인다. 끝.
로컬과 가상머신 간의 클립보드 공유 1. 게스트 확장 설치 가상머신 부팅 > 장치 > 게스트 확장 CD 이미지 삽입... > 탐색기 > D:\ 이동 > VBoxWindowsAdditions.exe 실행하여 설치 2. VirtuaBox 설정 - 머신 > 설정 > Expert 탭 > 일반 > Features 탭 > Shared Clipboard: "양방향" - 머신 > 설정 > Expert 탭 > 일반 > Features 탭 > Drag-and-Drop: "양방향" 클립보드와 드래그앤드롭을 설정한다. 끝.
이건 담당자가 누구죠..?;; 업무를 하면서 이슈를 올리는데 담당자가 할당이 안 되는 경우가 많다. 어느회사를 가든. QA의 문제도, 개발자의 회피도 아니다. 구조의 문제이다. 선 1줄 요약 이슈 담당자 부재: 사이드 이슈 담당자 공백 → 담당자 지정 원칙과 중재자 역할 설정 배경 개발은 피처 단위로 진행되며, 해당 기능에서 파생된 이슈는 QA가 기능 담당 개발자에게 직접 지정하고 있음. 그러나 테스트 과정에서 기존 이슈인지, 사이드 이펙트인지 불명확한 새로운 이슈가 발견되는 경우가 있음. 이 경우 QA는 이슈를 객관적으로 기록하고 보고하여 담당자 지정이 가능하도록 지원하지만, 담당 개발자를 특정하기 어려워 담당자 공백이 발생함. 개발자는 “이번 피처에서 해당 기능 수정은 아닙니다”, “현재 담당 중인 모듈과 직접적인 관련은 없습니다” 등으로 표현할 수 있음. QA는 발견된 이슈를 체계적으로 보고하되, 담당자 지정은 별도의 조율이 필요함. 이슈의 조치 담당자 부재 기능 개발에서 파생
재현이 안 되는데요..? 선 1줄 요약 QA는 재현 조건 책임, 개발자는 기술 원인 책임 배경 "재현이 안 되는데요?" 업무 하면서 여러번 겪는 일이다. 어디에서 문제인것인가. QA의 조건 누락하기? 개발자가 로컬 환경 결과로 판단하기? 타이밍 문제로 재현 안되니까 넘어가기? 재현 불가 이슈는 같이 해결해야한다. QA는 조건을 책임지고, 개발자는 원인을 책임지는게 이상적이다. 하지만.. 현실은 엇갈린다. 재현 불가 이슈에서 역할 분담 QA는 조건확인 내가 작성한 리포트를 돌아본다. 환경, 조건, 절차, 권한, 데이터, 캐시 등 리포트는 현상이 안된다고 전달하는게 목적이 아니다. 리포트를 보고 따라하면 재현이 되도록 하는것이다. 조건이 정확하지 않으면 재현이 안된다. 타이밍 이슈도 있겠지만, 최대한 명확하게 서술한다. 개발자는 원인파악 QA가 툴로 추적하는것보다 개발자가 소스, 로그, 설정값, 데이터흐름 등을 통해 원인파악하는게 빠르다. 원인분석은 코드를 직접 보는 개발자가 한다.
QA가 CS요..? B2B에서는 흔하다. B2C에서 CS를 한다고 하면 돔황차..는 아니고.. 이는 회사마다 다르다. B2C에서의 CS 이커머스에서 예를 들어보겠다. 상품, 배송, 결제 등 비기능 문의가 90% 이상이다. QA 스킬이 필요 없는 상황이 대부분이다. 이걸 QA가 처리한다면 비효율적이다. B2B에서의 CS B2B에서 CS는 제품 관련이 많다. 제품 사용 중 오류가 발생하면 QA한테 묻는게 빠르고 효율적이다. 1차적으로 QA가 재현여부를 확인한다. 그래서 B2B에서 QA가 CS를 맡는게 그리 놀라울 일은 아니다. QA팀에서 테스트를 했으니 이력을 알 것이고, PM 못지 않게 기능도 많이 알고 있는게 QA이다. 계약에 따라 유지보수도 진행해야한다. 고객 인입 CS 이슈 3가지 분류 - 문의: QA 선에서 처리가 가능 - 개선: 정책, 계약에 따라 PM이 판단 - 버그: 재현 확인 후 개발에 전달 버그라면 재현 여부를 확인하여 조치될 수 있도록 한다. 문의사항 같은 개선이 등
좀 섞였는데 2024 맞을 거다.. 실루엣몬.. 꽃이 좋은 곰. 포곰곰 양쪽눈잠에 찰칵. 뜨아거 눈 감음. 이븐곰 나뭇잎 뱉기. 이븐곰 스킬 패치 되고 나서 스킬 연사 꼬지모 사탕 보내면 친구 잘림. 꼬지모 리서치몬 모두 한화면에 다 담기 해봄. 친구 사탕몬 상태가.. 향로가 살렸음. 오류 발생해서 몇 칸인지 안 보임. 이럴 땐 재시작하면 됨. 베이리프 스이쿤 리서치 호수가 진짜 이뻤음. 배경 가지고 싶음. Previous image Next image 피츄 스이쿤 이벤트 호수 밤 Previous image Next image 이븐곰 배위잠.. 만보 하품할 때마다 드는 생각은 만보가 먹을 거 같음..ㅠㅠ 이브이 나뭇잎먹기잠 그대로 보내면 친구 잘림. 마자용 작년과 다른게 있음. 모자색. 모자 색깔 장사함. 피카츄 피카츄 메타몽 변신잠 시리즈 메타몽 폰이 구린 탓에.. 꽃밭 속에서 이런 일도 있었음. 찬스는 꼭 이럴 때.. 앤테이
면접관 구성: 관리자급?, 개발팀장, 인사팀 질문 구성: 경험 6, 기술 4 시간: 약 50분 면접 질문 자체는 좋았으나, 1차 면접 보고 잠수.. QA 면접 질문 테스트 메트릭 스모크 테스트 새니티 테스트 확인 테스트 회귀 테스트 시나리오 테스트 인력 관리 경험 애자일 스프린트 환경에서 QA 전략 결함 생명주기 이력서 바탕에 대한 사례 (근거) 프로세스 개선해 나가는 과정에서 어떻게 할 것인가 테스트 베이시스와 구멍 어떻게 할 것인가 기획 산출물도 여러 가지. 기획 산출물 중 뭐에 가까운가? 문제 해결 경험과 왜 그런 일이 발생했는가 합격하면 물어봐도 될 것들인데.. 요즘엔 이런 거 합격 시그널 아니다. 경험에 의한 빅데이타다. 물어는 볼 수 있다. ^^ 김칫국 드링킹 금지!! 탄생 연도 성격 장단점 최종학력 취득예정인 자격증 직전연봉 및 희망연봉 연봉 수평이동 가능 여부 내규에 따를 것인지, 최소 이만큼인지 거주지 및 소요시간 최종 합격 통보 후 입사 가능 소요 기간
면접 구성: 조직장(?) 1 질문: 경험 10 시간: 약 60분 후기 이전 조직 구조가 특이(?) 평범하지는 않았다. 팀 내 여러 직무가 있었고, 내 답변을 통해서 왜 그렇게 구성되어 있는지 알 것 같다고 했다. 난 여기서 탈락 포인트를 느꼈다.. 시간을 내 답변으로 거의 꽉 채워서 했다. 면접자가 회사에 질문할 시간에는, 면접관이 더 이상 나에게 시간을 쓰지 않겠다는 의지가 보였다.. 질문 내용 자체는 괜찮았는데 내 눈에 그런 태도가 보였다. 인터뷰가 끝나고 인사팀에서 물어보는 거에서도 이미 합불 판별이 난거 같은 느낌이었다. 정말 노트북, 필기구 아무것도 준비 안 하고 형식상 물어본 거 같았다. 물어보고 흘려듣기 마지막 발언이라고 강점 혹은 하지 못한 말이 합불에 큰 영향은 없다. 기업 이미지 관리 차원이다. QA 면접 질문 자기소개 이전 직장 퇴사 사유, BM, 팀 구조, 규모, 업무방식, 개발 방법론 회고 백로그 관리 프로세스 개선 기획이 없는데 TC를 어떻게 설계하는지 TC
드디어 열렸다!! 조건은 모름.. 아침에 피카츄 알람 듣고 일어나는데, 들어본 적 없는 새로운 노래가 들렸다. 설마 이게 그 콧노래 2번?! 제발 맞기를 피카츄 보이스 스페셜 콧노래 2번 해방 플플 기록은 이렇다. Pokemon Sleep Pokemon GO Plus + Night Cap Pikachu Pikachu Cries Special Humming 2 ポケスリ ナイトキャップのピカチュウ ピカチュウのボイス 鼻歌2 영어, 일본어 애타게 찾아다녔는데 드디어 해방!!
서비스는 출시 이후 "유지보수" 중심으로 전환된다. 하지만, 내부 기여도나 대우는 내 경험상 개발과 동일하게 "신규개발"이 우위이다. SI 쪽에서 듣던 용어를 자사 QA 쪽에서도 들었다. 개발자 뿐만 아니라 QA도 이렇게 나누는가 싶었다.. 여기서 말하는 유지보수란? 출시된 서비스는 기본적으로 유지보수를 하게 된다. 여기서 말하는 유지보수란 단순한 오류 수정 외에도 다음을 포함한다. UI/UX 개선, 디자인 변경 코드 리팩토링 서비스 안정화와 지속적인 개선 업무가 주를 이룬다. 그리고, 앞단계에서 못 하거나 안 하는것 짬처리도 포함이다.. 성과 인식: 누가 더 인정받는가? 돈, 성과는 신규개발이 더 많이 가져간다. 개발 SI 시장 기준인데 다른 곳도 비슷할것이다. 아무것도 없는거에서 창조한거랑, 뭐라도 있는걸 고치는거랑 기여도를 다르게 본다. 신규개발: 아무것도 없는 상태에서 완성된 기능을 만든 것 → 기여도가 눈에 띈다 유지보수: 기존 기능을 다듬고 수정하는 것 → 드러나지 않는
일부 경험해 봤습니다. 면접 질문으로 많이 들어볼 만큼 현재 진행형으로 논의되는 개발 프로세스 중 하나가 애자일이다. 개발팀에서는 애자일 방식을 따른다. 하지만 QA 입장에서는 이게 애자일이라고 느껴지지 않는 경우가 많다. 디자인 완료 → 기획 완료 → 개발 완료 → 테스트 순서로 진행되는 구조가 많다. 짧은 반복 주기로 진행되지만, 구조적으로는 폭포수 방식에 더 가깝다고 느껴진다. 스프린트 2주 단위의 릴리즈 주기를 가졌던 곳이 있다. 그에 맞춰 스프린트도 2주였다. 앱 중심의 프로젝트면 보통 릴리즈 주기에 맞춰 스프린트를 구성하는 경우가 많았다. 경험했던 곳에서 단순하게 1주는 개발, 1주는 테스트(수정 포함)라고 보면 된다. 탑다운으로 기획+디자인 거치고 개발이 끝나면 테스트가 온다. 실질적으로는 폭포수 방식에 가까워서 애자일 경험 여부를 말할 때 약간 고민이 된다. 회고 내 경험에서는 스프린트 다음으로 많이 하던 게 회고이다. 스쿼드 단위의 회고 경험은 없고, QA 팀 중심으
뒷면 앞면 1g도 골드바라고 한다..ㅎㅎ 되게 작다. 투자용은 아니고 선물용으로 알아보면서 나중에 투자 대비 알아본 걸 정리했다. 실물금과 보증서가 일체형이다. 신용카드보다 약간 작다. 가위로 잘라서 분리하는 순간 가치가 떨어질 거 같은 느낌이다. 품질보증 3가지 확인 사항 구매 시 꼭 확인해야는 3가지이다. 금에 직접 표기된 것도 꼭 확인하고, 종이 형태의 보증서도 같이 있는 게 좋다. 금 표기 예시 FINE GOLD 999.9 1g 콩알만 한 중량이 낮은 주물금에는 다 표기 안되는 경우도 있다. 1. 소재 FINE GOLD Au 금 金 2. 순도(함량) 999.9 (천분율 퍼밀) 99.99 (백분율 퍼센트) 표기 차이가 있고 포나인이면 된다. 9가 4개라 포나인(Four Nine)이라고 한다. 포나인과 쓰리나인(99.99% 또는 99.9%)은 다른 거다. 금 투자를 할 거면 포나인을 선택한다. 파이브나인도 있는데 표준은 포나인이다. 금테크에 쓰리나인은 손해이다. 24K라고만 써진
면접관 구성: 조직장(?), CTO 질문 구성: 경험 10 시간: 약 50분 QA 파트가 없고 빌드 업을 하기 위한 질문 위주였다. 어떻게에 대한 질문이 많았다. 그리고 면접에 대한 결과를 어느 채널에도 알려주지 않아, 지원 플랫폼에서 4주 뒤 자동으로 탈락되었다. 스팸함에도 절대 없었다. 면접 결과 무통보 회사는 기억에 잘 남는다. 서류 결과 무통보는 이제 그러려니 하다.. QA 면접 질문 지기 소개 이력서 성과의 근거 의견 충돌 어떻게 개발자 충돌 ㅇㅇ분야 어떻게 테스트할 것인가 비기능 테스트 바라는 점 프로세스 문의사항 같은 건 어떻게 테스트 레일, 지라 등 장점 문서 체계화 어떻게 사인 오프 문서 언제 이직 사유 지원 동기
면접관 구성: 팀장 질문 구성: 경험 10 시간: 약 40분 질문 다 하고서는 원하는 게 자동화 엔지니어 포지션이라고 한다.. 우대사항에 자동화 경험이 있었다.. QA 면접 질문 QA 계기 보안 테스트 (취약점, 암호화 등) 비기능 테스트 (부하, 스트레스 등) 다국어 테스트 시나리오 테스트 테스트 방법 테스트 범위 어떻게 테스트 일정 관리 테스트에서 가장 중요하게 생각하는 거 본인 강점 테스트 자동화 프로그래밍 언어 (c, java, python) 스펙에 없는 개선 사항에 대해 개발자가 호의적인가 조직 내 불협화음 감정적 대응 어떻게 몇 년 생
어지럽다.. 둘 다 동시에 경험해 봤다. 처한 상황, 직급, 나에게 오는 피해에 따라 다르겠다.. 여기서 성격이 좋고 나쁘고는 상대적이다. 성격 나쁜 일 잘 상사와 성격 착한(나쁜 의미에서) 일 못 동료였다. 성격 나쁜 일 잘 상사 다행(?)인 건 일 잘 상사시겠다. 개인적으로 일 못 상사는 더 싫다. 일을 잘하는 상사는 대외적으로 문제없다. 성격이 나쁘다는 건 나에게 직접적으로 나타나지 않았다. 다만, 일 못 동료에게 나타났는데 듣는 사람이 괴로울 정도다.. 일 처리는 잘 하니 나에게 오는 피해 같은 건 없다. 성격 좋은 일 못 동료 일을 못하는 동료는 내가 힘들다.. 나한테 간접적인 피해가 오게 되는데, 뒤치다꺼리를 내가 해야 하는 상황이 발생한다. 이게 반복되면 생각이 바뀐다.. 1인분은 해야 하지 않겠나 둘 다 힘들다.
특별한 잠카츄는 돈 주고 살 수 있음. 타이틀 값임. 졸린 눈 나이트캡 피카츄 피카. 잠만보 손 밟음.. 피카츄 이거슨 총파업. 포슬립 본섬 파업 숫자가 맨 앞에 오는데.. 패치됨. 이브이 애버. 첫 이로치라 찍어봤음. 이로치 애버라스 몽. 찬스는 이럴 때 뜸. 메타몽 찬스 타이밍 치코. 꼬리 같은 나뭇잎. 치코리타 잎사귀 디그다. 만보 손 어떻게 한 거야.. 디그다 브이. 이로치 이브이 총파업. 설원 파업 이 사이에 할카츄 주황이 있어야 하는데 사진이 읎음. 홀카츄. 홀리데이 빨간 모자 산타츄 리세 없이 되는대로 키움.
쇼핑몰 이동 구조 상품 목록 페이지에서 상품 목록을 클릭하면, 상품 상세 페이지로 이동하는 구조이다. 그리고 다시 목록으로 돌아가 위 동작을 반복한다. CSR vs SSR: 뒤로가기 UX의 차이 상세 페이지에서 뒤로가기를 누르면 이전 페이지(목록 페이지)로 이동한다. 아마 history.back()일 것이다. 이때 스크롤 차이가 발생한다. CSR 방식: 캐시 상태를 활용해서 목록으로 돌아가면 스크롤 위치가 유지된다. SSR 방식: 페이지를 새로 불러온다. 스크롤이 초기화되는 거다. 예상되는 문제 쇼핑몰 특성상 반복적인 동작이 발생한다. 목록 페이지에서 상품을 찾아 클릭하고 상세 페이지에서 보고 뒤로 가면 다시 목록 페이지이다. 그럼 다시 동일한 동작을 한다. 목록 → 상세 → 목록 → 상세 → 목록 ... 그런데 여기서 목록이 유지가 안 된다?! 어디까지 스크롤 했는지 찾아야 한다. 쇼핑 경험이 저하되면서 이탈하는 포인트가 되겠다. 무한 스크롤 방식이라면 체감이 더 클 것이다.. 대
재료 없으면 없는대로 두부와 소스 두개만 넣어서 잘 먹는다. ㅋㅋ 없으면 없는대로 먹어도 살아진다. 오늘은 재료가 남은게 있어서 조금씩 넣었다. 두부와 당근 조합 괜찮다. 재료 두부 300g 마파두부 소스 1개 마늘 조금 당근 조금 파 조금 양파 없음.. 고기 없음.. 시간 재료 손질 약 20분 조리 약 15분
서버 이슈 발견을 위한 API 테스트 선행 개발은 크게 백엔드(BE)와 프론트엔드(FE)로 나뉜다. 보통 백엔드 작업이 완료된 후 프론트엔드 작업이 시작된다. 구조만 알아도 프론트 작업이 가능하긴 하다. API 테스트는 언제? 사용자에게 보이는 FE 결과물이 나오지 않아도 BE 결과물(API)을 먼저 테스트하면 된다. 이전 회사는 API 테스트 없이 클라 테스트를 하다 보면 서버 이슈가 발견된다.. 디폴트 값으로 요청하는 경우에는 문제가 발견되지 않다가, 변경된 값으로 요청할 때 서버 응답 결과가 달라지는 문제가 발생했다. 문제 사례: 뭐가 맞는 거? A 플랫폼: 헤더 + 쿼리스트링으로 요청 → 상태 200 (정상 응답) B 플랫폼: 헤더로만 요청 → 상태 500 (서버 오류) API 문서: 헤더로 요청 여기서 드는 의문들 아니.. 이건 기준이 뭘까?-_- 결과가 나오는 걸 보니 문서 최신화가 안 된 거? 문서대로 요청을 해야 하는데 작업을 빼먹은 거? 그리고 요청을 어떤 방법으로
잘게 깍둑썰기하려고 했는데 너무 힘들고 귀찮다.. 계란은 잘 섞는다. 가난하면 시간이 든다. 알끈 안 버리고 잘게 끊어서 먹는다.. 스크램블 에그를 만들어서 잠깐 옮겨 놓는다. 프라이팬 설거지 보다 그릇 설거지하는 게 낫다. 당근은 맛이 안 나도록 푹 익혀야 하니 먼저 볶아준다. 양파, 파는 안 익어도 상관없으니 나중에 볶는다. 다 볶았으면 잘 섞는다. 볶음밥의 비밀은 굴 소스였다.!! 재료랑 비주얼이 어쩐지 짜장 소스를 부어야 할 거 같다.. 재료 계란 3개 양파 2개 는 너무 많았다.. 당근 조금 파 조금 굴 소스 조금 깨 조금 기름 조금 마늘 깜빡함 시간 재료 손질 약 30분 조리 약 15분
테스트의 목적, 조건, 절차 등이 명확한 것이라 생각한다. TC는 CL과 달리 명확해야 한다. 목적, 조건, 절차, 기대 결과가 불분명하면 테스트를 수행하는 입장에서 같은 기능을 다른 방식으로 해석할 수 있다. 베스트 케이스 누가 봐도 수행할 수 있는 거다. 쉽고 친절하고 자세하게 써서 수행하는 데 물어볼 게 없는 거다. 특히나 남이 쓴 TC를 수행하다 보면 애매모호한 표현은 각자의 생각대로 해석해서 결과가 달라지는 경우도 있다. 수행 절차와 기대 결과가 명확해야 한다. 수행 흐름을 고려하고 시나리오 간 맥락 연결된 거와 유지 보수가 용이하게 작성한 것도 좋다. 테스트 레일같이 지라와 연동되어 자동으로 리포팅되는 게 아니라면, 복사 붙여넣기로 이슈 리포팅을 쉽게 작성할 수 있는 구조를 고려하는 것도 괜찮다. 사전 조건에 스텝이 너무 길면 사전 조건에 ㅇㅇ 페이지 진입 상태 이런 식으로 적기도 하는데, 이건 작성 스타일에 따라 다르다. 테스트 레일처럼 스텝 하나에 기대 결과 하나씩 매
닭 한 마리 손질할 자신이 읎다. 뼈 나오는 것도 싫다. 손질 다 된 냉동 닭을 사서 편하게 조리한다. ㅋㅋ 냉동 닭을 해동시킨다. 해동되는 시간 동안 야채를 손질한다. 해동된 닭을 토막 낸다. 소스 잘 배어들게.. 모든 재료를 넣고 끓인다. 재료 찜닭 소스 냉동 닭 가슴살, 냉동 닭 안심 파 조금 양파 1개 마늘 조금 당근 없어서 못 넣음.. 시간 재료 손질 약 20분 조리 약 20분
간편하게 한 끼 가능하다. 삼각보다 사각이 밥알 넣기 편하다. 유부초밥에 들어있는 건더기로는 부족하다. 밥알만큼 잘게 썰기에는 시간이 많이 든다. 김, 깨만 추가로 넣어 먹는다. 재료 유부초밥 키트 밥 김 깨 시간 만들기 약 20분
짐이 있는 상태에서 타일 공사는 비추다. 공사기간 실제 공사는 2일이다. 하지만 함정이 있다. 타일 말리는 시간이 있어 총 7일은 못 쓴다. 결과 망했다. 메지 탈락, 단차 메지 탈락, 단차 메지 탈락 크로스 스페이서와 간격, 메지 탈락 크로스 스페이서 타일 단차 안 맞아서 생기는 문제가 다수 있다. 물이 안 내려가서 고이는 게 제일 큰 문제다. 일주일도 안 되어서 바닥 메지가 탈락했다. 메지 안에 있는 물이 자연적으로 마를 거라고 생각하지 마세욬 크로스 스페이서가 보이는데 정상이라고 한다. AS를 3번 방문했다. 수납장 수평 불량으로 2번, 벽 타일 떠서(?) 1번. 벽 타일을 눌렀더니 들어갔다 나왔다. 실크 벽지처럼 들어갔다 튀어나오는 느낌으로? AS 요청했더니 군말 없이 왔다. 문제 있는거였다.. 액세서리가 싸구려인지 6개월도 되지 않았는데 녹이 발생한다. 짐을 옮기는 과정에서 문 틀 필름이 뜯어졌다. 타일 자르는 소리 엄청 크다. 분진은 비닐을 덮는다 하지만, 작업자가 FM대
오징어볶음을 하려고 했는데 실패했다. 이거슨 볶음과 탕의 중간? 오징어 뭇국을 하려다가 양념이 없어서 볶음으로 바꿨다. 오징어볶음에 무가 안 들어가는 이유가 있었다. 물이 안 사라진다.. 약불에 졸여봐도 20분 넘게 졸여봤는데 이건 아니다.. 재료 냉동 오징어 300g 무 조금 마늘 조금 만능 양념 조금 파 조금 양파 넣고 싶었으나 없어서 스킵 당근 넣고 싶었으나 무와 조합 안 맞는다 하여 스킵 시간 재료 손질 약 30분 흙 묻은 무와.. 무를 채 썰어서 시간 다 잡아먹음 -_- 조리 약 20분 오징어 냄새가 나고 오징어가 꼬불꼬불 거리면 완성이다.
건조기 필터만 청소해왔다. 필터를 빼면 그 안에 먼지 부스러기 같은 게 있다. 필터 2개의 높은 난이도를 통과한 고운 입자이다. 물 청소가 되는 거였다.. 띠용.. 실은 스팀 기능도 사용 안 해봤다..ㅎㅎ 콘덴서..? 더듬이같이 생긴 그거..? 설명서를 보면 이렇게 되어있다. 콘덴서 케어 설명서 물 1리터 넣고 콘덴서케어 모드로 실행하면 된다. 콘덴서 케어 전 약 한 시간 뒤에 확인해 보면.. 어째서인지 필터에 먼지가 붙어있다. 그리고 필터 안쪽에 말끔하게 청소는 안 되었다. 몇 년 사용한 거 한 번 청소한다고 될 리가 없다. 콘덴서 케어 후 집안일은 끝이 없다.
뚝배기도 없고 중탕할 도구도 없다. 답은 전자레인지이다. 집에서 열일하는 전자제품 탑5에 든다. 재료 날계란 3개 (왕란은 아닌듯) 우유 100ml? 계란 1, 우유 0.7 정도? 자신 없으면 물 또는 우유를 조금만 넣는게 낫다. 많이 넣었다가 계란국..이 될수도 있다. 파 조금 당근 조금 양파 없어서 못 넣음.. 시간 재료 손질 약 20분 당근은 잘게 썰어준다. 조리 약 5분 맛있게 먹다가 정중앙에 안 익었다..
회원가입 시 휴대전화번호 중복 체크가 실패했던 사례이다. 앞자리 ‘0’ 하나로 갈렸다. 동일번호로 한 번은 ‘010’, 다른 한 번은 ‘10’으로 입력해 중복 체크를 우회한거다. 휴대전화번호, ‘010’과 ‘10’은 다른 값 회원가입 시 휴대전화번호를 기준으로 중복 가입 여부를 확인하는데 (CI 인증 아님) 중복 체크가 실패한 사례가 있다. 휴대전화번호를 input type="text"로 받는다. 아래 2개 번호는 사람은 같은 번호라고 인식하지만, 컴퓨터에게는 다른 값이다. 010-0000-0000 10-0000-0000 국내 휴대전화번호 형식 흔히 사용하는 국내휴대전화번호의 형식은 아래와 같다. 국가번호는 제외한다. 010-0000-0000 앞자리 0이 누락된 값을 다른 값으로 인식하면서 중복 체크에 실패했다. 전에도 말했듯이 컴퓨터에게는 융통성이 없고, 사람이 처리해야된다. 조금 자세하게 알아보면 이렇다. 데이터 타입을 숫자로 저장한다면 앞자리가 0이면 동일한 값으로 인식한다.
앞에서 실습한 테스트가 끝나고 데이터 및 변수를 정리한다. 실습하면서 생성한 데이터 및 변수를 삭제하여 초기 상태로 만든다. 앞에서 실습한건 아래 링크에 있다. 기능 테스트(1) 설정 기능 테스트(2) 스크립트 Postman > New > Collection > view all template > Functional testing 선택 Functional testing 컬렉션 > Cleanup 폴더 Cleanup 폴더 collection Variables 셋업 과정을 진행하면 6개의 변수가 생성된다. 기본 제공되는 2개는 클린업 대상이 아니다. Cleanup 전 collection Variables Delete toAccount 받는 계좌를 삭제한다. 변수 삭제 아님. 식별 정보는 URL에 아이디로 요청한다. 상태 코드 200을 받고 테스트 결과도 통과이다. Delete toAccount req Delete fromAccount 보내는 계좌 및 컬렉션 변수를 삭제한다. //clean
Postman Runner로 시나리오 기반 자동 실행 실습이다. API 요청이 순차적으로 연결된 시나리오를 바탕으로한다. 전체 흐름이 이어지도록 Runner로 자동 실행한다. 시나리오 (데이터 흐름) 예제는 유효한 정상 거래 흐름과 유효하지 않은 실패 거래 흐름 두 가지로 시나리오를 나눴다. 각 흐름을 구성하는 요청과 그 결과를 자동으로 실행하면서 전체 테스트를 검증할 수 있다. 정상 거래의 시나리오 API 키 생성 → 계좌 생성 → 전체 계좌 조회 → 사용자 간 트랜잭션 생성(송금) → 받는 계좌 트랜잭션 조회 → 특정 트랜잭션 조회 → 잔액 확인 → 테스트 후 계좌 삭제 및 변수 초기화 유효하지 않은 거래의 시나리오 API 키 생성 → 계좌 생성 → 전체 계좌 조회 → 잔액 부족 상태에서 트랜잭션 시도 → 받는 계좌 트랜잭션 조회 → 잔액 확인 → 테스트 후 계좌 삭제 및 변수 초기화 살펴보기 API Key와 인증은 컬렉션 레벨에서 관리한다. Previous image Next
이전 글 API 테스트: End-to-End (e2e)에서 함수에 대해 알아본거다. 예제에서 어떻게 코드 짜는지 알아보고 실무에 적용하면 좋을것들을 생각해본다. 상태코드 확인 보낸 요청이 제대로 처리되었는지 확인한다. 다음 요청으로 넘어가기 위한 기준점으로 사용한다. // 응답 상태코드가 특정 값인지 확인 pm.response.to.have.status(상태코드); // 상태코드 값이 200인지 확인 pm.response.to.have.status(200); // 상태코드 값이 400인지 확인 pm.response.to.have.status(400); 응답 처리 응답은 파싱해서 테스트하거나 값을 추출한다. 파싱한 응답을 변수에 담아 사용한다. // 응답을 JSON 객체로 파싱 let response = pm.response.json(); 구조 및 속성 확인 특정한 필드를 포함하는지, 자료형(타입)이 맞는지 확인한다. // 객체가 특정 속성을 포함하는지 확인 pm.expect(객체).
여러 컴포넌트 간 API 연동 흐름이 올바르게 연결되는지 검증하는 과정이다. 포스트맨 예제로 토큰 발급 → 사용자 정보 확인 → 토큰 해제 과정의 흐름을 테스트한다. 간단한 구성이지만 통합 테스트의 기본 구조를 이해하기에 충분하다. New > Collection > view all template > Intergration testing basics 선택 Intergration testing basics 통합 테스트란? 여러 컴포넌트를 함께 묶어서 테스트하는 과정 엔드포인트가 서로 다른 모듈, 외부 서비스가 연동될 때 어떻게 작동하는지 확인 API 통합 테스트에서 확인할 것들 서로 다른 엔드포인트 또는 서비스간 데이터 흐름과 상호작용을 검증한다. 테스트 목표 API 간 요청/응답이 정확하게 오고가는지 각 컴포넌트가 서로 올바르게 연동되는지 데이터 흐름이 일관되게 동작되는지 예제 살펴보기 collection level baseUrl, token을 컬렉션 레벨 변수로 관리한다. coll
공식 홈페이지 등을 바탕으로 정리 종합 안내소인지 경품 교환소인지 용어 통일 했으면 좋겠다.. 수령 장소 조건 증정품 운영기간 야외 잔디광장 - 포켓피스 피카츄 부채 04-25(금) ~ 05-18(일) 야외 잔디광장 5번 종합 안내소 (경품 교환소) QR 스탬프 랠리 6곳 중 1곳 방문 메타몽 프로모 카드 04-25(금) ~ 05-18(일) 야외 잔디광장 5번 종합 안내소 (경품 교환소) QR 스탬프 랠리 6곳 모두 방문 포켓몬 타운 2025 스티커 04-25(금) ~ 05-18(일) 야외 잔디광장 3번 메타몽 팬클럽 하우스 - 썬캡 (메타몽 또는 몽카츄 랜덤) 04-25(금) ~ 05-18(일) 야외 잔디광장 3번 메타몽 팬클럽 하우스 메타몽 프로젝트 공식 SNS 팔로우 메타몽 스티커 04-25(금) ~ 05-18(일) 야외 잔디광장 5번 종합 안내소 (경품 교환소) - SV 메타몽 배포 코드 04-25(금) ~ 05-18(일) 잠실 롯데월드몰 2층 (ZARA 매장 앞 체험 부스)
기능이 제대로 동작했는지 조회 API로 확인한다. 이전글 요청과 지금글 응답의 정합성을 테스트 코드로 검증한다. 기능 테스트(1) 설정에서 테스트에 앞서 사전 설정을 마쳤다. New > Collection > view all template > Functional testing 선택 Functional testing 컬렉션 > Account Tests 폴더 Account Tests 폴더 컬렉션 변수 변수 값이 이전글과 다르다. 지금 쓰는 글에서 변수를 살펴보면 이렇게 되어있다. collection Variables Test 001 - Validate account added to system 시스템에 계좌가 추가되었는지 검증한다. 계좌 목록을 조회해서 추가한 받는 계좌가 있는지를 찾는다. let response = pm.response.json() let accountId = pm.collectionVariables.get('toAccountId') let account = resp
포스트맨 Functional API 예제로 가상 은행 기능 명세 기반 테스트이다. 컬렉션 변수와 스크립트를 활용해 반복 입력 없이 자동화할 수 있다. 테스트 설정(인증 발급, 변수 설정) 단계까지 내용이다. New > Collection > view all template > Functional testing 선택 Functional testing 컬렉션 > Setup 폴더 글이 길어져 설정하는거만 설명한다. Functional testing 컬렉션 > Setup 폴더 Collection 인증 및 변수 설정 컬렉션 레벨로 인증, 스크립트, 변수를 설정한다. 새로 생성해서 변수가 없는데, 아래 과정을 진행하고 다시 확인해보면 값이 들어간다. 인증은 API 요청 개별 적용보다는 변수에 담아 컬렉션 레벨이든 환경 레벨이든 한꺼번에 제어하는게 편하다. 단순 조회 같은거에는 굳이 인증이 필요없다. 단순하게 사용자를 구분할때 인증이 필요하다고 보면 어느정도 맞는말이다. (기초적 관점) 테스트
기능 외적으로 중요한 구조 유효성과 보안 항목 테스트 내용이다. 스키마 유효성 검사와 SQL 인젝션 테스트 예제 실습이다. New > Collection > view all template > API testing basics 선택 API testing basics 컬렉션 > API tests 폴더 JSON schema v4 validation, SQL injection security check 파일이다. tv4.validate tv4는 JSON 스키마 유효성 검사를 위한 기본 라이브러리이다. 예제 코드를 보면 변수 2개를 쓴다. schema 변수는 검증하는 기준이 된다. jsonResp 변수는 검증하고자 하는 데이터이다. 2개를 비교해서 서로 일치하는지를 확인한다. var schema = { "type": "object" }; const jsonResp = pm.response.json(); pm.test('Schema is valid', function() { pm.expect
이번 예제에서는 json 응답의 자료형과 구조를 확인하는 거다. API 명세대로 확인해야 클라쪽 파싱 오류 및 렌더링 실패를 사전에 예방할 수 있다. New > Collection > view all template > API testing basics 선택 API testing basics 컬렉션 > API tests 폴더 Functional, Functional2 파일을 가지고 본다. match Functional 파일을 열면 스크립트가 작성되어 있다. let jsonData = pm.response.json (); pm.expect(jsonData.form.someHash).to.match(정규표현식); 해석하면 json 타입의 응답을 변수 "jsonData"에 담는다. .은 체이닝 연산자이다. 최종적으로 "someHash" 키의 **값(value)**을 가지고 검증하는 거다. match 함수에는 정규 표현식(이하 정규식)이 들어있다. 알파벳 소문자와 숫자를 포함하는 7글자가
API 테스트 중에 상태코드, 응답시간, 데이터타입, 응답구조 등에 대해 검증할 수 있다. 직접 코드를 타이핑하지 않아도 우측 스니펫에서 선택하여 작성 가능하다. pm.test 코드 (링크클릭)에 이어서 작성하는거다. 이전 글에서포스트맨에서 제공하는 샘플 예제를 만들었다. New > Collection > view all template > API testing basics 선택 API testing basics 컬렉션 > API tests 폴더 API testing basics 컬렉션 > API tests 폴더 Status pm.response.to.have.status(200); 상태코드를 확인하는거다. 200이 아니면 다음 테스트 진행이 어렵다.. 빠르게 확인해야한다. Response Viewer의 코드와 일치한다. Status Test Results 응용하기 Pre-request Script에 지원하지 않는 값을 넣어 서버 에러를 유도하여 500 코드를 받는지 등을 확인한다.
지난 글(링크 클릭)에서 연차 회계일과 입사일 기준의 충돌에 대해 작성했다. 회사는 노무사를 통해 대응할 것이다. 이에 근로자가 대응할 수 있는 방법을 정리했다. 근거 자료를 수집해서 노동부에 질의하는 것이다. 쟁점 연차는 매년 회계연도 기준(1월 1일)으로 회사가 선지급한다. 연차 사용 시기까지 회사가 통제한다. 연차촉진제. 퇴사 시점에는 입사일 기준으로 연차 발생일을 다시 적용하며 초과 사용을 주장한다. 즉, 회사가 지급하고 사용까지 강제한 연차에 대해, 퇴사 시점에서 초과 사용을 통보하고, 총 사용 개수 확인을 요구하고, 초과 사용 책임을 근로자에게 전가하려는 방식 중 하나이다. 사용 개수에 대해 반복적으로 확인 요청해서 눈치챔 수집 항목 연차 발생 내역 연차 사용 내역 연차 사용 촉진 안내 내역 발생, 사용, 촉진 안내 모두 회계연도 기준이다. 주의사항 해야 되는 것 구조 문제임을 질문으로 이끌기: 회사 지급 방식과 촉진 제도로 사용한 연차인데, 정산 기준만 바뀐 걸로 근로자
이전 글(링크 클릭)에서 기본 기능인 CRUD를 봤다. 포스트맨 예제에 스크립트가 들어있는데 그걸 살펴보는 글이다. Script 요청을 보내기 전과 응답을 받은 후에 쓸 수 있다. 스크립트로 할 수 있는건 요청 제어하기 응답 상태 확인하기 응답 기반 테스트하기 (assertion) 응답 내용 추출하기 응답 내용 변수에 담아 사용하기 문법은 자바스크립트(이하 js)를 쓴다. Pre-request 예: 날짜를 계산해서 쿼리 스트링에 넣어서 요청을 보낼 때 Post-response 예: 응답을 받아 응답 안의 특정 내용만 골라 보고 싶을 때 실습 예제 포스트맨에서 제공하는 샘플 예제로 보겠다. New > Collection > view all template > API testing basics 선택 2개의 폴더가 생성된다. Basic test syntax API tests Scripts > Post-response로 들어간다. pm.test(); // 기본 문법 pm.test("테스트
기대한 건 연차수당, 돌아온 건 마이너스 통보 연차 수당 vs 연차 소진을 고민했고 수당을 생각했다. 그랬는데.. 인사팀에서 마이너스 연차라고 한다. 올해 3개의 휴가를 사용했다. 당겨서 쓴 연차도 없다. 어떻게 된 일인가? 3개밖에 안 썼는데 초과 사용? 퇴사할 때는 입사일을 기준으로 한다고 한다. 발생 연차 내역에 대해 자세히 알려주지는 않았다. 사용 개수에 대해서 맞는지를 물었고, 마이너스라고 한다.. 올해 3개 썼는데 왜때문에 이게 가능한가? 엇갈린 연차 기준 회계 연도(여긴 1월)를 기준으로 하는 건 연차 발생 연차 사용 연차 촉진 3가지 모두 회계연도 기준이다. 회계 연도는 회사별로 다르다. 연차 미사용 수당? 그런 거 없다. ^^ 정리해 보면 기준이 다르다. 회계일 기준: 발생, 사용, 촉진 입사일 기준: 퇴직 정산 이게 맞는가? 연차 촉진하고 초과 사용? 월말에 퇴사로 날짜는 정해졌다. 퇴사하는 당월에 월초에 연차 기준에 대해 알려줬다.. 연초에 15개씩 주고 (회계
개별적으로 하려고 했으나.. 일정 컨트롤 못할 거라.. 종합 인테리어로 갔다. 샤시, 주방, 화장실, 현관, 발코니, 붙박이, 문틀을 제외했다. 10년 이상 된 집은 올수리가 필요하다.. 이전 집주인은 분양받고 부분 수리하고 연속으로 거주했다. 제일 먼저 눈에 들어온 건 강마루 바닥은 긁힌 게 많았고, 빛바랜 부분이 눈에 띄었다. 벽지 상태는 예상했다.. 오래가지 않을 거 같았다. 소모품 같은 거는 한눈에 봐도 낡았고, 싱크대 상판의 코팅은 이미 없다. 수리를 어느 정도 예상을 했는데, 막상 현장 점검을 해보니.. 다 하는 게 톤도 맞았다. 인테리어 비용 한도 초과다.. 이미 수입에 비해 과분한(?) 집을 사는데 돈을 써서 더 이상 돈을 쓸 수 없었다. 포기할 거는 위에 적은 대로다. 꼭 해야 하는 옵션이 있다. 시스템에어컨 종합 인테리어가 아닌 도배 따로 시스템에어컨 따로 하면 도배 전에 해야 한다. 도배 전에 구멍을 내고 에어컨 설치하고 도배 완료 후에 에어컨 뚜껑을 덮어야 깔끔
인수자가 동일 직무인 QA가 아니다. 직무 자체가 사라지는거라 다음 사람을 위해 일단 작성해둔다. 업무를 구조화해보면서 본인 커리어 정리에도 큰 도움이 된다. 이전에 직무 기술서? 정의서? 같은걸 작성했었다. 구성과 내용이 괜찮았던 기억이 있어 여기저기 참고해서 재구성해본다. 이전 포스팅에서 업무 범위(링크 클릭)에 대해 작성했었다. 그 글보다 더 상세한 버전이라 생각하면 된다. 들어가는 항목 대분류: 업무 분류, 범주이다. 제목: 간단하게 상세 내용을 압축해서 업무를 한 줄로 요약한다. 상세내용: 쉽고 자세하게 실제 업무 내용, 주의점을 포함하여 서술한다. 협업대상: 관련되는 부서나 직무이다. 발생시기: 언제 발생하는지에 대해 서술한다. 월급과 같이 매월 정기적으로 발생할 수 있고, 다른 팀에서 완성되면 발생할 수도 있다. 빈도수: 업무 전체를 100이라 보고 차지하는 비율이다. 사용툴: 업무를 하면서 사용하는 툴이다. 필요역량: 해당 업무를 하는 데 요구되는 지식, 기술, 능력이
SQA 공백기를 대비하는 글이다. 장기화될 수 있는 공백기를 대비하고자 자기계발 몇 가지를 정리한다. 선정하는 기준은 모집 공고 분석, QA 정보 사이트 분석해서 실무에 도움이 될만한 것들을 추렸다. 백수가 될 예정으로 5월 황금연휴는 나와 상관없는 이야기이다. 경제가 어렵다 하는데 취업을 언제 할 수 있을지 모르겠다. 구인구직 사이트 경쟁률 봐도 지원자가 수백 명이다. 회사에 선임자가 없다면 방향을 잡기 어렵다. 미리미리 공고를 분석해서 커리어 방향을 설계해봐야겠다. 자격증 시험을 통해 자격 여부가 나와서 강의를 수강한 것보다 증명이 된다. 자격증은 있으면 좋은, 부가적인 거다. 자격증이 실력을 완전히 증명하진 못하겠다만, 최소한 준비(=노력)했다는 흔적은 보여줄 수 있다. 테스팅: ISTQB, CSTS, ... 네트워크: CCNA, ... SQL 및 DB: SQLD, OCA, ... OS: 리눅스마스터, ... OA: 컴퓨터활용능력, MOS, ITQ, ... IT 전반: 정보처리
경영악화로 권고사직되어 퇴사하는 글은 이전 포스팅(링크 클릭)에서 썼다. 사직서 승인 후 한 달 동안 회사에 있으면서 해야 할 일과 퇴사할 때 필요한 것들을 정리했다. 인사팀 요청 서류 사직서: 사본이라도 보관한다. 증빙할 일이 있을 수도 있다. 원천징수영수증: 퇴사 연도 발급한다. 나중에 연말 정산할 때 필요하다. 이직 확인서: 실업급여 대상자라 노동부에 제출해야 한다. 퇴직금 정산내역: 실제 내역이 맞는지 확인한다. 경력증명서: 요즘은 4대보험 가입으로 이 회사에 다녔었다는 사실만 알 수 있다. 실제 업무는 알 수 없다. 퇴사 후 요청보다는 퇴사 전 발급 받아놓는 게 낫다. 급여 명세서: 현재 회사는 1일부터 말일까지의 임금을 다음 달에 준다. 급여 명세서는 회사 메일로 받는데 퇴사하면 회사 메일을 쓸 수 없다. 개인 메일로 요청해야 한다. 인사팀 확인 사항 돈 관련 지급 날짜: 퇴직금, 연차수당, 위로금 등 중요하다. 이건 사직서 작성했는데 따로 얘기가 없어서 물어본 거다. 퇴
한국이 해고가 어려운 나라라고 한다. 그렇다고 해서 정규직이 철밥통은 아니다. 이번 글은 사직서 작성까지의 경험을 시간 순서로 써봤다. 위험 전조증상도 있다. 돔황차 복지가 사라진다. 위험 신호다. 재택, 하이브리드는 많이 사라지는 추세라 그러려니 했다. 제일 타격이 큰 건 근로시간과 관련된 거다. 회사에서는 노무사를 통해 문제없음을 고지하고 서면동의를 얻었다. 연봉은 그대로 근로시간만 늘어난 것이다. 실질적으로 연봉, 월급, 일급, 시급이 감소가 되었다. 이게 가능하다.. 들어갈 때는 주 40시간 미만이었는데, 나갈 때는 주 40시간으로 바뀔 수 있다. 전사 메일을 받았다. 메일의 핵심 키워드를 살펴보면 연봉 동결, 인력 감축, 구조 조정, 조직 개편 등이 있다. 회사가 어렵다 어렵다 하더니 결국 올 게 온 거다. 구조 조정을 한 번 이상 해본 회사라 이상할 것도 없다. 시기가 언제일지, 앞으로 계획을 어떻게 해야 할지 생각해 본다. 정리해고 당사자만 모르고 있었다. 퇴근 시간이
CRUD를 메서드와 매칭하여 실습해본다. 개발의 가장 기본적인 기능 앞글자를 따서 CRUD 이다. CRUD 기능은 포스트맨에서 메소드와 매칭이 된다. - Create (생성하기) → POST - Read (읽기) → GET - Update (갱신하기) → PUT - Delete (삭제하기) → DELETE 이전 포스팅(링크 클릭)에서 구성 요소 별로 봤는데 이번 글에서는 포스트맨 메소드를 기준으로 본다. 실습 포스트맨에서 제공하는 기본 예제로 설명한다. 포스트맨에 가입하고 앱/웹 편한 환경에서 한다. 생성 과정 한 줄은 아래와 같고 다음에서 스샷과 함께 간단한 설명이 있다. Home에서 My Workspace 선택 > New 클릭 > Collection 선택 > REST API basics 선택 포스트맨을 처음 시작하면 아래와 같은 화면이 나타난다. Postman Home > Workspaces 회사에서는 팀으로 초대를 받거나, 로컬에서 할 거면 컬렉션 단위로 요청하면 될 것이다.
API 요청 시 값을 전달하는 방법은 여러 가지가 있다. 이전 포스팅 (링크 클릭)에서 쿼리 vs 바디 차이를 알아봤다. 이전 글에서 헤더는 성격이 다르다고 제외했었는데, 헤더에는 주로 메타 데이터가 담긴다. 쿼리 파라미터 (Query Parameter) 형식: GET /v0/api/main?language=ko-KR¤cy=KRW 위치: URL에 붙어서 전송된다. 특징: 요청 데이터를 담을 때 쓴다. (e.g. 검색 키워드, 필터 등) 캐싱에 유리하다. 요청 헤더 (Request Header) 형식: GET /v0/api/main 위치: Header에 포함하여 전송된다. GET /v0/api/main HTTP/1.1 Accept-Language: ko-KR X-Currency: KRW 특징: 메타 데이터, 부가 정보를 담을 때 쓴다. (e.g. 인증 토큰, 클라 환경 정보 등) 바디 파람과 마찬가지로 일반적으로 사용자한테 보여지지 않는다. 언어와 통화를 예로 들었는데, 어
Postman에서 API 요청 시 사용하는 구성 요소인 Params, Headers, Body에 대한 내용이다. 팀 단위로 포스트맨을 쓰면 팀에 초대받아 컬렉션 단위로 공유해서 쓰는게 효율적이다. 팀으로 안 써도 대부분 API doc에서 포스트맨 임포트 기능을 지원한다. 요청 만들기 Workspace에서 New > HTTP Request를 선택한다. 아래는 새 요청 생성 화면이다. 새 요청 생성: Postman Workspace에서 새 HTTP 요청 생성하는 화면 문서에 맞게 입력한다. 빨강: 요청 메서드 선택한다. (GET, POST 등) 초록: 요청할 URL 입력한다. 파랑: 식별할 수 있는 이름 지정한다. 아래는 요청 정보 입력 화면이다. 요청 정보 입력: 메서드 선택, URL 입력, 요청 이름 지정 화면 Params 요청 영역 > Params 탭에서 Key-Value 형태로 파라미터를 입력한다. 키, 값을 입력하면 URL에 자동으로 입력된다. 반대로 URL에 직접 입력해도 된
iOS에서 비밀번호 필드에 백스페이스를 입력했는데 전체 문자가 삭제되는 현상이 있다. 이슈처럼 보일 수 있는데 실제로는 애플의 보안 정책에 따른 기본 동작이다. 백스페이스 한번 입력으로 전체 삭제? 비밀번호 타입의 텍스트 필드에서 문자를 입력한 뒤 백스페이스를 입력했다. 문자가 1자씩 삭제되는게 아니라 입력된 문자열이 모두 삭제 되었다. 참고로 Android는 1자씩 삭제된다. 예상되는 사용자 불편: - 한글자만 지우고 싶었는데 전체가 사라짐 - 다시 처음부터 입력해야 하는 번거로움 이슈 아님: OS 정책 이슈를 발행했는데 결과적으로 개발적인 측면에서 보면 이슈가 아니었다. 개발자 확인 결과 애플 iOS의 내부 정책에 따라 동작하는 부분이었다. 우선순위를 따지면 앱보다 OS 정책이 먼저다. iOS에서는 비밀번호 필드(secureTextEntry = true)에 대해 보안 처리 방식이 별도로 적용된다. 보안 이유로 백스페이스를 입력하면 전체 삭제되는 동작이 기본값으로 적용된다. 불편하
GET과 POST는 모두 서버에게 데이터를 전달하지만, 사용하는 방식과 전달하는 위치가 다르다. API 요청에서 쿼리 파람, 바디 파람을 언제, 왜 나눠 쓰는지 차이를 알면 테스트 설계에 도움이 된다. 헤더 (Header)는 성격이 다르므로 이 글에서 제외한다. 쿼리 파라미터 (Query Parameter) 형식: GET /v0/api/user?username=tami&status=active 위치: URL에 붙어서 전송된다. 전송 방식: 주로 GET, DELETE 요청에 사용한다. 특징: 간단한 조회, 삭제 등에 사용한다. URL에 붙어 다 보인다. 요청 정보에 개인정보를 포함하지 않는 환경에서 사용한다. 크기 제한이 있다. 브라우저, 서버, 프록시에 따라 다른데 적은 쪽에 맞추는 게 좋다. 보수적으로 2KB(약 2048자)를 넘지 않는 게 좋다. URL 구조는 이전 포스팅 (링크 클릭)에서 알아봤다. 바디 파라미터 (Body Parameter) 아래 예제는 JSON 형식이다. 실
QA 팀 회고, 효과가 있는가? 2주 단위 KPT 회고를 몇 차례 경험하면서 형식적인 회고의 한계에 부딪혔다. KPT란? Keep: 유지할 점, 잘한 점 Problem: 문제점, 개선점, 아쉬운 점 Try: 다음에 시도해 볼 액션 아이템 구성원이 템플릿에 맞춰 3개 항목을 작성하고 한 명씩 발표한다. 마지막으로 투표 등을 통해서 다음 스프린트에 적용할 액션 아이템을 정한다. 취지는 점진적으로 업무를 개선해나는 것이다. 앞 글자를 따서 KPT다. 경험했던 회고 방식 KPT 기반 회고를 해봤다. 스프린트는 2주의 애자일 프로세스(실은 작은 폭포수)에서 배포가 마무리되면 했다. 회고하는 인원 구성은 프로젝트를 진행한 QA로 원청, 하청 모두 참여자로 구성됐다. 갑을 관계가 있는 인원 구성의 회고는 그다지 효과적이지 않다고 생각했다. 원청, 하청의 갑, 을 관계도 있다 보니, 하청 소속은 문제점은 거의 말하지 않는다.. 조심스럽다. 특히 원청의 문제점인 것은 입을 다문다.. 눈치 챙겨 회고
면접관 구성: 팀장 1, 팀원 1 질문 구성: 경험 10 시간: 약 50분 면접 질문 많이 기억나지 않는다.. 기억나는 건 탈락임에도 팀장은 귀찮아하는 티를 내지 않았다는 거. 합격/탈락 여부는 보통 면접 중에 결정된다. 합불을 전달하는 인사 쪽에서 얼마나 빠를지는 회사 사정이다. 면접 끝나면 탈락해서 안 볼 사람인데 회사에 대해 궁금한 점이 있으면 업무 외적인 것, 사소한 것도 지금 다 물어보라고 했다. 그리고 진짜 물어봤다.. 내 질문만 20분 된듯하다.. 아.. 이게 아닌가.. QA 면접 질문 프로젝트와 기술, 성과 소개 가장 잘 한 프로젝트/남들과 차별점 티시 작성 노하우 이건 잘 찾았다 하는 이슈 매뉴얼/자동화 테스트 비율 타부서와 소통 방법 의견이 다른 경우 QA 가치관, 중요하게 생각하는 거
화면 잠금, 백그라운드 등에 따라 타이머가 0초에서 멈추지 않고 계속 흘러가는 오류가 나올 수 있다. 사례를 보면서 이야기해보겠다. 타이머 구현 구조 타이머의 카운트 동작은 API 응답에서 만료시간을 주고, 그 만료 시간을 기준으로 FE에서 타이머를 구현하여 1초식 감소하게된다. 타이머 흐름은 FE에서 독립적으로 동작하는거다. 좀 더 아는척(?)해서 이런걸 비동기 갱신이라고 한다. 또 다른 구현 방식: API 활용 API를 1초마다 받아오고 그 내용을 렌더링한다면 시간이 매끄럽게 흘러가지 않을 가능성이 높다. API를 호출하고 받는 시간, 렌더링하는 시간을 고려하면 좋은 선택이 아니다. 데이터 낭비는 덤이다. API를 1초마다 요청해서 응답 받은 값을 렌더링하는 방식도 있을 수 있다. 하지만 이건 여러모로 비효율적이다. API를 호출하고 응답받는 데 걸리는 시간 렌더링에 걸리는 시간 네트워크 상태에 따른 지연 서버/클라이언트 리소스 낭비 결과적으로, 자연스러운 카운트 흐름이 깨지고,
같은 프로젝트라면 파트를 나누어 할 수도 있을텐데, 완전히 동일한 업무를 해봤다. 같이 하는 업무 파견을 갔을때의 경험이다. 테스트 방식이 특이했다. 동일한 케이스를 OS 버전 별로 나눠서 각각 테스트했다. 안드로이드의 경우 해상도가 다양하고 iOS에 비해 커스텀롬이 많다. 특정 단말 이슈가 상대적으로 있는 편이었다. 대부분이 기능적인것보다 디바이스에 따른 UI적인 이슈였다. 이를 커버할 목적으로 OS별 인원을 투입한것이다. 같이의 장점 사람이 수동으로 테스트를 하기에 다양한 엣지케이스를 찾아 테스트 커버리지를 높일 수 있다. 같이의 단점 하는 사람만 한다. 책임감 없고 묻어가려는 사람이 있다. ^^ OS버전별로 케이스를 수행하면 선발 주자가 이슈를 다 찾고, 후발 주자는 뒤늦게 확인하는 모양이 된다. 이모습은 마치 선발 주자는 정답지를 기록하고, 후발 주자는 정답지를 보면서 테스트 결과를 적는 것과 같다. 케이스의 시작을 모두가 1부터 시작하면 이렇게 된다. 이걸 방지하고자 한다면
개발자에게 '수정 이슈 언제 확인해 줘요?' 같은 말 듣지 말고, 네이버 메인 띄워 놓지 말고, 일하는 척이라도 했으면 좋겠다.. 지라는 BTS 툴로 주로 개발자와 QA 간에 이슈 핑퐁이 되는 게 주된 쓰임새이다. 그 외에도 업무에 유용한 기능도 제공하는데 지라에 익숙하지 않은 사람은 못 쓰는 거 같아서 써본다.. 아래 사진은 내가 쓰는 대시보드로 지라에 등록된 이슈를 모아 한눈에 파악하기 좋게 구성했다. 내 지라 대시보드 왼쪽: 내가 등록한 이슈 오른쪽: 다른 사람이 등록한 이슈 이슈는 상태 값, 유형, 나와의 관계에 따라 필터링해서 보여준다. 대시보드 설정하기 전에 저장된 필터가 있어야 한다. 필터 예시(JQL) project in (PIKAPIKA) AND issuetype in (Bug, Improvement) AND status in (Fixed) AND reporter in (currentUser()) ORDER BY updated DESC 필터 조건은 각자 환경에 맞춰서
결론부터 말하면 버그 등록 건수나 TC 갯수를 KPI로 삼는 건 반대한다. 자주 등장하는 항목이지만, 이게 성과를 말해준다고 생각하지 않는다. QA의 정량적인 성과는 다른 방식으로 측정해야 한다고 본다. 자주 등장하는 QA KPI 양대 산맥 많이 입에 오르고 사용하는 수치화 데이터 2가지가 있다. 버그 등록 건수 TC 생성/수행 건수 왜 이렇게 되는지를 보겠다. 버그 등록 건수 = 업무 성과? 버그를 발견 못 했다. = 일 안 한다. 버그를 발견 했다. = 일 한다. QA가 버그 잡는 사람(?)이라고 알려지면서 이런 인식이 생긴게 아닌가 싶다. 버그는 개발의 완성도에 따라 크게 영향이 있다. 완성도가 높을 수록 버그가 없다. 그런데도 QA가 버그를 못 찾았으니 일을 안 하는거라고 봐야하는가? 이건 QA가 아닌 개발 완성도에 대한 항목으로 적합해보인다. TC 생성/수행 건수 = 꼼꼼 지표? 케이스가 많다. = 꼼꼼하다. 케이스가 적다. = 대충한다. 보통 TC를 설계해서 테스트를 수행
1. 공백 문자와 데이터 처리 공백 문자가 들어가면 전혀 다른 결과를 가져오기도 한다. 컴퓨터에게 융통성이란 없고, 칼같이 정확하다. 그저 입력받은 값을 그대로 전달하여 받은 결과를 보여준다. 융통성을 보여줬으면 하는 것은 사람이 해결해 줘야 한다. 예를 들어보겠다. - "test"와 " test "는 서로 다른 문자열이다. - "피카츄"와“피카 츄”는 서로 일치하는 게 아니다. 컴퓨터는 다른 것으로 인식한다. 이걸 확인하고 싶으면 코딩하지 않아도 스프레드시트에서 쉽게 확인 가능하다. 각 셀에 “pikachu”, "pika chu"를 입력한다. 수식을 이용하여 일치하는지를 확인한다. A1, A2 셀에 값이 있다고 가정한다. A B C 1 pikachu 2 pika chu =A1=A2 =EQ(A1,A2) 결과는 FALSE 값을 반환한다. 이러한 차이가 오류를 발생시키거나, 검색 결과나 데이터 일관성에 영향을 줄 수 있다. 2. 공백 처리 방식 결정하기 이를 해결하기 위해 2개의 방법이
수정 비용 절감을 위한 사전 검토 TC 리뷰가 필요하다고 느낀 적이 있다. TC 기반의 스크립티드 테스트를 진행하는데 수행 실패가 발생한다. 플랫폼별로 테스트를 하다보면 양쪽 모두 실패가 발생하는 경우가 있다. 수행 실패가 발생하는 공통점을 찾았다. 기획에 정의되지 않은 부분이었다. TC란? TC는 요구사항을 포함하여 테스트 해야할 항목을 목록으로 정리한 항목 +α다. TCestCase(TC)는 CheckList(CL)와 다르게 누가 수행하더라도 동일한 결과가 나와야 한다. 수행자와 상관없이 동일한 결과가 나오려면, 객관적이고 자세하게 작성되는 게 중요하다. TC 리뷰가 필요한 이유 정의되지 않은 부분에서 각 플랫폼의 구현이 다르게 나왔다. 테스트 기간에 기획자는 기능을 정의하고, 개발자는 기능을 수정하는 상황이 반복됐다. 리소스가 낭비된다.. 어차피 조정이 필요한 부분이라면, 결함비용을 생각하면 테스트 전에 해결하는 게 더 낫다. 인스펙션 리뷰도 방법이지만, 일정상 TC 리뷰가 더
면접관 구성: CTO 1 질문 구성: 경험 10 시간: 약 50분 면접 전에 인적성검사한다. 토론하는 느낌이다. C레벨에서 어떤 고민이 있는지를 알 수 있다. QA 면접 질문 1차 면접 소감 이직 사유 산업 바꾸는 계기 목표 직무 정의 업무 평가 근거 현재 QA 조직은 규모 하나의 프로젝트에 2명/1명 투입 장단점 의견 전달 개선이 안될 때 어떻게 하는지 TC를 작성 노하우 베스트 TC와 워스트 TC의 차이 TC 관리 일정 산정 기준 요구했던 일정보다 일정이 반 넘게 줄어든다면 QA 업무가 품질관리보다는 테스터로 알고 있는 인식에 대한 생각 다른 직무에서 업무 침범한다 느낀다면 기획에서 정의되지 않을 걸 QA에서 발견하여 전달했는데 업무 침범이라는 등의 사례 의견 충돌 QA와 테스터 타팀에서 테스트만 해달라는 요청 중장기 목표 입사 가능일 총 경력 희망연봉 현재연봉
방문 코디(?) 이런 게 있어..?! 친구에게 질문을 받았다. 매수자로 부동산 방문할 때 차려입어야(?) 돈 많아 보이는 게 나은지, 돈 적어 보이는 게 나은지. 돈 많아 보이는 룩 경험은 없고, 굳이 따지면 돈 적어 보이는 룩에 가깝다.. 나의 답변은.. 콬 집어 말하자면 깔끔한 세미 정장 느낌이면 무난하다고 했다. 제일 중요한건 서로 시간 낭비 없이 조건을 명확하게 전달하면 된다고 했다. 실제로 부동산 방문하면서 받아본 차별이 있다.. 둘 다 임대차 계약을 위한 임차인 신분으로 방문했다. 옷은 거의 비슷한 톤으로 입는다. 부정적인 차별 세입자 살고 있다. 세입자가 월세 미납하여 나가는 거라 했다. 집주인 희망 날짜 정해져 있다. 보름 정도 남았다. 살고 있는 세입자가 나가면 공실 없이 바로 다음 세입자가 들어오기를 원한다. 집주인의 조건을 들어주면 뭐해줄 거냐고 물어봤다. 그러자 돌아오는 답변은.. "세입자는 그런 조건을 낼 수 없다." ??? 당황스럽다.. 중개사가 너무 집주인
이 글을 본 당신은 자격 요건 충족. 모집공고의 자격요건 분석 모집공고의 자격요건을 보면 아래와 같은 요구사항을 볼 수 있다: 웹 서비스 구조에 대한 이해 Web, App, API 특성 및 동작 원리 API에 대한 이해 등등.. 이 정도는 알고 테스트를 했으면 한다. 용어 정리 및 간단한 정의 쉽게 이해하기 위해 아래와 같이 정의하겠다. Web, App (Android, iOS) → 클라이언트 API → 서버 (서버의 결과물을 일부 전달받는 역할) 1. 서버와 클라이언트의 기본 개념 서버: 데이터를 저장하고 처리한다. 클라이언트에게 필요한 자원을 제공한다. 대부분 최종 사용자에게 직접 보이지 않는다. 클라이언트: 서버에 요청을 보내고 응답받은 데이터를 화면에 출력한다. 최종 사용자가 직접 본다. 2. 클라이언트-서버 관계와 데이터 흐름 클라이언트와 서버는 요청(Request)과 응답(Response)을 주고받는다. 둘이 서로 주고 받는 사이다. 데이터가 사용자에게 보이기까지의 과정
EBS 다큐프라임 『자본주의』 후기 EBS 자본주의 제작팀 다큐가 먼저인데 다큐는 보지 않았고 책만 봤다. 금융문맹도 쉽게 읽을 수 있고, 돈이 생기는 과정을 알 수 있다. 지금 살아가는 시대에서 살아남으려면 어떻게 해야할지 생각해본다. 후기 - 경제 기사 알아듣지 못 하는데 용어부터 낯설다.. 틀니 세대, 흙은 가르쳐주는 사람이 없다. 요즘 정보 많다. 잘 골라봐야한다. - 빚은 나쁜게 아니다. 잘 쓰면.. - 절대로 물가가 내려갈 수 없듯이 월급도 내려갈 수 없다. 동결은 있겠지만.. 내려가면 나가라는거.. - 물가와 M2통화량의 관계는 그래프를 보면 거의 일치한다. - 흔싸귀비. 화폐가치 하락은 돈이 흔해져서 돈이 싸진다. 돈을 더 많이 지불해야한다. - 뉴스에서 뭐 자꾸 최대치 어쩌고 하는데 어찌보면 당연한 얘기다. - 이제부터 돈 하면 떠오르는 이미지는 숫자다. - 지페, 동전 같은것도 돈이 맞다. 돈의 극히 일부다. - 지급준비율은 돈의 가치와 관계가 있다. - 돈으로 돈
QA는 개발 직무의 최하단? 회바회. 개발 소속일 수도 있고 기획 소속일 수도 있다. 많은 사람들이 자신의 전공, 업무에 대해서 추천하지 않는다. 누군가가 “ㅇㅇ 어때요?”라고 묻는다면 대부분 다른 진로를 권한다. 본인이 해봤지만 정말 이보다 지옥은 없을 수도 있고, 적성에 안 맞을 수도 있으며, 해보지 않은 다른 직무에 대한 환상이 있을 수도 있다. "QA 어때요? (시작하려고 하는데) 괜찮나요?"라고 물으면 체감상 80%는 개발자를 하라고 한다. 왜? 그리고 왜 개발자? QA 뭐 하는 직무인가? QA (Quality Assurance) 품질보증 대부분 QA = Test라는 인식이 강하다. 외주 업체가 많다. 외주 업체에서의 한계를 느껴 자사로 이직하려는 사람들도 많다. 본인이 하는 일이 무엇인지 모른 채 테스트만 하는 사람들도 있다. 테스트는 QA 업무의 일부일 뿐이다. QA의 역할 중 하나는 개발 프로세스를 검증하는 것인데, 이를 위해서는 개발 프로세스를 이해해야 한다. 개발
귀여운몬 위주다. 포켓몬 스티커 라인업 총17개 시크릿 피카츄 꼬부기 파이리 이상해씨 이브이 푸린 잠만보 뮤 팽도리 데덴네 세레비 치코리타 파치리스 지라치 니피아 알로라 식스테일
결론 남들보다 싸면 먼저 팔린다. 하락장? 조정장? 매수자 우위장? 이었다. 내 매물이 돋보이게 준비를 하였으나 그다지 효과를 보지 못했다.. 안내 책자 부동산에 방문하는 손님이 대기하는 동안 보라고 만들었다. 집 내부 사진을 도면과 함께 각도에 따라 첨부했다, 주변 인프라를 강조했다. 아이디어 좋은거 같은데 별 효과 없는 거 같아서 아쉽..=ㅅ= 프린트해서 다있소에 파는 클리어 파일에 넣으면 깔끔하게 완성이다. 실물은 부동산에 전달했다. 구글 드라이브 같은 곳에 공개용 프레젠테이션을 만든다. 그리고 요악본(?)과 함께 QR 코드 같은 거로 링크를 걸어 프린트한다. 방문하는 매수자 예정자에게 전달하면 된다.. 부록: 안내 책자 일부 매도 안내 책자 일부: 도면 매도 안내 책자 일부: 현관 사진(각도 포함)과 설명 매도 안내 책자 일부: 거실 통로 사진(각도 포함)과 설명 매도 안내 책자 일부: 거실 및 주방(각도 포함)과 설명 매도 안내 책자 일부: 거실 및 주방 사진(각도 포함)과
FIFO vs LIFO, 삭제 동작이 달라지는 이유 위아래로 아이템을 추가/삭제하는 동작이 있다. 추가를 하면 아래에 추가가 되지만, 삭제를 하면 동작이 나뉜다. 삭제 동작은 위에서부터 삭제할지, 아래에서부터 삭제할지 상황에 따라 달라질 수 있다. 이번 글에서는 추가/삭제 동작과 자료 구조 개념을 연결해 알아본다. 추가/삭제 동작의 기본 구조 추가 동작: 항상 아래쪽에 추가된다. 삭제 동작: 두 가지 방식으로 나뉜다. 위에 있는 것부터 삭제 아래에 있는 것부터 삭제 이 중 어느 방식이 적절한지는 사용 상황에 따라 다르다. 이런 기준은 자료 구조의 FIFO(선입선출)와 LIFO(후입선출) 개념과 연결된다. FIFO(선입선출) FIFO(First In, First Out) 방식은 가장 먼저 추가된 항목이 가장 먼저 처리된다. 예: 최근 본 상품 동작 방식: 최근 본 상품 10개를 저장한다. 11번째 상품을 추가하면, 가장 오래된 1번째 상품이 삭제된다. 2번째 상품이 1번째가 되고, 새
면접관 구성: cto 1, ceo 1 질문 구성: 경험 10 소요 시간: 약 50분 전에 인적성검사 QA 면접 질문 자기소개 경력소개 전향사유 지원동기 A회사 어떤 것들을 테스트 했나 성과 예를 들어 설명 단계를 추가하는 경우 코스트 대비 효과가 있었나 명확한 지표 A회사 이직 사유 자사와 외주 차이 외주 한정된 업무 범위를 어떻게 해결했나 B회사 이직 사유 여러 직군이 같은 팀인 경우 소통 문제와 해결 방법 원하는 피드백이 오는지 피드백이 없는 경우 어떻게 하는지 성격이나 성향으로 볼 때 직무가 맞는지 어떤 강점이 직무가 맞는지 기획 산출물에 대한 의견을 내는지 기획자가 누락에 대해 인정하는지 프로젝트의 마지막 입장 어떻게 대응하는지 사람 트러블 경험 재직 회사 가장 큰 성과 지금까지 경험이 QA업무하는데 도움이 되었나 다른 직무를 생각해본적 QA를 안 했다면 어떤 직무를 했을지 회사 공통의 직무 고충 그에 대한 대처 스트레스 해소법 스트레스에 민감한지 의사결정권자가 있어야하는지
면접관 구성: PM2, QA1 질문 구성: 경험 10 시간: 약 45분 QA팀이 아니고 어딘가에 속해서 있는 조직이다. QA 면접 질문 QA에 대해 어떤 철학을 가지고 업무하는지 기능 개선이나 의견 제시를 어떻게하는지 현직장 구성과 역할 QA 참여 시점 실시간 모니터링 경험 모니터링으로 프로세스 개선 경험 보안 테스트 경험 노션 툴 사용 여부 자동/수동 테스트 차이 자동화 테스트의 단점 ㅁㅁ 개선 사례 as-is to-be TC 리뷰 설명 지원회사 서비스 사용 여부 지원회사 서비스에서 까다롭다고(?) 느꼈던 부분 UX 경험 UX 개선 어떻게 설득할것인지 현직장 팀규모와 협업 방식 업무 공유 방식 이력서 핵심 역량 부분 설명 QA가 개발과 기획에 기여할 수 있는 부분 시프트레프트가 필요하다라고 생각해본 경험 단독으로 업무처리 못할 경우 어떻게 하는지 현직장에서 QA할때 잡는 포인트 외주와 자사 서비스의 차이점 주도적 업무 장점 자동화 스크립트 작성 포인트 커버리지가 높았던 시나리오 유
면접관구성: cto 2, 대표1 소요시간: 60분 질문 구성: 경험 9, 기술 1 SQA 면접 질문 어디서 발전을 했는가 강점이 뭔가 이력서 이전 공백 기간 각 회사 이직 사유 업무강도가 어떤거 같나 ux개선 사례 post put 차이 서드파티 로그인 구조 결제 할때 실명 현재 공부하고 있는것 신입과 현재 업무 기대방향 그레이에어리어에 대한 생각 3년도 안되었는데 이직하는 이유
자사와 파견, 둘 다 경험해봤다. 각자의 상황이 다르겠지만, 하나를 선택하라면 자사를 선택하겠다. 그 이유는..? 내가 경험한 파견 파견 근무에는 명확한 한계가 있다. 파견에서 주어지는 업무는? 핵심 업무는 원청(정직원)이 담당 단순 반복 작업은 파견 직원이 맡음 이런 이유로 파견에서 자사로 이직하려는 사람이 많다. 회사의 입장에서 보면 파견을 활용하는 것이 효율적이긴 하다. 단순 반복 업무 → 저렴한 노동력으로 해결 가능 원청 입장에서는 필요한 인력을 유연하게 운영할 수 있음 하지만, 파견에서 오래 근무하면 어떤 일이 벌어질까? 나이가 들고 연차가 쌓여도 전문성이 쌓이기 어려움 진입장벽이 낮은 대신 경력 개발 기회가 적음 핵심 업무를 맡지 못하다 보니, 성장 기회가 제한됨 나는 파견 실무자로 근무했기 때문에, 파견을 관리하는 쪽이나 본사에서 컨설팅하는 입장은 모르겠다. 하지만 실무 경험만으로도 파견의 한계를 직접 체감할 수 있었다. 내가 경험한 자사 그렇다면 자사는 무조건 좋을까?
숨은 스펙을 놓치면 생기는 허점 테스트할 때 변경된 부분만 집중하는 경우가 많다. 하지만 주변 스펙도 고려하지 않으면 예상치 못한 문제가 발생할 수 있다. 아래는 업무 중 실제로 발생한 문제를 재구성한 사례다. 1. 기존 스펙 vs. 변경된 스펙 기존 스펙 - 상품 구매 가능 시기: 오늘로부터 +2일 (모레) - 상품 환불 가능 시기: 사용일 -2일 변경된 스펙 - 상품 구매 가능 시기: 오늘로부터 +0일 (당일) - 상품 환불 가능 시기: 사용일 -1시간 요구사항에는 구매 및 환불 가능 시기의 변경 내용만 포함되어 있었다. 하지만 이 변경이 다른 스펙과 어떻게 연결되는지 생각해봐야 한다. 2. 숨겨진(?) 스펙 요구사항에는 없지만, 실제로 영향을 받는 연관된 스펙이 있다. 연관된 스펙 - 후기 작성 가능 시기: 사용일 오전 9시 - 쿠폰 발급 시기: 후기 작성 즉시 상품 구매와 연결되는 것은 후기 작성과 포인트 적립, 후기 작성과 연결되는 것은 쿠폰 발급이다. 이 관계를 고려하지
동일한 질문을 했을 때 답변이다. 유료 버전은 개떡같이 말해도 잘 알아듣는다! 무료 버전 네, 그만 알아보자. 다음. 유료 버전 돈의 효과? 내가 원하던 답이 나왔다. 결론 질문이 허접하면 유료를 쓰면 된다.
아래 내용은 내부 보안에 위배되지 않게 재구성한 예시임. [재현환경] 서버 : test [사전조건] 1. count: 12 [발생경로] /v0/result?size=10, page=1 [기대결과] lastPage: true [실제결과] lastPage: false [재현빈도] 항상 발생 (10/10) [비고] - 무한스크롤 방식 페이징 테스트에 관한 내용이다. 무한스크롤 방식으로 데이터를 처리할 때, 페이징은 중요한 역할을 한다. 이 글에서는 무한스크롤 방식에서 페이징 테스트와 테스트 과정에서 발견한 오류 사례를 공유한다. 페이징과 무한스크롤 방식 데이터를 조회할 때 한 번에 모든 데이터를 가져오지 않는다. 한 번에 많은 양의 데이터를 조회하면 부하가 발생할 수 있기 때문이다. - 쿼리에서의 페이징: 'limit' 함수를 사용해 조회할 컬럼 수를 제한한다. - 클라이언트에서의 페이징: 사용자에게 조금씩 데이터를 가져와 보여준다. 무한스크롤 방식의 동작 흐름 무한스크롤 방식에서 데이터
갈아타기 처음 해본 과정 기록 같은 날 이사, 매도, 매수가 이루어지기에 계획을 잘 세워야 한다. 매도가 확정되면 매수할 후보지에서 계약으로 이루어져야 한다. 매수 계약서 작성 후 보통 3개월 전후로 이사계획을 잡는다. 매수 계약까지 완료되면 이사 계획해야 한다. 수리, 인테리어가 필요하면 이것도 해야 한다. 1. 돈의 흐름 선매도 후매수 방식으로 진행할 경우, 자금 흐름이 다음과 같다. 수입 (굵은 빨강) 지출 (파란 밑줄) 갈아타기 자금 흐름 1. 매도 집 가계약금 수입 2. 매수 집 가계약금 지출 3. 매도 집 계약금 수입 4. 매수 집 계약금 지출 5. 매도 집 잔금 수입 6. 매도 집 주담대 상환 7. 매수 집 주담대 실행 & 잔금 납부 → ㄹㅇ스쳐지나감 7. 매수 집 잔금 납부 8. 각종 수수료 납부 (중개, 등기, 취득 등) 7번 두 개 맞음. 잘못 쓴 거 아님. 동시 진행이라 보면 됨. 2. 필요한 현금 계산 주요 항목별 지출 예상 금액 - 가계약
면접관 구성: fe 팀장 1, be 팀장 1, 연구소장 1 질문 구성: 경험 10 시간: 약 30분 면접 종료 후 수집 항목: 현재 연봉, 희망 연봉 어떻게 알게 되었고 어떤 역할을 기대하는지 리더형인지 팔로워형인지 프로세스 설명 QA하게된 계기 어떤 단계를 좋아하는지 같이 일하기 좋은/힘든 사람 대화가 안 통하는 사람 어떻게 할것인가 기억에 남는 이슈
난방 고장 나본 후기다. 3번째다..ㅋㅋ 1, 2 번째는 매수하고 얼마 되지 않아 고장 나서 뭔가 억울하다.? 3번째는 그러려니 하다. 2번째에서 교체하지 않은 부품이 문제였다. 분명 보일러를 틀지 않았는데 집에 들어오면 느껴지는 따스한 온기 그것은 내 돈이었다. 밸브가 파손되어 콸콸 다음달 관리비도 콸콸 눈으로 봐도 부러진 게 보인다. 물 흐르는 소리가 난다.
면접관구성: cto 소요시간: 60분 질문 구성: 경험 10 발표 과제 있음. 개인 노트북 지참해야함.. QA 면접 질문 팀에 바라는게 뭔가 매뉴얼테스트만 하는것을 자동화 도입하기위해 그 허들을 넘으려면 어떻게 해야하는가 어떤 기여를 할 수 있나 b2b, ㅇㅇ환경이 더 희소하지 않나 결제 쿠폰, 포인트 환불 테스트 결제 pg 결제 실패 테스트 정기적인 운영 환경 전수 테스트 프로세스 운영 CS 이슈 프로세스 매뉴얼테스트만하는걸 시프트레프트 하기 위해 어떻게 해야할거같나 교과서적인 답변을 한다 api테스트 어떻게 인상깊은 과제 다시 돌아간다면 어느 부분을 개선할 것인가 면접자 질문에 대한 면접관 답변 일부 개발자랑 친분이 쌓이는걸 원하지 않음. 개발적인걸 많이 아는것 또한 원하지 않는듯함. - 이유: 동작원리를 회피. 사용자 입장에서 생각을 하지 않음. 반복적인건 자동화. 나머지는 사람이.
'responseBody' is deprecated. (6385) var responseBody: any @deprecated — Use pm.response.text() instead @excludeFromPrerequestScript No quick fixes available 변수가 var 이면 해당 오류가 나온다. (여담이지만 var 보다는 const 권장한다..) Postman을 업데이트했더니 'responseBody'가 취소선과 함께 지원 종료(deprecated) 안내가 떴다. Postman에서는 'pm.response.text()'를 쓰라고 권장했지만, 적용해 보니 안 된다. typeof로 확인해 보니 string이다..-_- 이름부터가 싸했다. 기존 코드와 실패 사례 기존 코드 JSON.parse(responseBody); 변경 실패 코드 pm.response.text(); // typeof → string 'pm.response.text()'는 문자열로 반환한다.
누수 피해 후기 3번의 경험 누수 피해 경험 세 번 모두 피해를 봤다. - 첫 번째: 집에 누수 흔적이 있었다고 들음. - 두 번째: 이전에도 누수가 발생해 수리한 적이 있음. - 세 번째: 인테리어 작업 중 누수 문제가 발생한 것으로 보임. 누수 흔적의 중요성 이전에 누수가 발생한 곳은 다시 문제가 생길 확률이 높다. 따라서 누수 흔적이 있는 집은 피하는 것이 안전하다. 2번의 빅 데이타 경험이다 ^^; 누수 흔적을 발견하는 방법: - 벽지가 젖어 있거나 곰팡이가 핀 흔적 - 부분 도배가 되어 있는 경우 (곰팡이를 덮었을 가능성도 있음) - 벽 이음새가 벌어져 있음 (단순 마감 불량이 더 많은 듯) 누수 수리와 시간적 손실 - 수리 비용은 내 돈이 아니지만, 내 시간은 손실된다. - 세입자로 거주할 경우, 누수로 인한 벽지 교체는 집주인의 의지에 따라 결정된다. - 두 번의 사례 모두 건물 전체가 집주인 소유였기 때문에 집주인 마음이다. 누수로 인한 도배 문제 - 누수로 벽지를 교
구축 아파트 특올수리 후기 특올수리란? '특'은 샤시(창호)를 교체하는 것을 의미하고, '올수리'는 방 전체를 수리하는 것을 말한다. 이번 후기는 디자인적인 인테리어보다는 실질적인 수리에 가까운 경험을 다루었다. 1. 준비 단계 첫 수리, 막막했던 시작 처음 시도해보니 아는 게 없었다. 부정적인 후기도 많았고, 종합 인테리어가 아닌 개별 인테리어가 더 저렴하다는 것은 알았다. 하지만 아래 조건을 충족하지 못한다면 종합 인테리어를 고려하는 것이 좋다. - 업체별 일정 컨트롤이 가능할 것 - 작업 지시를 구체적으로 할 수 있을 것 - 시공 기간 동안 관리 및 감독할 여유가 있을 것 주의할 점 - 보양 작업은 별도로 진행해야 한다. - 공사 동의서 대행료는 약 30만 원 정도며, 대행을 맡기지 않으면 직접 해결해야 한다. (참고: 일용직 알바비는 일급 15~20만 원 수준이다.) 2. 계약 및 공사 과정 계약 과정 1. 견적 의뢰 2. 견적 비교 3. 업체 선정 및 계약서 작성 공사 기간
Chat-GPT 치트 시트 By Shane Fozard 프롬프트의 기본 구조: [역할]로서 [작업]을 [형식]으로 수행 역할로서 행동하기 - 마케터 - 광고 전문가 - 마인드셋 코치 - 베스트셀러 작가 - 상담사 - 웹사이트 디자이너 - 저널리스트 - 발명가 - 최고재무책임자(CFO) - 카피라이터 - 프롬프트 엔지니어 - 회계사 - 변호사 - 분석가 - 고스트라이터 - 프로젝트 매니저 작업 만들기 - 헤드라인 - 기사 - 에세이 - 책 개요 - 이메일 시퀀스 - 소셜 미디어 포스트 - 제품 설명 - 자기소개서 - 블로그 글쓰기 - SEO 키워드 - 요약 - 비디오 스크립트 - 레시피 - 판매 카피 - 분석 - 광고 카피 형식으로 표시하기 - 표 - 목록 - 요약 - HTML - 코드 - 스프레드시트 - 그래프 - CSV 파일 - 일반 텍스트 파일 - JSON - 리치 텍스트 - PDF - XML - 마크다운 - 간트 차트 - 워드 클라우드 Linked Prompting (연계 프롬
테스트를 설계할 때 기준이 되는 테스트 베이시스가 있다. 이 테스트 베이시스는 주로 명세서(기획 명세, 개발 명세 등)를 의미한다. QA는 이 산출물을 기반으로 테스트 케이스를 설계한다. 명세서만으로는 부족하다 입문자들이 흔히 저지르는 실수가 있다. 명세서의 내용만으로 테스트를 설계하고 테스트하는 것이다. 명세서에 명시된 내용만으로 테스트하는 수준이라면 살아남기 어렵다. 회사의 요구치가 그 정도라면 성장하기도 어렵다. QA의 역할은 단순히 명세서를 검증하는 데 그치지 않는다. 명세에 포함된 내용은 당연히 모두 테스트해야 하고, 그 외에도 기획 의도를 파악하여 추가적인 시나리오를 설계해야 한다. 기획 의도가 없는 테스트? 기획 명세에 없으면 테스트를 안 해도 된다..? ㅎㅎ 뭘 굳이 그렇게 산출물에 있지도 않은 내용으로 테스트를 하나..? 요즘 애들 말로 초월 테스트..? 투머치..? 하지만 QA의 역할은 이런 생각에서 벗어나는 데서 시작된다. 예외 상황이나 사용자 관점에서 발생할 수