지속적 통합을 손쉽게 적용하는 다섯 가지 방안

지속적 통합은 SW 통합에서 발생할 수 있는 중요한 문제들을 줄여주고 보다 빠르게 응집력 높은 소프트웨어를 개발할 수 있다는 점에서 널리 쓰이고 있습니다 . 본 원고에서는 지속적 통합 시 오류 발생을 억제하고 피할 수 있는 효과적인 방안 ( 빌드 관리 전략 수립 , 빌드 / 배포시기 관리 , 인수테스트 통과 후 탐색테스트 수행 등 ) 을 제공합니다. 

소프트웨어 공학에서 , 지속적인 통합 (continuous integration, CI) 은 지속적으로 품질관리를 적용하는 프로세스를 실행하는 것을 의미하며, 작은 단위의 작업 , 빈번한 적용 , 지속적인 통합은 모든 개발을 완료한 뒤에 품질관리를 적용하는 고전적인 방법을 대체하는 방법으로서 소프트웨어의 질적 향상과 소프트웨어를 배포하는데 걸리는 시간을 줄이는데 초점이 맞추어져 있습니다.

지속적 통합 시 발생하는 문제점 확인 및 보완 할 수 있는 방안

1. 빌드 관리 전략 수립
2. 잘못된 오류에 대한 근절
3. 빌드 / 배포 시기 관리
4. 인수테스트 통과 후 탐색테스트 수행
5. 분산된 팀을 위한 명확한 기대 설정

자세히 보기 →

디자인 패턴 자동화 Part 1

디자인패턴 자동화 개념 및 디자인 패턴 적용

소프트웨어 개발 프로젝트의 규모는 점점 커지며 복잡해지고 있다 . 전문가들은 프로젝트가 복잡해질수록 소프트웨어 개발 비용과 유지보수 비용은 더욱 증가하며 , 하드웨어 비용을 초과하게 될 것으로 예상하고 있다.

소프트웨어 규모와 개발 및 유지보수 비용간의 관계는 초선형 (Super-liner) 관계에 있다 . 결국 소프트웨어 규모가 크고 복잡할수록 개발과 유지보수를 위한 우수한 엔지니어를 필요한 반면 우수한 엔지니어를 고용하고 지속적으로 보유하는 것은 어렵게 된다 .

디자인 패턴은 이러한 문제점을 해결할 수 있는 SW 공학을 위한 강력한 도구의 일종으로 , SW 설계에서 자주 나타나는 문제를 위해 이미 개발되어 있는 해결 방법이며 , 많은 디자인 패턴들이 축적되면서 그 효용성이 증대되고 있다 .

• 보일러판 코드의 문제점
• 디자인 패턴 자동화 및 컴파일러 확장

자세히 보기 →

효과적인 SW자동화 테스팅 수행을 위한 FAQ

대부분의 SW 품질관리 전문가들은 SW 자동화 테스팅을 매우 효과적인 것으로 평가하고는 있으나 , 자동화 테스팅과 수동 테스팅을 구분해서 수행해야 할 최적시기를 선택하는 것은 여전히 의문사항으로 남아 있습니다 . 이를 위해 본 보고서에서는 SW 자동화 테스팅의 수행에 있어 가장 많이 제기되는 질문들에 대한 적절한 답변을 제공하고자 합니다 .

- SW 자동화 테스팅 수행을 위한 FAQ - 

1. SW 자동화 테스팅이란 ?

2. 자동화 테스트를 수행해야 하는 경우는 무엇인가 ?

3. 테스트 자동화의 우선순위는 무엇인가 ?

4. 수동 테스트에 적합한 테스트의 종류는 무엇인가 ?

5. 자동화 테스트 선택 시 주의해야할 사항은 무엇인가 ?

6. 팀의 지속적인 테스트 자동화 성공 방법은 무엇인가 ?

마이크 콘의 테스트 자동화 피라미드

자세히 보기 →

프로그래머 행위 메트릭스(Programmer Behavior Metrics, PBM)

프로그래머의 코딩 역량은 소스코드의 품질에 직접적인 영향을 미치며 , 결과적으로 프로젝트의 성공에 영향을 끼치게 된다 . 따라서 코딩 역량이 뛰어난 프로그래머 ( 고급 ) 의 행위를 분석하거나 다른 프로그래머와 비교하여 강 / 약점을 파악할 수 있다면 , 코딩 역량 제고의 시작점이 되며 궁극적으로 프로젝트의 성공 가능성을 높이는 방법이 될 것이다 .

일반적으로 고급 프로그래머들은 단위 시간에 더 많은 코드를 작성하고 더 적은 양의 결함을 발생시킬 것이라 기대된다 . LOC(Line of Code) 나 결함은 소프트웨어 메트릭스 [1] 를 통해 측정이 가능하며 이것들을 프로그래머의 명시적 행위 (Programmer Explicit Behaviors) 라고 규정하겠다 . 또한 고급 프로그래머들은 더 많은 시간을 디버깅하며 , 개발 도구를 더 효율적으로 사용하고 , 더 몰입 (flow)[2] 하여 코딩을 할지도 모른다 . 아직 측정하는 방법이 명확히 제시되지 않은 이러한 것들을 프로그래머의 암묵적 행위 (Programmer Implicit Behaviors) 라고 하겠다 .

