• 컴퓨터가 이해할 수 있는 언어로 바꾸어주는 과정을 말한다.
• 사용자가 작성한 소스코드 파일(. java)을 컴퓨터가 이해할 수 있는 기계어로 번역한다. (.class)

🖥 빌드 (Build)

• 컴파일된 코드를 실제 실행할 수 있는 상태로 만드는 일이다.
• 보통 컴파일을 포함한 배포하기 직전까지의 모든 과정을 ‘빌드한다’라고 표현하기도 한다.
• 컴파일은 빌드의 부분집합이다.

🖥 배포 (Deploy)

• 빌드가 완성된 실행 가능한 파일을 사용자가 접근할 수 있는 환경에 배치시키는 일이다.
• 실서버에 반영하는 것이다.

📝 Ref.site

https://choseongho93.tistory.com/296 https://bradbury.tistory.com/226 http://kko.to/-8y2KTar0z

소프트웨어를 실행해 결함으로 발생하는 장애를 찾아내기보다는 작업 산출물에서 직접 결함을 발견하는 것

✔️ 정적 블랙박스 테스트

• 소스코드를 보지 않고 프로그햄을 실행시키지 않는 검사 방식 주로 개발 명세서에 적힌 기준대로 제대로 구현되었는지 체크한다.

✔️ 정적 화이트박스 테스트

• 프로그램을 실행하지 않고 소프트웨어의 설계, 코드나 구조 등에서 상세하게 버그를 찾을 수 있는 방법 테스트 방법으로는 피어 리뷰, 워크 쓰루 등이 있다.

🤔 동적 테스트?

개발된 프로그램을 돌려보면서 테스트를 하는 방법이다. 직접 실행하면서 개발이 잘 되었는지, 특정한 상황에 대해 오류가 발생하지는 않는지 검사를 한다.

✔️ 동적 블랙박스 테스트

• 소스코드와 상관없이 실제 결과 값이 테스트 케이스 값과 같은지 판단한다. 모든 입력값이나 상황들을 조합해서 테스트를 할 수 없기 때문에 상황에 따라 ‘적당한’ 테스트 케이스를 설계하는 것이 필수적이다. 그 기법으로는 동등 분할(Equivalence partitioning), 경곗값 분석(Boundary condition), 실패를 위한 상태 테스트(반복, 스트레스, 부하) 등이 있다.

✔️ 동적 화이트박스 테스트

• 프로그램을 자동으로 돌려주는 스크립트를 작성해서, 소스코드를 확인하며 작동을 검사한다. 코드의 역할과 작동 방법을 관찰하여 테스트에서 배재할 대상이나, 중점적으로 보아야 할 영역, 테스트 접근 방법 등을 결정 소프트웨어를 제어하면서 직접 테스트를 진행한다.

📄 Reference Site https://kimgagakk.tistory.com/261 https://itholic.github.io/software_test/

ISTQB 란?

ISTQB 자격증 (ISTQB Certified Tester)은 비영리 국제 소프트웨어(SW) 테스팅 전문가 네트워크인 국제 SW 테스팅자격위원회 (ISTQB: International Software Testing Qualification Board)에서 주관하는 국제자격증 프로그램입니다. 출처 :https://www.sten.or.kr/bbs/board.php?bo_table=sten_ist

소프트웨어 테스팅 7가지 원리?

1.테스팅은 결함이 존재함을 밝히는 활동이지, 결함이 없음을 밝히는 활동이 아니다.

• 테스트의 목적 중 가장 큰 목적 중 하나는 이러한 제품 내 문제점이 잔존하지 않는지를 확인하고자 하기 위함이다.
• 결함이 전혀 발견되지 않는다고 해서 해당 소프트웨어에 결함이 없다고 증명할 수 없다.

2. 완벽한 테스팅은 불가능하다.

