요 며칠 기사를 자세히 읽을 시간이 없어서 지나쳤나본데...

세월호의 실소유주가 유병언이 아니라 국정원일 수도 있다는 기사까지 나오네요.

세월호에서 나온 직원 노트북을 복원했더니 국정원 지적사항이라는 제목으로 100여가지의 항목이 있다고 하던데...

그 지적사항 중에는 '직원 휴가 계획서'와 '작업수당 보고서 제출' 같은 내용도 있다면서요.

국정원은 그 중 4가지 정도 보안 및 대 테러 준비 사항에 대해 지적했을 뿐이라고 해명을 했다고 하던데...

복원된 문서중 일부입니다. (출처 프레시안)

[선내 여객구역 작업예정 사항] - 국정원 지적사항

이것이 제목입니다.

제가 회사에서 문서 작성을 한 경험에 의하면 국정원 말대로 100가지 중 4가지만 국정원 지적사항이라면 제목을 저렇게 뽑지 않습니다.

제목은 그냥 선내 여객구역 작업 예정 사항으로 하고 해당 항목 비고란에 '국정원 지적사항' 이라고 따로 표시를 할 겁니다.

국정원 해명을 전혀 이해할 수 없는 부분입니다.

그리고 JTBC에서 조사한 바에 따르면 취재진이 2천톤급 이상 여객선 17척의 유사시 보고계통을 조사했더니 세월호만 국정원 보고가 명시돼 있다고 합니다.

관련기사

국정원이 첩보 업무 수행상 일반 기업으로 위장하고 업무를 진행하거나 일반기업과 긴밀히 협조하면서 임무를 진행하기도 하는 것으로 알고 있습니다.

세월호를 운영하고 있는 청해진 해운도 그런 기업중의 하나이고 국정원이 생각보다 많이 관여를 하고 있었다면 이건 또 다른 충격이 아닐 수 없습니다.

국정원이 이번 사건 원인 중 하나이고 사고 후부터 지금까지 국민을 철저히 우롱했다는 얘기 이니까요.

만약 그렇다면 이번 사건에 대해 정부에서는 계속 뭔가를 숨기려고 하고 새누리당은 특별법에 계속 비협조적이고 사건 당일 세월호 선장이 경찰 집에서 숙식을 하고 그 아파트의 CCTV가 하필 그날 몇시간 동안 고장나 있었고..... 뭐 이런 많은 의문점들을 해소 시킬 수 있겠네요.

하여간 국가가 계속 국민들을 속이고 있다는 느낌을 지울수가 없습니다.

국가가 알아서 진실을 알려 주지는 못할 것 같습니다. 설사 진실을 말해도 이젠 그걸 믿을 국민은 없을 것 같습니다.

박근혜 정부로서도 수사권과 기소권이 주어진 특별법을 수용해서 객관적으로 진실을 밝혀야만 국민들이 납득할 수 있는 상황까지 왔습니다.

박근혜정부와 새누리당은 아직 정신을 못 차린 것 같으니 선거등을 통해서 국민의 뜻을 확실히 알려 그들이 특별법을 받을 수 밖에 없도록 강제했으면 좋겠습니다.

Software Estimation Memo

Size, Effort Cost, Schedule, Staffing

- Productivity (Size/Efforts)
- Defect Density (Defects/size)
- Effort = Size/Productivity
- Productivity
  : 비슷한 productivity Values 참조, 이전 프로젝트 참조
  : Organization productivity 참조 (PPB)
  : Industry Productivity Rate
- Product Size : Cost and Effort -> Schedule -> Risk Assessment
- KLOC : Kilo Lines of Code
- FP : Function Points
- WBS : Work Breakdown Structure
- Estimation Model
  : Dev FP ; Enh FP : KLOC (Technology Centric Development)
  : Large FP > 1500 Pday : DE Model (DE Point) -> WBS concept (Agile Project)
                           Development and Enhancement Projects
- MR (Micro) < 4Pds, Minor 4~15 ; Major > 15

