여러분들께 조금이나 간단하게 마이리얼트립 제품 기획실 구성원을 소개 드리고 싶어서 구성원을 야구 포지션에 비유해 보겠습니다.

팀을 진두지휘하는 감독(PM), 감독을 보좌하며 전술을 구상하는 수석코치(Designer), 가장 먼저 상대 타자를 맞이하는 선발 투수(Front-End Dev & Mobile Dev), 선발 투수 다음으로 마운드에 등판하는 중간 계투(Back-End Dev), 경기를 마무리 짓기 위해 마지막으로 등판하는 마무리 투수(QA)가 있습니다.

네, 그렇습니다. 이번 이야기는 마이리얼트립에서 마무리 투수를 맡고 있는 ‘QA’ 이야기를 해보려 합니다.








Speed or Perfection

시작부터 뜬금없지만 여러분의 시간은 소중하니 지루한 소개는 생략할게요. 우선 마이리얼트립은 무슨 일이든 빠르게 시도하는 것을 지향합니다. 고민보다는 빠르게 실행하고 빠른 시도를 통해 다양한 성공과 실패를 경험하자는 뜻이 담겨있죠. QA 관점으로 실패(버그로 인한 사용자 경험 저해)는 고객중심 서비스에서 전혀 가치 있는 일이 아닙니다. 하지만 우리는 안타깝게도 매번 ‘완벽하진 않지만 빠르게?’ or ‘빠르진 않지만 완벽하게?’를 선택해야 하는 상황에 놓이곤 합니다. 예시를 한번 들어보겠습니다.


“코드 한 줄 수정했어요. 수정한 부분만 확인하고 바로 내보내시죠.”

회사 매출과 직결된 이슈이기 때문에 긴급하게 서비스 배포가 진행되어야 하는 상황입니다. 저도 다급한 상황임을 인지하고 있습니다만.. 수정된 부분만 확인하고 배포하기엔 자꾸만 Side-Effect 발생이 마음에 걸립니다. 우선 Side-Effect에 대해 말씀드리기 전 레거시 코드에 대해 간단하게나마 알아볼 필요가 있습니다.

레거시 코드란 유산이라는 뜻을 가진 Legacy와 Code가 합쳐진 합성어로 타인이 작성해 놓은 오래된 개발 코드로 이해하시면 편합니다. 오랜 시간을 거쳐 서비스가 성장하는 과정 속 개발 코드 또한 점점 방대해져 갑니다. 시간이 지나 퇴사자들이 생겨나면서 자연스럽게 퇴사자들이 작성했던 개발 코드, 즉 레거시 코드가 생겨납니다. 

이러한 레거시 코드는 작성자 이외에 다른 사람이 개발 의도를 파악하기 쉽지 않기 때문에, 레거시 코드를 지우거나 수정했을 때 프로그램에 어떠한 영향을 미칠지는 그 누구도 확신할 수 없게 됩니다. 그렇게 아무 곳에도 쓰이지 않을 법한 A 코드를 삭제했더니 숨어있던 B 코드에서 남모르게 A 코드를 사용하고 있는 상황이 발생하면서 오류가 발생합니다.








Regression Test를 통한 테스트 커버리지 확보

속도감 있게 서비스 배포를 진행하고자 한다면 보다 안정적인 서비스를 제공하기 위한 안전장치가 필요합니다. 우리는 Regression Test(회귀 테스트) 기법을 통해 빠르게 배포되는 일정 속 최대한의 테스트 커버리지를 확보활 수 있습니다.

Regression Test란 개발자가 수정한 소스 코드가 다른 부분에 영향을 미치지 않는지 테스트하여 소스 코드의 수정이 또 다른 오류를 발생시키지 않도록 검증하는 테스트 기법입니다. 또한 Test Case의 분량이 30분~1시간 내외이기 때문에 테스트에 소요되는 시간도 매우 짧은 편입니다. 검증 마지막 단계에서 Regression Test까지 진행한다면 배포되는 서비스의 Side-Effect 이슈에 대한 갈증을 해소할 수 있을 겁니다.


검증 방식에 정답은 없습니다. 수많은 테스트 기법이 존재하듯이 다양한 테스트 기법을 활용해 사용자들이 더욱 건강한 서비스를 사용할 수 있도록 노력하는 것만큼 가치 있는 일이 있을까요?