• 모든 가능성(입력과 사전 조건의 모든 조합)을 테스팅하는 것은 불가능하다.
• 현실적으로 테스트 하기 위해서는 리스크를 분석하고 우선순위에 집중하여 테스팅하는데 집중을 해야 함

3. 조기 테스팅으로 시간과 비용을 절약할 수 있다.

• 개발팀에서 프로그램을 다 만든 후 테스트 하는 것이 아닌, 요구사항 분석 및 개발 시작하는 단계에서부터 참여한다면 크리티컬 한 결함 및 수정 비용이 낮아질 것이다.

4. 결함은 집중된다.

• 결함은 소수의 특정 모듈에 집중되어 발생하고 고장을 초래하는 경향을 보임
• 일반적으로 새로 만드는 것, 다른 모듈과 상호작용이 많을 것에서 결함이 많이 나올 확률이 높다.

5. 살충제 패러독스

• 동일한 테스트(TC)로 검증을 하다보면 언젠간 그 방법에서는 결함을 발견할 수 없다.
• 그렇기 때문에 주기적인 테스트 문서 업데이트가 필요함

6. 테스트는 정황에 의존적이다.

• 대상에 따라 테스트 내용이 달라지는 것을 의미한다.

7. 오류-부재의 궤변

• 개발된 시스템이 사용자의 요구사항을 만족하지 못하거나 사용성이 낮다면 오류를 발견하고 제거하더라도 결코 품질이 높다고 말할 수 없다.

📝Reference Site

https://digital-play.tistory.com/34 https://softwaretestingreference.tistory.com/196 https://flina.tistory.com/1301

좋은 제품이란 어떤 제품일까? 기능만 동작한다면 잘 만든 좋은 제품일까? 결함이 발견되지 않는다면 좋은 제품일까? 혹은 결함이 발견된다고 해서 그 제품이 나쁜 제품일까? 필자는 추후에 이러한 애매(?)한 선택의 길에서 조금이나마 편하기 위해 아래 글을 쓰기로 했습니다.👨‍💻

소프트웨어 테스팅 7대 원칙 역시 추후에 작성 예정입니다! 

🌏 ISO 25010 품질특성

🔨 기능성

• 기능 성숙도 : 명시된 요구사항의 구현 정도
• 기능 정확도 : 정의된 정밀도에 따라 정확하게 결과를 제공하는 정도
• 기능 타당성 :사용자의 목적 달성에 소프트웨어가 도움을 주는 정도

⚙️ 효율성

• 시간 반응성 : 기능수행 시 응답처리 시간과 처리율이 요구사항을 충족 시키는 정도
• 요소 활용 : 기능 수행 시 사용되는 자원의 유형 및 양이 요구사항을 만족 시키는 정도
• 기억 용량 : 제품 혹은 시스템 파라미터의 한계가 요구사항을 만족시키는 정도

🖇 호환성

• 공존성 : 다른 소프트웨어에 해로운 영향을 주지 않고 환경 및 자원을 공유하면서 요구된 가능을 효과적으로 수행하는 정도
• 상호 운용성 : 둘 혹은 그 이상의 시스템, 제품 혹은 구성요소가 정보를 교환하거나 교환된 정보를 이상 없이 사용 할 수 있는 정도

✂️ 사용성

• 타당성 식별력 : 사용자의 요구에 적절한 기능인지 식별 할 수 있는 정도
• 학습성 : 사용자가 소프트웨어의 사용법을 배워 명시된 목적을 달성 할 수 있는 정도
• 운용성 : 제품 혹은 시스템의 작동 및 제어를 쉽게 할 수 있는 정도
• 사용자 오류 보호 : S/W 가 발생한 오류로부터 사용자를 보호하는 정도 ex) 버튼 비활성화, 알림 창 등
• 사용자 인터페이스 미학 : 사용자 인터페이스가 사용자에게 만족스러운 정도
• 접근성: 연령과 장애에 관계 없이 사용 할 수 있는 정도

