반응형

지금까지는 테스터와 QA의 업무에 대해 다루었다

이제부터는 테스트를 어떻게 계획하고 요구사항을 어떻게 분석하고 테스트를 수행하는데 있어 어떤식으로 문서를 작성해야하는지 정리하려고 한다

소프트웨어 테스팅은 소프트웨어의 결함이 있는지를 발견하는 행동이지만 소프트웨어의 결함이 없다는 것을 증명하는 사실이 아니다.

QA의 업무 중 일부는 테스트 계획 설계부터 테스트 수행단계까지의 일련의 보고서와 문서의 작성이 50%를 차지한다.


우선 테스트 일정을 산출하기에 앞에서 테스트의 과정을 알고 가야한다.

테스트의 과정은 테스트 설계 > 테스트 분석 > 테스트 디자인 >테스트 설계 > 테스트 수행 순으로 테스트기 이루어지며 

테스트가 완료가 되면 시점을 QA Sign-off라고 한다 .

테스트의 단계는 5단계이지만 테스트 수행에 구현을 같이 포함시켰다

신입 주니어의 QA 엔지니어 중에서 테스트 결과서나 테스트 계획서를 작성해보지 않은 경험이 있을 수 도 있을 수도 있다.

테스트를 수행하기 전, 테스트 케이스를 작성하기 전에 반드시 시행해야 하는 단계가 테스트 일정 산출과 테스트 분석 단계이다.

또한 입사 사전 과제로 테스트 계획서 또는 테스트 결과보고서가 과제로 수행이 되는 경우가 많다.

테스트 산출과 계획이어야말고 QA에 있어 가장 큰 업무이다.

필자의 경우 2년의 경험이 있는 1인QA  프리렌서이지만.  용역보고서 및 테스트를 혼자 진행하면서 보고서까지 고객사에 제출한 경험을 토대로 QA의 업무에 있어 과정을 다시 정리해보려고 한다. 

우선 테스트 계획서는 테스트 목적과 테스트에 필요한 리소스(단말,인력)과 테스트에 소요예상되는 리스크를 모두 담아야 한다.

테스트를 왜 하는지 , 이 테스트가 통과되려면 어떤 기준으로 하는지, 테스트는 누가 할 것인지 , 테스트 문서는 어떻게 관리하였는지

테스트 리스크는 어떻게 관리 할 것인지에 대해서 최대한 상세하게 다르는 문서로 단순한 테스트 케이스 작성보다 고도화된 문서이므로

메뉴얼적인 테스터들이 이 문서를 작성할 일은 어쩌다가 있다.

테스트 계획 설계는  테스트 숙련도 평가 모델 TMMi(Test Maturity Model Integration)을 기반으로 작성하였다.

 

TMMi의 5단계 

Level1 초기(Initial)
  • 테스팅이 정의되지 않음
  • 테스팅과 디버깅을 한 부분으로 인식
  • 테스트는 조직원의 능력과 자신감에 의존
 
Level2 관리(Managed)
  • 테스트와 디버깅이 구분
  • 결함 발견 활동의 집중
  • 테스트가 SDLC에서 하나의 독립된 단계로 정의
  • 테스트 정책을 문서화하거나 정책의 일부분으로 정의
  • 전략·접근법 근거하여 테스팅 고 있다는 것을 증명
  • 테스트 정책과 전략
  • 테스트 계획
  • 테스트 모니터링 및 제어
  • 테스트 설계 및 수행
  • 테스트 환경
Level3 정의(Defined)
  • 테스팅이 개발생명주기와 통합되는 단계
  • 별도의 테스트 전담조직 보유
  • 조직차원에서 테스팅을 내재화
  • 테스트 조직
  • 테스트교육/훈련 프로그램
  • 테스트 수명주기와 통합
  • 비기능 테스팅
  • 동료 검토
Level4 관리&측정(Management & Measurement)
  • 동료 검토 활동 수행
  • 요구사항 분석 단계부터 예방적 테스팅
  • 테스트를 관리하고 측정하는 단계
  • 메트릭을 이용한 테스트 수치화, 정량화
  • 테스트 측정
  • 소프트웨어 품질 평가
  • 발전된 동료 검토
Level5 최적화(Optimization)
  • 결함 예방과 품질제어 활동에 초점
  • 테스트 프로세스가 정의·관리되며, 비용과 효과 모니터링
  • 테스트 프로세스가 지속적으로 개선·조정
  • 활동이 통계적 방법과 다양한 평가 기준에 의해 측정
  • 결함 예방
  • 테스트 프로세스 최적화
  • 품질제어

 


본 테스트 계획서는 필자(지스)가  신입 저연차 QA엔지니어에게 역량을 키워주고 발전시키기 위해 테스트 계획서를 작성가이드를 공유하기 위해 공유하는 것으로 외부 공유 시 사전문의 부탁드립니다. 

지스의 동의 없이 배포 또는 복사, 배포를 금지하며, 공부목적 이외 사용시 반드시 사전 문의 하시기 바랍니다.

 테스트 계획서는 먼저 업체명(프로젝트명) / 문서명 / 담당자를 구별하고 문서를 시작한다.

1) 목적

테스트 계획서에 대한 목적과 작성 이유에 대해서 서술한다. (임의로 만든 내용) 

즉 이 문서가 왜 쓰인지 어디에서 쓰이는 지 가이드 하는 프로젝트 공수 산정에 있어 문서 표준을 정립하는 것이다.

만약 QA프로세스가 없다면 문서 양식과 프로세스 부터 체계화해야 하므로 문서부터 만들어 나가야한다.

 

예시)

1. 개요

 1) 목적

당사 지스케어의 쇼핑몰의 상품관리에 있어 타사 온라인 이커머스 플렛품 쿠팡,스마트스토어,옥션,11번가의 플렛품에 동시에 등록하여 판매팀과 CS팀의 효율적인 업무를 위해 당사 몰과 타사몰의 서비스를 연동하는데 있음

당사 몰의 경우는 스마트스토어가 아닌 자체적인 마켓을 구축되어있어 별도로 플렛품화가 필료함 

2) 범위

이번 프로젝트 테스트이 범위가 어디까지 적용되는지를 적는다

예) 앱이면 앱 웹이면 페이지명 컴포넌트별로 나눈다.

2-1 대상

본 문서는 전사 프로젝트에서 공용으로 쓰일 수 있도록 단일화하는 목적으로 제작하였다.

21.1 테스트 대상 서비스

자사몰(지스케어몰)과 타사몰(무좀사)와 연동자사몰과 무좀사와의 쇼핑물의 상품 데이터 동시에 상품이 등록되는 서비스로 모바일과 웹 환경에서 오류없이 api 연동이 되어야한다.

2.2 테스트 항목

 - 모바일 환경과  PC브라우저 환경에서 원할한 연동되는 지를 확인한다

 - 요구사항과 기획서에 명시된 기능되로 각 상품별 카테고리가 동일하게 연동되었는지 확인 

-각 브라우저,OS환경 별 호환성 테스트  

- 타사 몰의 api 서버문제로 당사의 api와 연동되지 않았을 경우의 비기능 테스트 당시의 상품과 타사몰간의 상품데이터를 통합으로 연동하는데 있어 제외하는 조건은 아래와 같다 

- 스토어 몰에 상품이 등록되어 있지 않은 경우  -

타사몰의 데이터를 가져오는 중 해당 몰의 카테고리가 자사몰에 있지 않은 경우     ( 해당 기능의 경우 개발,기획 회의를 거쳐 구현가능한지 확인 필요) 

2.3  전제조건

두개의 연동 몰 사이에 api가 정상적으로 연결되어야 함

등록된 상품이 한 개 이상 있어야함

테스트 시작 전 연동에 필요한 api서버와 환경이 준비되어 있어야 함

타사몰과 사전에 협의가 있어야함

테스트 시작조건은 테스트 완료일까지 조건이 되어하며 준비되지 않을 시 QA일정을 조율해야 한다.

 

 

 

 

 

 

320x100
반응형

QA활동에 대해서


