오프닝: 일상의 테스트는 정말 쉽지만 체계적인 테스트는 매우 어렵다테스트의 정의는 "결함을 발견하기 위한 활동"이라고 명시되어 있습니다. 하지만 이것은 명확한 목적을 가지고 테스트를 할 때의 정의라고 생각합니다. 사실 우리는 무의식적으로 일상의 생활에서 테스트를 수행하고 있습니다. 무언가를 이용할 때와 같은 모든 상황에서 테스트 활동을 하는 것인데요. 예를 들면, 스마트폰에서 가장 많이 사용하는 앱을 실행해 보세요. 잘 실행되었나요? 방금 테스트를 수행한 것입니다. 테스트 케이스를 작성한다면 아래와 같이 작성할 수 있습니다.NumberStepExpected Result1OOO 앱을 실행한다.스플레시가 표시된다.- 홈 or 로그인 페이지 확인 물론, 이런 상황에서 네트워크가 끊겼다던가 서비스를 해주는 회사..

오프닝: QA나 테스트 엔지니어도 개발자다우리가 알고 있는 소프트웨어 개발자라고 하면 보통 코더, 프로그래머라고 생각하고 있을 거로 생각합니다. 하지만 이것은 잘못된 의미입니다. 기획자도 QA도 PM도 PO도 모두 개발자라는 사실을 알고 계셨나요? '소프트웨어 개발'의 정의를 구글 AI에게 물어봤습니다.소프트웨어를 기획, 설계, 구현, 테스트, 배포, 유지보수하는 일련의 과정입니다. 즉, 컴퓨터가 특정 작업을 수행하도록 지시하는 프로그램을 만들고, 관리하는 것을 의미합니다. '소프트웨어 개발자'의 정의를 구글 AI에게 물어봤습니다.소프트웨어 개발자는 소프트웨어를 설계, 개발, 테스트, 유지보수하는 일을 하는 사람을 말합니다. 즉, 컴퓨터 프로그램이나 애플리케이션을 만드는 전문가를 의미합니다. 공통으로 의..

오프닝: 내가 하는 일이 세상에서 가장 힘든 이유는?세상에는 많은 일들이 있습니다. 일이라는 것이 누군가에게는 경제 활동이고, 누군가에게는 자아를 성찰하는 활동이고, 또 누군가에게는 그 무언가의 의미일 것으로 생각합니다. 저는 컴퓨터 정보학(입학할 때는 컴퓨터공학이었는데 졸업할 때 컴퓨터 정보학으로 개명됨)을 전공하고, 한 때, 소프트웨어 개발을 하려고 했던 사람입니다. 물론, 개발의 재미와 탐구. 가장 중요한 것은 성취감이었던 것 같습니다. 개발의 시작은 대학교 4학년 때, 교수님 추천으로 인턴으로 입사하여 시작하게 되었습니다. 회사도 그 흔한 가산디지털단지나 구로도 판교도 아닌 천안 아산이었습니다. 회사에 정말 10미터 떨어진 기숙사에서 회사와 기숙사를 오가며 회사 생활을 시작했던 것 같아요. 그전에..