🤍 신뢰성

• 성숙성 : S/W 구성요소가 표준적 환경에서 신뢰도 요구를 충족시키는 정도
• 가용성 : 사용자가 원하는 시간에 사용 및 접근이 가능한 정도
• 결점 완화 : H/W 혹은 S/W 에 결함이 존재하더라도 시스템, 제품 및 구성 요소가 이를 극복하고 의도한대로 동작하는 정도
• 회복 가능성 : 중단 및 실패 발생 시 제품 혹은 시스템이 데이터를 복구할 수 있는 정도

🔒 보안성

• 기밀성 : 제품 혹은 시스템이 반드시 권한이 있는 데이터에만 접근 가능하도록 하는 정도
• 무결성 : 시스템, 제품 혹은 구성요소가 컴퓨터 프로그램 혹은 데이터에 대해 무단으로 접근 혹은 변경되는 것을 방지하는 정도
• 부인 방지 : 사건 및 행위 후에 부인하지 못하도록 행동 및 사건에 대해 입증되는 정도
• 책임성 : 시스템 내의 각 개인을 유일하게 식별하여 언제 어떠한 행동을 하였는지 기록하여 필요 시 그 행위자를 추적할 수 있는 정도
• 인증성(진본성) : 사건 및 행동에 대해 행위자임을 증명 할 수 있는 정도

💵 유지보수성

• 모듈성 : 최소한의 영향을 가진 개별 구성요소로 구성된 정도
• 재사용성 : 자산이 하나 이상의 시스템에서 사용될 수 있거나, 다른 자산을 구추하는데 사용될 수 있는 정도
• 분석성 : 시스템 변화에 대해 어떠한 영향을 받는지 효과적이고 효율적으로 평가할 수 있는 정도
• 수정 가능성 : 제품 혹은 시스템이 장애 없이 효과적이고 효율적으로 수정 될 수 있는 정도
• 시험 가능성 : 제품 혹은 시스템에 대해 테스트 기준을 효과적, 효율적으로 수립할 수 있는 정도

📥 이식성

• 적용성 : 제품 혹은 시스템이 다른 H/W,S/W 혹은 기타 사용환경에 효과적이고 효율적으로 적용 될 수 있는 정도
• 설치성 : 제품 또는 시스템이 성공적으로 설치 및 제거될 수 있는 정도
• 대치성 : 제품이 동일한 화경에서 동일한 목적을 위해 다른 지정 S/W 제품으로 대치될 수 있는 정도

🗓 Reference Site

https://6987.tistory.com/entry/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%ED%92%88%EC%A7%88%EC%9D%98-%EC%A0%95%EC%9D%98-ISOIEC-25010-%ED%92%88%EC%A7%88%ED%8A%B9%EC%84%B1

개발 관련 업무를 하는 사람들이라면 애자일은 한번쯤은 들어봤을 것 이고 어느정도 뜻은 이해 하고 있을 것이다. 필자 역시 그 중 한명 🙋 이 글은 애자일을 전문적으로 이해하고 쓰는 글이 아닌 저의 개인 정리이니 양해 부탁드립니다!

⭕️ 애자일(Agile)??

: 사전적 의미로는 "날렵한", "민첩한", "기민한" 이라는 뜻을 가지고 있다.

• 짧은 주기의 개발단위를 반복하여 하나의 큰 프로젝트를 완성해 나가는 방식이다.
• 즉각적인 피드백 그리고 협력을 중요시 한다.

애자일 자체는 방법론을 가리키는 말은 아니라고 한다. 
애자일 의미(?) 를 담고 있는 프로세스들을 애자일 방법론에 속한다고 함

애자일(Agile) 이 중요시 하는 4대 가치

1. 공정과 도구보다 "개인과 상호작용" 을

• 커뮤니케이션이 원활하지 않다면 프로젝트가 성공할 확률이 낮다

  2. 포괄적인 문서보다 "작동하는 소프트웨어" 를