소프트웨어 QA라고 하면 대부분 생각하는 것이 테스트라고 생각을 하는 경향이 있다 

QA엔지니어라고 하면서 실상은 테스트 엔지니어에 불과한 현실이다.

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라면 과연 테스트만 위주로 사고를 생각했는지를 생각하면 된다.

테스트검증위주의 사고에서 벗어나야한다.


테스트의 설계 

 

명세기반 테스트케이스를 작성할때 요구사항 명세서를 참고하기도 한다.

 

요구사항에 적힌 내용을 기반으로 테스트케이스를 설계를 한다.

명세기반으로 테스트케이스를 작성할 수 도 있지만 스토리보드(기획문서)를 기반으로 한 테스트케이스를 작성 할 수도있다 

테스트케이스를 작성을 하고 테스트를 수행하고 리포트를 작성한

 

자, 그러면 테스터도 Testcase를 작성하는데 QA는 안하냐고?

QA도 Testcase를 쓰는경우도 있다.

단지 QA는 테스트 중심의 사고가 아니라 품질, 이슈에 대한 프로세스에 중심되어야한다. 

QA는 테스트의효율성도 따져야하지만, QC를 수행하는 인력관리를 포함하며

품질의 목표에 달성하는 지, 이슈에 대한 우선순위 산정을 해야한다. 

리스크 분석과 이슈 분석을 해서 좋은 결과를 생각해야 한다 

더 좋은 테스터가 되기 위해서는 테스트를 어떻게 효율적인가를 생각해야하고

더 좋은 QA는 이슈를 찾는 것보다는 이슈를 어떻게 관리할 것인가를생각해야한다.

 

 

 

320x100
반응형

 

기존 포스팅 : https://jislog.net/13?category=854150 

테스터와 QA에 대한 차이는 기존에 정리를 했었는데 간단하게 다시 정리를 하려고 한다.

 

SQA(Sofrware Quality Assurance)의 개요

사전에 기획된 요구사항과 개발완료된 SW 제품과의 일치성 확인작업과 검증 중 발생한 이슈로 인해 생길 수 있는 비용적 문제를 산출하고 제품에 대한 안정성과 요구사항에 대해 만족하는지 품질을 보증하는 과정을 의미한다.

 

단순하게 테스트 위주의 검증 업무는 QA( Quality Assurance) 가 아니라 QC(Quaulity Control)에 해당하고

QA안에 테스트가 포함되어 있을 뿐, QA=테스트야 라고 절대로 오인해서는 안된다.

 

자 그러면 보증은 무엇일까?

 

보증이란 (ISO9001 표준에 따름)

보증은 조직 경영진에 의해 제공되며 결과에 대한 확신을 얻는 제품에 대해 긍정적인 선언을하는 것을 의미합니다. 제품이 기대나 요청에 따라 결함없이 작동 할 것이라는 보증을 의미한다.

 

QC는 Quaulity Control, Quaulity Check로 많이 불리는데

품질관리로 직역을 하는데 말그대로 제품에 대한 품질을 관리하는 것으로써 계획된 대로 제품이 개발이 되었는지 확인를 하고

기능은 정상적으로 동작을 하는지, 동작을 하지 않는다면 이 기능이 동작하지 않습니다 라고 보고를 하는 작업을 Test를 진행하고 리포팅하는 업무까지가 QC다 사실 QC는 하드웨어 생산 공정에서 많이 쓰이고 SW에서는 Test또는 검증(Inspect)라고 한다.

성적서 또는 명세서, 기획서에 맞쳐서 개발이 되었는지 체크리스트, 테스트를 검수를 진행을 한다.

 

QA와 QC는 소프트웨어를 포함하여 많은 분야에서 쓰고 있으므로 소프트웨어 QA와 의료기기 QA 제약 QA를 같은 용어로 보면 안된다

각각의 분야의 업무가 다르고 표준도 다르다.

 

SQA는 소프트웨어에서 기반한 품질 보증 업무이다 소프트웨어 QA인데 의료기기 품질 인허가를 한다면 그것은 의료기기 QA에 가깝다고 할 수 있다.

 

QA도 QC업무를 진행하는 경우가 많기 때문에 Test Engineer를 QA Engineer로 오해 하는 경우가 생긴다.

한마디로 간단하게 정의를 내리면 간단하다

Test Engineer (QC) 는 결함발견을 중점

QA Engineer는 결함발견 후 사후 관리에 있어 재발되지 않도록 방안을 생각하고 제품에 대한 품질을 관리한다.

 

 

 

TE(Test Engineer)와 QA(Quality Assurance)의 차이에 대해서

우리나라에선 TE(Test Engineer)와 언제부턴가 QA의 업무가 동급이거나 같은 분류로 인식이 되고 있다. 지금은 많이 바뀌는 추세라고 하지만... 잠깐 여기서 QA는 소프트웨어직군의 품질 보증 Qual

jislog.net

 

TE(Test Engineer)와 QA(Quality Assurance)의 차이에 대해서

우리나라에선 TE(Test Engineer)와 언제부턴가 QA의 업무가 동급이거나 같은 분류로 인식이 되고 있다. 지금은 많이 바뀌는 추세라고 하지만... 잠깐 여기서 QA는 소프트웨어직군의 품질 보증 Qual

jislog.net

 

많은 회사들이 QA팀과 테스트팀을 동일하게 분류를 하지만 QA팀은 검증중심의 테스트 업무 보다는 발견되는 이슈에 대해서

앞으로 어떻게 할 것인가를 생각하는 목표로 업무를 진행해야 합니다.

 

Sw 제품 Product에 보증과 최종 출시까지의 플로는 대략 이렇게 된다.

QA조직이 존재하고 별도로 테스트를 의뢰하는 QC팀이 외부 또는 내부에 있다는 전재하.

 

QC(품질관리) 테스팀에서 요구사항 명세서 또는 기획서를 기반으로 명세 기반 테스트 시나리오를 작성하고

일정을 산출하고 요구사항 기반으로 개발이 되었는지 테스트를 진행한다.

테스트 중 결함을 발견하고 결함을 보고하고 테스트 결과서를 작성하면 테스트팀의 사이클을 끝나고 다음 차수 스프린트로 넘어 가게 된다

QA팀은 내부에 있는 테스트팀또는 외주업체(아웃소싱)업체로 3차 테스트를 의뢰하여 테스트를 진행하고 리포팅을 받는다.

테스트 리포트에 발견된 보고서를 기반으로 자체적으로 재현테스트를 진행하고 이슈에 대한 우선순위를 선별하고

다음 차수에는 어떻게 해결할건지 내부적인 회의를 진행한다.

 

현재 sw qa공고에서 qa라고 소개하고 있는 테스트업체가 많이 있다.

단순히 테스트만 진행하는 업무는 qa가 아니다.

 

그럼 외주업무를 하는 테스트엔지니어 테스터의 업무의 범위는 어디까지일까?

 

테스트 플랜을작성하고 관리하는 업무는 테스트 엔지니어도 할 수 있다.

테스트 결과서 보고서 역시 테스트엔지니어 테스터가 작성한다.

 

품질 보증을 위한 다양한 테스트를 수행을 한다고 써있지만 검증업무이다.

 

 

테스트 일정관리.리소스 관리, 품질기준 확립, 형상관리의 업무가 빠져있다.

또 다른 테스트업체의 공고

제품이 명세서 파악 요구사항을 파악하여 테스트를 설계하여 테스트가 끝날떄까지의 보고서 결함을 관리하는 업무이다.

여기서 품질에 대한 기준점, 재발방지, 이슈 우선 순위에 대한 기준 정립에 대한 내용이 없다

아니 할 수 가 없다.

 

테스트 업체는 테스트 위주로 업무를 할뿐 이슈에 대해서 재발이 되지 않도록 개발팀과 소통하거나 대응이 불가능하다

3자테스트를 진행하기때문에 테스터와 개발자가 직접 컨텍이 불가능하며 기준은 테스트를 요청한 고객사에서 기준을 정하기때문에

테스터는 qa가 아니라 qc에 가까운 것이다.

