The life of TB

일상 2007. 9. 7. 09:41

원고 청탁을 받고 쓴 글이다. 주제는 Testing Principles에 대한 필자의 부연 설명과 생각이다. 이 글을 찾는 모든 사람들에게 도움이 되시길... PS) 원고가 실제 요청자에게 게시된 이후에 공개하도록 하겠다. 본래 목적에 충실해야 하니까. ^^

내글 2007. 9. 7. 09:37

본인의 예전 기고가 ZDNet에 실려서 이에 펌한다. ^^ http://www.zdnet.co.kr/builder/dev/etc/0,39031619,39161120,00.htm

내글 2007. 9. 5. 19:29

웹서핑을 하다가 글쓰기와 사고에 관한 어떤 분의 단상을 보게 되었다. 아래에 펌한다. ^^ http://lastmind.net/2006/12/why-we-write.html Why We Write By Joseph, Jang on December 4, 2006 11:22 AM | Permalink | Comments (0) | TrackBacks (0) Introduction 쓰는 것의 가장 본질적인 이유 중의 하나는 인간의 기억력을 (일반적으로는 정신적인 능력을) 신뢰할 수 없고(unreliable), 기억은 (정신적인 활동은) 왜곡되기 쉽상(volatile)이기 때문이다. 문학의 경우에는 우리가 쓰는 것 자체나 또는 쓰는 것의 결과물을 읽음으로서 오는 어떤 종류의 카타르시스를 즐기기 위한 목적도 있을..

외부스크랩 2007. 8. 28. 22:46

이하 BETTER SOFTWARE FEB. 2004의 아티클을 번역한 것을 공개한다. No Documentation? No Problem! How to make requirements appear out of thin air by Lakshmi Narayani 테스터들과 테스트 매니저들은 종종 테스트 해야 할 요구사항이 없음에 대해서 불평한다. 이 상황의 발단에서 부터 신화를 헤쳐보자. 요구사항이 없다고 말할 때, 그것은 요구사항 문서가 없는 것이다. 확실히 소프트웨어는 아무것도 없는 상태에서 개발되지는 않는다. 소프트웨어를 착안하고, 디자인하고 만드는데 기여하는 사람들이 분명히 존재한다. 그들은 약간의 문서를 가지고는 있거나 최소한 자신들의 머리속에 이러한 내용을 가지고 있다. 하지만 자신들의 머리속에..

테스팅 번역 자료들 2007. 8. 28. 13:46

http://www.zdnet.co.kr/itbiz/column/anchor/hsryu/0,39030308,39160320,00.htm 류한석님이 ZDNet에 포스팅하신 글을 펌한다. IT 업계 빅3의 빛과 그림자 류한석(IT 컬럼니스트) 2007/08/16 한국에서 소위 IT업계의 빅3라고 일컬어지는 삼성SDS, LG CNS, SK C&C는 IT업계에 어떤 영향을 미치고 있는 것일까? 또한 어떤 문제점이 있을까? 이들 업체들의 빛과 그림자를 살펴보도록 하자. 이들 업체들은 근래에 들어 SI(시스템통합)기업이라는 용어보다는, IT서비스 기업이라는 용어를 주로 사용하고 있다. 사실 한국에서는 SI라는 용어가 갖는 부정적인 느낌이 크다. 그리고 그러한 부정적인 느낌이 조성된 데에는 이들 업체들의 공헌이 크다..

외부스크랩 2007. 8. 17. 10:18

1. Try to break up your huge application into modules that are functionally independent. 2. Within each module you start with the functions one by one. 3. For a simple function write all possible test cases that arise to be tested, while using the application as there are no specs. 4. In this way you could complete one function and in turn whole application. 5. To prepare test cases or plan make..

테스팅 번역 자료들 2007. 8. 2. 10:49

테스트 플랜 (test plan)에 대해서 오해도 많고 실수도 많은 것 같다. 계획을 문서화 한다는 것은 어느 산업 분야나 이슈이며 어려운 작업임에는 틀림이 없는 것 같다. 이에 QA엔지니어가 테스트 플랜을 작성하는 데 있어 "블랙 박스"의 관점으로 접근할 때 필요한 내용을 서술해 보겠다. 인수 테스팅 상황 상용 어플리케이션이라면 포장지를 뜯고 사용자 매뉴얼을 읽으며 CD(혹은 DVD)를 트레이에 집어 넣으면서 시작하게 될 것이다. 기업용으로 특화된 어플리케이션이라면 해당 설치 예정 부서의 네트워크 망을 이용해서 어딘가의 웹서버에서 파일을 다운로드 받아 본인들이 직접 설치하거나 또는 TCO Stream 등의 전사적 PC 제어 소프트웨어를 통해 자동 다운로드 후 설치 과정이 사용자 모르게 진행되는 시나리오..

내글 2007. 8. 2. 10:08