• 프로젝트 산출물 등 문서들도 중요하지만 작동하는 소프트웨어가 더 중요하다. 

  3. 계약 협상보다 “고객과의 협력” 을

• 개발팀 입장에서 막바지에 요구사항 변경이 발생하더라도 환영해야 하고 처음부터 꾸준한 협력을 통해 이러한 일이 발생하지 않도록 노력해야 한다.

4. 계획을 따르기보다 "변화에 대응하기" 를

• 프로젝트가 초기에 계획한대로 흘러가지 않기 때문에 계획에 얽매이지 않고 변화에 적절히 대응하면서 나아간다. 

출처: https://life-with-coding.tistory.com/424 [코딩젤리:티스토리]

애자일(Agile) 장점? 단점?

장점

• 점진적 테스트로 버그를 보다 쉽고 빠르게 발견 할 수 있다.
• 계획 또는 기능 수정과 변경에 유연하다.

단점

• 빠르고, 신속하게 개발을 하다 보니 체계화된 문서가 적거나 없을 수 있다.
• 확정되지 않은 계획 및 요구사항으로 인한 반복적인 유지보수 작업이 많다.

항상 애자일을 주제로 이야기를 하면 빠질 수 없는 단어가 있다. 바로 워터폴(Waterfall) 이다.

🌊워터폴(Waterfall) ?

:폭포에서 물이 떨어지는 것처럼 위에서 아래 단계로 순차적으로 각 단계가 진행되게 된다.

• 각 단계가 뚜렷하게 나누어져 있다.
• 이전 단계가 완료된 후에만 다음 단계로 넘어가는 특징이 있다.

워터폴(Waterfall)에 관해서는 따로 정리를 해보겠습니다. (_ _ )

개인적인 의견 📝

아직까지 필자가 경험해본 결과 주변에서 10명중 8명은 "애자일이 옳고 워터폴은 글렀어!" 라는 의견들을 많이 접할 수 있다. 하지만 과연 애자일 = 정답 이고 워터폴 = 오답 일까? 아직 필자의 입장에서는 기준을 내리는 것 조차 어렵고 설령 내린다고 해도 저게 답은 아닐 것이다. 뭐든 그렇겠지만 "얼마나 제대로 사용하고 또 얼마나 적절하게 사용하는지에 따라 달라질 것이다.

Reference Site🗓

https://velog.io/@katanazero86/애자일agile이란-무엇인가 https://blog.daum.net/dbdb/478 https://sundappled.tistory.com/16 http://www.incodom.kr/애자일_방법론

업무에 있어 개발자, 기획자 분들과 그리고 QA 동료분들과 이야기를 하다 보면 자연스레 개발 용어들이 나오기 마련이다. 대단한 커뮤니케이션을 위해서가 아닌 그래도 이야기를 듣고 고개를 끄덕거릴 수라도 있게 나름 정리를 해보려 한다.😄

서버 와 클라이언트

클라이언트

: 네트워크를 통해 서버에게 정보를 제공받는 응용 프로그램이다.

서버

: 서비스를 제공하는 소프트웨어가 실행되는 컴퓨터를 서버라고 한다.

프론트엔드(FE)

• 웹/앱 등에서 사용자에게 보이는 부분에 대한 UI를 뜻함

백엔드(BE)

• 브라우저가 주고받는 데이터를 기록하고 가져오는 등의 뒷 단의 일을 처리하는 기술들을 뜻함

디버그

• 프로그래밍 과정중에 발생하는 오류나 비정상적인 연산, 즉 버그를 찾고 수정하는 것이다. 이 과정을 디버깅(Debugging)이라 하기도 한다.

컴파일

• 개발자가 작성한 소스코드를 바이너리 코드로 변환하는 과정을 말한다.

빌드