오프닝: QA의 역할과 책임에 대한 오해와 진실 풀어보기테스트를 다시 한번 정의하면 '테스트 활동은 결함을 발견하기 위한 활동'입니다. 품질 보증이라는 우리의 포지션 명인 QA는 다양한 테스트 활동을 통해 품질을 보증할 수 있는 데이터를 상품의 출시나 서비스의 오픈을 판단할 수 있도록 데이터를 수집하고, 제공해야 하는 것이 QA라는 포지션의 사람들이 해야 하는 숙명이라 생각합니다. 😂(숙명까지는 아니더라도??) 누군가는 QA가 출시의 판단 여부를 결정해도 되지 않느냐 물어보는 경우도 있었습니다. 개인적으로는 회사에는 제품과 서비스를 책임지는 포지션은 회사마다 조금은 차이가 있겠지만 일반적으로 명확히 R&R(Role and Responsibilities)에 명시되어 있을 겁니다. 프로덕트 단위에는 PM(..

오프닝: 프로젝트를 준비하는 QA의 자세는?테스트 계획서는 SI에서는 필수 산출물로 꼭 작성되어야 하는 문서입니다. 그리고 또 포함되는 문서가 품질 관리 계획서입니다. 이번 섹션에서는 품질 관리 계획서가 아닌 테스트 계획서에 대해서 말씀드리겠습니다. 간단하게 설명하면 품질 관리 계획서에는 기획/개발/테스트/배포/운영 유지보수에 대해서 품질을 어떻게 관리할지에 대한 내용이 있어야 하며, 테스트 계획서는 품질 관리의 일부 '테스트' 목적과 목표. 그리고 어떻게 테스트하고 테스트 관련 정보를 담은 문서라고 생각해 주시면 쉽게 이해 되실 거로 생각합니다. 프로젝트의 시작은 '킥오프'라는 활동으로 시작됩니다. 킥오프는 아시다시피 축구에서 공을 차는 것으로 경기를 시작한다는 의미로 새로운 프로젝트를 시작할 때 킥..

오프닝: 테스트를 분석한다고? 무엇을 설계한다는 거야?😉 잡썰제가 가장 잘하는 영역인 테스트에 대한 이야기를 해보려 합니다. 블로글 외에도 전자책도 준비하고 있습니다. 물론 블로그에 모두 담지 못하는 내용들로 가득 채워서 작성하고 있습니다.🤣 2024년부터 조금씩 준비하고 있었는데 올해는 어떻게든 완성을 해보려 합니다.🤔 본론의 시작처음 시작은 가볍게 테스트에 대한 분석과 설계에 대한 이야기를 해보려 합니다. 테스트를 분석하고 설계 한다는 것은 앞으로 우리가 어떤 테스트 방법을 통해 어떻게 이슈를 발견할지를 결정하는 매우 중요한 부분입니다. 대부분의 QA나 테스트 엔지니어는 이 부분을 생략하고, 기획서나 화면 설계서, 스토리보드, 최근에는 피그마 문서 작성이 완료된 시점에 바로 테스트 케이스를 작성..

개발자는 분명 테스트 했는데 QA가 테스트하면 로그인부터 안 되는 이유?[상황]아래 상황을 예로 들어보겠습니다.개발이 완료되고, QA 단계에서 테스트하게 된 상황입니다.QA 담당자 : 빌드 주세요.개발자 : 1.0.0 빌드 올렸습니다. 테스트 부탁드립니다.QA 담당자 : 1.0.0 설치했는데 앱이 실행이 안 되네요? 재빌드 부탁드립니다.개발자 : 빌드 옵션이 잘못돼서 재빌드했습니다. 1.0.1로 설치해서 재확인 부탁드립니다.QA 담당자 : 설치는 되었는데 로그인이 안 됩니다. 확인 부탁드립니다. 한 번쯤은 경험해 보았을 상황이라 생각합니다. [중략]왜 이런 일이 발생할까요? 이유는 매우 간단합니다. 테스트 방법이 다르기 때문인데요. 간혹 정말 생각지 못한 범위에서 결함이 발생하기도 합니다. 이 경우에는 ..

테스트 자동화를 처음 구축 하기 위해 필요한 정보2024년 현재 QA 및 테스트 업계에는 테스트 자동화에 대한 관심이 많은 것 같습니다. 예전부터 관심이 많았지만 많은 기업의 수요도 많아지는 것이 느껴지기도 하고 질문도 많고 궁금한 것이 많은 시기인 것 같습니다. 그래서 조금이나마 테스트 자동화를 준비하는 QA 혹은 엔지니어분들을 위해 흩어져 있는 정보들을 조금씩 모아서 정리를 해보았습니다. 결론 부터 말씀드리면 테스트 자동화는 쉽지 않습니다. 개발 지식? 프로그래밍이 어려운 것이 아닙니다. 프로그래밍 언어는 습득 가능하고 노력하면 누구나 할 수 있습니다. 어렵다고 하는 부분은 끝없는 작업이기 때문입니다. 작은 변화에 매우 민감하기 때문에 어렵다고 말씀드리는 것입니다. 테스트 자동화에 성공하기 위해서 ..

너무 많은 내용은 피로감이 늘어날 뿐이다테스트 요청서는 테스트를 수행하기 위해 꼭 필요한 문서입니다. 테스트 요청서는 테스트에 필요한 정보를 모아놓은 문서이며, 테스트의 범위를 결정하기도 하는 중요한 문서입니다. 또한, 테스트가 완료되었을 때 필요한 정보를 통해 이후 작업을 수행할 수도 있습니다. 오늘은 테스트에 꼭 필요한 테스트 요청서에 대해서 간단하게 알아보려 합니다. 그리고 테스트 요청서에 필요한 정보를 Confluence에서 JIRA 데이터를 어떻게 가져오는지도 간략하게 설명드리도록 하겠습니다. Confluence에 테스트 요청 양식 만들기 No.구분옵션 여부상세 설명1프로젝트명필프로젝트의 이름을 작성.2담당 개발 부서필담당 개발 부서명을 작성3담당 개발 파트옵담당 개발 파트를 작성4담당 개발장옵..