기능에 대한 결함 인자가 왜 발생했는지 어떻게 하면 발생하지 않을지 리소스를 제안 할 수가 없다

이게 qa와 qc의 가장 큰 차이이다

품질 보증인 qa안에 테스트가 들어가므로 qa도 검증업무를 당연히도 진행 할 수 있다. qa는 테스트 이후의 위험인자를 파악하고 기준을 정할 수 있지만 단순히 테스트를 진행하는 검증위주의 테스트엔지니어는 qa로 볼 수 없는 것이다

제품에 대한 관리를 qa라고 하는 것도 테스터는 관여를 할 수 없다.

내가 하는 업무가 검증업무인데 qa라고 생각하고 있다면 다시 한번 고민을 해야한다.

나는 테스트 케이스를 만들고 검증이 외에 이슈에 대한 기준을 세워본적이 있는지

발견된 이슈가 개발팀과 소통해서 재발되지 않도록 소통을 해본적이 있는다면 qa업무를 진행을 한것이다.

 

이것은 한국의 외주 테스트 업체와 자체적인 제품있는 자사의 업무 차이이기도 하다.

그렇다고 테스트 엔지니어가 필요 없다는건 아니다 소프트웨어 테스트의 표준은 테스트를 내부가 아닌 외보조직에 두는것을

기준으로 하고 있기때문에 반드시 외부 테스트가 필요하다.

하지만 단순한 테스트는 qa가 아니라는 점이다

 

 

320x100
반응형

 

이틀간 백신 이상반응 5천735건 신고…

사망 5명, 인과성 미확인

10.27일 기준으로 집계된 백신 이상반응은 5735건


▶ 2/26일 코로나 19백신 접종 시작 후 10/27일 0시까지

백신 접종 후 사망자: 1,156명

코로나 사망자: 1,212명

===>사망수 차이 : - 56명

코로나로 인한 사망한 수랑 백신접종 후 사망자가 이제 거이 비슷해졌다.

백신으로 얻는게 클까 코로나를 걸려서 죽는게 클까?

백신을 안맞고 코로나 걸렸으면 살았을것이다 라는 말들이 괜히 있는게 아닌 듯 하다

 

한편 백신을 맞은 뒤 이상반응이 의심된다고 보건 당국에 신고한 신규 사례는

지난 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에서 긴급허가가 되고부터 보급이 되기 시작했다.

 

 

https://news.naver.com/main/read.naver?mode=LSD&mid=sec&sid1=102&oid=366&aid=0000769605

접종완료자도 부스터샷 안 맞으면 ‘백신패스’ 뺏기나… “백신 강제 부당해”

질병청 “백신패스에 부스터샷 포함 여부 검토중” 부작용 우려에 ‘부스터샷 거부’ 속출 접종 거부자들 “개인 접종 강제하는 백신패스 부당해” 다음달 1일부터 시행되는 ‘백신패스(접종증명·음성확인제)’ 도입을 앞두고 혼

news.naver.com

2차까지 맞은 접종완료자도 백신패스를 하려면 부스트샷을 맞아야한다라는 말도 나오고 있다.

백신패스대상이 안되면 문제가 있다

나는 2차까지 다 맞았는데 미접종자랑 똑같은 취급이 된다.

부스트샷까지 해야 백신패스면 생명을 오가는 오징어게임같은 도박을 해야한다.

백신을 맞았다고 코로나에 걸리지 않는 것이 아니다.

2차에 맞으면 접종이 끝날 줄 알았나요? 

백신패스를 맞아면 이제 3차 4차 10차까지 갈지 모른다.

독감주사처럼 매해맞는건 납득할 수 있다. 근데 독감주차보다 사망자수가 헐씬 많고 위험핟

백신은 바이러스와 싸워서 면역력을 길러주는 목적일뿐 치료제가 아니다.

치료제라면 이게 맞지 않으면 너네 생활못해라고하지만 백신이 안전하다고 할 수 없다.

돌파감염은 당현히 생길 수 밖에 없다 .

 

백신을 맞아도 변이바이러스에서 안전할 수 없다.

 

얀센 백신 돌파감염 10만 명 중 266명…돌파감염 30대 가장 많아

돌파감염 추정 사례 중 위중증자는 281명, 사망자는 87명입니다.

 

돌파감염 변이 바이러스 분석을 완료한 4천여 명 중 약 94%(3,888명)에서

주요 변이인 델타형 3,800여명, 알파형 30명, 감마형 2명, 베타형 1명이 확인됐습니다.

최근 1주일간 국내 주요 변이바이러스 검출률은 99.8%로 모두 델타형 변이로 확인됐습니다.

지금까지 국내에서 발견 변이 바이러스는 총 4만 6천여 건이고 델타형이 약 4만 2천여 명으로 가장 많습니다.

알파형이 3,200여 명, 베타형 51명. 감마형 27명입니다.

 

 

 

물백신이라 할 수는 없지만 효과가 거이 미비한 수준이다.

백신으로 얻는건 과연 향체인가 사망자수인가

 

 

 

백신패스를 반대하는 청원은 10월 1일에 시작하여 11만명의 동의를 얻었고

20만명을 넘을 것 같다.

정부는 이런청원이 있어도 답은 뭐 국민을 위해 어쩔수 없는 선택입니다라고 할 가능성이 보인다.

최근 청원답변을 보면 거이 회피성 답변이다.

 

질병청에서 과연 어떤 답변으로 재미를 줄지 궁금하다


백신패스, 백신접종 다 좋다

근데 하나가 빠졌다.

백신접종률을 올리고 위드코로나로 가려면 정부가 백신에 대한 안정성과 신뢰를 국민들에게 주어야한다

백신을 맞고 사망하거나 문제있으면 우리가 책임질게! 라고 말하던 정부

현 상화은 인과관계를 따질 수 없거나 기저질환이 있어서 인정할 수 없습니다.

기저질환 있으면 오히려 맞으라면서 맞고나서 부작용생기면 기저질환이 있어서 안됩니다.

분명 생각해보면 이상하다.

백신은 선택이라고 했는데, 미접종자 차별안한다고 했는데

기저질환자는 맞아야 효과가 있다고 하는데, 기저질환자가 맞고 중증에 걸리거나 사망하면

기저질환 떄문이에요 사기가 아닌가? 

 

군대가면 나라의 아들 , 들어가면 누구아들?이랑 다른게 없다.

백신에 대해서 책임을 정부에서 먼저 신뢰를 주어야하는데 인과성이라는 만능의 단어를 쓰고있다.

 

백신맞고 죽은 사람이 10명중 2명이라는데 그중에 한명이 나겠어?

야 나는 맞고 아무렇지 않아 라고 해도 맞고 부작용이 생기거나 사망한 사람은

단순히 운이 없었던 걸까?

단순히 대를 위해 소가 희생하기엔 백신사망자랑 코로나 사망자수가 맘먹는다.

백신 왜 안맞는지 정부도 알고는 있을것이다.

[단독] 질병청 “백신 부작용 지원예산 전액 삭감했다"

2022년에는 백신접종 후 이상징후발견이 되어도 정부지원을 하지 않겠다는 방침을 공개했다.

 

2022년 ‘이상반응 인과성 불충분 지원’ 없어

내년 접종-부작용 인과성 부족 땐 지원 안 해

질병관리청 논란 일자 "예산 증액 협의 중"

미접종자 576만 명 중 546만 명이 예약 안 해

예정처 “백신 두려움, 거부감 적지 않아” 지적

 

 

백신자체가 오징어게임이다.

백신을 맞고 산 사람만이 백신패스를 얻을 것이니..

 

백신1차를 맞았지만 아직 괜찮은게 단지 운이 좋았던 것이라고 생각한다

 

 

 


백신의 인과성드립도 문제이지만

백신패스도 문제점이 많다.

 

 

접종 후 심근염 아나필락테스, 알레르기는 백신접종을 완료하지 않아도 인정이 되지만

당뇨병 고혈압 등 기저질환자는 백신패스대상의 예외로 인정되지 않는다.

 