• 컴파일된 코드를 실제 실행할 수 있는 상태로 만드는 일을 뜻한다.
• 빌드에서는 컴파일, 테스트, 배포 등 과정이 포함될 수 있고, 빌드 과정을 도와주는 도구를 빌드 툴이라고 한다.

배포

• 빌드가 완성된 실행 가능한 파일을 사용자가 접근할 수 있는 환경에 배치시키는 일

AS-IS / TO-BE

• AS-IS 는 개선 되기 전 상태를 뜻하고 TO-BE 는 개선 된 후 상태를 뜻한다.

Reference Site 📗

https://reinvite.tistory.com/84 https://velog.io/@jennyfromdeblock/클라이언트와-서버-빠르게-개념잡기 https://freezboi.tistory.com/39 https://choseongho93.tistory.com/296 https://www.sindohblog.com/2181

이 글은 API의 전문적인 이해가 아닌 제가 업무에 있어 필요로 하는 기초 지식을 정리하기 위해 쓰는 글입니다. 추가적으로 공유해주실 자료들이 있다면 언제든지 환영입니다. 🙋

API 란?

Application Programming Interface 의 줄임말 이다. 비유를 해보자면 대표적으로 음식점으로 비유하는 경우가 있다😋

위 사진처럼 API는 손님(프로그램) 의 요청사항을 요리사(응용프로그램) 에게 올바르게 전달하여 원하는 메뉴가 나올 수 있도록 도와주는 점원(API) 이라고 생각하면 된다. 쉽게 말해, API는 프로그램들이 서로 상호작용하는 것을 도와주는 매개체로 볼 수 있다.

API의 역할은??

• 서버와 데이터베이스에 대한 출입구 역할을 한다.
• 애플리케이션과 기기가 원활하게 통신할 수 있도록 한다.
• 모든 접속을 표준화하기 때문에 기계/ 운영체제 등과 상관없이 누구나 동일한 액세스를 얻을 수 있다.

API의 유형?

• Public API : 개방형 API로 누구나 제한 없이 API를 사용할 수 있다.

• Private API : 회사 개발자가 자체 제품과 서비스를 개선하기 위해 내부적으로 사용하는 용도 3자에게 노출되지 않는다.

• Partner API : 기업이 데이터 공유에 동의하는 특정인들만 사용 할 수 있다. 비즈니스 관계에서 사용되는 편이며, 종종 파트너 회사 간에 소프트웨어를 통합하기 위해 사용된다.

API 의 유형은 아키텍처와 사용 범위에 따라 분류된다.

마지막으로

다음에는 REST API 에 대해 정리를 해보려 합니다. 공유해주실 자료가 있다면 부탁드립니다! 🙏

📋 Reference Stie

https://aws.amazon.com/ko/what-is/api/ https://brunch.co.kr/@hyoi0303/25 https://ittrue.tistory.com/31 https://blog.wishket.com/api https://brunch.co.kr/@operator/65

테스트 업무를 진행하다 보면 굉장히 헷갈리는 부분들이 있다. 예를들자면 Smoke Test 와 Sanity Test 이다. 뭔가 각각의 뜻은 알 듯 하면서도 정리가 안된 느낌이다... 구글링을 통해 내가 이해 한 부분들을 기록하려 한다. (언제나 피드백은 감사합니다! 🙇)

🌫 Smoke Test

이 테스트의 유래는 전자 회로 기판에 전원을 넣었을 때 기판에서 연기가 나는지 확인하는 테스트 에서 유래 했다고 한다. 다른 말로는 *BVT (Build Verification Testing) * 라고 부르기도 한다.

정리하자면 이렇다.

• 테스트에 앞서서 프로그램의 중요한 기능이 잘 작동하는지 확인하기 위해 소프트웨어 빌드 후에 수행되는 소프트웨어 테스팅이다.
• 가장 기본적인 부분을 테스트 한다.
• 해당 빌드가 더 이상 리소스를 투입해서 테스트를 할 가치가 있는 빌드인지 판단하고 개발팀에 피드백을 주기 위한 목적이다.

