호기롭게 TECH 블로그에 등록될 글감을 작성하려고 보니, 주제는 어떻게 선정해야할지가 막막했습니다.
첫번째 : 주제 정하기
QA엔지니어로써 TECH 블로그에 주제를 정하기 위해 5가지의 큰 기준을 잡아봤습니다.
1. 관심 분야 파악: 자신이 관심 있는 기술, 도구, 프로그래밍 언어, 프레임워크 등을 파악합니다.
자신의 전문성을 강조할 수 있는 주제를 선택하여 독자들에게 정보를 공유하고 피드백을 받는 형태로 글감을 작성합니다.
2. 업계 동향과 트렌드: QA 시장에 최신 업계 동향과 트렌드를 파악합니다. 새로운 기술의 도입, 현재 시장의 트렌드, 미래에 대한 핵심기술을 선정하여 독자들과 토론하는 형태으로 글감을 작성합니다.
3. 문제 해결과 가이드: QA엔지니어 또는 Software엔지니어(Dev)가 자주 마주치는 문제를 해결하는 방법이나, 실용적인 가이드를 제공하는 주제를 선정하여 독자들에게 가이드를 전달하는 형태로 글감을 작성합니다.
4. 프로젝트 경험 공유: 자신이 진행한 프로젝트나 QA 경험을 공유하는 주제를 선정합니다. 프로젝트의 참여한 QA 엔지니어의 A to Z 를 공유하고, 어려웠던점이나 갈등이 있었던경우 어떻게 극복했는지 본인의 경험을 독자들에게 전달하여 공감대를 형성할 수 있드록 글감을 작성합니다.
5. 튜토리얼과 팁: QA 엔지니어가 사용하는 특정 기술이나 도구의 사용법을 소개하는 튜토리얼이나, 유용한 팁을 제공하는 주제를 선정합니다. 본인의 주관적인 생각도 좋지만 정보의 전달은 객관적으로 정확하게 전달되도록 글감을 작성합니다.
관심 분야, 문제 해결과 가이드, (프로젝트) 경험 공유
저는 이 3가지 기준을 잘 조합해서 글을 작성하기로 했습니다.
주제는 "QA 엔지니어로 어떻게 성장을 해야할까?" 로 말이죠!
반응형
두번째 : 대상 독자, 독자가 얻을 수 있는 내용 정하기
주제를 선정하였으므로
이제 두번째는 내 글을 누가 읽어줬으면 좋겠고, 어떤 정보를 얻어가면 좋을지 고민해야 됩니다.
대상 독자에 맞게 어휘력, 단어 사용을 고려해야 합니다.
또한 누구나 아는 내용을 적는 양산형 정보글을 작성하는 건 개인 블로그에서 충분히 작성해왔으니..
독자가 얻을 수 있는 내용을 확실하게 정해야 합니다.
저는 위와 같이 대상 독자와 독자가 얻을 수 있는 내용을 정하였습니다.
세번째 : 글의 주요 내용은?
.주제와 대상 독자가 정해졌으니, 글의 주요 내용을 정해야 합니다.
제 경험에서 발생한 문제를 먼저 공유해드리고, 이 문제는 독자들이 궁금해하고 관심있어하는 주제일 것입니다.
또한, 문제 해결을 위해 어떻게 노력하고 있는지에 대해 글을 설계하으므로
위의 인과관계가 물 흐르듯 자연스럽게 이어져야 읽기에도 편한 글이 될 것입니다.
머릿말 :redgate의 Test Engineering Skill Map (https://www.red-gate.com/blog/test-engineering-skills-map)을 참고하여 QA엔지니어는 어떤 Skill 을 향상시켜야 하는지 방향성을 제공해 줍니다. (쏘카 QA팀도 해당내용을 참고하여 본인이 어떤 Skill이 부족한지 확인하고 장기적인 Skill up 목표를 세워 달려나갑니다.) 내가 QA엔지니어로써 어떤 부분이 부족한지 확인하고, 구체적인 목표를 달성할 수 있습니다. QA Skill영역은 단순히 노력이냐, 재능이냐 두 가지의 불분명한 관점이 아닌 Specialist, Product/Domain, Leadership, Project를 기준으로 여러 가지 사례를 확인하며 보다 구체적인 관점으로 QA Skill을 완성시킬 수 있습니다.
서론 : 전 직장에서 면접관 업무를 진행했던 경험으로 여러 면접자들이 Skill을 어필하지 못했던 사례에 대해 알아봅니다. 그리고 본인이 느꼈던 착오에 대해 간단하게 설명합니다.
본론 : 주요 Skill 과 각 항목에는 어떤 능력들이 필요한지 알 수 있습니다. 쏘카에서 본인이 QA엔지니어로 성장하기 위해 어떤 목표를 설정하고 진행하는지 확인할 수 있습니다.
결론 : 본론을 바탕으로 QA엔지니어가 어떻게 자신을 단련시키고, 어필하는지에 대해 제 생각을 정리하여 글을 마무리합니다.
위의 3가지 단계로 글을 작성하였습니다.
여기서 끝!
이라고 생각하였으나
막상 글을 작성하고 보니 일기장인지, 어떤 내용을 전달하려고 하는지 감이 오지 않았습니다.
뭐가 잘못된 것일까?
1. 정보 공유를 위한 목적이아닌 위에서 언급했던 수습과제를 끝내기 위해 작성한 글 같다.
2. 글의 목적이 명확하지 않다. (QA SKILL 에 관한 내용인지 REDGATE에 대한 설명인지...)
3. 과도한 접속사 사용으로 글을 읽기에 불편하고, 문장이 길다.
4. 한글 영문 혼용규칙을 설정하지 않아 어디서는 엔지니어, 어디서는 Engineer ...
Katalon 에서 소프트웨어 품질에 대한 설문 조사와 분석을 바탕으로 작성된 리포트입니다.
QA 업계에서 일어나는 변화, 테스트 자동화와 인공지능 기술의 활용 등에 대한 정보를 제공하는 문서입니다.
머리말
요즘 빠르게 변화하는 세상에서, 조직들은 소프트웨어 품질(QA) 관행에서의 개선을 위해 내부와 외부 모두를 살펴야 합니다. 소프트웨어 품질을 빠른 속도로 제공하는 데에 대한 강점과 약점을 결정하기 위해 자신들의 관행에서 생성된 정보와 데이터를 수집하고 분석해야 합니다. 동시에, 그들은 각자의 산업에서 현재 상황과 트렌드를 찾아내야 합니다.
이 보고서는 3,000명 이상의 응답자를 대상으로 한 조사 결과를 바탕으로, 현재 소프트웨어 품질의 상태를 스냅숏으로 담아내며, QA 기술, 관행, 도구에 대한 통찰력과 트렌드를 예측합니다. 우리의 연구는 소프트웨어 엔지니어, QA 엔지니어, 분석가 및 관리자를 대상으로 조사되었으므로, 이러한 소프트웨어 품질을 보장하는 데 직접 관여하는 사람들의 의견과 목소리를 반영합니다.
본문
반응형
결론(이라 쓰고 3줄 요약이라고 적기)
자동화 테스트는 생각보다 많은 팀이 사용하지 않는다.
그럼에도 필요한 기술이다.
왜냐면 자동화를 도입한 팀들은 시간과 비용을 절약했기 때문이다.
상업적인 목적으로 만들어진 자료이기 때문에 100% 맹신할 필요는 없습니다.
그냥 이런 흐름이 있구나~라고 가볍게 보는 걸 추천드려요!
58 page 중에 3분의 1 정도는 Katalon이 어떤 회사인지... 알 수 있습니다.
## 🎯 기능 요구사항
- [ ] 2개의 숫자에 대해 덧셈이 가능하다.
- [ ] 2개의 숫자에 대해 뺄셈이 가능하다.
- [ ] 2개의 숫자에 대해 곱셈이 가능하다.
- [ ] 2개의 숫자에 대해 나눗셈이 가능하다.
- [ ] AC(All Clear)버튼을 누르면 0으로 초기화 한다.
- [ ] 숫자는 한번에 최대 3자리 수까지 입력 가능하다.
- [ ] 계산 결과를 표현할 때 소수점 이하는 버림한다.
it("AC버튼을 누르면 0으로 초기화" ,()=>{
cy.get(".digit").contains("2").click();
cy.get(".modifier").contains("AC").click();
cy.get("#total").should("have.text", "0");
});
AC버튼을 누르면 0으로 초기화되도록 testcase를 작성합니다.
초기화하기 전에 사전 조건은
계산기에 값이 있어야 합니다.
따라서 2를 먼저 입력해 줍니다.
그리고. modifier에 포함된 AC button을 클릭해 줍니다.
그러면 결과 값(#total)은 should (여야만 합니다.) "have.text", "0"(0을 가진 텍스트여야 합니다.)
여섯 번째 요구사항
it("숫자는 한번에 최대 3자리수까지 입력", ()=>{
cy.get(".digit").contains("1").click();
cy.get(".digit").contains("2").click();
cy.get(".digit").contains("3").click();
cy.get(".digit").contains("4").click();
cy.get("#total").should("have.text", "123");
});
이 계산기 애플리케이션은 숫자를 한 번에 최대 3 자릿수까지 입력 가능합니다.
따라서 3자리수까지 입력 가능한지 확인을 하기 위해
1~4를 클릭해 줍니다.
원래대로라면 1234 가 나오겠지만 애플리케이션 특성상 123 만 출력되어야 합니다.
그러면 결과 값(#total)은should (여야만 합니다.) "have.text", "123"(123을 가진 텍스트여야 합니다.)
일곱 번째 요구사항
it("계산 결과를 표현할 때 소수점 이하는 버림한다.", ()=>{
cy.get(".digit").contains("1").click();
cy.get(".operation").contains("/").click();
cy.get(".digit").contains("2").click();
cy.get(".operation").contains("=").click();
cy.get("#total").should("have.text","0");
});
이 계산기 애플리케이션은 소수점 이하는 버립니다.
그래서 1 나누기 2를 하면 0.5 가 나오게 되지만
이 계산기 애플리케이션은 0 만 나오게 됩니다.
결과 값(#total)은should (여야만 합니다.) "have.text", "0"(0을 가진 텍스트여야 합니다.)
The long way with the full path 방식으로 cypress open 합니다.
Welcome to Cypress!
화면을 확인하고
E2E Testing 을 클릭합니다.
Choose a browser화면에서
사용할 브라우저를 선택하고
Start E2e Testing in Chrome 를 눌러줍니다.
E2E specs 에 도착했습니다.
여기서는 examples 로 어떻게 동작하는지에 대한 예시를 간단하게 보여줍니다.
과제를 하기 위해 New spec 을 클릭해서 cy.js 파일을 만들어주거나
vscode에서 e2e 폴더 하위에 cy.js 파일을 만들어줍니다.
과제 분석
이 counter 라는 서비스의 요구사항은 무엇일까요?
- [ ] counter의 초기값은 0이다.
- [ ] + 버튼을 클릭 시 count가 1증가한다.
- [ ] - 버튼을 클릭 시 count가 1감소한다.
- [ ] + 버튼을 클릭 시 count가 10이 넘는 경우 더이상 증가하지 못한다. (Max 값이 10)
- [ ] - 버튼을 클릭 시 count가 0보다 작아지는 경우 감소하지 못한다. (Min 값이 0)
- [ ] reset 버튼을 클릭 시 counter가 0으로 초기화된다.
it("+ 버튼을 클릭 시 count가 10이 넘는 경우 더이상 증가하지 못한다. (Max 값이 10)", ()=> {
for(let i=0; i<11; i++) {
cy.get(".increase-btn").click();
}
cy.get("#value").invoke("text").should("eq","10");
});
it("- 버튼을 클릭 시 count가 0보다 작아지는 경우 감소하지 못한다. (Min 값이 0)", ()=>{
cy.get(".decrease-btn").click();
cy.get("#value").invoke("text").should("eq","0");
});
For 문을 사용해 + 버튼을 클릭합니다.
이런식으로 계속 클릭하는 것을 볼 수 있습니다.
그리고 다섯번째 요구사항은
그리고 0에서 - 버튼을 눌럿을 경우 0보다 작아지지 않아야 하므로
-버튼을 클릭 한 다음 0과 비교를 합니다.
과제하기 4. 여섯번째 요구사항
it(" reset 버튼을 클릭 시 counter가 0으로 초기화된다.", () =>{
cy.get(".increase-btn").click();
cy.get(".reset-btn").click();
cy.get("#value").invoke("text").should("eq","0");
});
자동화 중 비교적 쉬운 cypress를 선택하였고, cypress는 E2E Test에 특화된 Frontend 테스트 도구입니다.
그럼 cypress를 설치하기 전에 E2E Test가 무엇인지부터 알고 가야 할 것 같습니다.
그리고 왜 자동화 테스트가 필요한지, 좋은 자동화 테스트를 하려면 어떻게 해야 하는지
간단하게 느껴보는 시간을 갖도록 하겠습니다.
E2E TEST가 뭘까?
E2E TEST는 (End To End Test), Endpoint 간의 테스트입니다. 쉽게 말하자면 "사용자 관점에서 테스트하는 것" 풀어 말하자면 "실제 사용하는 것과 같은 조건에서 전체 시스템 테스트" 진행입니다. 주로 사용자에게 제공하는 Web이나 App 등 GUI를 통해서 시나리오, 기능테스트를 수행합니다. API, DB 등 외부 서비스들을 모두 사용하여 통합된 시스템을 테스트합니다. 그렇기 때문에 위에 말한 것처럼 사용자 관점에서 테스트한다고 말할 수 있습니다.
왜 자동화 테스트가 필요할까?
위와 같이 장점, 단점이 있지만
높은 비용과 진입장벽이 높다고 생각하기 때문에 자동화 테스트를 꺼려하는 사람들이 많습니다.
그러나 적절한 자동화테스트를 조합한다면 위와 같은 문제를 해결할 수 있습니다.
테스트를 자동화를 하기 위해 코드를 설계하고 테스트를 한다.
엄청 복잡하죠?
그래서 명확한 목적을 가지고 자동화 테스트를 도입해야 합니다.
빠르고, 버그를 찾고, 안정적이게 진행해야 합니다.
실행속도가 느리면 차라리 사람이 하는 게 더 좋습니다. 그래서 항상 실행속도가 빨라야 합니다.
그리고 테스트 코드의 가독성도 좋아야 어떤 내용을 테스트하는지 알 수 있으며 수정도 용이합니다.
그리고 자주 변하는 로직과 변하지 않는 로직을 구분하는 것은
자주 변하는 로직에 대해 자동화테스트를 설계한다고 하면, 변할 때마다 수정이 필요합니다.
테스트를 하기 위해 비효율적인 비용이 들어가는 부분입니다.
그리고 버그를 찾을 수 없는 테스트는 의미가 없습니다. 단순히 "잘 돌아간다" 식의 테스트는 배척해야 합니다.
또, 신뢰성을 바탕으로 자동화 테스트가 진행되어야 합니다.
테스트할 때마다 결과가 달라진다? 특정환경에서만 안된다? 신뢰성이 낮아지게 되는 이유가 됩니다.
그러면 다 자동화 돌리면 되는 거 아닌가?
정답은 NO입니다.
테스트를 위한 자동화 코드를 설계한다고 할 때
설계 비용보다 얻을 수 있는 효과가 더 작다면 사람이 진행해야 합니다.
그리고 모든 모듈에 대해 단위 테스트를 진행해야 한다?
물론 초기에는 가능하겠지만 운영하고 있는 서비스라면 이것 또한 비효율적입니다.
마지막으로 모든 테스트 케이스를 E2E TEST로만 진행한다?
이것도 NO입니다.
무조건적인 테스트는 없습니다.
주어진 환경, 리소스, 일정 등에 따라 알맞은 퍼즐을 끼워야 합니다. (사실 제일 애매함)
인트라넷에서 각 부서 게시판으로 이동 후 글을 작성하고, 댓글을 달아서 업무를 진행했습니다.
업무에 관한 모든 정보가 인트라넷에 남아있는 장점이 있습니다.
그러나 대부분의 작성글은 비밀글이고, 퇴사자가 발생하게 되면 관련문서를 찾아가기 힘든 적이 한두 번이 아니었습니다.
그리고 내선전화로 이해를 돕고, 급한 용무도 처리하였습니다.
●Slack●
Slack 은 인스턴트 메시징 프로그램입니다.
비공개 채팅 또는 채널, 워크스페이스 등을 만들어 음성 통화, 화상 통화, 미디어 및 파일 통신이 가능합니다.
그리고 또 여러 소프트웨어와도 통합하여 사용할 수 있고요.
그렇기 때문에 긴 설명이 필요 없습니다.
저는 슬렉을 통한 업무가 딱딱한 대화환경을 조성하지 않음으로
다양한 커뮤니케이션이 가능하다는 것을 몸소 깨달았습니다.
보고를 하는데 형식적인 문서와 언어 사용을 위해 시간이 걸리지도 않고
허들을 통해 논의하고, 브레인 스톰을 즐길 수 있습니다.
메신저
메신저가 無 VS Slack입니다.
●메신저 없음●
메신저가 없습니다.
모든 업무는 인트라넷으로 진행했으니깐요.
그래서 다른 직원과 사담을 나누는 것은 자리에서 잠깐 얘기하는 것뿐이었습니다.
간단한 업무 지시도 메신저가 없었으므로 빠르게 전달되지 않았습니다.
●Slack●
Slack 은 조직적인 커뮤니케이션을 위해 개발되었지만 커뮤니티 플랫폼으로도 활용하고 있습니다.
이모지를 제작해서 쓸 수도 있고, 개성 넘치는 프로필도 꾸밀 수 있습니다.
DM을 통해 비공개적인 교류도 할 수 있습니다.
공통 관심사가 있는 사람들을 모아 채널을 만들어서 소통하기도 합니다.
기획서 & 디자인 가이드
PowerPoint 와 ZEPLINVS Notion, Miro, Figma입니다. 입니다.
●PowerPoint 와 ZEPLIN●
기획서는 PowerPoint로 버전별로 확인할 수 있었습니다. PowerPoint 첫 페이지에 버전관리 항목을 작성하여 관리를 합니다. 단, PowerPoint는 한 번에 모든 기획을 볼 수 있지만 새로운 정책, 기획이나 수정사항이 반영되기까지 시간이 오래 걸립니다. 디자인 가이드는 ZEPLIN으로 화면별 디자인가이드를 확인할 수 있었습니다.
●Notion, Miro, Figma●
User Story와 Acceptance Criteria(인수테스트 시나리오)를 Notion으로 확인할 수 있습니다. 그리고 전반적인 기획은 Miro로 확인이 가능하고요. UX와 Flow에 따른 최종 디자인은 Figma에서 확인할 수 있습니다. 비교적 많은 도구를 통해 기획문서를 확인해야 하지만 직관적이며 도구 내에서 소통이 가능한 장점이 있고 빠르게 반영된다는 장점이 있습니다.
BTS
REDMINEVS Jira 입니다.
●REDMINE●
인트라넷과 연동해서 쓸 수 있는 Redmine입니다. Redmine 도 다양한 기능을 추가할 수 있습니다만 참고문서를 쉽게 찾을 수 없고 플러그인을 적용하는 데에 어려움이 있었습니다. 전 직장에서 Redmine은 전 직원이 들어올 수 없었습니다. 개발, QA, 기획자가 주로 협업하는 공간이었습니다. 그렇기 때문에 디자인, 사업부 정책논의가 필요할 경우에는 해당 이슈를 캡처해서 공유해줘야 하는 불편함이 있었습니다. (지금 와서 생각해 보면 왜 그랬는지는 모르겠음, 수정권한을 빼고 입장했으면 좋았을 텐데...)
●Jira●
처음에 우아한 형제들이나 다른 기업 면접을 봤을 때, 티켓관리는 어떻게 하느냐? 라는 질문을 들었을 때 의아했던 부분이 있었습니다. Redmine을 사용하면서 티켓이라는 단어를 들어본 적이 없었거든요. Jira를 사용하면 일감, 이슈들을 티켓으로 관리할 수 있습니다. 티켓으로 소요시간을 측정하거나, 우선순위 산정, 히스토리 남기기, 다른 티켓과의 연결이 용이합니다. Jira는 활용방법이 무궁무진합니다. JQL로 필터 기능을 사용하여 내가 원하는 정보만 확인할 수 도있고요. 아직 사용한 지 2개월밖에 지나지 않아 설정된 값만 확인이 가능하지만 자유자재로 쓰게 된다면 업무 효율이 향상될 것입니다.
팀 내부 문서 & Test Case
Excel, Google Drive VS Confluence, TestLink입니다. 입니다.
●Excel, Google Drive●
팀 내부문서나 Testcase는 구글 스프레드시트 혹은 엑셀로 작성하여서 개인 폴더에 보관하거나 팀 드라이브에 공유를 했습니다. 계정을 연동하면 오프라인에서도 작업이 가능하고요. 수정이력도 확인할 수 있지만 문서의 양이 많아질 때를 대비하여 카테고리별로 정리가 확실해야 합니다. 딱히 엑셀과 구글 스프레드시트, 드라이브는 단점이 없다고 생각합니다. 상황에 맞게 적절한 선택을 하면 되니깐요. 그러나 텍스트에 최적화되어있다는 느낌을 많이 받습니다. 따라서 팀 내 가이드문서를 만들 때는 살짝 아쉬웠습니다. 그림과 같이 설명하기에는 가독성이 떨어졌거든요. 물론 제가 잘 활용하지 못했을 수도 있지만...
●Confluence, TestLink●
팀 내부 문서는 컨플루언스에 모두 저장하고 있습니다. 업무 공유부터 시작해서 회의록, 가이드문서까지 컨플루언스에 작성합니다. 작성했을 때, 관찰자에게 알림을 보내줄 수 돈 있고 관찰자에게 알리지 않고 게시할 수도 있습니다. 직접 코멘트를 추가할 수도 있고 댓글로 소통이 가능합니다. 테스트 링크는 저도 처음 봤습니다. 테스트 케이스를 관리하는 툴은 생각도 못했어요. 오픈소스 도구이고 쉽게 접근할 수 있는 도구인데요. Test Spec을 정하고 Test case를 작성하여 Test Suite를 형성합니다. 여러 Step actions을 Expected results에 매칭시킬 수 있고, 각자 사용 방법에 따라 Testcase 뿐만 아니라 Test 시나리오도 작성할 수 있습니다. 그렇게 작성된 Testcase를 plan을 세우고 build version을 구분하여 자유자재로 활용할 수 있습니다. BTS와 연동도 가능하여 Testcase 수행할 때도 버튼클릭으로 상태를 바꿀 수 있습니다. 성공/ 실패 히스토리도 파악할 수 있고요. 좀 더 연구해 볼 만한 도구입니다.
반응형
이렇게 해서 오늘은 간단하게
전 직장과 현 직장이 사용하는 협업 도구를 비교해 봤습니다.
갑자기 늘어난 협업 도구부터 숙지해야 했기 때문에
업무 피로감이 늘어났었어요.
그런데 이러한 협업 도구들을 사용하면서
왜 피곤하게 이런 걸 쓰냐?
라는 생각보다는
뭔가 조금 더 익숙해지고, 잘 활용하게 된다면
업무 효율을 높이거나 커뮤니케이션을 할 때 시간을 단축시킬 수 있겠구나
라는 생각이 들었습니다.
즉, 비효율적인 건 아니라는 겁니다.
그러나 무분별하게 잘 나가는 회사들이 쓴다더라
해서 무조건적으로 도구만 많이 쓴다면 그건 닭 잡는데 소 잡는 칼을 쓰는 것과 다름없는 행동이겠지만요.