POWERUMC 와 함께하는 .NET 플랫폼 이야기 @powerumc

매뉴얼 테스트와 테스트 자동화. 정말 그 범위를 정하기도 힘들고, 잘 하기도 힘든 가장 기초적인 테스트 방법입니다. 아마도 대다수의 사람들이 알고 있는 테스트의 기본이기도 합니다.

메뉴얼 테스트(Manual Test)는 수동 테스트라는 의미로 테스터에 의해 직접 수행하여 테스트 결과를 기록하는 방식이며,
테스트 자동화(Automated Test)는 자동 테스트라는 의미로 프로그래밍이나 스크립트에 의해 자동으로 테스트를 수행하여 결과를 기록하는 방식입니다.

개발자라면 테스트 자동화를 최우선으로 여기지만, 사실은 매뉴얼 테스트의 영역이 갖는 테스트의 의미는 매우 비중이 높습니다. 많은 사람이 오해하는 것 중에 하나가 자동화 테스트가 정교하고 정확하다고 생각한다는 것입니다. 최근 추세도 자동화 테스트에 매우 큰 비중을 갖고 시스템을 구축하고 테스트 인력을 양산하고 있는 것도 사실입니다. 필자가 전제를 말씀을 드리자면 자동화 테스트는 그 신뢰도가 그리 높지 않습니다.

반면, 매뉴얼 테스트는 매번 인력이 투입되는 테스트이기 때문에 테스트 수행 비용이 매우 비싼 편이며, 테스트 수행 속도가 느리지만 그 신뢰도가 매우 높은 편입니다.

아마도 독자 여러분들은 매뉴얼 테스트가 왜 테스트 결과의 신뢰도가 높은지 의아해 할 수 있을지도 모릅니다. 최근 테스트 자동화를 구축하기 위해서 모든 테스트 케이스의 90%, 많게는 95%이 이르기 까지 테스트를 자동화하기 위해 노력하고 있습니다. 즉, 메뉴얼 테스트:자동화 테스트=95:5 라는 비율을 갖게 되는데, 이것의 비율에 대한 신뢰 퍼센테이지는 매뉴얼 테스트가 훨씬 더 신뢰도가 높다는 의미입니다. 바꾸어 말하면, 매뉴얼 테스트로 수행하는 테스트 케이스가 몇 되지 않기 때문에 그 만큼 테스트의 신뢰할 수 있는 확률이 높다는 의미입니다.

하지만 이런 꿈 같은 이야기는 안타깝게도 단지 수치적이고 해외의 사례입니다. 우리나라의 테스트는 전혀 이런 이상적인 환경을 따라가지 못하고 있습니다. 그 이유 또한 이전의 포스트 중 "[ALM-Test] 8. 소프트웨어 테스트 후진국 "대한민국"에서 언급하였듯이 테스트를 대하는 자세, 테스트에 대응하는 자세가 아직 성숙되지 않았기 때문입니다.

자동화 테스트부터 이야기 해 봅시다.

실제로 소프트웨어 세계 1위 기업인 Microsoft 는 처음 기업을 만들면서 납품하던 여러 가지 DOS(Disk Operation System) 제품부터 테스트의 중요성을 깨닫고(깨닫기 보다 그들이 이미 소프트웨어계 최고의 인물이기 때문에…) 이 DOS 제품에 대한 테스트를 적극적으로 투자하였습니다. DOS 제품을 만들던 당시 여러 나라와 다양한 컴퓨터의 요구 사항에 맞는 DOS 제품을 거듭 납품하기 전부터 하나 둘 씩 테스트 인력을 확보하기 시작했습니다.

운영체제로 동작하는 DOS 제품은 시스템 동작에 가장 기본적으로 제공하는 인터페이스를 제공하는 매우 중요한 제품이기 때문에 테스트에 대해 명확한 철학을 가지고 있었습니다. DOS 제품 자체는 내부적으로 인터럽트(Interrupt) 라고 하는 이벤트 기반으로 시스템과 디바이스를 제어하고 이것을 이용하여 동작하는 소프트웨어가 상당하기 많이 보유했기 때문에 그 제품 자체가 매우 정교할 수 밖에 없습니다. (최종적으로 작은 기업이었던 Microsoft 는 MS-DOS 를 IBM PC에 납품하면서 점차적으로 거대 기업으로 자랄 수 있는 기반이 되었습니다)

