일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 |
- 2941
- The Balance of the World
- 시스템 프로그래밍
- 균형잡힌 세상
- 5622
- 시프
- system programming
- 해바
- Parenthesis
- file IO
- 바샤
- c++
- 브런치
- Baekjoon
- process control
- 10773
- 입력 버퍼
- Zero That Out
- 백준
- LJESNJAK
- IT
- Process Communication
- For Beginners
- 1874
- 4949
- QA
- 전자책
- BAKA
- File 조작
- c
- Today
- Total
목록QA (6)
해바
앞서 다음과 같은 순서로 QA 프로세스가 진행된다고 얘기했었다. QA Plan > Entry Criteria > QA Start > Test Execute > Exit Criteria > QA Sign off * Test Execute: Testing > Bug Report > Issue Tracking 이 중 앞서 다루지 않았던 Test Execute(테스트 수행)에 대해 조금 더 구체적으로 다뤄보려 한다. 개괄적인 시각에서 테스트는 테스트를 하고, 버그(결함)를 찾아, 유관 부서에 이슈를 공유하고 수정 여부를 확인하는 과정을 반복하는 활동으로 볼 수 있다. 이때 테스팅에는 여러 가지 방법들을 적용할 수 있는데, F/E QA 프로젝트에 TE로 참여했을 때 여러 회사들에게서 대체로 Sanity Test ..
자격증은 필수일까? 이전에 소프트 스킬을 다뤘다면, 이번에는 하드 스킬에 대해 이야기해보고자 한다. 하드 스킬은 소프트 스킬과 달리 능력의 정도를 가시화하기가 쉽다. 그중 자격증은 능력을 가시화하기 좋은 대표적인 예이다. 몇 가지 QA 자격증이 있지만 이번 주제에서는 ISTQB-CTFL을 기준으로 다뤄보겠다. QA에 입문했다면 아마 ISTQB라는 자격증을 들어봤을 것이다. 회사에서 권유하거나 지원해주기도 하고, 채용 공고에서 우대 사항에 심심찮게 등장하며, 간혹 필수로 요구하는 곳도 있기에 관심이 없더라도 한 번쯤 알아보게 되는 자격증이다. ISTQB의 경우 예전에는 영어로만 시험을 볼 수 있었지만 비교적 최근에는 한국어로도 응시가 가능하여, ‘그럼 한번 볼까?’ 하고 홈페이지에 들어갔다가 금액을 보고 ..
QA의 관점이란 어느 조직이든 주니어일 때는 주어진 일을 잘 수행하기만 하면 되는 업무를 맡는다. 그리고 시니어로 갈수록 프로젝트 단위, 팀 단위, 조직 단위의 관리를 요구받는다. 즉, 전자는 나무를 볼 줄 알아야 하고, 후자는 숲을 볼 줄 알아야 하는 것이다. QA도 마찬가지다. 다른 점이 있다면, QA는 특히 다른 조직보다도 숲을 보는 능력을 단기간에 요구받는다. 이제 막 QA에 뛰어들어 TE 롤을 수행할 때에는 나무 분석을 잘하기만 하면 된다. 결함인지 아닌지를 판단하고, 그밖의 결함이 더 있는지 방법을 바꿔보며 다시 해보는 집요함이 중요하다. 그런데 이 정도의 업무를 수행하는 데에는 경험의 차이가 있을 뿐, 특별한 지식이나 자격이 필요하지 않다. 다시 말해 내가 아니어도 쉽게 다른 누군가로 대체할..
프로세스가 무엇인가? 앞서 QA가 하는 일에 대해 설명하면서 프로세스라는 것을 자주 언급했다. 그럼 QA의 프로세스는 무엇일까? 그리고, 도대체 프로세스가 뭘까? 프로세스는 컴퓨터에서 연속적으로 실행되고 있는 컴퓨터 프로그램이라는, 컴퓨터 용어로써의 사전적 의미를 갖고 있다. 하지만 재미있게도 QA는 IT 직무임에도 프로세스라는 용어를 컴퓨터 용어가 아닌 비즈니스 용어로써 사용한다. 즉, QA 프로세스란 QA Workflow(업무 흐름)와 같다고 이해해도 무방하다. 용어의 정의가 어찌 됐든 프로세스의 뜻에는 눈에 보이는 대상 또는 그에 준하는 명확한 대상에 대해 설명하는 것이 아니라는 공통점이 있다. 이 말은, 프로세스에는 기준도 없고, 정답도 없다는 것을 의미한다. 단지 효율적인 프로세스가 최선의 프로..
QA란 무엇인가? 제삼자가 QA는 무슨 일을 하냐고 질문했다면, 당신은 뭐라고 답할 것인가? 혹시 테스트하는 사람, ‘테스터’를 먼저 떠올렸는가? QA 종사자에게 QA가 테스트를 하는 일이냐고 물어본다면 그 이상의 것을 한다는 걸 설명하기 위해 입이 근질근질할 것이다. 하지만 IT산업 종사자에게 물어본다면 아마 대체로 그렇다고 할 것이고, QA를 잘 모르는 사람들이라면 그렇지 않냐고 오히려 반문할 것이다. 물론 인지도의 차이도 있지만, QA가 흔히 테스터로 설명되는 이유는 3가지라고 생각한다. 첫째, 직무 이름 자체가 직관적이지 않기 때문이다. ‘개발자’는 무언가를 만들 것이며, ‘기획자’는 대충 계획 같은 것을 하겠구나라고 연상이 되지만 QA는 전혀 그렇지 않다. Q&A냐고 묻지나 않으면 다행일 것이다..
현재 기준 3년이 채 되지 않는 경력이지만, 과거의 저와 비슷한 고민을 하는 분이 있다면 도움이 되기를 바라는 마음으로 글을 써보려 합니다(필자의 직무이해도 향상과 귀여운 수익성 기대는 덤). [For Beginners] 1. QA에 관심있거나, 잘 몰랐던 사람들을 대상으로 2. 주 1회 1주제로 총 8개의 글을 써볼 예정 3. 주제는 제안을 받거나, 아이디어가 떠오르면 더 추가될 수도 4. 좋은 글을 지속적으로 쓴다는 확신이 들면 Brunch, 전자책으로도 확장 예정 5. 글의 내용은 지속적으로 수정될 수 있음 필자보다 훨씬 뛰어난 분들이 많기에, 피드백은 언제나 환영입니다.