본문 바로가기

QA & TEST90

나로호! 왜 발사를 못하고 있는가? 나로호가 연속하여 2회나 발사를 중지하였다. 발사를 중지한 이유로는 여러가지가 있겠지만... 그중에 가장 큰 문제가 소프트웨어 결함이다. 조금더 자세히 확인하면, 실무자는 고압탱크의 압력 측정을 소프트웨어가 높은 우선순위가 아님에도 자동으로 카운트다운 56초에 강제로 발사를 중지시킨 것. 소프트웨어 개발 프로젝트에서 7년 넘게 QA를 진행하다보니 아래와 같은 의문이 든다. 1. 소프트웨어 스펙을 만들어서 관리했을 텐데... 압력 측정에 대한 가이드가 있지 않나? 2. 소프트웨어에 대해서 사전에 시뮬레이션이나 테스트를 해보았는가? 3. 관련 부분에 대한 사이드 이펙트는 아닌가? 4. 혹시 알고 있던 문제는 아니였는가? 발사 일정이 촉박하다고 합니다 돌아오는 26일 이전에 발사를 못하게 되면, 국제적으로 발.. 2009. 8. 21.
V모델에 이은 W모델 http://www.gerrardconsulting.com 에게 게재된 내용을 한국어로 변경하였습니다. 테스팅 이론을 접하다 보면, V모델이라는 내용을 많이 볼 수 있습니다. 이 내용을 간단히 보자면 개발 초기부터 사용자에게 인수되는 시점까지 테스트를 진행하는 방법론을 제시하는 것이다. 이에 현대형 모델은 아마도 W모델이 아닐까 싶다. V모델에서 기재되어 있는 부분을 잘 살펴보면, 개발과 QA 관계에 대한 산출물 기준으로 코드에는 유닛테스트를 진행할 수 있고, 시스템 디자인 단계에서는 통합 테스트를 하는 식으로 단계적으로 기재되어 있다. W모델은 QA가 사전 준비해야 하는 부분들에 기재되어 있다. 조금 더 구체적으로 접근한다면, 기획 단계에서 구현 요구 사항이 발생한다면, QA는 테스트 요구사항을 사전에.. 2009. 7. 27.
Testing Network인 STEN을 보며 아쉬운 점 STEN 에서 정말 즐거운 시간되시길 바랍니다. Copyright(C) 2005~2010 STEN All rights reserved. [ STEN 홈페이지 내용의 무단 복제,복사,인용, 전재, 변조, 출판, 전시, 판매를 금합니다. ] - 위 내용은 STEN 최하단에 표시된 사항입니다.- STEN은 국내 QA인력 네트워크로 최초 싸이월드 클럽에서 시작하여, 근 10년의 국내 엔지니어의 교류의 장이었습니다. 하지만 요즘 STEN이 상업적인 목표를 향해 달려나가고 있는 부분이 참으로 아쉽다. 각 면들은 배너로 도배가 되어 있으며, 모든 행사에는 언젠가부터 더 많은 기업의 광고들이 쏟아져 나왔다. 더구나, STA라는 곳이라는 회사체에서 매출을 위해서 하는 모든 부분은 이쪽에 공지가 되고 있으니 말이다. 그리.. 2009. 7. 24.
티맥스 윈도우를 바라보는 내 관점 티맥스에서 윈도우를 얼마전에 발표를 했다. 필자는 업무시간에 이어폰을 꽂고 그 관심을 있는 대로 쏟아서 보았다. 우선 UI만 놓고 보자. UI는 비스타의 느낌을 표방하였다. 여기서 주목해서 들어야할 부분은 이렇다. 시연하던 수석연구원은 이런 이야기를 했다. "독자적인 UI가 있었으나, 내부의 반대로 현재 UI를 채택해서 사용했다." - 사용자 관점의 최종단에 있는 UI가 어느 누구에게 검증을 받았는지… 궁금한 노릇이다. 또한 검증을 받았다라고 하더라도, 그 효용에 대한 부분은 내부 외에는 모를 것이다. 사용자에게 오픈되지 않는 것에 대한 스펙을 정해놓고, PT에서 이야기 한다는 것은 조금은 아닌듯하다. 그리고 그 완성도라고 하면… 조금은 한숨이 나올 정도… 버벅거림!!! 아직 프로토 타입이라 그런 거려니.. 2009. 7. 9.
홈페이지 관리 툴 파비콘 http://tools.dynamicdrive.com/favicon/ 사이트랭크 확인하는 곳 www.site-rank.com Quality Inbound Link http://www.aboutus.org 도메인툴 http://www.domaintools.com/ Broken Link Checker http://www.iwebtool.com/broken_link_checker 홈페이지의 브라우져호환성 체크도구 http://browsershots.org/ 검색엔진별 키워드순위 체크 http://www.marketleap.com/verify/ http://tools.seobook.com/general/advanced-rank-checker/ http://www.rankingcheck.com/ 호스팅이웃.. 2009. 3. 23.
버그 테스트의 버그프리 서비스 종료 버그테스트에서 버그프리라는 서비스를 들고 나와서! 일전에 이슈가 된적이 있다. 억단위 보상을 해주겠노라고!! 하지만 지금은 이런 서비스를 접겠다고 한다. 이유는!! 바로 버그테스트가 힘들기 때문이다... 여기 역시 아웃소싱 전담회사다 보니... 거래처가 매출의 전부를 차지하고 있다. 필자가 버그를 몇건 등록해봤는데... 답변이 너무 우스워서~!! 한마디로 돈이 안되는 버그를 올렸다라고나 할까요? 참 우습게도!! 버그는 심각도나 우선순위는 판단할수 있겠지만!! 그 가치를 누군가 판단한다는건 안될일 이라고 생각한다~ 여튼 시도는 좋았으나, 용두 사미의 이런 서비스를 보니 마음이 그닥 좋지가 않다. 다음에는 더 오래 효율적인 테스트 관련 서비스가 생겨났음 좋겠다. ㅎ 2008. 12. 31.
[테스트 뒷담화] 워드프로세서 테스트 (언제나 시간이 제일 큰 문제다.) *사에서 만든 워드프로세서 패키지를 테스트한 적이 있다. 이 워드 프로세서는 상당히 많은 기능을 가진 알려진 제품이다. 이 제품 테스팅 요청을 받았을 때는, 시간이 아주 아주 오래 경과되어 QA담당자가 완성도가 높다고 하였다. 하지만, 제품이 내 손으로 넘어왔을 때에는 여러 가지 부하에 맥을 못 추고 CPU점유율 100%를 1시간 이상 대기한다던가… 하는 아주 큰 문제들이 나타나기 시작했다. 처음에는 아주 아주 시간들이 많이 남아 있는 줄 알았다. 하지만, 아니었다. 단 일주일이라는 시간 안에 제품 기능테스트와 성능테스트, 인쇄테스트를 끝내야 했다. 항상 생각이 드는 것이지만, 이렇게 항상 닥쳐서 일하는 것이 우리나라 IT의 현재가 아닌가 싶다. 그래서 나는 일주일 동.. 2008. 11. 3.
서버 부하테스트(스트레스 테스트) 툴 Load and Performance Test Tools Funkload - Web load testing, stress testing, and functional testing tool written in Python and distributed as free software under the GNU GPL. Emulates a web browser (single-threaded) using webunit; https support; produces detailed reports in ReST, HTML, or PDF. Avalanche - Load-testing appliance from Spirent Communications, designed to stress-test security, netwo.. 2008. 10. 30.
Test Project 준비에 따른 소견 (무릎팍 도사의 손예진!!! 메롱!) 딱 이런 느낌이다. 프로젝트를 정말 하고 싶을 때가 있지만… 그것이 항상은 아니다. 프로젝트는 나의 커리어에 도움을 주겠지만… 나의 정신 건강에는 도움이 안된 때가 더 많다. 무언지 모르겠지만… 하고 싶어서 열심히 할 때, 하기 싫지만 꼬박꼬박 월급을 받기 위해 할 때… 아주 우스운 이야기지만… 나도 사람인지라… 느슨해질 때가 있다. 프로젝트를 준비하게 됨에 있어 나는 여러 가지를 고려한다. 일단 프로젝트 볼륨! 프로젝트 볼륨을 산정해보고는… 한숨을 쉴 때도 있고, 오히려 후딱 해치우자 라는 생각으로 매진하는 경우가 있다. (대부분 후자의 경우이다.) 그리고 나의 컨디션… 컨디션이 좋고 나쁨에 따라 일에 대한 속도나 output은 양질로 흘러갈 수 있다고 믿는다. 요.. 2008. 10. 29.
[테스트 뒷담화]STB 테스트 경험담 (본 이미지는 본인이 테스트 한 제품이 아니니 오해 마시기 바랍니다.) 예전에 이런 적이 있었다. STB 테스트를 위해 파견을 간 적이 있었다. 대기업이라서 그런지 보안도 철저하고 나름의 시스템은 어쩌면 나를 주눅들게 만들 정도 였다. 그 안에서 나는 STB를 테스트 하기로 했다. STB가 다수 준비되지 않아, 저녁 6시부터 다음날 6시까지 근무해야 했다. 모두가 없고 테스트를 위해 남아 있는 나~ 어쩌면 조금은 무서웠을 지도 모른다. (실은 적적함과 더위와 싸워야 했다.) 결론은 중소기업의 개발자와 대기업의 개발자는 같은 개발자였다. 보통 중소기업의 개발자들과 많은 커뮤니케이션을 해본 나는 대기업 개발자의 엄청난 뱃보를 기대했지만... 같은 버그, 같은 문제, 같은 실수를 범하고 있었던 것이다. 더 심.. 2008. 10. 23.