오픈그래프(open graph) 웹사이트 링크를 복사하여 블로그나 카카오톡, SNS 등을 통해 공유할 때 썸네일 이미지, 제목, 설명이 나오는데요. 이 부분을 오픈 그래프(open graph)라고 부릅니다. 아래 이미지는 카카오톡에서 다음 포털의 URL을 입력했을 때 나타나는 오픈그래프를 예시로 캡쳐한 것입니다. 오픈 그래프가 표시되도록 하려면 HTML 문서 상단의 태그 안에 태그를 활용하면 됩니다. 태그에는 웹사이트나 페이지를 설명하는 데이터를 넣는데 오픈 그래프 태그도 바로 여기에 들어갑니다. 1 2 3 4 5 6 7 8 cs 오픈그래프 이미지는 공유하는 플랫폼에 따라 다르게 표시될 수 있습니다. 플랫폼마다 지원하는 크기가 다르기 때문이죠. 다양한 플랫폼의 썸네일에서도 잘 보이도록 제작하는 것이 중요..

블로그의 스킨을 설정하고 자기 취향에 맞게 수정하는 경우 종종 있을텐데요. 크롬 브라우저의 개발자도구 메뉴에서 이런 직업에 활용해 볼 수 있는 기능이 있어 소개하고자 합니다. 1. 다양한 단말기 스크린 크기 확인 내가 설정해 놓은 스킨이 어떻게 보여지는지, 다양한 단말기에서 의도한 대로 잘 보여지는지 확인할 수 있습니다. (1) 먼저 크롬 브라우저를 실행하여 개발자도구(F12) 메뉴를 실행합니다. 오른쪽 상단 메뉴 > 도구 더보기 > 개발자도구 로 진입해서 클릭해도 됩니다. (2) 좌측에 나타나는 개발자 도구 메뉴에서 상단에 있는 Toggle Device Toolbar 아이콘을 클릭합니다. (3) 그러면 상단에 Dimensions: 라는 문구 옆을 클릭하면 테스트할 기기를 선택할 수 있는 리스트가 나타납..

서비스를 기획하는 단계에서 텍스트로만 작성하면 실제의 모습을 상상하기 어렵겠죠. 그래서 개발하기 전에 시각화시키는 작업이 필요합니다. 흔히 프로토타입을 만든다거나 프로토타이핑이라고 합니다. 프로토타입은 시제품이라는 의미이기도 합니다. 상상을 시각화하면 훨씬 많은 부분에서 직관적인 판단이 가능해집니다. 서비스의 핵심 기능을 주요 사용자의 행동 프로세스에 따라 사전 검증해보는 목적으로 사용할 수 있습니다. 프로토타이핑에는 2가지 방식이 있습니다. 1) 하이 피델리티 프로토타입(High Fidelity Prototype) - 이 방식은 실제 서비스만큼 높은 완성도로 프로토타입을 만듭니다. 실제 사용자를 대상으로 피드백을 받아 서비스를 개선하기에 용이합니다. 반면 완성도가 높은 방식이기 때문에 프로토타입을 만드..

스프트웨어 개발 방법론이란 소프트웨어 개발에 있어 생산성과 품질 향상을 목적으로 개발 전과정에 지속적으로 적용할 수 있는 절차나 기법 등을 말합니다. 소프트웨어 개발에 공학적 기법을 접목해보려는 시도에서 소프트웨어 공학이 시작되었고 그 해결책으로 제시된 것이 개발 방법론이라고 하네요. 대표적인 방법론으로는 2가지가 있는데요, 워터폴은 완전히 기획이 끝난 이후에 개발을 하는 개발 방법론입니다. 애자일은 서비스를 단위로 쪼개어 특정 기간 안에 개발 범위를 세분화하고 점진적으로 고도화하는 개발 방법론을 말합니다. 1. 워터폴(Waterfall) 방법론 워터폴 방밥론에서 개발 과정은 선형적입니다. 프로젝트 시작부터 최종 결과물 전달까지 특정 순서에 따라 이루어집니다. 개발 과정에서 프로세스 각 단계에서 동일하고..

기본적인 웹 사이트의 구조는 GNB - LNB - SNB - Contents - FNB 순으로 구분되고, 가장 상위에 있는 GNB부터 가장 하위에 있는 FNB까지 계층 구조를 가지고 있습니다. 메뉴 구조 용어 - GNB(Global Navigation Bar) : 웹 사이트에서 가장 최상위 메뉴를 정의하는 역할 - LNB(Local Navigation Bar) : GNB의 아래 단계로 서버 메뉴를 구성 - SNB(Side Navigation Bar) : GNB와 LNB를 제외한 나머지 메뉴들을 모두 지칭 - Contents : 웹 사이트 화면의 콘텐츠 영역을 의미 - FNB(Foot Navigation Bar) : 일반적으로 기업의 정보, 저작권, 사이트맵 등을 표기하는 용도로 사용 서비스를 기획할 때 ..

