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입니다.
무조건적인 테스트는 없습니다.
주어진 환경, 리소스, 일정 등에 따라 알맞은 퍼즐을 끼워야 합니다. (사실 제일 애매함)
신체 : Game.SetAtt("Strength", 3) 지능 Game.SetAtt("Intelligence", 3) 테크 능력 Game.SetAtt("TechnicalAbility", 3) 반사 신경 Game.SetAtt("Reflexes", 3) 냉정 Game.SetAtt("Cool", 3) 특전 초기화 Game.AddToInventory("Items.PerkPointsResetter",1) 특성 포인트 Game.GiveDevPoints("Attribute", 1) 특전 포인트 Game.GiveDevPoints("Primary", 1) 게임 머니 Game.AddToInventory("Items.money",1234) 레벨 변경 Game.SetLevel("Level",50)