이 이후 Windows 95 가 출시되면서 굉장히 획기적인 기능이 추가되었습니다. 그것이 바로 플러그앤플레이(PnP-Plug in Play) 입니다. 이것은 독자들도 알다시피 새로운 하드웨어나 장치가 추가되면 자동으로 OS가 그 장치를 인식할 수 있는 기능이었습니다. 가령, 그래픽 카드를 사서 꼽았는데 Windows OS가 알아서 새로운 장치가 추가됨을 알려주고 드라이버를 설치하라고 알려주거나 자동으로 환경을 구성할 수 있는 기능을 일컫습니다. 데스크탑 컴퓨터 환경에서는 매우 획기적인 OS의 기능이었습니다.

일단 다시 처음으로 돌아가서, 왜 자동화 테스트를 해야 하는가… 필자는 "하지 않아도 됩니다." 라고 말하고 싶군요. 애자일 개발을 수십 가지 지침 중의 하나가 바로 TDD(Test Driven Development-테스트 주도 개발) 입니다. 오해 중의 오해라고 하면 이 지침이 마치 필수 조건으로 인식되는 경우가 있습니다. 필자가 테스트를 하지 않다고 된다는 의미는 테스트를 할 만큼 규모가 없음에도 불구하고 테스트를 의무적으로 강조할 필요는 없다는 의미입니다.

그럼 테스트 자동화를 위한 개발 환경이 다음에 적용된다면 자동화 테스트를 적극적으로 추천합니다. 각 항목이 참(True)라면 반드시 고려해보기 바랍니다.

• A = ( 10명 이상의 개발자가 하나의 프로젝트에 투입되었다. )
• B = A and ( 3명 이상의 개발자가 다른 개발자의 소스 코드나 컴포넌트에 연관되어 있다. )
• ( A or B ) and ( 두 개 이상의 연계 시스템, 산하 시스템 또한 레거시 시스템이 존재한다. )
• C = ( 소프트웨어 특성상 매우 복잡하거나 여러 가지 알고리즘을 사용한다 )
• A = A or ( 5명 이상의 개발자와 2개 이상의 팀이나 파트가 협업을 해야 한다 )

즉, A or B or C = True 라면 반드시 테스트 자동화를 고려하기 바랍니다.

필자가 언젠가 세미나에서 언급한 적이 있습니다. 테스트는 개발자간의 신뢰라고요.

"나는 너를 믿지만 너가 만들 코드는 믿지 않는다. 테스트 코드가 없다면…"

여럿이 함께 개발해야 하는 환경에서 타인의 코드에 의한 오류인 경우 내가 낸 오류보다 더 화가 나는 것도 그 때문입니다. 신뢰~!

왜 자동화 테스트의 신뢰도가 낮은가

일반적으로 테스트를 자동화하면 할 수록 그에 대한 노력은 두 배가 됩니다. 일반적으로 자동화 테스트를 완벽하게 수행하는 경우 제품 코드보다 테스트 코드가 1.5~2개 가량 많습니다. 즉, 100,000 라인에 달하는 코드로 만든 제품은 최대 200,000 라인의 별도의 테스트 코드가 필요하다는 의미입니다. 왜 이렇게 제품 코드보다 테스트 코드가 많은지 궁금할 수 있습니다.

그 이유는 다음과 같습니다. 테스트 대상이 어떤 것인지에 따라 테스트 기법은 매우 다양합니다. 그리고 다국적 제품인 경우 나라 별로 법적인 대응 코드, 화폐나 날짜 체계, 그리고 문화적 다양성 체계 등이 상당한 분량의 테스트 코드를 양산할 수 밖에 없습니다.

• 테스트 계획 (Planning)
• 기능 테스트
  • 동등 클래스 분할 기법
  • 경계 값 분석 기법
  • 조합 분석 기법