정보를 의미있게 만들기 위해서는 논리적으로 적절하게 배치하는 작업이 필요합니다 .이를 정보의 구조화라고 합니다. 정보의 구조화를 위해서는 수집하고 분석한 자료들을 글, 그림, 도표 등을 통해 표현하는 것이 필요합니다. 수집된 정보의 유형에 따라 표현하기 용이한 구조화 기법이 다릅니다. 1. 다이어그램 다이어그램이란 기호나 선 등을 이용하여 정보 간의 관계나 구조 등 다양한 내용을 전달하는 그림으로 정보를 시각화하는 기술입니다. 흔히 말하는 개체관계도, 순서도 등의 개념도 여기에 포함될 수 있습니다. 다이어그램의 목적은 정보의 전달에 있습니다. 다이어그램은 표현 내용에 따라 비교 통계 다이어그램(도표, 그래프 등), 기구 계통 다이어그램(조직도, 계통도 등), 기능 및 해부 다이어그램(기상도, 구조도, 해..

Test Case 작성 단계에서 테스트 설계시 사용되는 기법에는 명세기반기법, 경험기반기법, 구조기반기법 등이 있습니다. 명세 기반 기법(Specification-based Technique) 문서에 기반하는 기법입니다. 테스트 케이스를 명세서로부터 체계적으로 도출해 내는데 일반적으로 Black Box Testing으로 분류되는 기법입니다. 내부구조를 참조하지 않고 문서를 작성하여 테스트 조건과 테스트 케이스를 도출합니다. 커버리지가 구조기반 기법보다는 제한적입니다. 동치분할, 경계값분석, 조합 테스팅, 상태전이 테스팅, 결정 테이블 테스팅 등이 있습니다. - 동치 분할 : 입출력 데이터를 2개 이상의 그룹으로 분할하여 각 그룹별 대표값을 선택하여 테스트 진행 - 경계값 분석 : 입출력의 경계값에 초점을..

Test Case의 정의 일련의 입력값과 기대되는 출력값의 목록입니다. 제품의 품질을 측정하는 행위를 기술해 놓은 문서이기도 하며, 고객의 요구를 충족시키기 위한 내용을 기록한 문서이기도 합니다. Test Case의 목적 요구되는 보장성(Coverage)을 갖는 최적의 Test Case로 가장 많은 결함을 발견할 수 있도록 하는 것입니다. SW의 기능을 가능한한 누락하지 않고 테스트하여 일정 수준의 테스트 보장성을 확보할 수 있게 셀계되어야 합니다. Test Case의 필요성 생산자는 제품고유의 기능과 성능 확인을 위해서 소비자는 Needs에 대한 만족도 확인을 위해서 테스트를 실시합니다. 그리고 이를 통해 제품의 품질이 결정됩니다. 이처럼 테스트를 실시하기 위해서는 테스트에 대한 절차와 표준화된 문서가..

6. Regression Testing(회귀 테스트) 이미 테스트가 완료된 부분에 테스트를 반복하는 것을 의미합니다. 에러 수정 이후 기능의 변경 등이 있는 경우 이용하거나 발견되지 않았던 또다른 에러를 발견할 수도 있습니다. 버그 수정 이후 그 버그 뿐만 아니라 연관된 기능들에 발생할 수 있는 문제점을 검증합니다. 반복적이고 입체적인 검증을 할 수 있지만 수정된 문제점 위주로 검증을 진행하므로 새로운 문제를 찾을 확률은 낮은 편입니다. 비슷한 개념으로 Confirmation Testing(확인 테스트)이 있는데 이는 결함이 발견되고 수정된 후에 원래의 결함이 성공적으로 수정되었는지 확인을 위해 다시 테스트하는 것을 말합니다. 7. Configuration Testing 여러 종류의 환경에서 SW를 검증..

1. Specification Testing 스펙을 이용하여 각 기능들을 검증하는데 종종 이 단계를 건너뛰기도 합니다. 상품 기획서 등 각 문서에 대한 확인시 좋은 검증 방법입니다. 신입사원이나 익숙하지 않은 사용자의 경우 필요합니다. 문서를 보고 검증하기 때문에 잘못된 사항들에 대한 검증은 진행하지 못하며 만약 문서가 잘못되었다면 잘못된 검증을 할 수도 있습니다. 2. Smoke/Sniff Testing 가장 먼저 이용하는 검증기법으로 SW가 만들어졌을 때 바로 검증을 시작할 수 있는 준비가 되어 있는지를 확인하는 방법입니다. 개발자가 SW를 Release하기 전에 기본적인 기능의 작동 여부를 확인할 수 있습니다. 하지만 다른 기능들과의 연계부분이나 통합 부분에 대한 검증은 진행할 수 없습니다. 3. ..