QA팀이라고 생각하면 대부분 테스트를 하는 부서라고 생각을 한다. 맞을 수 도 틀릴 수 도 있다. 통싱 적으로 개발팀에서 자체 개발 테스트를 하지 않고 QA팀에서 테스트를 진행하고 QA팀에서 테스트가 정상적으로 진행되었다면 QA Off라고도 한다 QA 하면 검증을 하는 업무라고 많이들 이야기를 한다. 반복적인 테스트와 부화적인 스트레스 테스트를 진행하여 통과가 되어야 QA라고 하는데 이건 잘 보면 QC활동이다
QA에 대한 교육이나 컨퍼런스를 찾아보면 QA에 대한 교육은 없고 테스팅에 대한 이론과 교육만 존재한다.
ISO 29119 표준 어디에도 QA= TEST라는말은 없다. 대체 이 오해는 왜 생긴 것 일까?
ISO 29119 1장부터3장까지에는 QA 테스트라는말은없다
QA는 예방활동이다.
QA에 활동에 테스트가 포함되긴 하지만 절대로 QA=TEST가 되서는 안 된다.
기능에 대한 오류가 발생했을 때는 QA제대로 했어? 가 아니라 테스트 제대로 했어?로 말해야 한다
QA는 리스트 발생에 대한 인자에 대한 예방하는 활동이므로 QA기간이라고 하면
테스트를 포함하여 요구사항 파악하고 테스트를 계획하고 테스트를 수행하고 리포트를 하고
배포까지의 일련의 과정을 QA기간이라고 해야 한다.
단순하게 테스트 기간을 QA기간으로 생각하고 있는지 다시 한번 생각해봐야 한다.
QA는 테스트에 대한 환경, 일정관리 , 이슈에 대한 관리 , 테스트 수행, 테스트 결과보고, 배포까지의 과정을 다루는
큰 툴을 다루고 있고 단순한 테스트업무를 하지않는다.
다시말해 테스트는 QA라고하면 안된다.
테스트는 테스터의 영역이다
테스터나 테스터 엔지니어는 주어진 테스트를 수행하고 이슈를 생성하고보고하는데 그치거나 테스트 일정관리까만 관여하는게 통상적이다. 이건 QA가 아니라 QC의 영역이고 Test Engieneer이다.
다시한번말하지만 QA는 테스트야라고 한 단어로 끝내는게 아니다.
테스트를 잘하면 품질이 좋아질까?
테스트에는 수 많은 테스트 기법과 방법과 방법론들이 존재한다.
테스트는 고객관점 사용자 관점에서 바라보고 테스트를진행하고
QA활동은 고객관점 테스트와 요구사항기반으로 개발이되었지까지의 확인을 하는 과정이다.
단순하게 이슈를 많이 찾아서 리포팅한다고 해서 그에 대한 테스트 커버리지가 확보된다고 할 수 없다.
소프트웨어 테스팅 활동은 소프트웨어의 결함을 찾아내는 활동으로 품질을 보증하는 활동이 아니다.소프트웨어 개발과 소프트웨어 테스팅에서 가장 먼저 시행되는 과정은 요구사항 파악이다.요구사항과 기획의도를 파악하고 기획서문서를 기반으로 되었는지 테스트를 하고 테스트를하면서 리포팅을 하고 결과에 따라 위험인자와 이슈원인과 방지안을 찾는게 QA이다.단순한 테스팅은 Test Engieneer의 영역이지 QA의 영역에서 거리가 있다.그래서 요구사항 기반으로 개발이되었는지 부터 분석하는게 QA의 업무이기도 하다. 물론 프로세스가 에자일기반으로 돌아간다면 설계단계부터 기획 테스트를 돌면서 스프린트로 돌아가기때문에 다른 이야기지만. 그건 나중에 다루도록 하고
정말 1부터 100까지 모든 일련의 과정을 문서화시키는 곳은 거이 없을 것 이겠지만
테스터도 동일하게 역량에 따라 요구사항명세서에 기재된 기능에 따라 테스트케이스를 역으로 설계하고
이 기능이 만족하는지 테스트 케이스를 명세기반으로 설계를 할 수 있다.
QA는 테스트에 대한 전반적인 일정일 관리하고 테스트에 소요되는 리스크를 분석하고
이뤄진 테스트에 대해서 중요한이슈인지에 대해 판별을 내리는 과정이고
단순한 테스트의 활동은 QA로 분류해서는 안된다.
많은 기업들이 QA를 Test로 오해하고 있고 이게 대중화가 되면서 QA가 테스트가 되버린 거짓말같은 세상이 되었다.
내가 QA라면 과연 테스트만 위주로 사고를 생각했는지를 생각하면 된다.
테스트검증위주의 사고에서 벗어나야한다.
테스트의 설계
명세기반 테스트케이스를 작성할때 요구사항 명세서를 참고하기도 한다.
요구사항에 적힌 내용을 기반으로 테스트케이스를 설계를 한다.
명세기반으로 테스트케이스를 작성할 수 도 있지만 스토리보드(기획문서)를 기반으로 한 테스트케이스를 작성 할 수도있다
지난 23∼24일 이틀간 2132건으로 집계됐다. 이틀간 사망신고는 모더나 백신 접종 사례 1건이 추가됐다. 당국은 접종과 사망 간 인과성을 조사할 예정이다.
백신 1차 접종률 80% 달해…완료율도 70% 돌파
코로나19 백신 1차 접종률이 80%에 다다른 것으로 집계됐다. 접종 완료율은 처음으로 70%대에 진입했다. 25일 코로나19 예방접종대응추진단(추진단)에 따르면 이날 0시 기준 코로나19 백신을 권고 횟수대로 모두
국내에서 백신 접종이 시작된 올해 2월 26일 이후 신고된 이상반응 의심 신고는
누적 33만9002건(사망 누적 815건)이다. 이날 0시 기준 누적 접종 건수(7530만8637건)와 비교하면 0.45% 규모다.
출처 : 국민일보뉴스 보도
백신접종 후 발생하는 사망사례는 점점 늘어나고 있다.
그러나 백신으로 인한 사망에 대한 인정은 아직까지도 단 2건에 불과하다.
인 . 과. 성 미. 인. 정
질병관리청은 인과성에 대해서 인정할 의지가 1%도 없다.
지난,8월 1일 장애인 수영선수인 김슬희가 코로나백신 접종 후 3일만에 사망했다.
8월 1일 오후 5시경, 어머니가 퇴근했다. 집에 있던 동생은 “엄마, 나 배고파, 라면 끓여 먹을래”라고 해서 라면을 먹었다. 그 이후 어머니는 샤워를 위해 화장실로 들어갔고 동생은 “나 어지러워서 좀 누워있을게”라면서 방으로 들어가서 핸드폰을 켰다. 약 30분 후에 어머니가 동생을 깨우러 갔지만 그때 동생은 이미 의식이 없었다.
김슬희선수가 사망 후 국가수에서 백신으로 인한 가능성을 배제할 수 없다는 결과를 내놓았음어도
질병청은 인과성을 인정할 수 없다는 말만 되풀이했다.
이외에도 백신으로 인한 사망 사례는 백신접종자와 접종률이 느는만큼 사망/부작용도 그 비율처럼 증가하고 있다.
21.10.28일 뉴스
건장한 헬스트레이너 건장한 사람이 모더나 백신을 맞고 사망하는 사례
백신접종 후 생리불순 발생
34세의 젊은 아이의 아빠가 백신접종 후 사망하기도 하였고 10월 27일 뉴스
그리의 친구의 친구가 백신을 맞고 사망해서 최근 논란이 되기도 하였다.
김구라는 “20대 분들, 젊은 층에서 큰 사고가 많더라”며 백신을 접종한 20대가 갑작스럽게 숨진 사례들을 언급했다.
그리는 “사실 제 친구의 친구도 그런 사고를 당했다. 화이자 맞고 죽었다”며 “(사망한 친구는) 모르는 친구다. 멀쩡했는데 5일차에 (갑작스레 사망했다)”고 전했다.
이에 김구라가 “멀쩡했는데 그런 거냐”고 묻자 그리는 “맞다. 멀쩡했는데 그렇게 됐다”며 “아무 증상 없다가 심장을 쿡쿡 찌르는 증상이 있거나 조금이라도 이상하면 바로 병원으로 가라”고 당부했다.
대구 백신 이상반응 중증환자 130명 중 인과성 인정 '0명'
연합뉴스
27일 대구시 코로나19 예방접종 이상반응위원회에 따르면
지난 25일까지 지역에서 코로나19 예방접종 후 이상 반응을 신고한 1만6천464명 중
중증 환자는 130명으로 집계됐다.
이 중 백신과의 인과관계를 인정받은 사람은 단 한 명도 없었다.
경증 환자의 경우 심의 신청 146명 중 67명이 백신과의 인과관계를 인정받았다.
코로나확진자가 2000명대로 다시 늘어나는 가운데, 정부의 의지는 굳건하다.
확진자수가 2000명을 넘었음에도 정부는 거리두기를 계속할 수 없다며
백신패스를 도입한다.
백신패스는 11월부터 시행이 되는데 백신패스 후 확진자수가 급증하겠는데
확진자가 늘어난건 백신을 맞지 않아서라는 말장난을 할 가능성이 없지않아 있다.
백신접종률이 80% 가까이 되었다.
그만큼 사망한 사람과 중증으로 가거나, 부작용으로 고생하는 사람도 있다는 것이다.
모든 경우에는 반드시 득과 실이 크다.
하지만 정부의 판단은 10명중2명죽는게 코로나로 인해 죽는거보다 더 효과가 커!
이런 근거로 인과성이라는 앞뒤없는 드립을 하는 것으로 보인다.
백신맞고 안맞은 사람이 더 많아! 백신접종완료자가 3599만2708명인데
이중에 사망하는 사람이 1100명대니까 백신을 맞고 죽는게 더 이득이다 라는 주장이지 않을까
설령 인과성을 인정해주면 백신에 대한 책임을 떠안고 가야하기때문에 회피를 하는 것이다.
화이자 백신은 2상 임상실험을 하고 3차부터는 FDA에서 긴급허가가 되고부터 보급이 되기 시작했다.
BTS..? 방탄소년단...? 내가 아는 BTS는 방탄소년단의 지민 정민 이런 분 밖에 모르는데...
하면혼납니다...ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
아 방탄소년단 팬분들이 이 글을 읽으신다면 무시해 주세요 (제발... IT 공학 이야기임)
방탄 내용 1개도 없으니까 뒤로 가주세요...ㅠㅠ
가끔 일하는 동기분들이나 지인분들 중 QA나 Tester로 근무를 하는데 BTS 물으면 모르는 경우가
허다하기에 그냥 이런 게 BTS라고 하는 거 구나를 정리해 려고 하다.
물론 많은 글들과 블로그들에 BTS에 정의와 정리가 잘 되어있지만
굳이 콘텐츠를 만드는 건 신입의 마인드에서 이해가 되기 쉽게 하기 위함이다.
BTS는Bug Tracking System의 줄인 말로, 버그 추적 관리 시스템이다.
개발 단계에서 발견된 버그나 이슈들을 통합 관리하는 시스템인데 BTS라고 하기도 ITS라고도 한다
ITS는 (Issue Tracking System)는 줄임말로 이슈 관리 시스템인데
그냥 같은 의미로 쓰이고 있다.
Bug Tracking System 과 Issue Track System을 알기 전에 알아야 할 것 이 있다.
버그와 이슈다.
먼저 버그(Softwaere Bug의 줄임말)는 소프트웨어의 결함을 나타내는 용어이다. 소프트웨어가 예상하지 못한 잘못된 결과를 내거나,
오류가 발생하거나, 착오나 오작동이 발생하는 등의 문제를 뜻하는데
이 버그의 유래는1947년 하버드 대학교에서 연산을 처리하고 있는 계산기컴퓨터 마크 ll 가 오류를 뽑아내고 고장이 일어났는데
이게 왜 이런가를 분석해보았는데 나방과 벌레들이 기계 사이에 끼어있다 라고 해서 Bug라고 붙여지고 시작했다.
자 그럼 버그가 소프트웨어의 결함을 나타나는데, 어디서는 버그라고 그러고 어디는 이슈라고 그러는데
이슈(Issue)의 사전적 정의는 문제, 문제점을 의미하고 있고
이슈 안에는 버그, 기능, 구현에 대한 부재, 요구 사항 누락 등 포괄적인 게 들어간다.
이게 버그와 이슈와의 차이지만 통상 그냥 버그랑 이슈랑 같은 의미로 쓰는 팀, 회사, 프로젝트가 많다.
소프트웨어의 문제는 어디서 일어나는가를 따지고 올라가다 보면버그(Bug)와요구 사항 미충족 등으로발생한다
소프트웨어 개발 단계에서 잘못된 코드와 디자인 등의 사유로 버그가 발생하고 이 문제를 어떻게 해결할 것인가를
하다가 이슈까지 온 것으로 추정된다.
버그는 결함을 의미, 이슈는 문제점을 의미(문제 점안에는 버그와 요구 사항 미충족 다양한 문제를 담는다)
기능적인 오류를 발견하여 이걸 관리한다고 하면 그냥 이슈나 버그를 동일한 용어로 사용을 많이 한다.
이번에 이슈 몇 건이에요? 이번에 버그 있었어? 말이 아 다르고 아 다른 건데
듣다 보면 같은 소리임.
버그(Bug)가 왜 발생했냐에 대한 원인을 하나둘 식 인과관계를 집어 가기 위해 디버그/디버깅을 한다.
디버그도 그 버그가 어디서 나왔어를 찾기 위해 소스코드를 다시 검사하고 추적하는 디버거를 사용.
이슈/버그 관리 툴에서 기본적으로 있는 카테고리 기능이 있는데
담당자(Assigner) : 이슈를 해결할 담당자/개발자/기획자/책임자
우선순위 : 이슈의 처리를 해야 할 순위의 등급 P3/P2/P1으로 하기도 하고 한다
이슈 등급 : Major Minor Critical 와 같은 이슈의 등급을 정하는 등급이다.
마감일 : 이슈/버그가 반드시 해결되어야 할 일정 일을 기입하기도 한다
상태 : 기본적으로 열림/닫힘으로 구분하고 그 외 세부적인 상태(시작, 수정 완료, 재현 불가 등)를 가지고 있기도 한다. 오픈 이슈는 분석, 검토, 해결이 끝나지 않은 이슈, 닫힌 이슈는 해결되었거나 모종의 이유(재현 불가, 기술적으로 불가능, 중복 등)로 더 이상 검토할 필요가 없는 이슈이다.
BTS는 프로젝트/개발 관리 측면에서 효율적으로 애사일 팀에서 그 크롬으로 각자의 일 Task를 뽑아내려고 하는 것도 있지만
제일 큰 목적은 말 그대로 버그/ 이슈관리의 유무이다.
이슈 또는 버그가 발견됐고 이 버그를 해결하기 위해선 어떤 팀의 어떤 개발자에게 넘어야 되고
어느 유관부서의 책임인가
이 이슈는 마이너 한 이슈인가 아닌가를 인과관계를 따지고 이 이슈는 언제까지 해결해야 하고
이번 주 스크럼이나 이번 주 배포 일정까지는 수정이 될 수 있니?
수정이 안되면 이게 지금은 진행하고 다음에 고칠 거야 In Progress 하고 이슈는 이제 수정됐고 확인도 완료되었어
그럼 이슈 닫음 Closed까지의 모든 프로세스를 할 수 있는 게 BTS(방탄소년단 아님..)
과거에 BTS가 없이 엑셀로 담당자는 이 사람이고 이걸 고쳤으면 코멘트를 썼는데
이게 프로세스나 효율적으로 별로 안 좋아서 bts / its를 쓰기 시작했다.
지라나 레드 마인 멘토 등의 BTS의 CI/CD나 REST API 연동 같은 기능은 다루지 않고 그냥
이런 툴이 있구나만 다룬다
정리하면 정말 끝도 없어서...
버그/이슈 관리 툴에는 어떤 것이 있을까를 보면
1. Jira
제일 보편적으로 많은 회사들이 사용하고 있는 이슈관리 툴이다.
제조사 : 아틀란시안(Atlassian)
지라의 제조사인 아틀란시안은 오스트레일리아에 있다.
사진 삭제
사진 설명을 입력하세요.
지라는 많은 기업에서 사용하는 만큼 모르는 이도 거의 없다. 지금은 개발팀이나 QA 팀이 아니어도
생산공정,반도체업계,기획팀에서도 지라로 이슈 Task를 생성해서 프로젝트를 효율적으로 관리하고 있는 만큼
지라는 거이 이슈관리툴계의 아이폰..? 수준이다 모르는 사람이 거이 없다.
지라는 비용이 무료냐 그것도 아니다.
소프트웨어 테스터들이나 QA들이 입사 후 개발팀과 협업을 위해 지라를 쓰는 경우가 많은데 그냥 오피스같이 보통
다 세팅돼있어서 그렇지 사실 이거 돈뭉치임...
라인선스가 유저로 비용이 측정돼있어서 프로젝트팀마다 요금이 다르게 들어간다.
50유저로 계약했는데 회사 인력 충원이 되었으면 다시 요금을 계산해야 하는 번거로움이...
지라는 오래된 툴이기도 하고 분기마다 기능이 업데이트되는 만큼 많은 회사들이 지라를 쓰는 이유는 편에서다.
대부분의 사람들은 QA가 테스트의 동의어(같은영역)라고 생각하지만 사실 품질 보증(QA) 은훨씬 더 광범위한 범위입니다.
다른 프로세스 및 활동뿐만 아니라 위험 관리도 제품의 품질을 보장하는 부분으로 간주되어야 합니다.
적절한 품질 보증의 구성 요소 중 하나이다. 요약하자면 다음과 같습니다.
양호한 리스크 관리에는 품질 보증 활동을 조직하기 위한 소프트웨어 개발의 실질적인 개선이 활동이 포함됩니다.
데이터표 분석표인데 매니징 영역이 제일 크게 기여하고 있습니다.
2. 모든 SDLC(소프트웨어 생명주기)를 커버할 수 있어야 한다.
소프트웨어 품질 보증은 소프트웨어 개발의 전체 수명 주기와 전체 자기 개발 프로세스에 걸쳐 적용되어야 하는 개념입니다.
3. 품질 개선에 집중해야 합니다
QA 테스트는 제품의 최종 결과물의 품질을 최적화하기 위해 소프트웨어 개발 프로세스를 개선하는 데 초점을 맞춰야 합니다.
품질 보증 프로세스의 목적은 소프트웨어 개발로 나타는 사용되는 프로세스와 활동이 최종 제품의 높은 품질을 유지하도록 설계되었다는
고위 경영진급들과 기타 회사의 이해 관계자들의 신뢰를 얻을 수 있도록 보장하는 것입니다.
4. 지속적인 모니터링
여기에는 프로세스의 지속적인 모니터링 및 합의된 표준과 절차가 개발 프로세스 전체에 걸쳐 준수되고 있는지 확인하는 작업이 포함합니다.
5. 방해 받지 않는 품질 보증 절차
또한, 소프트웨어 QA는 SW 설계 공정이 올바르게 작동할 수 있도록 공정 보증 팀에 약간의 자유와 권한이 부여되어야 합니다.
이를 통해 신뢰할 수 있고 고품질의 제품을 일관되게 제공할 수 있다면 회사의 평판에도 긍정적인 영향을 미치게 됩니다.
6. 효과적인 방법론 적용
효율적인 QA테스트에 있어 방법론을 사용할경우 QA테스트를 통해 소프트웨어가 요구 사항 및 표준을 준수하도록 보장하므로 전체 라이프 사이클의 비용이 절감될 수 있습니다.
이는 생명에 중요한 제품의 개발에 있어 기본적인 조건입니다.
(대표적으로 에자일 개발 방법론 폭포후 모델 V모델..등등)
7. 유지 보수 비용 절감
적절한 QA를 통해 이후 소프트웨어 수정이 덜 필요하기 때문에 소프트웨어의 유지 보수 비용도 절감됩니다. 물론 소프트웨어의 릴리스 및 구현 후에만 발견되는 오류 수정 및 수정은 비용이 많이 들고 회사의 평판에 영향을 줄 수 있습니다.
따라서 QA절차에서 소프트웨어가 출시되기 전에 오류를 식별함으로써 전체 라이프 사이클 비용을 전반적으로 절감하는 것이 중요합니다.
8. 전체 조직 문화의 전환
품질 보증 및 테스트 프로세스는 제품의 전체 수명 주기를 소비해야 하며, 생산 또는 유지 보수 프로세스의 모든 단계를 QA에서 다루어야 합니다.
품질 보증의 개념은 소프트웨어를 한번에 테스트하여 버그를 보고한 다음 버그를 수정하는 것이 아니라,
처음부터 품질 제품을 만들고 품질 제품을 테스트하여 QA가 작동하고 실제 프로세스가 개선되도록 하는 것입니다.
전체 조직 문화를 혁신해야 하며 QA가 지속적으로 노력하고 있습니다.
9. 두가지 기본 원칙을 따릅니다.
어떤 제품을 개발 중이든 품질 보증에는 두가지 원칙이 따릅니다. 이들은 "목적에 적합하다"와 "한번에 제대로"입니다.
10. 목적에 맞게 맞춤 적용
"목적에 맞다"는 제품이 해야 할 일을 하고 의도된 목적에 적합하다는 것을 의미한다.
11. 한번에 제대로 연습하기
"한번에 제대로"는 모든 오류를 제거해야 함을 의미합니다. 기본적으로, 여러분의 제품은 장기간에 걸쳐 신뢰할 수 있게 올바르게 작동해야 하기 때문에 이러한 두가지 목표를 달성할 수 있는 많은 방법과기술이 있습니다.
12. 요구 사항을 간결하게 공식화한다.
품질 보증은 명확한 요구 사항부터 시작합니다. 요구 사항을 기록하고, 분할하고, 우선 순위를 지정하고, 관리하는 방식이 최종 제품의 품질에 크게 영향을 미칩니다. 이는 요구 사항이 간결하고 이해하기 쉬운 방식으로 표현되어야 한다는 것을 의미하며, 개발자가 요구되는 사항을 이해할 수 있고 생명주기에 따라 진행됨에 따라 더 많은 기능이 필요하기 때문에 개발자에게 도움이 되는 과정입니다.
13. 성숙한 프로세스 사용
제품 개발에 사용할 올바른 프로세스를 정의하고 이러한 고정 프로세스와 편차 없이 계획대로 사용하는 것이 중요합니다.
14. 업계 표준 준수
또한 개발 팀이 의료, 자동차 또는 항전, 임베디드 시스템 개발 또는 철도 소프트웨어 개발 및 기타 안전에 중요한 영역과 같은 산업 분야의 표준을 준수하는 데 도움이 되도록 설계된 클래스만 사용했다는 사실을 입증하는 것이 중요해 지고 있습니다. 그런 다음 소프트웨어 제품을 테스트하고 QA팀이 제품의 주요 기능을 철저히 테스트해야 합니다.
15. 제품 출시 후 QA의 운영
테스트가 완료되면 QA팀의 일정이 끝난게 아닙니다 단 하나의 버그 없이 출시되는 소프트웨어가 거의 없기 때문입니다. 따라서 사용자 규칙과 사용자는 발견한 버그를 제출할 수 있어야 하며 운영 팀이나 QA 및 개발 팀은 모든 문제를 해결하기 위해 이러한 버그를 함께 해결하고 운영해합니다.