• 구조적 테스트
  • 블록 테스팅
  • 결정 테스팅
  • 조건 테스팅
  • 기본 경로 테스팅
• 모델링 기반 테스트
• 다국적 지원을 위한 로케일(Locale) 테스트
• 비기능 테스트
• 테스트 이력 관리 및 버그 추적, 관리
• 전반적인 테스트 품질 관리 활동

그럼 다시 질문하자면, 왜 자동화 테스트의 신뢰도가 낮은가 입니다. 의외로 답은 매우 간단합니다. 개발 코드는 언제나 버그나 결함을 내포하고 있을 가능성이 있는데, 테스트 코드라고 다를 바가 없습니다. 테스트 자동화의 테스트 신뢰도는 테스트 코드 자체에 의존해야 하기 때문에 테스트 코드 자체가 잘못된 검증은 한다면 올바른 테스트가 아닙니다. 하물며, 개발자에게 엄격한 NullReferenceException 이나 Null Point 가 빈번하게 발생하는 버그라면, 테스트 코드 또한 개발 코드에 의해 동작하므로 이러한 잘못된 동작이 테스트 결과에 미치는 영향은 상당히 높을 수 밖에 없습니다. 쉽게 말해, 테스트 코드도 사람이 만드니까 실수를 한다는 것이죠.

개발자에게도 버그나 결함으로 지속적으로 코드를 관리해야 하지만, 테스터에게도 테스트 코드를 꾸준히 관리해야 하는 의무가 있는 것입니다. Microsoft 의 자동 업데이트 기능으로 Windows OS 가 꾸준히 패치되고 있긴 하지만, 어떤 패치는 네트워크 기능을 마비시키거나 그래픽 드라이버가 마비되는 애교 만점 패치도 상당 수 존재합니다.

이렇게 거대한 최대 소프트웨어 기업도 간지러운 애교에 많은 사용자가 분노하고 비방하고 욕설을 퍼붓고 운영체제의 안정성을 논하며 펌하 하는데, 왜 개발자들은 자신이 만드는 버그에 대해 그렇게 관대한지 더욱 사랑스럽기도(?) 합니다.

다시 이전에 얘기하던 Windows OS의 플러그앤플레이(Pnp-Plug in Play) 에 대한 내용은 잠시 보류하고, 매뉴얼 테스트를 다루어 본 이후에 다시 원점에서 다시 논의해보도록 하겠습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

최근 여러 달 동안 블로그를 관리하지 않아 이렇게 다시 글을 올리는 것이 약간은 부담이 되네요. 거의 1년이나 방치해둔 제 블로그에 '어떤 글을 첫 번째 글로 올려야 하나?' 라는 기본적인 것부터 시작해서 앞으로 어떤 주제를 가지고 지속적으로 블로그를 해야 하는지도 말입니다. 이미 마음속으로는 "테스트"라는 소프트웨어 공학적인 주제를 가지고 첫 번째 글을 쓸 것이라고 마음은 먹었지만, 그 동안 느낀 많은 것들 또한 천천히 블로그로 포스팅 하리라 약속을 드립니다.

소프트웨어 테스트 후진국 "대한민국"

소프트웨어 개발 중 테스트는 소프트웨어 개발 라이프사이클의 중요한 과정 중으로 하나임을 전산과를 전공하였다면 이미 알고 있을 것입니다. 그 만큼 소프트웨어 개발 과정 중 "테스트" 단계는 일련의 모든 이전 단계, 즉 분석, 설계, 개발이라는 범위의 기나긴 여정의 과정을 검증하는 단계이고, 그리고 이 과정에서 상당한 분량을 지식을 얻을 수 있는 과정이 테스트 과정이기도 합니다.