테스트 자동화를 통한 리소스 확보

어느 곳이든 소규모 QA는 항상 바쁩니다. 개발팀의 경우 각 파트마다 담당하는 플랫폼이 분산되어 있기 때문에 각자가 맡은 작업에만 집중하면 됩니다. 그러나 이 모든 작업들이 끝이 나면 산발적으로 QA에게 넘어오게 되죠. (이곳은 마치 옥천 hub..?) 적은 인원으로 업무를 골고루 분배하기 위해선 리소스 관리는 필수입니다. 


Regression Test는 서비스 검증의 마지막 단계에서 진행되어야 하는 고정적이고 반복적인 업무입니다. 아무리 30분~1시간 분량의 빠르게 진행되는 테스트라고 해도 서비스 배포가 다수의 플랫폼에서 동시에 진행되어야 한다면? 검증이 필요한 플랫폼마다 여러 차례 Regression Test를 수행한다고 가정했을 때 하루에 주어진 업무 시간의 거의 절반을 차지하게 됩니다. Regression Test는 분명 테스트 커버리지를 높여주고 속도감 있는 배포를 위한 테스트인데, 이런.. 양날의 검이 되어버렸습니다. 이때 등장해야 하는 것이 바로 테스트 자동화입니다.

테스트 자동화란 무엇일까요? 이름만 들어보면 ‘자동화’라는 단어 때문에 기계 혼자서 알아서 짠! 하고 테스트하는 것처럼 들리는데요. 기본적으로 테스트 자동화는 테스트 커버리지를 높여주는 목적으로 사용됩니다. 그 밖에도 사람이 수행하는 단순하고 반복적인 QA 업무를 소프트웨어의 도움을 받아 일관성 있는 테스트를 도와주는 테스트용 소프트웨어입니다. 그렇기 때문에 사람이 직접 테스트 코드를 작성하여 프로그램이 대신 테스트를 수행하는 것으로 이해하시면 됩니다.

이제 저희도 개발의 힘을 빌려봅시다. 혹시라도 프로그래밍 언어를 다뤄야 한다고 해서 겁먹을 필요는 없습니다. 개발자분들처럼 서버를 구축하고 앱을 개발하고, 이런것들은 잠시 넣어두세요. 우리는 테스트 자동화에 필요한 기본적인 지식들만 배워나가면 됩니다.









Selenium을 활용한 테스트 자동화

테스트 자동화에는 다양한 소프트웨어 프레임 워크가 있지만 그중 Selenium을 선택하였습니다. Selenium은 가장 대중적인 프레임 워크로써 참고할 만한 다양한 예제와 문제 해결 방안을 찾기에 용이하며, 다양한 서비스를 제공하지만 모두 오픈소스라는 장점이 있습니다. 또한 Python을 가뭄에 콩 나듯 공부해봤던 저에게 Selenium은 Java, Python, C#, Ruby 등 다양한 언어로 테스트 코드 작성이 가능하기 때문에 Selenium을 선택하게 되었습니다.

테스트 자동화가 실행되는 동안 다른 업무에 집중할 수 있고 그에 따른 리소스 확보가 가능하니 프로덕트의 변경점에 대한 테스트 코드의 유지 보수만 이루어진다면 얼마든지 QA 리소스 확보의 큰 도움이 될 수 있습니다.


                                       











Selenium Grid를 활용한 Parallel Test

Selenium에서 제공하는 Selenium GRID를 활용한다면 웹 브라우저, 모바일 앱의 Parallel Test가 가능하기 때문에, 다양한 웹 브라우저(IE, Chrome, FireFox 등) 테스트와 안드로이드 디바이스의 제조사(Samsung, LG, Google 등) 또는 OS 버전 별 다수의 플랫폼에서 동일한 테스트를 여러 환경에서 동시에 테스트가 가능하니 4번의 테스트를 한차례에 진행한다면 4배 빠른 테스트가 이루어지는 셈이죠.

Selenium Grid : Hub & Node 개념








Jenkins CI 빌드 스케줄러 활용한 서비스 모니터링

조금 더 응용해서 테스트 자동화와 Jenkins CI 빌드 스케줄러를 통해 주요 기능의 대한 서비스 모니터링도 가능합니다. 테스트 스크립트를 원하는 시간대를 설정하여 주기적으로 테스트 결과에 대한 내용을 Slack Bot으로 받아볼 수 있습니다.