즉 백신을 맞고 사망하여도 기저질환자는 기저질환자라 인과성이 0이라는 것

기저질환을 인정안하는데 기저질환자는 백신 꼭 맞으세요

앞뒤가 안맞다.

 

고혈압이 있는데 백신으로 인해 죽거나 안맞으면 인정이 안된다는 소리다.

 

11월부터 시행되는 백신패스는 이렇다.

11월이후는 백신접종을 완료하지 않았거나 미접종자도 상관없이

10명이상 모일 수 있고 식당카페 목욕탕 헬스장 업종의 경우

시간제한이 해제된다.

미접종자 일부제한은 검토중이다.

 

그럼 차별화하는 업종은?

 

현재는 영화관이 12시까지는 이용가능하고

음식섭취가 불가능하지만 11월부터는 시간제한이 없어진다

음식섭취는 접종자만 가능

 

노래방과 목욕탕은 접종완료자만 백신패스로 이용할 수 있다.

유흥시설은 12시까지 이용가능하지만 접종자만 이용가능하다.

 

48시간 이내 발급된 PCR음성확인서가 있으면 유흥시설이나 목욕탕 노래방을 이용 할 수 있다

 

“원칙적으로는 발급 후 48시간까지 유효하다. 다만 밤 시간대에 효력이 종료될 수도 있어 시설에 따

라 48시간이 지난 날의 밤 12시까지도 효력을 인정해 준다. 예를 들어 백신 미접종자가 오후 7시까지 효력이 인정되는 PCR 음성 확인서를 들고 목욕탕을 갔다가 효력 시간이 지났다면 바로 나오는 게 아니라 밤 12시까지 머무를 수 있는 것이다.”

 


백신접종을 완료해서 백신패스가 되었다고 하더라도

안전하고 클린한 상태가 아닌데 과연 어떻게 될까?

 

인과관계를 떠나고 백신패스 다 집어지우고

지금까지의 정부와 상황을 정리해본다

 

Q : 백신 접종 후 사망자가 있다 없다?

A : 있다

Q: 그럼 혹시 모를 사망을 피하기 위해서 백신에 대한 본인의 생명권을 지킬 권리 있어 없어?

A: 있다

신체적 자유는 헌법 상의 기본권이다 접종에 대한 선택권은 주어져야하고 차별은 없어야 한다.

혜택이 있어야할 뿐

Q: 백신이 안전하고 효과적이라면 접종자가 피해볼 일 있다 없다?

없어야지.

자기가 지금 접종 했다고 부당한 기본권을 억압하는 정책에 동의하는게 민주시민인가?

백신을 2차가 아니라 몇 달 간격으로 무한정 계속 맞아 하는 건데 그 것도 동의하는거지?

Q: 그러면 백신을 맞고 사망사람들은 그냥 희생한 사람들인가?

 

A : 아니지 그 사람들들도 선량한 시민이고 피해자다.

Q : 백신을 접종을 강요하는 사람들이나 정부가 있는데 백신을 맞고 사망하거나 부작용이 생기면

책임을진다 안진다?

A : 안 진다. 단지 너가 운이 없었을뿐 삑 인과성은 없습니다

 

Q : 백신을 맞으면 코로나에 걸리지 않는다

A : 아니다 백신을 맞고 변이바이러스에 걸린 사례는 증가하고 있고 백신은 향체를 만들어 주는 것 뿐이고

치료제가 아니다.

 

 

 

 

백신에 대한 이슈와 논란은 끊이지 않고 있고 사망 부작용도 이틀에 한번 꼴로 뉴스화되고

있는데 알려지지 않은 사망자가 많다.

회사 단톡방에도 지인이 사망했다는 분도 있고 백신맞고 중환자실갔다는 사례가 많이 있다

나만 안전하는게 끝이 아니라 당현히 백신은 우려가 될 수 밖에 없는 사실이다.

 

백신패스를 도입하기 전에 백신에 대한 안정성부터 검증을 해서 보상을 생각해야하는데

정부는 인과성이라는 마법의 단어를 이제 그만 썼음 좋겠다.

 

 

20-30대 코로나 확진자는 격리되고 생활치료시설에서 무사히 치료되서 복귀를 하고

사망자수는 현저이 적은데 백신으로 사망한 20-30대가 헐씬 많다 무증상으로 걸리거나 확진되어도 중증으로 가거나 사망한 사례는 20-30대는 거이 없다.뭐가 득이고 뭐가 실일까?

이건 음모론이 아니라 사망자와 사례를 기반으로 정리한 것이다

화이자 1차 접종 후 심장 두근거림과 열이 나서 응급실을 갔지만 응급의학과 교수들도 백신접종부작용이 의심될뿐 정확한 원인은 알 수 없다고 했다. 당연하다 백신이 올해 처음나왔는데.

320x100
반응형

 

BTS 하면 방탄소년단을 생각하는 분들이 많다;;

뭐 틀린 말은 아니지만..;ㅋㅋㅋ

소프트웨어 업계에서는 BTS를 방탄소년단으로 생각하지 않는다.

Tester 면접을 갔는데 BTS는 어떤 걸 써보셨어요?

 

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유저로 계약했는데 회사 인력 충원이 되었으면 다시 요금을 계산해야 하는 번거로움이...

 

지라는 오래된 툴이기도 하고 분기마다 기능이 업데이트되는 만큼 많은 회사들이 지라를 쓰는 이유는 편에서다.

 

에자일 프로세스를 도입하는 회사들이 업무하기에 편하게끔 백로그 설정, 스크럼, 칸반보드를 프로젝트 대시보드에 설정해서

각자의 일감 Task를 지정이 가능하다.

 

이슈 개별 필터링, 대시보드 개별 설정은 지라가 그나마 편하게 되어있다.

 

 

지라의 가격

 

지라는 서버 설치형이 있었는데 2년 전인가.. 인가 4년인가 그렇게 오래 안 되었는데 월 구독형으로 돈 장사하려는 건지

바뀌었는데 생각보다 가격이 있는데 월 7달러면 오피스보단 싸지만....

 

 

 

근데 스탠다드  기준 지라 1유저당 월 7달러면 50명이라고 하면 350달러고 X 12 하면 1200달러니까

연 140만 원 정도가 라인선스 비용으로 날아간다

 

아직까지는 중소기업에서 우리는 업무툴 지라를 써요! 하면서 복지를 내거는 곳은 못봤다 (이게 복지면 회사 없애야지...)

 

 

지라는 아틀란 시안의 제품답게 컨플리언스나 위키연동이 간편하게 된다

근데 아틀란시안 컨플리언스위키 비용 따지면....엄....

 

버그관리말고도 CI/CD , Git 연동 , 리파지스토리 연동 편한 기능이 지라가 정말많은데

 

문제는 돈이다.

 

돈이많은 회사가 아니고서야...지라는 한번 더 생각을 한다.

 

2. Redmine

사진 삭제

사진 설명을 입력하세요.

 

지라 다음으로 많이쓰이는건 레드마인이다.

오픈소스이기도 하고 무료이다 지라에 비하면 비용적으로 낫지만

일감이라는 단어를 쓰는 게 맘에 안 듦...

이슈를 일감으로 하니까 노에같잖...아

 

 

사진 삭제

사진 설명을 입력하세요.

비용적인 면에서 지라에 비해 레드 마은을 쓰는 게 소규모 회사나, 작은 팀에서는 훨씬 낫다.

지라에 비해서 인터페이스가 다소 없어 보이긴 하지만

무료인데 이 정도면 감지덕지

 

레드 마인은 클라우드형이 아닌 설치형으로 서버에 직접 설치를 해야 한다.

 

 

 

 

뭐 사실 없어 보이는 이 인터페이스도 Redmin Up 같은 테마 블로그인을 깔면 좀 더 이뻐지긴 한다.

 

 

 

 

3. Micro Focus ALM(Application Lifecycle Management)

응용프로그램 생명주기 관리 툴로 ALM으로 사용한다.

 

사진 삭제

사진 설명을 입력하세요.

 