필자가 현재 회사로 이직을 하고 약 1여 년간 소프트웨어 테스트라는 Sub Job을 맞게 되면서, 초기에 가볍게 시작한 테스트 활동이 이제는 어느 정도 정착된 소프트웨어 테스트 프로세스를 수립하게 되었고, 이것을 올바르게 판단할 수 있도록 데이터를 시각화하기 위한 다양한 시도를 해 보았습니다. 그리고 테스트를 대하는 우리들의 자세에 대해서도 매우 비판적인 요소들이 많지만, 즉 이것은 아무도 올바른 테스트를 시도하지 않았고 경험해 보지 못한 것이라는 반증이기도 합니다.

사실 우리나라에서는 "테스트"라는 용어가 피부에 와 닿게 된 시점이 바로 "애자일" 개발 프로세스(방법론이라고 칭하지 않음) 덕분에 여러 사람들의 입방아에 가장 자주 오른 용어이기도 합니다. "애자일 프렉티스", "애자일 소프트웨어", "애자일 개발" 이라는 일파만파적인 용어와 수식어 들이 생겨나면서 우리나라의 현실적인 소프트웨어 개발 생태계에서 "테스트"가 재조명 받는 시기가 바로 "애자일"의 영향이 매우 컸음을 의미합니다.

물론, 자사의 솔루션이나 소프트웨어를 전문적으로 개발하는 진정한 소프트웨어 개발 업체에서는 정직하고 잘 동작하는 소프트웨어를 출시하기 위해 테스트에 상당한 노력을 기울이고 있습니다. 높은 단가로 팔리는 소프트웨어에 결함이 있다는 것은 고객에게 매우 치명적이기 때문에 이들의 업체들은 소프트웨어 테스트 전문 인력을 확보하고 꾸준히 품질 유지를 위해 노력하고 있으니까요.

특히 20세기 후반부터 큰 규모의 소프트웨어 개발을 일컬어 "엔터프라이즈 급"의 제품이 개발되고 이것은 즉, 혼자서 잘 동작하는 소프트웨어가 아닌, 다른 시스템, 소프트웨어, 컴포넌트와 잘 동작해야 하는 이식성 때문에 압도적으로 비중 있게 다루는 것 또한 테스트 입니다.

엔터프라이즈 급의 소프트웨어는 상하수직 관계와 팀간의 범위 등이 잘 조직화가 잘 된 우리나라에서 특히 가장 높은 퍼포먼스를 보여주기도 합니다. (높은 퍼포먼스가 그에 걸 맞는 품질을 보장하는 것이 아님을 주의해 주세요) 그리고 테스트는 1단계에서 2,3 단계까지 체계적으로 이루어지기도 합니다. "단위 테스트", "기능 테스트", "통합 테스트"라는 폴더를 만들고 수십 가지 문서를 양산해내면 테스트 단계는 통과하게 되는 것이지요^^. 테스트 이후 단계에서 문제가 발생하면 유지보수 계약에서 추가적으로 지원하면 되니까요..;; (물론, 그 과정이 단순한 과정이 아닌 것도 잘 아는 바이지만…)

흔히 모든 사람들이 문제라는 것을 인지하고, 테스트가 중요하다는 공감대가 형성이 되어야 비로서 저와 함께 논의가 될 수 있으리라 생각합니다.

개발자가 아닌 돌팔이를 주도적으로 양산

일단 개발자의 정식 명식은 "소프트웨어 기술자" 입니다. 일반적으로 우리나라에서는 개발자의 등급을 분류하기를 다음과 같이 분류하는 것을 좋아합니다.