Jenkins CI 슬랙 알림 연동 예시

테스트 자동화를 통해 Regression Test의 테스트 소요시간을 줄이면서, 다수의 플랫폼에서 반복적인 Regression Test 수행의 리소스 낭비를 Selenium GRID를 통해서 해결할 수 있습니다.
참고로 테스트 자동화는 ‘절대’ 마법이 아닙니다. 귀찮고 반복적인 일이 싫은 사람을 위한 도구일 뿐이지 그 이상 그 이하도 아닙니다. 언제나 그렇듯 사람이 꽃보다 아름답습니다.


개인 토이 프로젝트로 Google map 을 정말 조~금 다루어 보았는데 

- Google Map API를 통해 지도 로드하기

- DB에 저장된 위,경도를 이용해 지도에 Marker 찍기

- Marker 클릭 시 Infowindow 노출하기

- makerCluster 를 이용해 줌 아웃 시 클러스터 노출하기


생각보다 혼자 낑낑대며 해본게 꽤 많아 저것들도 천천히 블로그에 남겨볼 예정이다!


그리고 최근 개발 뽐뿌를 자극하던 것이 있었으니..



직방 - 원룸 매물 찾기

 



구글 - 음식점 위치 찾기



여러 서비스에서 위와 같은 html 태그에 mouseover 통한 지도 마커 이동 동작을 자주 볼 수 있는데


내가 만들어본것 중 가장 난이도가 있을 거 같았지만 구글님께 물어보면 된다.


참고로 자랑은 아니지만 JS (Java Script) 를 공부해본적도 없고 JS 언어 구조를 하나도 모른다 ㅇㅅaㅇ


그냥 파이썬으로 직접 사이트를 만들고 싶었고, 멋들어진 동작을 구현 하려면 JS나 Jquery가 필요하니 부족하지만 그냥 눈치껏 몸으로 부딪혀 보았다.



PinTravel(가제)




포스팅된 게시글 카드에 id을 값을 data-wonder 속성 값을 부여해준다.

<article class="card" id="{{ forloop.counter0 }}" data-wonder="{{ travel.id }}">


다음 wonderlinks 라는 변수에 data-wodner 속성 값을 받아온다.

var wonderlinks = $('[data-wonder]');


그리고 wonderlinks 변수에 filter 펑션을 사용하여 원하는 return 값을 정의해준다.

wonderlinks.filter(function(){

return $(this).data('wonder') === markers[i][3];
}).on('mouseover', (function(marker){
return function(){
map.panTo(marker.getPosition());
$('.card').mouseover(function(){
var number = $(this).attr("id");
});
$('.card').mouseout(function(){
infowindow.close();
});
}
})(marker));

google.maps.event.addListener(marker, 'mouseover', (function(marker, i) {
return function() {
map.panTo(marker.getPosition());
}
})(marker, i));

google.maps.event.addListener(marker, 'mouseout', (function(marker, i) {
return function() {
infowindow.close();
}
})(marker, i));


지도에 marker를 for문을 통해 그려주고 있다보니 스크립트와 for문이 꼬여 완전하지 못하게 동작 하느라 꽤나 애를 먹었다..


개발 실력이 뛰어나지 못해서 코드의 대한 설명을 적을 순 없지만, 노력의 결과물을 어딘가에 기록해두고 싶어 이렇게나마 글을 적어봤습니다 🖐🏻

scp [옵션] [aws pem] [원본파일경로] ubuntu@[주소]:/[옮길 원격서버 파일경로]


scp -i /Users/yeonsin/.ssh/aws.pem /Users/yeonsin/File/ ubuntu@11.11.11.111.com:/srv/




참고 : http://2joong2.tistory.com/entry/AWS%EC%95%84%EB%A7%88%EC%A1%B4-%EC%9B%B9-%EC%84%9C%EB%B9%84%EC%8A%A4-%EC%9A%B0%EB%B6%84%ED%88%AC-%EC%84%9C%EB%B2%84%EC%97%90-SCPSecure-Copy-%EC%82%AC%EC%9A%A9%EB%B2%95

'ETC' 카테고리의 다른 글

[CSS] 25 Cool CSS Card UI Examples  (0) 2018.08.08
[Google] Lat, Lng, Plcae ID  (0) 2018.08.03