원래 HP HP Quality Center / ALM이었는데 Micro Focues ALM이 변경되었다.

 

 

 

사실 이걸 쓰는 회사는 LG전자 MC 사업부 밖에 못 봤다.

 

320x100
반응형

 

나는 지금 의료업계 병원 쪽에서 근무를 하고 있지는 않지만 평소에 발목을 자주 접질리고

깁스와 스프린트를 1년에 10번 이상 하는 그런 타입이라 반깁스, 깁스에 대해 걍 이 쪽이 다쳤을때는

스프린트 반깁스를 처방하는구나 뭐 이런거에 꽂혀서 공부했다.

외래 갔을 때 원장님과 교수님께 물어보고 얻은 지식과 논문과 책에서 공부한 내용을 기반으로 정리하였다.

나중에 까먹을까 봐... 정리했다 친구가 레포트쓰냐고하는데 그런목적은 아니었는데...ㅋㅋ

 

 

부목의 목적과 사용

부목의 목적 - 일반적으로 근골 골계의 뼈의 골절, 인대의 손상 등 다양한 사고 발생 후 움직을 방지하여 환자의 통증과 빠른 치유를 위해

부목을 이용하여 고정 및 지지를 하고 빠른 접합 회복에 대한 목적이 있다.

움직임을 최소화하며 빠른 회복을 위해 부목과 깁스 고정을 시행함

 

깁스 고정 시기 : 통상적으로 깁스의 기간은 최대 1달까지이다.

6주정도도 하는 경우도 있는데 통깁스 시행 시 3주-4주를 넘지 않는다

골절부위나 수술에 따라 달라지긴하는데 보통 한달 이내이다.

예상보다 골절 부위가 회복이 안될 경우는 길게 될 수도 있음

오래했을 경우 근육이 굳어 재활치료 시 환자도 고생이다.

 

 

의학용어로 골절 Fx(Fracture)인 경우에

복합골절, 금,부러짐 등 손상에 시술하는데

금갔을겅우도 골절이고 부러졌을때도 골절이다.

 

부목의 종류와 사용

부목(고 정지 지대)의 일환으로 사용대는 것은 일반적으로 Splint(부목 반깁스)와 Cast(석고붕대) 두 가지이다.

일반적으로는 깁스와 반깁스를 같은 단어로 보는 사람이 많은데, 반깁스와 깁스는 다르다.

 

기브스나 반기브스라고 하는 분들이 많은데

틀린 표현이다 기브스는 Gibbs 일본식 발음으로

정식명칭은 깁스/반깁스다

 

반깁스는 말 그대로 반만 고정하는 형태의 부목이다.

환부의 반만 고정한다해서 반깁스

그래서 반깁스는 깁스로 정의하지 않고 부목으로 정의하기 때문에

상해, 손해보험에서 반깁스는 골절상이어도 보상 대상이 아니다.

깁스(통깁스)는 석고를 이용하여 다리 전체가 고정되는데 이게깁스다.

 

깁스는 석고를 이용하여 고정하는 방식인데, 물에 석고붕대를 적시고 환부에 Pading 하며 경화시키고 고정하는 방식으로

반깁스와 다르개 완전히 굳어 환자가 직접 풀수 없는 구조로 되어있고 통깁스라고 불린다.

석고상이나 손바닥 찍어서 만드는 모형같은 형태로 보면된다.

 

 

깁스(통깁스) 의 방법

깁스는 일반적으로 석고를 감기 전에 스티키넷을 먼저 양말처럼 신고 그 위에 솜 붕대를 감고 진행한다.

이때의 깁스는 부목고정(반깁스)가 아닌 통깁스를 의미함

 

골절이 심하거나 움직임을 최소화해야하는 경우 또는 수술 직후 보통 깁스 고정을 시행함

 

 

깁스의 시행과정

먼저 일반적으로 통깁스라고 불리는 깁스의 과정부터 설명한다.

 

스타키넷이란 관상붕대라고도 불리며 양발형태로 신는 붕대다.

깁스 순서 1. 스타키 넷 착용

2. 솜 붕대로 부위를 감는다.

 

 

3. 솜 붕대로 부위를 감은 후 그 위로 석고붕대를 감아주고 좌우로 눌러주면서 고정시켜주면 깁스의 고정이 끝난다.

이떄 스타키넷과 솜붕대를 감는 이유는 맨 피부에 깁스를 하면 깁스를 제거할 수 없고

피부에 손상이 갈 수 있기때문에 보호목적을 위해서 별도로 하고 착용을 한다.

 

다리 깁스를 하는 SLC(Shot leg cast)의 경우 종아리 끝까지 할 경우 발가락 부분의 종아리 끝을 깔끔하게

몰딩을 하면서 고정시켜야 한다.

 

 

여기서 그럼 깁스와 반깁스의 차이는 뭘까

 

반깁스의 방법

 

다리를 전체를 고정하는 게 아니라 이렇게 반만 부목 형태로 고정하는 것을 의미한다.

 

 

 

저 하얀색 지지대가 반깁스라고 하는 스프린트다

 

반깁스(Splint) 부목의 시술

Splint는 폴리와 유리섬유 재질 두 가지의 방식이 있는데

요즘에는 대부분 폴리 섬유가 사용되지만 유리섬유가

좀 더 무겁고 사용되는 곳도 많다.

유리섬유는 경화(굳기)가 되기 전에 커팅을 했을 경우 모서리가

날카로운 부분을 형성된다고 한다.

 

사진 삭제

사진 설명을 입력하세요.

대략 이런...? 느낌이다 저기에 스치면 따가움

 

유리섬유의 Splint의 경우 경화되는 내부 포켓부분이 이렇게 석고재질로 되어있어서 날카롭다.

 

 

폴리의 재질의 Splint의 경우

 

유리보다는 덜 날카롭고 부드럽다.

 

반깁스 Splint의 종류

 

Splint 스프린트는 롤Roll 타입과 Pre-cut의 Splint가 있다

 

 

Roll Type의 원하는 길이로 잘라서 사용하는

Roll Splint

대표사진 삭제

사진 설명을 입력하세요.

롤타입의 스프린트도 2인치부터 6인치까지 있으며

환자의 부위의 두께, 부위에 따라 적절하게 사용가능

 

 

규격에 따라 잘라있는 Pre cut Splint

(One Stap Splint)로도 불림

5x30 5x45 5x60 같은 길이로 컷팅되어있고

SLS는 5X30이나 4x30을 주로 사용한다

손목의 경우 2인치,3인치를 주로 사용하고

부위별, 환자의 부위에 맞게 6인치까지 사용가능하다

 

Pre-Cut One Stap Splint

 

의료보험이 적용되서 반깁스는 2만원대(압박붕대포함)

통깁스의 경우 2만5천원부터 3만원후반의 가격이다

병원 의원급이냐 종합병원에 따라 비용은 상이하다

 

보통 건강보험처리하면 18760원대로 본인부담금이 처방된다.

 

precut은 SLS냐 LLS냐에 따라서 길이에 따라 비용 수가 (비용)이 결정되는 것 같다

 

 

다리 반깁스의 주의점 : 반깁스(스프린트)를 통한 다리깁스 시 뒷꿈치 욕창의 문제

 

반깁스 시술이나 깁스 시술 시 뒷꿈치가 깁스에 눌려

욕창이 생기는 경우가 있다

욕창발생 시 통증을 유발하고 멍이들거나 피부괴사등의 문재가 발생하시때문에

뒷꿈치의 욕창을 방지하기 위해 솜붕대를 두껍게 감거나, 폼패드를 요즘에는 많이 사용하고 있다,

그냥 처음에 스프린트로 모양을 만들떄 솜붕대를 감소하거나 아래의 폼패드를 하고 모양을 만들고

굳은다음에 다시 붕대를 감으면 뒷꿈치 통증은 그나마 덜하다. 이게 너무 스프린트와 뒷꿈치가 딱붙어도 문제라

 

스프린트 시술시 솜붕대를 두껍게감고 스프린트를 경화 (굳혀야) 욕창이 덜 잘생한다 눌리지않고 여우가 있기 때문.

