돈버는걸 자동화 할때까지

1. 스타트업 회사 한 곳에 서류를 통과해서 면접을 진행했습니다. 2. 면접은 대화 형식으로 진행됐고, 처음의 자기소개는 간단하게 지금 하고 있는 일과 일을 하게 된 계기에 대해서만 설명했습니다. ( 처음에 흥미를 이끌거나, 재미있는 이야기로 호기심을 드리는 것 보다, 경력직으로써 이직을 하려는 것임으로 진중하게 대화하려고 노력했습니다. ) 3. 기억에 남는 대화가 몇 개 풀어보자면 - QA가 개선 요청한 사항을 회사에서 받아들이지 않을 경우엔 어떨까요? : QA는 결함을 찾고 개선을 요청 하는 것 까지가 업무라고 생각합니다. 그 이후에 설득이나 결정의 영역은 CEO나 결정권자에게 있고 결함을 찾고 개선사항을 발굴해 저장하고 문서화 하는것만으로도 충분히 좋은 일을 했다고 생각합니다. - QA가 요청하는 ..

https://www.iso.org/standard/64764.html ISO/IEC 25000:2014 Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Guide to SQuaRE www.iso.org 1. 경로로 들어가서 BUY 버튼을 선택합니다.

임시로 작성, 나중에 수정예정 지금도 QA 과제 진행중이지만, 지금 스스로 배우고 느낀점을 오늘 저장해두지 않으면 잊어버릴 수 있다고 생각해서 미리 간단하게 정리해둡니다. 1. QA과제는 회사가 면접자의 역량을 파악하는 것 뿐만이 아니라, 면접자가 회사의 업무를 미리 파악할 수 있는 기회를 준다. 2. QA과제에서 중요한 것중 하나는 상상력이다. 전달받은 제품의 본질을 빠르게 파악하는 분석력도 중요하지만, 분석을 바탕으로 이 제품을 테스트 한다면 어떤 문제가 어디에서 발생할까? 를 미리 예측하고 보완하는 상상력이 필요하다. - 실제로 테스트 케이스의 보완은 문제의 발견과 함께 진행된다. ( 이게 참 아이러니하다 ) - 하지만, 과제 면접에서 실제로 테스트를 진행하고 문제를 발견할 수는 없기 때문에 일어날..

나중에 한번 더 정리하기 전에 임시로 지금 떠오르는 생각들을 미리 저장해두겠습니다. 기존의 하드웨어 QA 즉 자동차, 항공, 공장, 이런 직접적인 물건이나 하드웨어가 있는 QA의 경우에는 테스트도 품질 검수도 그에 맞는 리스크 관리도 모두 직접 사람이 진행했어야 했습니다. 따라서, 과거의 QA는 인력관리와 가까운 일을 더 많이 했습니다. 자리에서 테스트를 하는 건 제품의 제조업과 생산자들이 진행했고, QA는 그런 인력들을 관리하며 중간에 생기는 문제를 해결하고, 또 같은 문제가 발생하지 않도록 부족한 인력을 충원하거나 장비를 새로 구매했을 것 같습니다. 하지만 현대의 QA는 컴퓨터로 소프트웨어, 즉 얼마든지 복제가 가능하고 모든 정보를 한눈에 파악할 수 있는 물체의 품질 관리를 진행하고 있습니다. 따라서..

QA로써 가장 처음 블로그에 올리고 싶었던 건 테스팅의 7가지 원리이다. 품질 관리의 가장 기본이 되는 테스트는 아래 7가지 원칙을 모른다면 하지 않는 것과 다르지 않다. 실라바스 : http://www.kstqb.org/board_skin/board_view.asp?idx=426&page=1&bbs_code=4&key=0&word=&etc= #1. 테스팅은 결함이 존재함을 밝히는 활동이지, 결함이 없음을 밝히는 활동이 아니다 (Testing shows the presence of defects, not their absence) 테스팅은 결함이 존재한다는 것을 보여줄 수 있지만, 결함이 없다는 것을 증명할 수 없다. 테스팅은 소프트웨어에 발견되지 않은 결함의 존재 가능성을 줄일 수는 있지만, 결함이 전..