✔️ Sanity Test

위 테스트는 새로운 S/W 빌드가 주요 테스팅 업무를 수행하기에 충분히 적합한가를 판단하기 위해 수행하는 테스트 이다.

정리하자면 이렇다.

• Regression Test(회귀 테스트) 의 하위집합이다.
• 새로 추가된 기능, 수정된 버그를 중점으로 두어 테스트 한다.

+ Regression Test (회귀 테스트) 란?

: 이미 테스트된 프로그램의 테스팅을 반복하는 것으로, 결함 수정 이후 변경의 결과로 새롭게 만들어 지거나, 이전 결함으로 인해 발견되지 않았던 또 다른 결함을 발견하는 테스트이다.

📗 Regression Test 에 대한 개인적인 생각

평소의 대화에서도 자연스레 "애자일하다" 라는 말을 사용 할 정도로 빠르고 점진적인 개발이 자리잡다보니 회귀테스트의 범위는 날이 갈수록 많아질 것이다. 개발 초창기에는 동적인 회귀테스트를 진행한다면 큰 무리 없이 진행하겠지만, 시간이 흐르고 제품의 기능들이 추가된다면 해당 테스트에는 결국 수많은 리소스를 투입해야 할 것이다. 그러므로 이런 부분들을 최대한 효율적으로 해결하기 위한 방법은 회귀테스트의 자동화가 필수적이라고 생각한다.

📑 Reference Site

https://www.guru99.com/smoke-sanity-testing.html https://www.sten.or.kr/bbs/board.php?bo_table=test_story&wr_id=9563 http://www.jidum.com/jidums/view.do?jidumId=612 https://sambalim.tistory.com/139

처음 QA 직군으로 입사하여 업무를 시작하고 (단순 테스트업무지만..) 사수 및 업무 교육때 중점적으로 이야기 하는 단어가 블랙박스 테스팅 이었다. 당시에는 그냥 "기대결과만 보고 테스트하는게 블랙박스 테스팅이구나" 정도로만 이해 했지만 이제는 그렇게 이해 하면 안되겠다 생각하여 나름의 정리를 하려 한다.👨🏻‍💻

Blackbox Test

** 소프트웨어의 내부 구조나 작동 원리를 모르는 상태에서 동작을 검사하는 방식** "제대로 동작하는지 확인하는 것." 사용자 관점에서의 테스트이다.

대표적인 블랙박스 테스트 설계기법

• *동등 분할 * : 입력데이터를 동일한 동작이 예상되는 동등 클래스로 분할하고, 각 클래스로부터 대표 값을 선택하여 테스트 하는 기법

• *경계값 분석 * : 입력 조건의 중간 값보다 경계 값에서 에러가 발생 될 확률이 높다는 점을 이용하여 테스트 하는 기법

• *오류예측 기법 * : 각 시험기법들이 놓치기 쉬운 오류들을 감각 및 경험으로 찾아보는 기법

** 위 기법들 외 다른 기법들도 존재함 (본인 기준 대표적인 리스트)**

개인적인 생각

QA 직군에서 제일 기초적이자 먼저 배우고 잘 알아야 하는 기법이라고 생각한다. 하지만 이 명세기반 기법을 기본으로 테스트를 하는 일이 많기때문이라고 생각한다. 하지만 무엇보다 원활하고 효과적인 블랙박스 테스트를 하기 위한다면 먼저 해당 업무 도메인, 검증 제품의 (S/W H/W) 에 대한 기본적인 스펙을 알고 이해해야 한다고 생각한다. 그렇게 된다면 위에서 설명한 기법들을 잘 활용하여 품질 향상을 기대 할 수 있다.

📋 Reference Site

