이진아
1) Unit Test, 통합 Test 등에서 발견된 결함을 고치지 않고 넘어가서 그 결함을 안고 출시하는 경우가 많다.
2) 개발기간이 늘어날수록 테스트 기간은 짧아진다.
3) Risk 기반 테스팅 - 장애 발생가능성이 높고, 비즈 임팩트가 큰 모듈을 우선적으로 테스트 한다.
가) 테스팅 순서 (시스템 테스트 또는 인수 테스트의 경우) --> 단위 테스트 및 통합 테스트는 (2), (3)번 순서가 바뀜
(1) 장애발생 가능성이 높고, 비즈 임팩트가 큰 모듈
(2) 장애발생 가능성이 낮고, 비즈 임팩트가 큰 모듈
(3) 장애발생 가능성이 높고, 비즈 임팩트가 작은 모듈
(4) 장애발생 가능성이 낮고, 비즈 임팩트가 작은 모듈
4) Early Test Design (조기 테스트 설계)
바. 테스팅을 하게 되면 비용이 줄어들까? - 알수 없다.
사. 테스팅의 일반 원리 : 테스팅에 "정답"은 없으나 일반 원리는 대부분 참일 수 있는 "모범답안" 이상의 내용임.
1) 테스팅은 결함이 존재함을 밝히는 것
2) 완벽한 테스팅은 불가능
3) 개발 초기에 테스팅 시작
4) 결함 집중
5) 살충제 패러독스 (Pasticide Paradox - 결함이 테스트케이스에 내성을 갖게된다. 살충제를 자꾸 뿌리면 버그(모기, 파리 등)이 해당 살충제에 내성이 생기는 것과 마찬가지 원리)
6) 테스팅은 정황에 의존적
7) 오류-부재의 궤변
아. 탐색적 테스팅(Exploirtory Testing)
자. ISO / IEC 29119 - SW 테스팅 국제 표준 (현재 제정 중)
차. 계속해서 Software Testing Adventure Map에 대한 설명~ (이부분이 중요한데...튜토리얼 때 보다 간략한 내용이기는 하지만
http://www.sten.or.kr/bbs/tb.php/news/1635에서 동영상으로 볼 수 있습니다.)
##테스팅 온라인 교육 오리엔테이션 (+6차시 SW수명주기와 테스트 레벨)## 클릭
카. 인생 철학과 인생 전략
1) 본 인생철학은 일생을 살아감에 있어 대부분의 판단과 즐거운 생활 및 업무 수행에 있어 기반이 된다.(종교관, 학파... 등등등)
2) 본 인생전략은 일생을 살아감에 있어 완성도 높고 생산적으로 일(업무)과 생활을 대처하는 거시적은 접근법이다.
대부분의 일(업무)과 프로젝트를 완성도 높고 생산적으로 처리함에 있어 기반이 될 수 있다.
* 테스트 정책이 인생 철학과 유사하고, 테스팅 전략은 인생전략과 유사하므로, 인생철학과 인생전략이 필요하다면,
테스팅에 있어서도 테스팅 정책과 전략이 테스팅을 일관성/생상성있게 진행하는데 반드시 필요하다.
타. V-모델은 모델일 뿐이다. 우리가 모델하우스에서 살지 않듯이 V-모델도 우리가 우리 테스팅의 실정에 맞게 커스터마이징해서 쓰면 된다.
파. 소감
1) 테스트의 중요성이랄까... 회사에서 TDD도 해봤고, 대학때 배운 내용들도 있었다. 하지만 아직 그렇게까지 와닿진 않는 느낌?
2) 고해상도 지도를 파일로 구했으면 좋겠다. 여기 올라와 있는건 폰트가 뭉개져서 알아보기가 힘들다.
*고해상도를 링크의 답글에서와 같이 시간을 두고 공개할 예정입니다. http://www.sten.or.kr/bbs/tb.php/infodata/899
*또한, CC 라이선스로 아예 .ai 파일을 공개하는 것도 진행 중입니다.
가. Rails vs Merb
나. Demo #1
1) Simple CRUD with DataMapper
2) Merb MVC
다. 소감
1) Rails는 몇번 들어보기도 했고, 최근 2주간 튜토리얼 동영상 본게 있어서 이해는 쉬웠다.
2) 그런데 나는 Ruby on Rails보다는 Merb쪽 시스템이 더 맘에 들더라. Rails는 시키는 대로 하지 않으면 안된다는 점이 반감을 샀다고 할까...ㅡ,.ㅡ;
가. 기술적인 시도에 의미나 다른 무언가를 담는 것에는 개발자가 약하다.
1) Python으로 신호를 보내면, Scratch에서 받아서 액션을 취한다.
2) 주로 팀별로 과제를 했는데 딱히 정해진 목표가 없는지 내가 듣지 못했는지 모르겠지만...ㅡ,.ㅡ; 하여튼 시간에 쫓기지 않고 자유롭게 스크래치를 만져볼수 있었다.
가. 지역화폐를 이용한 소통의 시간
나. 자기가 다른사람에게 전수해 줄수 있는, 자신있는? 기술을 2가지 적고, 자기가 배우고 싶은 기술을 2개 적어서 각각의 게시판에 붙인 뒤,
서로가 배우고 싶거나 가르쳐주고 싶은 사람을 불러서 가르쳐주고 그 시간에 따라 포인트(땀이라 불린다)을 제공하는 게임.
1) 사람과 사람 사이에 이렇게 가르쳐주고 배움으로써 사람간의 소통을 꾀한다...였나ㅡ,.ㅡ; 역시 그때 그때 적지 않으면 곧 잊는다; 이 저주받을 기억력
2) 내가 가진 기술이란게, 다른 사람들이 잘 찾지 않을 종류라거나 오타쿠로 취급받기 딱 좋은 것들 뿐이라... 딱히 적을게 없었다.
3) 결국 LETS가 대안언어축제 행사 중에서 제일 참여하기 힘들었다..ㅡ,.ㅡ;
라. Paradigm Shift
마. 참가
1) Testing에 대해서 아는것이 대해서 얘기해봐라.
2) Testing을 어떻게 하는지?
바. V Model & Test Life Cycle (표가 엉망진창 --> 제가 좀 수정했습니다. 이제는 엉망진창 아님)
안녕하세요 이진아입니다.
남자입니다ㅡ,.ㅡ;
현재 웹 개발 1년차 초짜입니다.
Daum Communication에서 일하고 있으며, 담당하는 서비스는 아고라입니다.
이 페이지를 보시면 http://www.daum.net가 자동으로 시작 페이지로 바뀝니다.
....였으면 좋겠네염.
------ 11월 28일 (금) ------
1. Ice Breaking
가. 6 x 6 게임 : 서로 친해지기 위한 게임. 6x6 표의 각각의 칸마다 행동이 적혀있고 주사위를 2번 굴려서 나온 좌표의 행동을 취한다.
나. 첫사랑 얘기하기라거나, PT체조, 엉덩이로 이름쓰기 등 부끄러운 행동도 있었고 다른 테이블의 사람과 자리를 교체하는 것도 있어서 서로가 친해지도록 하는데 중점을 둔거 같다.
가. 제목 : 환승게임
나. 개념 : 윷놀이와 지하철 노선도의 결합
다. 깨달은 점
1) 프로젝트의 산출물의 버그를 제작자 자신은 찾기 힘들다.
2) 자신이 열정적으로 참여할 때 더 능률적으로 실행할 수 있다.
가. Intro
1) P-camp 의 3가지 P : People, Process, Product?)
2) 기술은 단지 지식일 뿐이다.(20 ~ 30%) 인간관계가 더 중요하다(70 ~ 80%)
나. 일부 기업들은 단기적 이익 때문에 미래를 희생하는 일이 많다.
1) 회사가 위기가 올거 같으면 사람을 자른다. 하지만 이것은 단기적인 처방밖에 안된다.
2) 여유는 조직이 효율적으로 작동하고 성장하기 위해 조직 내 모든 계층의 사람들에게 있어 필수적이다.
3) 변화의 윤활유
다. 100% 바쁜 사람은 빠른 응답을 하기 힘들다.
1) 고민할 여유조차 없다(꼭 해야 할일만 하니까)
2) 100% 바쁜 조직은 변화가 일어날 수 없다.
라. 좋은 자리를 사원들에게 준다.(창가 자리)
마. 문제 프로젝트의 현실 :
회사의 관료적인 보고체계로 인해 기본 요구사항 외에 부가적인 제약사항이 추가된다. 프로젝트는 JSP와 Flash로 프로그래밍을 해야 하는데 관련 기술 전문가는 부족하고, 너무 형편 없어서 어떤 팀도 데려가지 않을 K와 P를 팀에 반드시 포함시켜야 하고, 게다가 한번도 사용해 본 적이 없는 새로 개발된 방법론을 사용해야 하고, 방법론 관리 부서에서는 매주 확인을 한다고 하고, 팀원들은 매일매일 10쪽짜리 보고서를 작성해야 한다. - Death March Project
바. 프로젝트는 결혼과 비슷한다. :
시작하는 데 있어 논리와 무관한 이유가 있고, 초기 기대치와 다른 현실을 깨닫게 된다. 첫 회사, 첫 프로젝트, 첫 매니저가 매우 중요하다ㅡ,.ㅡ;
사. 프로젝트의 실패 및 문제 발생이 예외적인 것이 아니라 보편적이다 :
평균 6 ~ 12개월 정도 일정이 지연되고, 50 ~ 100% 정도의 예산을 초과한다.
아. 합리적이지 않은 낙관주의를 경계해야 한다.
자. 일정이 지연되는 이유는 팀원들이 일을 열심히 하지 않아서가 아니라, 초기에 잘못된 일정을 계획했기 때문이다.
차. 프로젝트 매니저의 가장 중요한 권리 :
사람을 선택할 권리. 팀에 어울리지 않거나 적합하지 않다고 생각하는 사람은 강력하게 거절할 수 있는 용기가 있어야 한다.
카. 프로젝트의 이해
1) 문제가 있는 업무를 한번 수락하면, 두 번째, 세번째 업무도 수락하게 된다.
2) 문제 프로젝트에서는 최고 이해관계자의 진짜 요구사항이 쉽게 왜곡될 수 있다는 사실을 명심해야 한다.
3) 프로젝트의 상황은 계속 변한다.
타. 매니징의 이해??? 직접 참가.
1) 현 조직에서 일하면서 가장 큰 애로사항이라고 생각하는 것을 딱 하나만 적어주십셔.
2) 세상에 3가지 사람이 있다. 혼자 타는 사람.(활화) 혼자 못타지만 다른 탈것이 있으면 타는 사람(가연성). 혼자 타지도 못하고 다른 탈것이 있어도 타지않는 사람(불연성).
3) burnout syndrome(탈진 증후군) : 할일이 너무나 많지만, 일할 시간이 없고, 혼자서 모든 일을 처리하려고 할 때 발생한다.
4) 권한을 위임하고 논공행상[論功行賞]*을 해야 한다. 매니저는 자기가 답답하다고 아랫사람이 하는 일을 뺏어서는 안된다. 그러면 아랫사람을 더이상 발전하지 못하게 된다. 팀원들과의 관계도 좋지 않게 된다.
파. Great PM과 커뮤니케이션
1) Great PM이란?
가) 팀원을 존중하고, 피드백을 주고, 코칭을 하는 사람
나) 팀원에게 적절한 권환위임을 하는 사람
다) 바라는 결과를 명확히 알려주는 사람
라) 방법보다는 결과에 초점을 맞추는 사람
마) 실수했다는 것을 인정하는 사람
바) 팀원의 경력 개발을 지원하는 사람
사) 팀원의 변화와 공헌을 알아차리고 감사하는 사람
아) 감정의 폭발에 반응하기 보다는 사건에 대응하는 사람
자) 조직의 상층부에 영향력을 행사할 수 있는 사람
차) 자기 자신을 관리하는 사람
하. 소감
1) 매우 공감이 간다고 할까..ㅡ,.ㅡ; 이걸 우리 쪽에 도입해서 하고 싶지만 아무래도 힘들듯 하다.
*논공행상[論功行賞] : 공적의 크고 작음 따위를 논의하여 그에 알맞은 상을 줌.
------ 11월 29일 (토) ------
가. http://sten.or.kr/demo/14 : 데모
1) 테스팅 큰그림, 컨셉, 개발과 연계된 내용들을 이해하고 개발을 한다면, 개발 생산성과 효과가 높아지고 품질이 좋아질 것이냐? 조직 차원에서도 그럴것이냐????
2) 테스트, 개발을 하는 사람들이 테스팅 관련 스킬들을 갖추고 일을 한다면, 퍼포먼스가 더 좋아질 것이냐??
나. 동영상 : 회사에서 테스팅을 도입을 했을 때 개발자들의 느낌 인터뷰
1) 좋은 점은 확실히 QC( what the...) 가 된다??? 의식적으로 문서화를 하게 된다.
2) 놓치는 부분이 없어지고, Unit Test 작성이 쉬워진다.
3) 테스트 하는 방식이 도입 전에는 경험 위주로 진행하다가, 도입 후에는 체계적으로 테스팅을 진행하게 된다.
4) 테스팅을 하는게 힘들긴 하지만, 처음부터 테스트를 체계적으로 진행하면 좋겠다????
다. Software Testing Map