본 원고에서는 프로그래머의 암묵적 행위 측정 방법에 대해 중점을 두고 있다 . 프로그래머의 행위와 측정 방법을 정의하고 , 구현된 측정 시스템 (PBMS) 의 주요 아키텍처에 대해 논의하며 , 약 1 개 월 간의 시범 적용 사례를 소개하겠다 .

1. 프로그래머 행위
2. PBMS 구축
3. 시범 적용 사례
4. 결론

자세히 보기 →

사용자 경험 설계 프로세스의 핵심이 되는 UEM(사용자 경험 관리)

최근 SW 개발자 및 품질관리 전문가들은 기존의 UX( 사용자 경험 ) 설계에서 초점을 두고 있는 애플리케이션의 외양 디자인 , 손쉬운 활용을 위한 기능 배치 등에서 벗어나 실제 UX 등에 초점을 두고 있는 UEM( 사용자 경험 관리 ) 에 관심을 두고 있습니다 . 사용자 경험은 애플리케이션 성능과 매우 깊은 관련이 있으며 , UEM 을 통해 사용자 경험 설계 프로세스 개선을 추구할 수 있습니다.

소프트웨어 품질 전문가들은 ‘UX(user experience, 사용자 경험 )’ 란 용어를 애플리케이션 성능보다 설계와 연관을 맺는 경향이 있습니다. 이러한 기존의 UX 가 개발자와 품질관리 ( 테스터를 포함한 ) 전문가들 사이에서 UEM(user experience management, 사용자 경험 관리 ) 이라는 개념을 도입하게 된다면 기존 UX 의 설계중심 측면은 변화할 것입니다.

현행 사용자 경험 설계 프로세스에 있어 한계에 직면한 조직들은 UEM 개념을 추가함으로써 성능적 측면까지 향상될 수 있을 것으로 기대합니다.

▶ UEM 이란 무엇인가

▶ 사용자 경험 설계에서 UEM 의 중요성

▶ UX 설계 프로세스를 어떻게 개선하는가 

자세히 보기 →

최소한의 시간, 비용, 인력으로 SW품질테스트를 수행하는 4가지 Tip

소프트웨어 품질테스트는 최소한의 시간 , 비용 , 인력을 투입하여 시작하였다가 비즈니스에 가치를 증명하면서 자원 투입을 늘리는 것이 통상적인 방법입니다 . 따라서 본 원고에서는 자원이 한정되어 있는 조직에서 테스트를 효과적으로 수행함으로써 품질을 달성하기 위한 네 가지 방안을 제시하고 있습니다.

소프트웨어 품질 테스트 방안

1. 시간이 없다면 , 휴리스틱 활용을 통해 소프트웨어 품질 테스트 수행할 것
2. 자금이 없다면 , 모바일 테스팅을 위한 BYOD 파티를 개회하라
3. 테스트 수행자가 없다면 , 적절한 특성을 지닌 사람들을 모집하라
4. 위험기반 및 역량 기반 자원조달 방법을 사용하라

자세히 보기 →

파라미터를 고려한 컴포넌트 인터페이스의 최적 테스트 시퀀스 생성 기법

컴포넌트의 외부 행위는 파라미터를 가진 인터페이스로 정의됩니다 . 소프트웨어 개발자는 컴포넌트를 테스트하기 위해 인터페이스를 통해 각기 다른 파라미터의 값을 반복적으로 입력하고 , 입력 값에 따른 출력 값을 관찰합니다 . 테스팅에 소요되는 시간을 줄이기 위해 테스트 케이스를 자동으로 실행하는 테스팅 자동화 도구가 효율적이지 않은 테스트 시퀀스를 수행한다면 테스팅 자동화의 효과는 줄어듭니다 . 유한 상태 머신을 기반으로 하는 기존의 테스트 시퀀스 생성 기법들은 파라미터를 가진 인터페이스 테스팅에 최적화된 테스트 시퀀스를 제공하지 않습니다 . 본 원고에서는 컴포넌트 인터페이스를 파라미터를 고려한 상태 모델로 표현하고 최적의 시퀀스 생성 기법을 제안합니다 . 최적의 시퀀스 생성 기법은 파라미터를 가진 상태 기반의 행위 모델에서 특정 간선을 원하는 회수만큼 수행을 보장하는 시퀀스를 생성하며 , 생성된 시퀀스는 최적의 테스트 수행 시간을 갖습니다 .

최적 테스트 시퀀스 생성 기법

1. 테스트 시퀀스 생성 프로세스와 모델
2. 테스트 케이스 맵핑
3. 최적 테스트 시퀀스 생성
4. 최적 테스트 시퀀스 생성 알고리즘 평가

자세히 보기 →