깍돌이

안녕하세요 깍돌이입니다. 오늘은 되게 오랜만에 작성을 하게되네요

기술 포스팅은 아니고 QA를 일하면서 항상 재밌지만 매번 힘든 경우가 있게 되는데요 마음을 다시 잡기 위해서

도 있고 해당 고찰 시리즈(?) 를 작성 하고 몇달뒤에 나는 얼마나 후회했던 점을 많이 수정하고 보완하였는지

판단하고 싶어졌습니다.      

다시 한번 인사드립니다. 안녕하세요 이제 5년차 Software QA 로 일을하고 있는 깍돌이 입니다. 

벌써 올해 5년차가 되었지만 아직도 제 자신이 보기에 부끄러울정도로 부족함이 보입니다.  

6년차 부터는 고연차라고 생각 하고 자기 자신을 다져서 튼튼하게 만들어야 될 것 같습니다.

버그 & 이슈 

QA로 일하면서 즐거운(?) 점도 버그 이지만 완전 정 반대로 힘들어지는 경우도 버그 입니다.(저는 그렇습니다.)

이슈를 찾아서 개발자에게 전달 할 때 가 즐거운 게 아니라 다른 분들이 생각하지 못한 이슈를 찾아 낼 때가 그렇습니다.

이러다 보니 모든 케이스를 열린마인드로 바라보는 것도 좋은 거 같습니다.  그래서 TC를 안쓰고 테스트하는 Ad hoc testing(애드훅) 테스트의 경우에 TC에서는 나오지않던 이슈들이 도출되기도 합니다.

QA가 하는 여러 활동 중 에는 많은 사람들이 대표적으로 알고 있는 테스트 활동이 있습니다.  간단하지만 간단하지 않은 활동이죠 해당 활동들을 간단하게 하지 않기 위함과 그로 인하여 제품의 품질을 높이기 위한 추가 활동들이 수 없이 있습니다.   

Test Case

개인적으로 QA의 자산이라고 생각하며 Test Case가 탄탄해야 제품의 품질 을 끌어올릴수 있다고 생각합니다.

철없을 시절에는 1건이라도 자동화가 우선이지! 라는 착각을 했지만  탄탄한 Test Case가 없다면 자동화도 무의미 합니다. 제대로된 자동화를 하기 위해선 많은 공수가 들기도 하는데 Test Case가 물렁 거린다면 그 이후에 작업들도 다 무용지물이 되는건 한순간입니다.

TestCase는 매우 꼼꼼하게 작성합니다. 말 그대로 자산이고 또 다른 QA (담당하지않은) 가 왔을 때 확인하는 시간은 좀 걸리겠지만 제품에 대한 이해가 조금 부족해도 수행 할수 있도록 작성되어야 합니다.  개발자들 을 예로 들면 주석이 꼼꼼하게 달려 있는거랑 비슷하겠네요

TC가 빈틈없이 작성되어있다면? 물론 빈틈없이 모든 케이스를 작성해서 배포시간내에 테스트가 가능하다면 이보다 더 좋을순 없습니다.  하지만 모든 케이스를 다 넣게 되면 TC의 거대화가 진행되면서 필요없는 TC활동이 생기게 되며 이는 비효율적입니다.  또한 배포의 형태에 따라 TC를 매번 Regression Test (회귀 테스트) 를 진행할수는 없는 노릇입니다. 

QA도 Release Plan (배포계획) 에 따라서 Test Plan ( 테스트 계획 ) 을 작성하는데 이 또한 근거가 되는 것은 Test Case 입니다.  그래서 특정 여러 배포에 따라서 Check List라는 형태로 간소화하여 Major 기능들 위주로 확인할 수 있습니다.

Check List 

매번 Regression Test (회귀 테스트 ) 를 돌릴수 없기 때문에 기본적으로는 Release Plan 에 따른 Test Plan 을 짜야 하지만 때로는 Check List 로 작성하여서 최소한의 리스크로 확인 하는 경우도 있습니다. 해당 제품에 대한 메이저 기능들 (절대로 안되선 안되는 ) 이죠 물론 케이스가 조금 응용됐을 때도 안되는 케이스도 어느정도 고려를 해야합니다. 

개인적으로는 Test Case를 작성하고 -> Check List 형태로 간소화하여 사용하기도 합니다.

반대로 Check List로 만든 후에 Test Case 로 정밀화 하기도 합니다.

고찰

버그에 대한 고찰을 이야기하다가 여기까지 왔었네요. 정기 릴리즈 시기가 와서 배포 대기를 하고 있었습니다.

왠지 모르게 이번 배포는 자꾸 2%가 찜찜 하더군요 

배포 중에 하드한 이슈들도 찾고 잘 처리하여 마무리 를 하였습니다. 하지만 배포후에 이슈가 생겼고 