대학병원급은 다리의 경우 솜붕대를 감고 반깁스를 제작하는경우가 많은 것 같았다.

 

대표사진 삭제

사진 설명을 입력하세요.

반깁스 시 욕창과 뒷꿈치 통증 방지를 위해 사용되는 레노폼힐

 

 

 

반깁스 Splint 하는 경우와 cast 깁스를 하는 경우

반깁스는 골절 부위가 심하지 않거나 많이 부어서 깁스를 하지 못하거나, 깁스를 고정할 만큼 고정이 필요하지 않을 경우

반깁스 Splint 시술을 시행한다

 

깁스(통깁스) Cast의 경우 반깁스보다 더 고정이 잘 되므로 골절 및 인대 손상이 심해 장기간 고정 및 단단한 고정이 필요할 때 시행하고

깁스는 반깁스에 비해 스스로 풀 수 없기 때문에 샤워하는데 어려움이 있다.

 

먼저 깁스는 상지냐 , 하지에 따라 나뉘는데

상지는 손가락, 손목, 팔꿈치

하지는 발가락, 발목 , 종아리, 무릎, 허벅지정도를 하지라고 한다 .

 

먼지 상지의 부터 정리한다.

 

단하지 깁스 부목의 종류는 여러가지가 있다.

 

Sugar tong splint , Short Arm Splint, Sugar tong Splint, Long arm splint

줄여서 STS, SAS, STS, LAS로 부르기도 하고

깁스의 경우는 Splint 에서 Cast로 바궈 STS,SA,LAC,SAS로 부르기도한다;.

 

1. Sugar tong splint (STS)

설탕 집게 모양처럼 생겼다그래서 붙여진 슈가 스프린트

 

손바닥부터 손등(팔꿈치 시작전까지) 대어 고정시켜는 방식이다.

주로 손목관절의 손상, 골절된 경우 사용된다.

 

사진 삭제

사진 설명을 입력하세요.

이때 팔꿈차와 손목의 각도가 90도가 되어야 깁스 제거 후 불편하지 않는다.

 

손목관절 중에서 골절이 많이 일어나는 골절이 노뼈(척골)의 골절이 많이 일어나는데,

어떻게 골절이 되느냐에 따라서 Colles 골절, Smith 골절로 지는데

Smith 골절일 경우 주로 시행한다고 한다

 

사진 삭제

사진 설명을 입력하세요.

Xray상으로도 보이는 손목이 완전 절반쩍도 꺽이면서 발생한 골절은 스미스 골절이라고 하는데

손목 구조상 손목을 관적을 틀면 손등까지 움직이므로 보통 슈가 스프린트를 사용한다,

 

 

 

2. Dubble Sugar tong splint (DSTS)

사진 삭제

사진 설명을 입력하세요.

Dubble Sugar tong splint 는 주로 팔꿈치의 골절, 손등의 골절 시 주로 시행하며

이때도 손목과 팔꿈치의 각도가 90도를 유지해야한다.

 

 

3. Finger Splint (FS)

사진 삭제

사진 설명을 입력하세요.

 

 

Finger Splint는 손가락에 하는 부목이다.

주로 알류미륨판으로 고정.

 

 

4. Shot Arm Splint (SLS) 또는 Short Arm Cast(SAC)

사진 삭제

사진 설명을 입력하세요.

손바닥부터 손목까지 주로 고정을 할떄 시행하며

손목염좌 손목골절 손바닥손상 팔꿈치 아래 부위의 손상시 시행

 

5. Long Arm Splint (LAS) 또는 Long Arm Cast(LAC)

사진 삭제

사진 삭제

사진 설명을 입력하세요.

고정 위치 : 손목부터 팔꿈치까지 고정

대상: 주로 팔꿈치 관절의 손상이나 근육파열 인대손상

팔등 골절이나 손목골절이 심한 경우에도 시행 행된다.

 

 

6. thumb Spica splint OR thumb Spica Cast

사진 삭제

사진 설명을 입력하세요.

엄지손가락과 손목은 관절이 연결되어 있어 건초염(드퀘르벵) 증후 군이나 손가락 주위 인대 근육손상 시

엄시손가락을 움직이면 손목이 움직이기에 같이 고정한다.

 

스피카 부목은 엄지 손가락을 제외한 다른 손가락을 자유롭게 움직일 수 있도록 고정한다.

주로 엄지손가락의 골절, 손목 임대손상, 골관절염, 드퀘르벵 증후군 또는 주상골 골절시 주로 사용된다.

 

 

 

7. radial gutter splint

사진 삭제

사진 설명을 입력하세요.

2, 3번째 손가락의 골절이나 2, 3번째 중수골의 경부, 체부, 기저부의 골절이 있을 경우 시행한다.

 

8. Ulnar gutter Splint Or Ulnar gutter Cast

 

사진 삭제

사진 설명을 입력하세요.

주로 손목 척측, 즉 손목의 새끼 손가락 방향 주위의 염좌나 힘즐염의 손상시 시행하며

단하지로 엄지손가락,검지손가락을제외하고 중지손가락부터 스프린트를 대고 시행한다.

5번째 손가락의 골절이나 4, 5번째 중수골의 경부, 체부, 기저부의 골절이나 인대손상이 있을경우 시행한다.

 

 

 

 

 


다음으로 하지(다리)다.

 

다리에 하는 부목, 깁스의 종류는

3가지로 나눠진다

3가지중에서도 단하지와 장하지로 나뉘는데,

 

 

SLC, SLS 는 단하지 고정

LLC, LLS 는 장하지 고정 말그대로 길다해서 장하지

Cylinder Splint , Cylinder Cast도 장하지이다.

 

 

1. Short Leg Cast Or Short Leg Splint

SLC : Short Leg Cast / SLS : Short Leg Splint

 

말 그대로 짧은 다리 고정이란 의미로 쓰이며 발가락부터 발목, 종아리까지의 고정을 한다,

주요시기 : 발목 골절, 발등 골절, 중족골, 발가락 골절, 인대 파열, 종아리근육 파열

부위에 따라 길이가 달라지는데 무릎 밑까지 하는게 일반적이다.

 

다리(하지)의 반깁스 설명에 앞써 반깁스(스프린트)의 시술과정을 간략히 정리

대표사진 삭제

사진 설명을 입력하세요.

Splint의 사용방법은 진공포장된 스프린트를 개봉하여 물을 적시고 스프린트의 물을 짜내고 환부의 고정하면

15분-20분 이내 굳는다.

대표사진 삭제

사진 출처 : 비엘테크 스프린트 소개 영상

 

다리 기준으로 SLC 또는 SLS 시술 시 골절 부위에 따라 길이가 달라지는데

무릎 밑까지 하는 경우 fibular head(무릎 밒에 있는 비골두뼈) 중앙부터 시작하여 발끝까지 한다.

Splint나 Cast 시술 시 비골 후 뼈가 눌리지 않도록 주의해야 하며

발목의 경우 90도의 각도를 유지한 상태에서 깁스 고정을 올바른 고정이 된다.

반깁스의 각도가 90도가 아닐 경우 뼈가 붙는데 문제가 생긴다.

예외적으로 골절부위에 따라 90도보다 높게하는 경우도 있긴함

 

대표사진 삭제

출처 : 주식회사 덕인 스프린트 소개 영상

필요에 따라 다리 반깁스(Splint)의 몰딩으로 환부에 맞게 제작이 완료된 후에는

발가락의 형태에 맞게 자를 수 있다.

발가락 형태에 맞게 둥글게 커팅 하는 게 깁스 신발을 신거나 이블류에 걸리지 않는 것 같다.

 

반깁스 시술 시 발꿈치 부분과 정강이 부분의 욕창이 생겨서 깁스 중에 피루 괴사 피부가 멍이 드는 증상이

많이 발생하는데 통증이 발생할 경우 빠른 시일에 병원에 가서 재시술을 해야 한다,

간혹 응급실 EM에서 급하게 시술해서 욕창이 생기는 경우도 많이 봄 ㅠㅠ

