Records rather than Memories

블랙박스 테스트 기법의 일반적인 특징: - 테스트 컨디션, 테스트 케이스, 테스트 데이터는 소프트웨어 요구사항, 명세서, 유스케이스, 사용자 스토리와 같은 테스트 베이시스로부터 도출한다. - 테스트 케이스는 요구사항과 요구사항 구현 결과물 간 차이와 편차를 식별하는 데 사용한다. - 커버리지는 테스트 베이시스에서 테스트된 항목과 테스트 베이시스에 적용한 기법을 기반으로 측정한다. 화이트박스 테스트 기법의 일반적인 특성: - 테스트 컨디션, 테스트 케이스, 테스트 데이터는 코드, 소프트웨어 아키텍처, 상세 설계 또는 소프트웨어 구조와 관련된 기타 정보를 포함한 테스트 베이시스로부터 도출한다. - 커버리지는 선택한 구조(예: 코드나 인터페이스) 내에서 테스트한 항목과 테스트 베이시스에 적용된 기법을 기준으로..

Real-Time Rendreing의 특징 A mix of solutions Real-time rendering is complex and demanding Plus we often need a patchwork of different solutions to overcome a challenge Real-Time 렌더링은 다양한 솔루션의 종합판이라고 할 수 있습니다. 그 이유는 복잡하고 어렵기 때문인데 렌더링의 각 단계를 미리 계산하기 위해 최대한 부담을 줄여야합니다. Plus we often need a patchwork of different solutions to overcome a challenge 직면하는 문제가 복잡하기 대문에 여러가지 솔루션을 조합해서 사용합니다. 여기서는 조합하는 Real-..

보호되어 있는 글입니다.

보호되어 있는 글입니다.

1. Testing shows the presence of defects, not their absence > 밝혀지지 않는 결함의 존재를 줄일수는 있지만 전혀 발견되지 않았다고해서 해당 SW가 완벽하다는 뜻은 아니다. 2. Exhaustive testing is impossible > 완벽은 불가능하기에 리스크 분석과 우선순위를 토대로한 테스트에 노력을 가해야합니다. 3. Early testing saves time and money > 초기부터 시작하는 테스팅을 shift left 라고한다. 4. Defects cluster together > 소수의 모듈에서 몰려 발생하는 경우가 많기 때문에 실제 관측한 결합 집중 영역을 리스크 분석의 주요값으로 사용합니다. 5. Beware of the pesti..

어느 날 미용실에서 머리를 자르고 나서 들었던 의문이 있었다. "저 미용사님들은 머리를 잘라주고 나면 허무하지 않을까?" 나는 어릴 때부터 그림을 그리거나 작은 레고 등등을 만드는 것을 좋아했다. 열심히 시간과 노력을 들여 작은 하나의 물건을 만들었을 때 하나씩 그러한 물건을 수집하는 느낌이 들었기 때문이다. 지금도 직접 무언가를 만들지 않더라도 하나씩 또는 여러개씩 무언가를 모으는 것을 좋아한다. 그런데 한 미용사님이 내가 잘 보지도 못하는 뒷머리의 모양과 머리카락 하나까지 신경써주면서 열심히 작은 하나의 물건을 만드는 느낌이 들었다. 하지만 결국 심혈을 기울인 한 사람의 머리는 완성되고나면 그 즉시 떠나게 되는 운명이다. 물론 직업으로서 그리고 고객 관리 차원에서 열심히 모양을 만들어 주는 것이라고 ..

누구나 하기 싫은 일은 있다. 작게는 설거지 같은 집안일 또는 개인적인 목표부터 크게는 공적인 발표나 보고서 같은 의무적인일까지 나는 대부분 내가 하는 행동들은 하고 싶은 일부터 하곤했다. 내가 하고싶지 않으면 시도하기 자체가 꺼려졌고 그것을 지속하기 어려웠다. 그래서 항상 내 마음이 내킬 때 그 일들을 시작했다. 막상 시작하면 난 임무를 완수하기 위해 포기하지 않는 면이 있었지만 그것이 무서워 반대로 새로운 것을 시작하지 않는 면도 있었다. 작년 한 스터디 모임을 함께 하자는 권유를 들었을 때 속으로 하기 싫은 마음이 들었다. 나는 새로운 사람들과 새로운 과제를 이야기하는 것 자체에 부담을 느끼는 사람이기 때문이다. 그런데 혼자 곰곰히 생각하니 항상 '내가 하고 싶은 일'만 한다면 계속 변화가 없는 사..

K2 : 이해 (understand) Testing’s Contributions to Success 결함으로 장애가 발생하거나 이해관계자의 요구를 충족시키지 못하는 상황을 줄일 수 있다. 요구사항 리뷰 > 테스트 불가 기능 제거를 통해 리스크 줄임 사용자 스토리 개선에 참여 > 작업 산출물에서 결함 발견 시스템 설계 중 테스터와 협업 > 기능 설계의 결함 유입이 낮아지고 필요한 테스트를 일찍 식별 코드 개발 중 > 결함 발생 리스크 낮춤 릴리스 전 테스트 > 발견한 결함 디버깅 가능 > 이해관계자의 필요와 요구사항을 충족시킬 가능성을 높임 Quality Assurance and Testing 품질 보증(QA, Quality Assurance)과 테스팅의 차이점 QA는 품질 보증과 품질 제어를 포함한 더 ..