http://www.jidum.com/jidums/view.do?jidumId=588 https://www.crocus.co.kr/1681 https://catsbi.oopy.io/7c084479-c9d0-44a1-acb9-f6b43a19e332 https://devinus.tistory.com/6 https://inpa.tistory.com

이 글은 저의 주관적인 입장이고 기록입니다. 다른 or 틀린 내용들의 피드백은 언제나 감사합니다!

QA가 뭐야?

QA 란 'Quality Assurance' : '품질보증' 이라고 이야기 한다. 솔직히 주변에서 "넌 무슨일 해?" 라고 물을때가 나는 굉장히 난처하다. "QA 라고 제품을 개발 할 때 문제없이 제품이 출시 될 수 있도록 도움을 주는 업무야" 라며 나름대로 상대방이 이해 할 수 있게 풀어서 대답하지만 10명중 5명 이상은 "아~ 테스트 하는 업무구나!" 라는 답이 돌아온다. 솔직히 말하자면 나는 아직 이제 갓 시작한 주니어 QA, 아니 TE라고 정의하는게 맞다. 하지만 스스로 QA라는 직무를 알아가고 공부하며 느낀 바로는 QA 는 테스터가 아니라고 생각한다. QA라는 직군 안에 테스트 업무가 있고 중요시 하지만 "QA 는 테스터야" 라고 정의 할 수 없다. 그렇게 나의 정의를 증명하고 기록하기 위해 이 블로그를 시작하고 성장하려 한다. 물론 지금은 업무적, 이론적 지식들이 부족해 정확한 정의를 내릴 순 없지만 이 안에서 내 나름대로 느낀점을 기록하는 글이라 생각하고 봐주었으면 한다. (지극히 주관적인 의견이 많이 반영 될 듯..ㅎ)

좋은 QA가 되기 위해서는?

내가 생각하기에 좋은(?), 업계에서 선호하는 QA가 되기 위해서는 내 기준 가장 중요시 하는 스킬 중 한가지를 뽑자면 아무래도 '간결한 팩트전달 '이라 생각한다. 직군 특성상 혼자만 일을 하는게 아닌 원활한 커뮤니케이션이 이루어져야 하기 때문에 간결하고 정확한 의미 전달이 중요하다고 생각한다. 이런 능력을 뒷받침하기 위해서는 결국에는 업무적인 지식의 스펙트럼을 넓혀야 한다. 기획, 개발, 디자인 분야에서의 최소한의 업무 지식이 있어야 비로소 QA 업무 요구사항을 충족한다고 생각한다.

(물론 기본적으로 테스팅 관련 지식도 보유해야 한다 ..^^)

내가 바라는 QA 는?

주니어 QA(TE) 의 입장으로 개인적인 바램은 현재 QA 직군의 진입장벽이 낮다. (나 역시 낮은 진입장벽으로 해당 직무를 접했음) 이런 낮은 진입장벽때문에 QA = 테스터 라는 공식이 생겨난 것 같기도 하다. 여기서 우리가 노력해야 하는 것들은 분명히 존재한다. 우리 스스로 직군의 퀄리티를 높이기 위해 노력을 해야 한다는 점이다. QA 답게, QA스럽게 일하기 위해선 테스트를 탈피해야 한다고 생각한다. 테스트를 하지 않는게 아닌 품질개선에 집중하기 위해 테스트에 들어가는 리소스를 줄여야 한다는 뜻이다. 그렇게 하기 위해선 테스트의 자동화가 가장 필요하다고 생각한다. 그렇게 한 걸음 씩 테스트를 자동화화 하고 그로인해 병렬적으로 테스트 하게 된다면 제품의 퀄리티 그리고 QA직군의 퀄리티는 자연스레 올라가고 단순 테스터라는 정의도 사라질 것이라 믿는다.

이 글에서는 블로그를 시작하기 전 개인적인 생각(?) 을 작성 한 글입니다 . ( _ _)