Data Function
- EIF : External Interface Files - Application 에만 참고 되고 Maintained 되지는 않음
- ILF : Internal Logical Files - Application 에 의해 Maintained 되는 파일들

Transactional Functions
- EI : External Inputs - 1개 이상의 ILE를 Maintain 하기 위함
- EO : External Outputs - 사용자에게 정보를 주기 위한 것 (로직의 결과물)
- EQ : External Inquiries - 사용자에게 정보를 주기 위한 것 (데이터 수정 후 제공)

- VAF : Value Adjustment Factor
- GSCs : General System Characteristics

- Large FP
  : Sub Application 들이 있음
  : Sub System Level FP counting

- KLOC
  : Development Project with less Functional Scope
  : Reengineering. Migration Projects
  : Technology Centric Development

- DE Model
  : Development and Enhancements Projects (FP/KLOC or DE Size Unit)
    Home Grown WBS concepts

* Maintenance Estimation Models

- FTE (Full Time Equivalences) - Maintenance and Prod. Support Proposal/Projects
- CP (Maint Model) : Small Maintenance : Micro MPs, GUI based. Use Post Data
- MR GUI : GUI Based Maintenance Request, Minor and Major MRs
- MR NGUI : Non GUI Based Maintenance Request, Minor and Major MRs
- PPM : Micro MRs and Production Support

* Test Estimation Methods
- Testable items (Manual Testing Method) : TC
- Test Automation

- RET : Recorded Element Type
- DET : Data Element Type. A unique user recognizable, non-repeated field
- FTR : File Type Reference. A FTR is ILF maintained, and EIF referenced

- DFP = (FP + CFP) * VAI
  DFP : Development Project FP counting
  FP : Adjusted FP Count for functions available after installation
  CFP : Conversion Unadjusted FP counting
  VAF : Value Adjustment Factor