해당 이슈는 QA를 거친 제품에 대한 이슈였습니다.

아주 특이한 케이스였으면 "와 이런 케이스도 있을 수 있구나"  싶었지만 "특별" 하지만 "특이" 한 이슈는 아니였습니다.

다른 분들은 어떨지 모르겠지만 저는 해당과 같은 상황이 닥쳤을 때가 가장 QA하면서 힘든 상황이였습니다.

어떠한 면에서는 현실이 아니길 기도하기도 했습니다. 하지만 이슈가 발생했던건 현실이였죠.. 

어떤 분들은 "자동화를 해라" 라는 부분에서 스트레스를 받지만 저는 공부하면서 자동화하고 자신의 기술 습득의 향상이 되는 부분이라 하는 만큼 결과도 보여지고 매우 좋아하는 요구사항입니다.

하지만 위와 같이 배포 후 이슈가 1건이라도 발생했을 경우 ( 자잘한 이슈가 아닌 사용성 문제가 있는 ) 에는 QA로써의 책임감에 따라서 정신적으로 많이 힘들었던 기억이 있습니다. 물론 최근에도 비슷한 경험을 하고 멘탈이 조금 씩 나가지만 소 잃고 외양간 고치라는 말처럼 그러다보니 최소한 2번은 절대 발생하지 않겠다 는 생각으로 발생했던 이슈들은 전부 체크리스트에 넣고 시간이 오래걸려도 해당 부분은 추후에 볼수 진행하면서 구멍을 메꾸려고합니다. 

QA는 자기 제품 혹은 자기가 맡은 모듈에 따라서 책임감을 어느정도 가지고 있어야 한다고 생각하고 있습니다.

개발은 개발팀에서 하겠지만 결국 제대로된 상품이 되기위한 Flow 중 QA라는 Flow도 있고 밀접한 관계로 일을하기 때문에 일을하면서 내가 이 제품의 담당자이며 관련자다 라는 책임을 가지고 이슈없는 배포 깔끔한 배포가 이루어질수 있도록 더욱 노력해야 할 것입니다.

ICST(International Conference on Software Testing Verification and Validation) 2010 발표

구글의 개발 단계별 결함 수정에 들어간 비용 에 대해서 작성한 자료를 보면

개발자가 테스트 주도 개발(Test Driven Development, TDD) 과정에서 결함을 발견시 5달러의 비용을 줄일수 있지만 QA단계인 시스템 테스트 과정에서 발생한 결함의 경우 5,000달러의 품질 비용을 줄일수 있다는 것 

이런것을 보면 적용시기가 문제이지 품질에 시스템을 적용하는건 비용의 문제가 아님을 보여주는 계기가 된다.

잔존 결함 밀도, 코딩표준 준수율, 코드 리뷰 수행률, 중복 코드, 코드 복잡도 

feat. NHN 은 이렇게 한다 !  소프트웨어 품질관리 

자바! 자바! 이클립스라는 IDE자체에 별 생각이 없었기에 자바를 굳이 시작하진 않았습니다. 

(Node.js 로 웬만한건 다 구현이 됐었고 심지어 자동화도 *Node.js에서 *selenium도 메이저 버전이고 아주 급격하게 성장하고있는 퍼펫티어도 Node.js기반입니다.)

새로운 프레임워크 (Integrated Automation Framework) - Fitnesse

이번에 새로 들어온 회사에서 통합 테스트 프레임워크인 Fitnesse 라는것을 만나게 되었는데

정말 자동화에 대한 아이디어가 샘솟는 프레임워크 였습니다.