반드시 각도는 반깁스나 석고 깁스고 90도를 유지해야 한다.

 

간혹 치료방법이나 부위에 따라 90도가 아닌 65도로 등 각도가 바뀌는 경우가 있는데

L자형 90도로 고정이 안되면 걷는 것도 불편하고 힘들다.

 

대표사진 삭제

출처 : 주식회사 덕인 스프린트 소개 영상

 

사진 삭제

사진 설명을 입력하세요.

 

오더에 따라 처방을 내릴 때 용어가 쓰이는데 참고하면 좋다,

 

2. Long Leg Cast , Long Leg Splint (LLC)

LLC는 SLC와 같은 의미에서 그냥 길다 해서

발가락부 터 허벅지 끝까지 고정

아킬레스건 골절이나, 무릎인대 손상, 허벅지뼈 손상 등 움직임을 최소화할 때 고정한다

 

 

사진 삭제

사진 설명을 입력하세요.

 

3. Cylinder Splint

Cylinder Splint 는 발목의 끝부터 무릎의 끝인 허벅지까지 고정하는 방식이다.

무릎의 염좌,무뤂의 인대 손상, 무릎의 골절에 주요 사용

 

LLC(Long Leg cast)가 발가락부터 였다면 실린더는 발목 끝부터 고정한다

 

사진 삭제

cylinder splint

 

대표사진 삭제

사진 설명을 입력하세요.

 

응급실에서 시행한 Cylinder Splint 시행 사진

 

 

사진 삭제

사진 설명을 입력하세요.

이렇게 무릎 손상의 시행하는 고정방식이다,

 

대표사진 삭제

사진 설명을 입력하세요.

양쪽 발목 반깁스도 해봤는데

양발깁스의 경우

대표사진 삭제

사진 설명을 입력하세요.

DSLC 또는 DSLS로 불림

 

DSLS(Dubble Short leg Splint)라고도 하고

DSLC(Dubble Short Leg Cast) 라고도 하는것 같다

 

양쪽 발목이나 인대가 같이 손상되는 경우가 사실 드문데, 한쪽 다리를 다친 상태에서

목발을 짚다가 계단에서 넘어진다던가...교통사고가 나거나 갑자기 툭 떨어져서 다치면 골절이나 인대 손상이 간다.

 

 

 

 

320x100
반응형

 

거의 3주 가까이 기다려서 받은 맥북

1월 12일 결제 / 1월 26일 출고 준비 중 / 1월 28일 수령

교육 할인받아 구입 116만 원 + 에어팟

 

 

열심히 할부...

 

 

기존에 사용 중인 윈도우 노트북을 포기하고 메인 노트북으로 맥북으로 구입하게 되었다.

이번에 맥북에어를 고르게 된 이유는

M1 이 말도 말고 탈도 많지만

실보다 득이 너무 많았지만 아이폰의 앱을 사용할 수 있고

일단 팬리스!!

(팬이 없단 소리)

 

 

 

 


M1으로 사용하고 느낀 점

1. 아이폰의 앱을 맥에서 사용가능

- 일부 앱의 경우 사용이 불가능

iOS 네이버 지도 앱 실행

 

2. 팬리스

- 침대나 책상에서 노트북 할 때 하드한 작업이 아님에도 불구하고

팬이 돌아가는 걸 보면 거슬려서 팬리스가 쓰고 싶었다.

3. 8코어임에도 나름.. 저렴한 가격

4. 발열

생각보다 발열은 모르겠다

유튜브 후기처럼 발열이 거의 없다시피 한 것도 아니고

무릎에 대고 썼을 때 따뜻하다 허벅지가 따뜻

순수 배터리로만 써도 열이 발생하는데 발열이 적다는 건 모르지만

성능은 만족스..

 

 

애플 실리콘 M1으로 사용했을 때 생기는 단점

 

1. 인텔 기반이 아니기 때문에 패럴 로즈, 가상PC, 부트 캠프를 지원하지 않는다

- arm의 윈도를 돌릴 수 있는 패럴러즈 베타가 나왔긴하지만 암 아키텍쳐 기반의

윈도우는 에뮬레이터가 애플 로제타 번역에 비해 성능이 뛰어나지 않기때문에

로제타처럼 자연쓰럽기 쓸수 없기에.. 윈도우 컴퓨터가 있어야 한다

애플이 공식적으로 부트캠프를 지원하지 않기에...쓸수가 없다

 

2. 호환성의 문제

확장 프로그램과 플로그인들이 아직 애플 실리콘 기반으로 포팅이 아직 안된 상태라서

쓸 수 있는게 제한적이다

다만 젯브레인의 IDE의 경우 파이참 등 애플실리콘으로 벌써 대응이 되었다

- 다행히 회사의 재택용 가상PC가 윈도우10이라서 회사업무는 원격으로 들어가면

무라없이 수행할 수 있고, 본가에 24시간 향시돌아가는 서버 윈도우PC가 있기에

언제든지 윈도우를 사용헐 수 있기에 극복가능

 

로제타2로 대부분의 기능은 사용이 가능하지만 언제 죽을진 모름 ㅠㅠㅠ

근데 생각보다 안정적임...소름

 

 

1월 28일에 도착했다

퇴근길이 어찌나 설랬는지 두두두둥

이상하게 애플 공홈의 배송은 DHL을 걸쳐서 배송을 우체국으로 이관해서 우체국으로 온다

애플의 DHL을 담당하는 물류가 있는 듯한데,

DHL도 국내배송을 통해 가능한데

왜 굳이 ....

대표사진 삭제

사진 설명을 입력하세요.

애플의 가격은 뭔가 포장비이지 않을까 싶을 정도로

포장이 정말 원클릭이다.

두둥 맥북에어!

사실 기존에 쓰던 노트북은 윈도우였고 컴퓨터도 윈도우였지만

언제부턴가 애플워치..부터 시작해서

애플으로 생태계를 바구고 있다

연동성은 진짜 ...너무 편하기에...

 

대표사진 삭제

사진 설명을 입력하세요.

박스 뒷면은 8GB RAM과 256GB SSD

 

 

포장 비닐도 간단하게 칼 없이 스스슥

대표사진 삭제

사진 설명을 입력하세요.

구성품 30W충전기 , C to C 타입충전기

설명서

사진 삭제

사진 삭제

사진 설명을 입력하세요.

의미없는 애플스티커는 갤럭시쓰는

친구폰에 붙여줬다

이. 제 아이폰

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

 

 

 

항상 느끼지만 애플은 케이블마는거

장인이다 어떻게 저렇게 이쁘게 선을 말까...

 

두둥

대표사진 삭제

사진 설명을 입력하세요.

에어팟 자연스럽게 올려두기

애플의 스테인 마감은 정말 우수하다

영룡한것..

 

충전기는 기본적으로 30W가 제공되지만

맥북에어의 최대출력이 45W까지 가능하다

2015맥북에어는 45와트 충전기를 줬었는뎁...

아니 근데 맥북은 환경을 사랑하지 않나보다

환경을 사랑하면 충전기를 안줬어야...할말하않..

 

맥북 충전기를 허브에 연결하면 PD OUT으로

맥북의 충전은 왠지모르게 되지 않았다.

너무 많은 전력은 쓰는 것도 아닌데...

 

이렇게 C타입 입력에 충전기를 연결했지만

대표사진 삭제

사진 설명을 입력하세요.

배터리 충전 중이 아니라고 뜨며 충전이 안됨...ㅠㅠ

 

결국은 충전기랑 허브 2개를 꼽는 걸로....ㅠㅠ

집에선 뭐.. 상관없으니까 ..?

 

 

맥북을 처음 열면...

맘대로 켜진다

맥북의 부팅음 데에에에에에엥하고 켜진다.

너무 시끄러우니 꺼버리기로..

 

요즘 이슈가 되고 있는 M1 맥북 불량들을 체크해봤다

첫번째로 흔들어봤지만 틱틱하는 굴러다니는 리는 나지않았다

휴 다행

 

대표사진 삭제

사진 설명을 입력하세요.

보호종이 제거