- EFP = [(ADD+(HGA+CFP) * VAFA] + (DEL * VAFB)
  EFP : Enhancement Project FP Count
  ADD : Adjusted FP of functions added
  CHGA : Adjusted FP of functions changed
  CFP : Conversion adjusted FP counting
  VAFA : VAF of application after completion of enhancement project
  DEL : Adjusted FP of functions deleted
  VAFB : VAF of application before commencement of enhancement project

- 14 General System Characteristics
  1. Data Communications
  2. Distributed Data Processing
  3. Performance
  4. Heavily Used Configuration
  5. Transaction Rate
  6. Online Data Entry
  7. End-User Efficiency
  8. Online Update
  9. Complex Processing
  10. Reusability
  11. Installation Ease
  12. Operational Ease 
  13. Multiple Sites
  14. Facilitate Change 

High Performers vs. Workaholics: 7 Subtle Differences

(원본을 보시려면 위 제목의 링크를 클릭하세요.)

나는 일중독증에서 회복되고 있다.

지난해 나는 High performer와 workaholic의 다른점에 대해 알고 싶어 관련된 책도 읽고 나름대로 연구도 해 보고 나를 대상으로 실험도 해보고 했었다. 우리의 여러 가치들을 희생시키지 않으면서도 일할 수 있는 좀 더 우리에게 건강한 그런 방법이 있다고 나는 믿는다. 우리 사회는 일을 잘 하고 성과를 많이 내기 위해 일중독자가 되어야 한다는 잘못된 생각을 가지고 있다. 일을 하는 방법은 두가지로 분류할 수 있다.

High performance와 workaholism은 외견상으로는 비슷한 것 처럼 보인다. 둘 다 열심히 일하는 것을 말하는 것 같다. 그 둘 사이에서 크게 다른 점은 그들 일과의 관계에서 그 자신이 어떻게 느끼고 있느냐 이다.

High performer는 건강하게 일하는 방법을 유지하고 행복을 느끼면서 계속 영감을 받으면서  일을 열심히 한다.

workaholic 은 건강하게 유지되지 않는 방법으로 행복하게 느끼지 못하고 burn out 되버리는 방법으로 일을 열심히 한다.

1. Doing Business vs. Being Busy

High performer의 첫    번째 목표는 business를 하는 것이다. 그들이 관심을 갖는 것은 결과이다. 그들이 창조적인 가치를 보지 못하는 순간 그들은 대신에 전략을 세우고 일을 더 분발하게 된다. 그들은 economy, business 가 wave인 것을 안다. 그래서 그들은 하향기일 때는 기다릴 줄 알고 상향기 일 때 성과를 낼 줄 안다.

workaholic의 첫번째 목표는 바쁜 것이다. workaholic은 모든 시간을 다 일을 해야 한다. 아무것도 안하고 있으면 뭔가 불안한 것이다. 그 불안정성은 그들의 가치를 알지 못하는데서 나온다. 그들은 그들이 더 바쁠 수록 자신이 더 가치 있다고 생각한다. 그 결과로 일별, 주별, 월별, 분기별 그리고 연단위로도 그렇게 바쁠 필요가 없는 시기에도 바쁘게 지낼 수 있는 그런 방법을 찾아낸다.



2. Knows What's Enough vs. Never Enough

High performer는 어느만큼이 충분한 지 안다. 1점이든 50점이든 그 크기는 상관없이 충분할 때를 아는 것이다. win은 win인 것이다. High performer는 해당 분야에서 어느 정도 얻는 것이 충분한지 아는 것이다. 그럼으로서 성공의 정의가 명확하게 서 있게 된다.

workaholic은 충분한게 어느만큼인지 모른다. 항상 자신은 충분하지 않다고 생각한다. 그리고 자신은 한상 시간이 충분하지 않고 충분한 지원을 받지 못한다고 생각한다. 그들은 항상 '좀 더'에 촛점을 맞춘다. 그리고 모든것을 극대화 하고자 한다. 왜냐하면 그들은 그들에게 어떤것이 성공인지 그 의미를 정확하게 모르기 때문이다.



3. 100% At The Right Time vs. 110% All Of The Time

High performer는 언제 turn it up 해야 되는 지를 안다. 자기 차례가 되면 자기가 가지고 있는 전부를 준다. 그들은 불확실한 110%를 취하려고 하지 않는다. 그들은 110%는 지속 가능하지 않다는 것을 안다. 그들의 capacity를 초과하려고 하지 않는다. 그들의 100%가 경쟁자의 110%보다 더 나은 것임을 그들은 알고 있다.

workaholic은 '무엇을 위해 거절하는데?' 라고 생각하고 항상 무리하고 grind 하고 go H.A.M.(Hard as a Motherf**ker. 지랄 맞게 힘들게 한다.) 하게 된다. 그들은 뭐가 더 중요한지 그 우선 순위를 매기지를 못한다. 그래서 모든 것이 중요하다고 생각해 버린다.

7. Put Self First vs. Second

High performer는 그들이 알아야 그렇게 행할 수 있으므로 자기 자신을 첫번째로 둔다. 그렇게 함으로서 다른 사람들에게 higher level로 serve 할 수 있다. 때로는 이기적인 모습으로 비칠 때도 있지만 사실은 그것은 이기적인 것이 아니라 이타적인 것이다. 왜냐하면 같이 일하고 있는 사람들에게 first-class service를 주고 싶기 때문에 그렇게 하는 것이기 때문이다.

workaholic은 그들 자신보다 다른 사람들을 우선순위에 둔다. 이것은 이타적인 모습으로 보일 수 있다. 하지만 이것은 지속적일 수 없다. 우리가 가지고 있는 것보다 더 많이 준다면 그럴 수 있는 자원을 계속 보충할 수 없기 때문이다. 그러한 행동은 좋은 의미에서 나오는 것일 수 있다. 하지만 그것에는 다른 사람들이 자신을 필요로 하고 자신이 영웅적인 존재로 인식 되고 싶기 때문도 있다.

이 글을 통해 workaholic과 high performance를 확실하게 구분하는데 도움을 주었으면 한다. 그리고 여러분 자신은 어느쪽이고 매일 여러분의 일을 훌륭하게 성취하는데 도움을 줄 수 있으면 하는 바람이다.

Wishing you more happy hours,

Jullien Gordon
www.julliengordon.com

Automated Testing Advantages, Disadvantages and Guidelines

이 글은 Automated Testing에 대한 간략한 소개로 시작합니다. Automated Testing의 다른 방법들과 잇점 그리고 Automated teste들이 automation의 잇점을 충분히 활용하기 위해 반드시 따라야 하는 가이드 라인 등도 함께 소개 됩니다.

Advantages of Automated Testing

Introduction:

"Automated Testing"은 현재 사용하고 있는 manual testing 과정을 자동화 하는 겁니다. 이를 위해서는 먼저 현재 회사나 조직에서 사용하고 있는 manual testing process를 formalized 해야 겠죠. 

Automation은 manual 혹은 human involvement를 줄이고 기술이 필요로 하지 않은 반복적이거나 redundant 한 일들을 줄이기 위한 strategy, tool, artifact들이다.

최소한 아래의 프로세스들이 포함된다. :

- 예상되는 결과를 포함한 자세한 테스트 케이스. 이 테스트 케이스는 Business Functional Specification과 Design documentation을 바탕으로 개발 된다.

- standalone Test Environment. 테스트 케이스가 매번 반복될 때마다 어플리케이션에 수정되면서 적용될 수 있도록 하는 미리 정해진 constant 같은 것들이 restorable 될 수 있도록 하는 Test Database 같은 것들이 포함 되어야 한다.

아래와 같은 테스트 타입이 자도화 될 수 있습니다.

* Functional – 항상 예상대로 진행 되어야 하는 것들에 대한 테스트

* Regression – 어떤 시스템의 동작이 변경되지 말아야 되는 경우에 대한 테스트

* Exception or Negative – 시스템에 일부러 에러를 일으켜서 테스트 해야 되는 경우

* Stress – 어플리케이션이나 operational infrastructure 의 capacity 를 측정해야 될 경우* 

* Performance – 시스템의 퍼포먼스가 business projection, 요구조건과 관계된 온라인 트랜잭션 과 batch run들 모두에 대해 알맞게 이루어 지고 있음을 보여주어야 할 필요가 있을 때.

* Load – 시스템의 capacity와 performance가 하드웨어나 소프트웨어의 업그레이드가 필요할 정도로 노화되는 시점을 파악할 필요가 있을 때

Benefits of Automated Testing

* Reliable: 매번 실행될 때마다 정확하게 동일한 동작을 시행함으로서 human error를 줄일 수 있다.

* Repeatable: 같은 동작에 대해 반복 시행될 경우 소프트웨어가 어떻게 작동하는지 테스트 할 수 있음.

* Programmable: 어플리케이션의 알려지지 않은 부분을 알아내기 위한 정교한 테스트를 프로그램할 수 있음.

* Comprehensive: 어플리케이션의 여러 기능들을 한번에 테스트하는 test suite를 만들어 사용할 수 있음

* Reusable: 하나의 테스트 케이스를 여러 버전의 어플리케이션에 적용할 수 있다. (유저 인터페이스가 바뀐 경우에도 사용할 수 있다.)

* Better Quality Software: 적은 resource로 짧은 시간에 더 많은 테스트를 진행할 수 있다.

* Fast: Automated Tool은 사람이 하는 것보다 훨씬 빨리 일을 처리 할 수 있다.

* Cost Reduction: Regression을 위한 테스트 인원을 감원할 수 있다. 

해당 작업에 알맞는 tool을 고르는 것과 deploy를 위해 해당 조직의 제대로 된 적용 범위를 정함으로서 이러한 잇점을 최대화 할 수 있다. Automation 이 반드시 사용되어야 할 알맞는 적용 범위를 정하는 것이 중요하다.

아래의 분야들은 반드시 자동화 되어야 한다.

1. 중복적으로 진행되는 일이나 시나리오.

2. 단순하고 오래 걸리며 human error를 일으 킬 수 있는 반복적인 일

3. 잘 개발 되고 잘 구성되어진 use case나 시나리오 우선으로 자동화

4. 상대적으로 안정된 부분

Automated tester들은 자동화의 장점을 최대화 하기 위해 아래 가이드 라인을 따라야 한다.

• Concise: 최대한 간단하게

• Self-Checking: Test Report에 모든 결과가 있도록. 사람이 별도의 분석작업을 할 필요가 없도록

• Repeatable: 사람의 개입 없이 여러번 테스트가 진행될 수 있도록

• Robust: 테스트의 결과가 항상 같아야 함. 테스트가 외부적인 변화에 영향을 받지 않도록 해야 함

• Sufficient: Tests verify all the requirements of the software being tested. 해당 소프트웨어에 대한 요구조건을 모두 검증할 수 있어야 함

• Necessary: 각 테스트 마다 특정 테스트 사항들이 포함돼 있어야 한다.

• Clear: 모든 statement가 이해하기 쉬워야 한다.

• Efficient: 테스트 실행 시간이 적당해야 한다. (너무 길면 안된다.)

• Specific: 각 기능마다 failure point가 있어야 한다.  unit test failures provide "defect triangulation".

• Independent: 각 테스트는 임의의 suite 내에 있더라도 독립적으로도 실행 될 수 있어야 한다.

• Maintainable: 테스트는 쉽게 이해하고 수정하고 확장 될 수 있도록 만들어야 한다.

• Traceable: 요구사항의 시작과 끝과 같이 테스트의 시작과 끝을 추적할 수 있어야 한다.

Disadvantages of Automation Testing

자동화 테스트가 많은 장점을 가지고 있지만 단점도 있다. 아래에 그 단점들이 있다.

• 자동화 테스트 script를 작성할 수 있는 인원이 필요하다.

• 디버깅하는 것이 가장 이슈인 부분이다. 테스트 스크립트에 에러가 있는 경우 deadly consequences에 이르게 할 수 있다.

• playback method들인 경우 테스트를 유지관리 하는데 비용이 든다. GUI에 약간의 변화가 있어도 test script 는 수정되거나 다시 작성되어야 한다.

• 테스트 데이터를 관리하는 것이 어렵다. 

위의 단점들이 테스트 자동화로부터 얻을 수 있는 잇점에 손상을 가할 수 있다. 테스트 자동화에는 이렇게 장점과 단점이 있음에도 세계적으로 널리 적용되고 있다.

• Software Testing Best Practices
• Bug Reporting – Art and Advocacy
• Software Testing Myths
• Challenges in Testing Web Based Applications
• Auditing Software Testing Process
• Testing for Agile Software Development
• What is User Acceptance Testing?
• System Testing: Why? What? & How?
• What is Regression Testing?
• Integration Testing: Why? What? & How?
• Unit Testing: Why? What? & How?
• Effective Software Testing
• Metrics Used In Testing
• Syllabus for Certified Software Tester
• Software Quality Management
• Software Project Planning
• Software Cost Estimation
• Risk Analysis
• Technical Terms Used in Testing World
• Bug Life Cycle & Guidelines
• So you want to be a Software Tester?
• Automated Testing Best Practices
• Database Checkpoints in WinRunner
• Data Driven Tests using WinRunner
• Why Choose LoadRunner for Performance testing
• Testing : Introduction to CMM
• Automated Testing Advantages, Disadvantages and Guidelines
• Testing Types
• WinRunner – TSL Functions
• Life Cycle of Testing Process
• Best Practices in Automated Testing
• A Unit Ttesting Framework for the Oracle PL/SQL Language
• Usability Engineering – Usability Testing
• Functional Testing Tools
• SDLC : Software Development Life Cycle
• QuickTest Professional 8.0 CBT Tutorial and Evaluation Copy
• SQL Unit Testing Tools
• Microsoft .NET Unit testing Tools
• XML Unit Testing tools Series 1