(출처 : http://www.nextree.co.kr/p2613/)  여기서 QA(저희)는 QA담당자와 개발자 둘다 포함하고 있습니다.

나중에는 도커로 묶던 어플리케이션 형태로 만들어서 쓰면 될거 같기도 하고

- 테스트코드에 대해서 백엔드에 작업을 해놓고 프론트 앤드 화면에선 파라미터 값을 입력 하면

  백엔드에서는 set이라는 모듈을 통해 파라미터에 따른 함수 실행을 하는 형태 

(하나의 test set 에 이용자가 정하는 여러가지 케이스에 대해 테스트를 하고 History 까지 남길수 있습니다.)

Node.js와 연동에 대해서 조금 찾아 보았으나 해당 fitnesse에 대한 자료도 많진 않았고 연동자료들이 있긴하였으나

조금 억지스러운 연동들이 많았습니다. ( fitxutre를 파싱하여 쓰는 형태다보니 node에서도 어거지로 맞추면 돌아는 가는형태이지만 이걸 억지로 하는건 기존 저희 팀에 개발된 프로젝트와도 삐걱댈수 있기 때문에 정말 필요한 형태가 아니라면 지양 하고자 했습니다.)

그리고 IT인으로 살아가는데 잘하는 언어가 html css, js ts(js수퍼셋) 이라면 뭔가 아쉬울거 같았습니다. (물론 저는 js를 좋아합니다.)

학부생을 나오면서 C , C++ , pyhton 맛은 봤지만 어디가서 뭐 이거로 뭐 할수 있습니다. 수준은 아니였기 때문에 한가지를 더 하고 싶었던 생각이 있었습니다. 업무에 적용해서 하면 훨씬 빠르게 성장할수 있었기 때문입니다.

그래고 매년 코테를 재미삼아 C,C++ 로 했었는데 이제는 이것도 그만하려고 합니다. 심지어 작년엔 nhn 에도 붙었었지만 지원이력만 남는게 썩 좋지는 않은거같아서  추가적인 언어에 대한 갈망이 있던 찰나에 Fitnesse를 만났고

JAVA를 선택하게 되었습니다. 

Fitnesse의 메인 언어는 자바입니다.  자바와는 거리가 먼 커리어였기에 이번에 자바의 정석을 통하여

기본기를 좀 다지고  멋진 Fitnesse 적용기가 되려고 합니다. 

우선 자바의 히스토리 뭐 이런건 책에 있으니 넘어가고 JDK 를 일단 설치 하여야 합니다.

오라클 JDK는 유료화 선언이 되었기에 openJDK 를 설치 하도록 합시다.

단순히 openjdk 라고 검색하게되면 리눅스 계열 설치는 많이 나오기 때문에 저는 윈도우즈에서 openjdk 를 설치하고

진행 해보려고합니다.( 나중에 꼭 MAC을 사서 MAC에서 하는 그날을... )

http://jdk.java.net/archive/

openjdk 링크입니다.

* 참고로 LTS버전(안정화 버전)은 1.8버전이고 그다음 LTS버전은 18.9버전입니다. 

JAVA 8 - LTS 

JAVA 18 - LTS ( 예정 )

저는 공부용이니 JAVA 10 을 쓰겠지만 프로덕션은 8이 맞습니다.

GA Date : Oracle 자바의 출시일을 뜻합니다.

저는 10.0.2 (build 10.0.2+13) 로 설치 하도록 하겠습니다.

해당 압축을 푼 후 jdk-10.0.2 폴더를 이동 하도록 하겠습니다.

해당 위치에 openjdk 라는 폴더를 만든 후 위에 압축을 풀어 이동합니다.

내 컴퓨터 우클릭 - 속성 - 고급 시스템 설정 - 고급 탭 - 환경 변수 

앞에서 지정하였던 폴더 경로를 복사후 

새 시스템 변수로 등록 합니다.

확인 후에 

Path 선택 후 편집 을 이동하여 아까 지정한 JAVA_HOME 변수를 사용한다.

아래와같이 %JAVA_HOME%\bin 을 입력 후 확인 

후 종료

윈도우 로고 + R => cmd 입력 

java --version 과

javac --version 을 입력합니다.

정상적으로 openjdk 설치를 확인하였습니다.

여기서 마지막으로 java와 javac를 입력 하였는데요

기본적인 설명만 적어놓고 다음 시간으로 넘어 가도록 하겠습니다.

javac  - 자바 컴파일러 로 자바 소스코드 (.java) 를 바이트코드로 컴파일합니다. (.class)

    -> javac Hello.java

java - 자바 인터 프리터 로 컴파일러가 생성한 바이트코드 (.class)를 해석하고 실행합니다.

    -> java Hello 

javap - 자바 역 어셈블러로 컴파일된 클래스파일(.class)을 원래의 소스로 변환합니다. (java) 

    -> javap Hello > Hello.java

만약에 같은 프로젝트에 쉘로  build.sh 를 만들어서 빌드한다고 하면 (IDE 없이)

#!/bin/sh

javac Hello.java 
# javac Hello.java -encoding=UTF-8    Encoding Settings
java Hello

이런 형태가 될것 같습니다.

만약에 작성된 에디터와 인코딩이 맞지 않는 다면 빌드시에 -encoding을 사용하여서 맞춰줄수 있습니다. 

javadoc - 자동문서 생성기로 소스파일에 있는 주석 /** */을 이용하여 JAVA API 문서와 같은 형식의 문서를 자동으로 생성합니다.

jar - 압축 프로그램 클래스 파일과 프로그램의 실행에 관련된 파일을 하나의 jar 파일(.jar)로 압축하거나 압축해제합니다.

JDK ( Java Development Kit ) 자바 개발도구

JRE  ( Java Runtime Environment ) 자바 프로그램이 실행하기 위한 최소환경

JRE는 JDK 안에 포함되어 있으며 JDK 가 더 큰 영역입니다. 

javac는 JDK 안에 있습니다.

여기까지 자바를 시작하기 위한 기본 준비가 되었습니다. 얼른 자바에 기본을 다지고 통합 테스트 자동화까지

해보도록 합시다.