자세한 개발자 등급 기준은 다음의 링크를 참고 하세요 (http://career.sw.or.kr/hrdict/front/guide/renew/sub1-4_popup.jsp )

• 초급 기능사 : 기능사 자격증을 취득한 자
• 중급 기능사 : 기능사 자격 취득 3년 경과 및 산업기사 취득한 자
• 고급 기능사 : 기사, 산업기사 취득하고 기사 취득 후 7년 경과한 자
• 초급 기술사 : 기사 취득, 산업 기사 이상 취득, 지식경제부장관이 고시한 공인민간자격을 취득한 자
• 중급 기술사 : 기사 취득 및 그 후 3년 업계 종사 …
• 고급 기술사 : 중급 기술사 취득 후 3년 이상 업계 종사
• 특급 기술사 : 고급 기술사 취득 후 3년 이상 업계 종사
• 기술사 : 기술사

참 문제가 많은 등급 분류 제도이지요? 대충 밑바닥부터 특급 기술사가 되려면 어림잡아 20년은 넉넉히 업계에 종사해야 하고, 빨리 빨리 자격을 취득하는 것이 상책인 제도인 것 같습니다. 이것도 저것도 싫다면 몇 가지 제한이 있긴 하지만, 양반으로 승진하는 방법은 "기술사"가 유일한 방법이네요. 석사, 박사 과정을 이수하고 좀 놀다가 기술사를 따면 초고속으로 "기술사"로 승진할 수 도 있지요. 이런 등급 제도를 싸잡아 대략 4등급으로 나누면 "초급", "중급", "고급", "특급", 이렇게 네 부류의 개발자(사)로 나뉘어 지는데, Microsoft 제품과 Borland 제품을 가지고 논지 20년이 훌쩍 넘는 필자 또한 아직은 초급을 벗어날 수 없는 운명에 처해있네요.

저렇게 등급화한 것이 문제가 아니라, 닷컴 열풍으로 소프트웨어 개발자 양산을 주도한 정부로써 진정한 엔지니어를 양산하려는 시도가 아닌 "초급 기능사"를 너무 많이 양산한 것이 문제이고, 일단 현업으로 뛰어든 초급 기능사는 현실적으로 다음 등급을 넘기 위해 다시 학교로 돌아가는 것이 가장 빠른 방법인 것이 더욱 문제이고, 더욱 문제는 막 현업에 뛰어든 기능사 개발자들이 더 높은 고지로 갈 수 있는 문턱은 당시 이미 닫혀버렸다는 것이 가장 큰 문제입니다. 덕분에 수 많은 일자리를 창출하고 당시 청년 실업률이 낮은 편이었으며, 누구에게나 개발자의 길이 열려있었다는 것이 지금 현재의 개발자 구인난의 대표적인 정책 실패라고 봅니다. 정책만이 실패한 것이 아닙니다. 닷컴 열풍 이후 지금의 소프트웨어 생태계는 이미 파괴되어버렸고, 지속적인 정책이 뒷받침 되지 않아 많은 수의 개발자들이 소프트웨어 업계를 떠났습니다.

소프트웨어를 공부하려고 뛰어는 사람들이 아닌, 단지 특정 플랫폼과 개발 언어를 가르치면서, 그 시장이 원하는 플랫폼과 개발 언어의 문턱을 넘지 못하면 그대로 낙오될 수 밖에 없으니, 학원 문턱을 통해 현업에 종사할 수는 있어도, 잘 할 수 없는 반복적으로 순환되는 구조적인 문제점을 아직도 그 때의 문제들을 우리 현업 종사자들이 짊어지고 가고 있습니다.

3년 후, 5년 후, 10년 후, 20년 후 개발자의 미래

어떤 개발자가 좋은 개발자인가부터 시작해 봅시다. 10점 만점 중에 각 개발자에게 점수를 주어보았습니다.

1. 개발자는 코딩을 잘 하면 좋은 개발자입니다. (1점 드립니다)
2. 개발자가 코딩을 잘하는데 커뮤니케이션 스킬이 좋으면 좋은 개발자 입니다.(4점 드립니다)
3. 개발자가 신기술에 거부반응 없이 잘 소화하면 좋은 개발자 입니다. (5점 드립니다)
4. 문서화, 시각화 역량이 좋으면 더 없이 써 먹을 데가 많은 개발자 입니다 (SI에서 쓰는 문서 제외) (8점 드립니다)
5. 부하직원을 잘 부리고 성격도 좋으면 금상 첨화 입니다 (10점 드립니다)

이것이 무언인가 잘 생각해 보시면, 신입 사원이 팀장까지 가기 위한 스킬북이라고 보셔도 좋습니다. 전형적으로 우리나라에서 요구하는 개발자 구인 스킬이지요. 결국 코딩 하다가 커뮤니케이션 스킬을 인정받으면 5~10년 후 팀장 명함은 따놓은 당상입니다. 즉, 이것이 대다수의 개발자의 커리어가 될 수 도 있다는 의미입니다.

• 이렇게 궁극의 개발자는 바로 관리자인 것인가…?
• 개발도 제대로 못해본 사람들이 어떻게 좋은 소프트웨어를 만들 것인가…?

코드+코드+코드…+컴파일=소프트웨어

개발자+개발자+개발자…+야근=소프트웨어

아마도 필자가 수 년 전에 사용했던 이력카드의 스킬 인벤토리는 여러 개발자들도 낯설지만은 않을 것입니다.

우리나라 소프트웨어 산업의 80%인 SI(System Integration) 프로젝트가 모두 이런 형식의 이력카드를 사용하고, 고객사들도 원하는 것이 이런 형태의 이력카드이며, 여기에 근무기간을 합산하여 개발자 등급을 분류하여 페이(월급)을 지급합니다. 내가 저 프로젝트에서 뭘 하든 개발자를 바라보는 자세가 한낮 스타크래프트의 SCV, 그 이상이 아니다는 의미이기도 합니다.

저 또한 저러한 이력카드를 채우지 않은지 오래되었지만, 최근에는 제 스킬 인벤토리를 페이스북에 올려놓고 꾸준히 업데이트를 하고자 노력하기도 합니다. (http://www.facebook.com/profile.php?id=100000339676463&sk=info ) 좋은 예가 될지는 모르겠지만, 제 스킬 인벤토리는 최대한 특정 플랫폼에 종속적이지 않도록 작성했고, 제가 수행한 업무를 잘 소개하려고 노력 하였습니다. (물론 제 진짜 이력서가 아닌 제 간략한 정보임을 인지하고 봐주세요) 그리고 제가 개발자로써 어떤 활동을 하며, 어떤 에반젤리즘을 하는지도 http://powerumc.codeplex.com/ 를 통해 게시하고 있습니다.

이러한 필자의 발버둥은 SCV 이상이 되고 싶음을 갈망하는 것일지도 모릅니다. 하지만 개발자는 개발자다워야 합니다. 개발자는 개발이 기본이 되어야겠지요.

애자일 개발 프로세스에서는 함께 하는 팀간에 비즈니스 모델이나 비전을 제시하고 함께 공감대를 형성하여 최상의 퍼포먼트와 팀워크를 구축하는 것이 첫 번째 단계입니다. 그래야 반복이고 머고 잘 됩니다. 애자일 개발 프로세스는 몰라도 됩니다. 팀원이 "이것이야 말로 애자일 프로세스로 돌아가는 프로젝트구나!!!" 라는 것을 느끼게 할 필요도 없습니다. 첫 단추를 잘 꿰면 굳이 애자일 프로세스가 아니더라도 마치 자연의 생태계의 흐름처럼 애자일리티할 수 밖에 없기 때문입니다.

즉, 필자가 이 섹션에서 하려는 말은 개발자는 개발이 기본이 되어야지, 회사나 프로젝트의 비즈니스는 그 다음 단계라는 것입니다. 회사나 프로젝트의 이익을 창출하는 비즈니스의 모델과 프로세스를 잘 이해하면 좋지만 개발자의 기본적인 소양을 갖추지 못한 사람이 그 비즈니스를 구현하게 되면 그것처럼 서포트하기 힘든 것도 없습니다.

결국은 좋은 테스트를 하기 부적격한 개발자들

이야기가 삼천포로 갔습니다만, 필자는 앞으로 테스트에 대한 연제는 계속될 것입니다. 그런데 다시 한번 우리나라 소프트웨어 생태계를 구성하는 많은 사람들을 보고 느낄 때는, 테스트가 문제가 아니라 개발자 한 명 한 명이 갖는 커리어와 목표의식이 없는 것이 더 큰 문제입니다. 이러한 우리나라 소프트웨어 개발에 대한 입방아는 책 한 권으로도 모자랄지도 모릅니다. 그리고 이를 공감하는 분들도 제 주변에 꽤 많은 편이고요.

결국 마치 필자가 우리나라 소프트웨어 생태계를 전반적으로 싸잡아 몰아가는 것처럼 보이지만, 꼭 그렇지는 않습니다. 왜냐하면 한 동안 테스트를 Sub Job으로 수행하면서 이러한 개발자의 근본적인 자세, 테스트를 대하는 자세, 테스트에 대한 편견, 테스트 결과가 개발자 자신에게 미치는 영향 등 여러 가지 경험을 하면서 결국 근본적인 문제에 대한 생각을 한 것 뿐입니다. 즉, 테스트라는 일련의 소프트웨어 개발 단계에 들어가기도 전에 많은 수행 착오를 거치면서 테스트의 기술적인 문제가 아니라 그 이전에 테스트를 바라보고 이해하는 사람들의 문제라고도 바꾸어 이야기 할 수 있습니다.

다시 말해,

• 대다수의 개발자는 테스트는 필요하지만 내가 알 바는 아니라고 생각하고 있습니다.
• 그리고 자신에게 부정적인 영향을 주는 테스트에 대한 적대적인 반감을 드러내는 것은 개발자로써가 아닌 감정적으로 대응하는 개발자들의 문제점들이 내포하고 있습니다.
• 더 문제인 것은 테스트를 단 한번도 생각해 본적 없는 사람들이 테스트에 대해 펌하하고 논하는 것도 참 안타깝습니다.
• 이보다 더 큰 문제는 테스트를 수행하는 사람 또한 소프트웨어/테스트 공학 1장도 읽어 보지 않은 사람들이 대부분이라는 것도 테스트를 수행하는데 큰 걸림돌입니다.
• 종합해보면 테스트라는 일련의 단계에 대한 최소한의 이해가 부족하고, 스스로 부족한 것을 알고 받아들일 줄 아는 이해심도 부족합니다.

소프트웨어 개발 사이클에서 초기 분석과 설계를 잘 하는 것이 중요하고 그것을 잘하는 사람이 있음으로써 개발에까지도 영향을 미치는 것은 "애자일 개발 프로세스"든 "전통적인 개발 프로세스"든 마찬가지 입니다. 테스트도 마찬가지 입니다.

라이브 서비스를 하는 소프트웨어 서비스 업체들도 성능, 버그, 결함, 오류, 해킹 등에 많은 투자를 하고 심도 있게 다루는 부분입니다. 테스트는 분명 매우 민감하고 기본적이며 중요한 단계입니다.

테스트는 개발을 염두하고 테스트를 하지만, 개발자는 테스트를 염두하고 개발하지 않습니다. 그렇기 때문에 테스트는 개발자에게 언제나 불리할 수 밖에 없습니다. 아무런 이음매가 없는 개발 단계에서 테스트 단계까지 자연스러운 이음매를 맺기 위해서 기술적인 것은 기본이 되어야 할 것이며, 그 근본적인 공학적인 지식도 앞으로 꾸준히 다루어 보고자 합니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

처음 Visual Studio 2010 릴리즈 되었을 때는 HTML5 기능이 추가가 되지 않았습니다. 그래서 XML Schema 를 이용하는 방법으로 HTML 텍스트 에디터에서 HTML5 구문을 사용하기도 하였습니다. 하지만 이번 Visual Studio 2010 SP1에는 정식으로 HTML5 인텔리센스와 유효성을 검사할 수 있는 기능이 추가가 되었습니다.

이 기능을 활성화하기 위해서 도구->옵션의 텍스트 에디터->HTML->유효성에서 HTML5 유효성 검사를 지정할 수 있습니다.

HTML5가 지원하는 여러 구문을 인텔리센스에서 자연스럽게 보여줍니다.

더불어 CSS3 를 완벽하게 지원하지는 않지만, 일부분 CSS3를 지원해 줍니다. CSS3 기능은 앞으로 그 기능을 보강할 수 있는 확장 기능으로 Visual Studio Gallery 에서 배포가 되길 기대해봅니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.