추 언어를 한국어로 설정하려면 이러면서 시리가 나옴..

주를 추 언어로 발음함...ㅋㅋ

 

처음 딱 시작하면 시리가 나온다

 

 

대표사진 삭제

사진 설명을 입력하세요.

균일도와 빛샘을 보기위해 모니터 상태부터 체크

이정도면 빛샘없고

균일하다

 

휜색도 제대로 표현해주는 듯 했다,

맥은 사실 회사 컴퓨터로 썼었지만

개인 컴퓨터로 쓰는건 사실 처음이다

 

오피스 깔고

비주얼 스튜디오도 깔고 이러쿵 저러쿵 셋팅 끝

이렇게 나도 모르게 앱등이가 되어간다.

애플제품을 좋아하는건 아닌데 쓰다보니

내가 익숙해지는 듯하다

앱등은..사실 아님

애플 싫어..환경보호 한다면서

핸드폰 충전기 뺏는데 노트북은 주고

앞뒤 안맞음..

 

애플기기의 호환성은 맥북을 쓰면서

다시 한번 생태계의 위대함을 느꼈다.

맥북으로 작업을

하다가

전화가 오면

이렇게 맥북에서 전화를 받을 수 있다

맥북에 있는 마이크로 그대로 전달된다

갤럭시도 이런 기능이 되긴하지만

뭔가 깔아야되는데...이건 좋았다.

 

 

이블속에서 가지고 놀기 좋다

회색 토퍼랑 한 몸

잘어올린다

손 올려보기

사실 실버랑 스페이스 그레이 골드중에

고민을 했는데 그레이덕후라..

그레이로 질렀다

대표사진 삭제

사진 설명을 입력하세요.

애플기기간의 호환성은

정말 신기하게도 안정적이다

 

대표사진 삭제

사진 설명을 입력하세요.

에어팟을 블루투스를 켜서

다시 검색할 필요없이

아이폰에서 페어링한 에어팟을 그대로

연결이 가능해져서 편했다

아이폰에서 페어링 된 상태에서

바로 페어링 상태변경 가능하다!

 

사실 이건 Mac OS 카탈리나인가 그전부터 됬던건데

맥북에서 에어팟이 이렇게 쉽게 되는거보고 신기...

이래서 다들 애플생태계를 못나가는건가 싶다

 

그리고 M1의 신세계

iOS 앱 설치가 가능해서

네이버지도랑 인스타를 노트북으로 바로바로 켜서

할 수 있다!!

 

네이버지도를 어플로 탁탁

켜서 검색가능 한거 정말 편하단 말이지

즐겨찾기로 가도 되지만..

 

쿠팡이츠를 노트북으로 시킬 수 있다니

미친거 아니냐구!!!

 

뭐 작업하다가 아 배고파하고

타다다닥!!!

 

대표사진 삭제

사진 설명을 입력하세요.

윈도우가 필요할땐 이렇게!!

 

앞으로 열심히

써보자

작업용 메인노트북!!

 

320x100
반응형

원본내용  : https://www.deviqa.com/blog/20-software-quality-assurance-best-practices-for-2019/

 

=========================================================================

 

소프트웨어 품질 보증 QA 은 광범위한 범위이며 전체 프로세스는 소프트웨어, 응용 프로그램 또는 프로그램 개발의 전체 수명 주기에 걸쳐 발전해 왔습니다. 

다음은 품질 보증 테스터가 적용되어야 하는 2020년의 모범 사례 중 몇가지입니다

 

내용이 좀 길지만 다들 업무하면서 업무에 맞게 벤치마킹하여 QA, 테스트 활동에 도움이 되었으면

좋겠으며 QA = Test야! 라는 편견이 조금은 꺠지길 기대합니다. (사실 저도 처음엔..)

 

 

 

 

1. 품질 보증에는 위험인자 관리가 포함된다. 

 

대부분의 사람들은 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 및 개발 팀은 모든 문제를 해결하기 위해 이러한 버그를 함께 해결하고 운영해합니다.

관련 기사: 테스트를 중지해야 하는 경우

 

16. 개발 팀과의 긴밀한 협업

 

"DevOps 데브옵스"라는 용어가 있습니다 이는  민첩한 환경에서 개발 및 운영 팀의 긴밀한 협업을 의미합니다.

(위키백과 참고 ) 

팀이 어떤 방법을 사용하든 간에 협업은 모든 버그를 적시에 해결하는 데 도움이 되므로 중요합니다.

 

17. 최종 사용자 유저의 사용 환경과 방식을 고려해야 합니다

 

테스트는 품질 보증의 핵심 요소 중 하나이므로 Unit 테스트 및 우수한 개발 사례를 통해 제품을 올바르게 구축할 수 있습니다. 

QA 및  테스트도 설계가 기획되로 정상적으로 되었는지 확인합니다.

이는 시험관이 최종 사용자에게 좀 더 초점을 맞춘다는 것을 의미합니다

 

18. 100% 버그가 없는 제품은 불가능합니다!

 

앞서 언급했듯이, 어떤 소프트웨어도 완전한 오류가 없을 수는 없다는 없습니다. 테스팅의 원칙에도 나와있듯이

즉, 버그가 없으면 아무것도 실행되지 않으며 QA의 목표는 모든 버그를 완벽하게 테스트하고 모든 버그를 수정하는 것이 아니라 코딩 개발작업과 함께 활동하여 최악의 버그가 발생하지 않도록 하고 의도된 목적에 맞는 작동 가능한 제품만 출시하는 것입니다.

 

즉 이 제품이 잘만들어졌나 아니면 잘못만들어졌냐를 보증하는 것.

 

결함이 나오지않는다고 완벽한 소프트웨어라고 할 수 없습니다.

출처: 버그 프리 소프트웨어 같은 것이 있나요? 기사 

 

19. 블랙 박스 테스트 & 화이트 박스 테스트

품질 보증 QA에서는 블랙 박스 테스트는 기능이 계획대로 작동하는지 확인을 하는 과정이며

화이트 박스 테스트라고 하는 테스팅은 소프트웨어 코드를 올바르게 동작하는지 철저히 검토 하는 과정입니다

화이트 박스 테스트는 내부 구현과 무관하게 소프트웨어의 기능성을 검사하는 블랙 박스로 취급되는 블랙 박스 테스트와는

 반대로 프로그램의 내부 구조와 작동을 테스트한다. 또한 회색 박스 테스트도 있는데, 

이는 소프트웨어의 테스터가 이러한 알고리즘에 기초한 내부 데이터 구조 및 설계 테스트에 대한 지식을 가지고 있지만 

사용자 또는 블랙 박스 레벨에서 이러한 테스트를 실행하는 두 종류의 혼합물이다.

 

20. 소프트웨어 개발을 위한 가장 적합한 방법론 확인

또한 소프트웨어 개발에 사용되는 방법에 따라 품질을 개선의 목표에 달성할 수 있습니다. 

예를 들어 스크럼(scrum)에서는 이후의 모든 반복을 테스트합니다. 

소프트웨어의 각 부분을 개별적으로 테스트한 다음 반복 크기에 따라 전체 제품을 통합한 후에 테스트합니다. 

연못에 대해서는 모델링을 할 때 모든 것이 마지막에 테스트됩니다.

 

결론:

 

좋은 품질 보증  QA Testing 과정은 일반적인 다른 모든 프로세스와 별도로 특히 위험 인자 관리 프로세스를 

그 안에 포함하고 별도로 관리해야 합니다

소프트웨어 출시 전후에 지속적인 모니터링을 통해 비용을 절감하는 것을 목표로 하면서 비용절감의 최우선으로 이행되어야 합니다.

소프트웨어의 전반적인 품질을 개선하는 것이 초점이 되어야 한다. 

품질 보증 테스트를 수행하는 동안, 검사자는 최종 사용자의 관점에서 제품을 검토하는 것과 

더불어 모든 기본 원칙을 기반으로 SW 산업의 표준을 준수해야 합니다.

 

이상 논문같은 긴 번역문을 읽어주셔서 감사드립니다.

 

320x100

+ Recent posts