[엘리스 SW QA 트랙 2차 스터디] 사이드 프로젝트 회고 (4/18~5/5)

📌 스터디 목표

1차 팀 프로젝트 당시, 매니저님과 1대1 면담을 할 수 있는 시간이 주어졌다. 그 자리에서 매니저님께서는 2차 팀 프로젝트 역시 웹 자동화로 진행될 가능성이 높다고 말씀하셨다. 하지만 분명 부트캠프 초반 커리큘럼에는 Appium도 포함되어 있었고, 나 역시 그 실습을 기대하고 있었다. 그런데 코치님께서 레이서들의 로컬 환경 문제를 언급하시며, Appium은 실습 없이 그냥 넘어가셨고, 이 과정에 대해 아쉬움과 불만이 컸다.
 
그래서 나는 2차 팀 프로젝트도 웹 자동화로 진행된다면, 별도로 Appium을 공부할 수 있도록 명세서와 APK 파일을 제공해달라고 매니저님께 요청드렸다. 다행히 매니저님께서는 흔쾌히 승낙해주셨고, 이후 1차 프로젝트가 끝난 뒤 실제로 자료 제공이 가능하다는 답변을 받았다. 마침 2차 스터디 모집 시기도 다가오고 있었기에, 이 기회를 활용해 Appium 학습을 중심으로 한 스터디와 사이드 프로젝트를 함께 진행하면 좋겠다는 생각이 들었다. 그렇게 이번 스터디가 시작되었다.
 
사실 오프라인으로 10일간 진행했던 1차 팀 프로젝트는 이론 수업에서 배운 내용보다 훨씬 더 값지고 유익한 시간이었다. 이번 사이드 프로젝트는 수업 이후에 진행되는 만큼, 매일 오프라인으로 만나기는 어렵지만, 온라인으로 소통하고 협업하는 새로운 경험을 할 수 있다는 점에서 긍정적으로 바라보고 있다. 무엇보다 이 스터디를 통해 Appium에 익숙해지는 것이 가장 큰 목표다. 다른 레이서분들도 Appium을 제대로 다뤄보지 못한 채 넘어갔기에, 함께 부딪히고 배우며 성장해나가길 기대하고 있다.

---

📌 4/17 - Appium 특강

어제 진행된 특강에서는 Appium 환경 세팅부터 Python을 활용한 자동화 스크립트 작성까지 실습을 중심으로 진행되었다.
 
🛠️ JDK, node.js, Android Studio 및 SDK 설치

가장 먼저 JDK와 node.js, 그리고 Android Studio 및 SDK 설치를 완료해야 했다.
위에 첨부한 사진들은 실습을 위해 설치해야 하는 필수 SDK들을 포함하고 있다.
 
🛠️ Java와 Android 환경 변수 설정

✅ Java 시스템 변수 추가
변수: JAVA_HOME
값: C:\Program Files\Java\jdk1.8

✅ Java 시스템 변수 Path 추가
%JAVA_HOME%\bin  

✅ Android 환경 변수 추가
변수: ANDROID_HOME
값: C:\Users\samsung\AppData\Local\Android\Sdk

✅ Android 시스템 변수 Path 추가
%ANDROID_HOME%\platform-tools

 
🛠️ appium 및 appium-doctor 설치

pip install -g appium
pip install -g appium-doctor

 • appium과 appium-doctor를 설치하고, 터미널에 appium-doctor를 입력하여 시스템 환경이 올바르게 구성되었는지 확인했다.
 • 이후 Appium Inspector도 설치했는데, 이는 GitHub의 공식 릴리즈 페이지를 통해 다운로드 받을 수 있었다.
 

### Diagnostic for necessary dependencies starting ###는 Appium 실행에 필요한 필수 구성 요소들을 점검하는 단계이다.
이 항목들 옆에 모두 ✔️ 표시가 나타난다면, Appium을 실행하기 위한 환경이 제대로 갖춰졌다는 의미이며, 준비가 완료된 상태라고 볼 수 있다.
 
🐍 Python 자동화 스크립트 작성

pip install Appium-Python-Client

 • 스크립트를 작성할 때는 먼저 Appium-Python-Client 라이브러리를 설치해야 한다.
 • 이 패키지를 설치해야만 Python 코드에서 appium 관련 모듈을 불러올 수 있다.
 
⬇️ Appium 자동화 스크립트 맛보기

from appium import webdriver
from appium.options.common.base import AppiumOptions
from appium.webdriver.common.appiumby import AppiumBy
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

import unittest

class SimpleTest(unittest.TestCase):
    def setUp(self):
        options = AppiumOptions()
        options.load_capabilities ({
            "platformName": "Android",
            "appium:deviceName": "emulator-5554",
            "appium:automationName": "UiAutomator2"
        })

        self.driver = webdriver.Remote("http://127.0.0.1:4723", options=options)
        print("Appium Driver Created")

    def test_search_input(self):
        try:
            # 검색창에 키워드 입력
            search_box_id = "com.android.chrome:id/search_box_text"
            wait = WebDriverWait(self.driver, 10)
            search_input = wait.until(EC.element_to_be_clickable((AppiumBy.ID, search_box_id)))
            search_input.send_keys("Test Input")

            url_bar_id = "com.android.chrome:id/url_bar"
            url_bar = wait.until(EC.element_to_be_clickable((AppiumBy.ID, url_bar_id)))
            actual_text = url_bar.text
            expected_text = "Test Input"
            
            self.assertEqual(actual_text, expected_text, "Assertion Failed")
            print("Assertion Passed")

            # 검색 결과 클릭
            suggestion_xpath = f'//android.widget.TextView[@resource-id="com.android.chrome:id/line_1" and @text="{expected_text}"]'
            suggestion_element = wait.until(EC.element_to_be_clickable((AppiumBy.XPATH, suggestion_xpath)))
            suggestion_element.click()

            result_page_search_xpath = f'//android.widget.EditText[@text="{expected_text}"]'
            result_element = wait.until(EC.visibility_of_element_located((AppiumBy.XPATH, result_page_search_xpath)))
            self.assertTrue(result_element.is_displayed(), "Not Displayed")

            home_button_id = "com.android.chrome:id/home_button"
            home_button = wait.until(EC.element_to_be_clickable((AppiumBy.ID, home_button_id)))
            home_button.click()
            print("Test completed")
        except Exception as e:
            print(e)
            raise

    def tearDown(self):
        if self.driver:
            self.driver.quit()

 
📱 에뮬레이터 및 Inspector 연동
터미널에 appium 명령어를 입력하여 Appium 서버를 실행한다.
 > 서버가 실행되면 터미널에 사용 중인 포트 번호(예: 4723)가 출력된다.
 > 이때 출력되는 Port Number는 Appium 설정에 필요한 Remote Port이다.
이후 Android Studio에서 Virtual Device(가상 디바이스)를 생성하고, Start 버튼을 눌러 실행시켰다.
 > 가상 디바이스가 정상적으로 실행되었다면, 터미널에 adb devices 명령어를 입력하여 연결 상태를 확인할 수 있다.
 > 이때 출력되는 디바이스의 Serial Number는 Appium 설정에 필요한 deviceName이다.
 
Appium Inspector에서는 다음과 같이 설정을 입력했다

Remote Host: 127.0.0.1
Remote Port: 앞서 확인한 포트 번호(기본값: 4723)
Remote Path: /
JSON Representation: {
    "platformName": "Android",
    "appium:deviceName": "emulator-5554",
    "appium:automationName": "UiAutomator2"
}

그 결과, Virtual Device와 Appium Inspector가 정상적으로 연결되며 화면이 동기화되었다.
 
❓ 그렇다면 이 과정은 어떻게 동작하는 것일까?
🔹 Appium 서버 실행 (appium)
   > appium 명령어는 Appium 서버를 실행하는 명령어다.
   > 이 명령어를 입력하면 Appium 서버가 지정된 포트(기본: 4723)를 열고, 클라이언트 요청을 받을 준비 상태가 된다.
   > 하지만 이 시점에는 아직 디바이스와 연결된 세션은 생성되지 않으며, 단순히 “나는 준비됐어! 명령 줘!” 상태로 대기 중이다.
🔹 테스트 코드에서의 세션 생성
   > 테스트 코드가 실행되면, 코드 내에 설정된 capabilities 정보를 기반으로 Appium 클라이언트가 Appium 서버에 POST /session 요청을 보낸다.
   > Appium 서버는 해당 요청을 받아 디바이스에 연결하고, 고유한 세션 ID를 생성한 뒤 이를 클라이언트에 반환한다.
   > 이후 테스트 코드는 이 세션을 통해 명령을 디바이스에 전달하고, 디바이스에서 수행된 결과는 다시 Appium 서버를 통해 테스트 코드로 반환된다.
   > 세션은 테스트 실행 시마다 새로 생성되며, 기존 세션을 재사용하려면 명시적으로 session ID를 테스트 코드에 전달해야 한다.
🔹 Appium Inspector의 역할
   > Appium Inspector는 테스트 코드를 작성하기 전에 디바이스의 UI 구조를 시각적으로 탐색하거나, 요소의 속성 값을 확인할 수 있도록 도와주는 도구다.
   > Inspector 역시 자체적으로 POST /session 요청을 보내며, 이때 Appium 서버는 별도의 세션을 생성한다.
   > 따라서 Inspector와 테스트 코드는 기본적으로 각각 독립된 세션에서 작동한다. 
   > 단, Inspector에서 생성한 세션 ID를 복사해 테스트 코드에 직접 지정하면 같은 세션을 공유할 수 있다.
 
⬇️ Appium 개념에 대한 부분은 아래 글을 참고

[엘리스 SW QA 트랙 7주차] 학습 내용 정리 및 회고 (Python을 활용한 테스트 자동화)

---

📌 4/18 - 1일차 회고 (첫 회의 & apk 연동 삽질)

오늘은 매니저님께서 사이드 프로젝트 전용 디스코드 방을 개설해주셨고, 스터디원들과 본격적으로 여러 사항들을 논의할 수 있었다. 논의된 내용은 모두 Notion에 정리하여 공유하고, 각자 작업 내용을 명확히 파악할 수 있도록 했다.
 
🔍 adb logcat을 활용한 크래시 로그 분석
제공받은 APK 파일을 Android Studio의 가상 디바이스에 드래그 앤 드롭하여 설치한 뒤 실행을 시도했는데, 앱이 실행되자마자 자꾸 강제 종료되는 현상이 발생했다.
 
앱 크래시 원인을 파악하기 위해 터미널에 adb logcat > crashlog.txt 명령어를 입력한 뒤, 문제의 앱을 실행하고 Ctrl + C를 눌러 로그 수집을 중지했다. 이후 notepad crashlog.txt 명령어를 통해 수집된 로그를 메모장으로 열어 크래시 원인을 파악했다.

java.lang.UnsatisfiedLinkError: dlopen failed: "/data/data/com.example.travel_on_final/app_lib/libflutter.so" is for EM_AARCH64 (183) instead of EM_X86_64 (62)

crashlog.txt를 통해 분석한 결과, 앱이 강제 종료되는 이유는 명확했다.
 
즉, 해당 Flutter 앱은 ARM64 아키텍처에서만 동작하도록 빌드되어 있었고, 내가 사용한 에뮬레이터는 x86_64 기반이었기 때문에, 핵심 네이티브 라이브러리인 libflutter.so를 불러오지 못해 앱이 죽는 현상이 발생한 것이었다.
 
💡 ARM64 대응 가상 디바이스 생성
이 문제를 해결하기 위해 Android Virtual Device(AVD)를 새로 생성했다. System Image는 'Google Play ARM 64 v8a System Image'로 설정하여, ARM64 아키텍처에 맞는 환경을 구성했다. 그런데 새로 만든 가상 디바이스를 실행하려 하자, 다음과 같은 에러 메시지가 출력되며 실행 자체가 되지 않았다.

The emulator process for AVD Medium_Phone_2 has terminated.

문제의 원인은 내 노트북이 Intel 기반 CPU를 사용하고 있다는 점이었다. ARM 기반 시스템 이미지를 에뮬레이션하기 위해선 하드웨어 가상화 지원이 필요하며, 이 조건을 충족하지 못한 것이다. 게다가 나는 아이폰을 사용하고 있어서, 테스트를 위한 안드로이드 실기기 설치도 불가능한 상황이다. 혹시나 해서 AMD CPU를 사용하는 본가 데스크탑에 원격 접속하여 동일한 작업을 시도해보았지만, 에뮬레이터 실행은 여전히 실패했다.
 
최후의 수단으로, Flutter 개발 환경을 직접 설치한 뒤, x86_64 기반으로 앱을 다시 빌드해보려 시도했다. 그러나 빌드 과정은 의외로 복잡했고, 설정 충돌과 의존성 오류가 반복되면서 무려 4시간 이상을 소모했음에도 불구하고 결국 실패로 끝나고 말았다.

---

📌 4/19 - 2일차 회고(에뮬레이터 실패 -> 실기기 전환 및 APK 설치 완료)

🌀 에뮬레이터로는 연동 실패… 결국 실기기 구매
오늘은 스터디원분이 공유해주신 Udemy Postman 강의를 통해 Postman을 복습한다고 사이드 프로젝트에 많은 시간을 투자하지 못했다. 그래서 약 오후 7시쯤부터 다시 APK 연동을 시도했는데, 여전히 되지 않았다. 계속 실패가 반복되자, 화가 치밀어 결국 성수에서 당근마켓을 통해 '갤럭시 와이드4'를 4만 원에 구매했다.
 
📱 Android 실기기 환경 설정
갤럭시 와이드4 기기를 세팅하며 다음과 같은 절차를 거쳤다

1. 개발자 옵션 활성화
 : 설정 > 휴대전화 정보 > 소프트웨어 정보 > 빌드번호 7번 연속 터치
2. USB 디버깅 On
 : 설정 > 개발자 옵션 > USB 디버깅 활성화
3. PC와 USB-C로 연결
 : 터미널에 adb devices 명령어 실행 시, 기기의 Serial Number가 뜨면 연결 완료

 
🛠️ APK 파일 수동 설치 및 Appium 연동

 
이후 cmd 창에서 아래 명령어로 직접 APK를 설치했다

adb install {apk 경로}

 
설치가 완료된 뒤에는 이전에 정리했던 내용, "📌 4/17 - Appium 특강"의 "📱 에뮬레이터 및 Inspector" 연동 부분을 참고하여 실기기와 Appium을 연동했다. 이때 Inspector 설정의 JSON Representation에서 "appium:deviceName" 값에 adb devices 시 출력된 기기의 Serial Number를 입력해야 정상적으로 연결된다.
 
🔍 초기 화면 탐색 – XPath 위주가 될 듯?
앱이 정상적으로 실행되자, 메인 화면의 UI 요소들을 대략적으로 훑어봤다. 대부분의 요소가 resource-id나 명확한 속성이 없어 보였고, 결국에는 XPath로 접근해야 할 가능성이 높다는 느낌을 받았다. 자동화 스크립트 작성에 꽤나 까다로운 작업이 예상된다.

---

📌 4/20 - 3일차 회고 (앱 주요 기능 파악)

오늘은 Jest를 복습한다고 사이드 프로젝트에 많은 시간을 투자하지 못했다. 그렇지만 Appium 환경 세팅은 모두 마무리된 상태였기 때문에, 오늘은 본격적으로 앱의 주요 기능들을 파악하는 데 집중할 수 있었다. 
 
🗂️ 참고 자료

• README 파일
• 시연 영상

위 두 가지를 기반으로 기능 흐름을 정리해봤고, 기획서나 와이어프레임 등 다른 문서 파일들은 권한 만료나 평가판 종료 등의 이유로 제공되지 않았다. 사실 문서가 부족하다 보니, 기능이 어떤 결과를 기준으로 나타나는지, 이 동작이 의도된 것인지 오류인 것인지를 파악하기가 쉽지 않았다. 그래서 현재는 실제 앱을 실행해보고, 직접 조작하며 체감하는 방식으로 기능 분석을 진행하고 있다. 기획 문서 없이 기능을 파악한다는 것이 쉽지만은 않지만, 오히려 유저 입장에서 기능을 바라보는 연습이 된다는 점에서 나름의 의미가 있다고 느낀다.

---

📌 4/21 - 4일차 회고 (툴 선정부터 기능 분담까지 초기 설계 완료)

 
오늘은 본격적으로 프로젝트 진행을 위한 기초 설계를 완료한 날이었다. 다만, apk가 에뮬레이터에 설치되지 않는 문제로 인해 공기계가 없는 팀원분들 중 약 4명 정도가 프로젝트에서 이탈하게 되었다. 아쉬운 일이지만, 디바이스 의존도가 높은 Appium 특성상 어쩔 수 없는 상황이라고 생각한다.
 
🛠️ 프로젝트 협업 툴 결정

• TC/시나리오: Google Spreadsheet 
• 협업 채널: Discord + 스터디 온라인 강의실 (Slack은 추후 도입 여부 결정 예정)
• 이슈 관리: Jira
• 문서 정리: Confluence
• 코드 관리: GitHub

 
📄 기능 분담 및 TC 작성 방식 결정

• 주말 동안 각자 파악한 앱 기능 내용을 Confluence 문서로 통합 정리했다. (GPT의 도움을 받았다.)
• 이후 사다리 타기 방식으로 기능을 분담했고, 본인은 홈 탭을 담당하게 되었다.
• 각자 자신이 맡은 기능을 기준으로 TC/시나리오를 직접 작성하기로 했다.
• TC 작성 방식은 자동화를 염두에 두고, 시나리오 중심의 구조로 통일했다.

 

📌 개인적으로 수행한 작업들

• Notion에 정리되어 있던 초기 문서들을 전부 Confluence로 이관
• 팀원이 제공한 포맷을 바탕으로 Google Spreadsheet에 테스트 케이스 기본 틀 구성
• 다른 팀원들을 위해 시나리오 기반 테스트 케이스 작성 전략 정리 문서 작성 및 공유

---

📌 4/22 - 5일차 회고 (테스트 시나리오 작성 완료)

 
오늘은 각자 맡은 기능에 대한 테스트 시나리오 작성을 완료한 날이었다. 본인은 앱을 직접 실행해보며 실제 동작 흐름을 눈으로 확인한 뒤, 가능한 한 명확하고 구체적인 시나리오를 작성했다.
 

 
💬 시나리오 피드백 시간

• 작성한 시나리오들을 Google Spreadsheet에서 서로 피드백을 주고받았다.
• 하나씩 확인하고 의견을 나누는데, 스프레드시트 셀 안에 각자 한 줄씩 코멘트를 남기는 방식이 너무 귀엽고 훈훈했다.
• 단순히 온라인 댓글이 아닌, 같은 화면을 바라보며 직접 문서를 고쳐나가는 과정에서 협업의 즐거움을 다시금 느낄 수 있었다.

 

시나리오 작성은 완료! ✨ 우리는 시나리오를 먼저 작성한 뒤, 이를 바탕으로 테스트 케이스(TC)를 작성하기로 했다.
 

그리고.. 우리 팀원분들 너무 좋아.. 훈훈해.. 나 이런 거 좋아하네.. 🥰
다들 정말 열심히 하신다. 너무 좋다. 그래서 나도 자연스럽게 더 열심히 하게 된다.
수업을 듣고, 복습 및 정리도 하면서 프로젝트까지 병행하려니, 생각보다 쉽지 않다는 걸 새삼 느끼는 요즘이다.

---

📌 4/23 - 6일차 회고 (테스트 케이스 작성 시작)

 

처음에는 테스트 케이스 작성 방식에 대해 이렇게 생각했다. 우리는 "TC 하나당 테스트 함수 하나"를 작성하기로 팀 내에서 정했지만, 내가 맡은 TC들은 사전 조건과 수행 단계가 대부분 동일했고, 단지 클릭해야 하는 지역 필터 요소만 다를 뿐이었다. 그래서 나는 “이건 테스트 함수 하나로 처리하고, 파라미터만 다르게 주면 되지 않나?”라고 생각했다. 중복되는 코드를 반복해서 작성하는 게 오히려 비효율적이라 느꼈기 때문이다.
 

하지만 팀원들과 논의한 결과, 테스트 코드에서는 파라미터화를 활용하더라도, TC 문서에서는 각각의 기대 결과가 다르기 때문에 개별적으로 작성하는 게 맞다는 의견이 나왔다. 예를 들어, 선택한 필터에 따라 결과로 나와야 하는 지역명이 다르고, 이 기대 결과 자체가 TC마다 다르기 때문에 문서 기준에서는 분리하는 게 타당하다는 것이었다. 아직까지 자동화를 고려한 TC 설계 경험이 많지 않아서 처음엔 헷갈리기도 했지만, 이렇게 팀원들과 의견을 나누고 조율하는 과정 자체가 큰 배움이 되었다고 느낀다. 정답은 없지만, 서로 다른 시각에서 접근해보는 경험이 쌓이다 보면 점점 더 나은 기준이 생길 것이라 믿는다.

---

📌 4/24 - 7일차 회고 (테스트 케이스 작성 완료)

 

오늘 수업 주제를 미리 확인했을 때, CI/CD는 분명 시간도 오래 걸리고 복습 및 정리까지 하면 꽤 벅찰 것 같았다. 그래서 어제 아픈 몸을 이끌고, 저녁 시간에 테스트 케이스 대부분을 미리 작성해두었다. 어제 하루 종일(오전/오후) 수업을 쉬고 푹 쉬어서 그런지, 그리고 약을 이틀 연속 꼬박꼬박 챙겨 먹어서 그런지, 침도 못 삼킬 정도로 아팠던 목이 오늘은 꽤 괜찮아졌다 ㅋㅋ
 
아무튼 덕분에 오늘은 남은 테스트 케이스까지 약 3시간 만에 모두 마무리할 수 있었다. 다른 팀원분들도 작성을 마치면, 이제 본격적으로 디렉토리 구조, 브랜치 전략 등 코드 작성을 위한 환경 세팅 논의에 들어갈 예정이다. 그리고 드디어.. Appium 자동화 코드 작성을 시작하게 될 것 같다! 다만 한 가지 걱정되는 건, Appium이 Selenium과 얼마나 다를까? 기본 개념은 익숙한데, 실제로 해보면 또 다를 수도 있으니 부딪히면서 익혀봐야 할 것 같다.

---

📌 4/25 - 8일차 회고 (디렉토리 구조 및 네이밍 규칙 확정)

 

쉬는 시간에 다른 분들 테스트 케이스를 검토할 겸 Google 스프레드시트에 들어갔다가 깜짝 놀랐다.
스터디원분 중 한 분이 요약 관련 내용을 정말 깔끔하게 정리해주셨다. 완전 능력자!
 

오늘은 팀원들과 함께 초기 디렉토리 구조를 비롯해 페이지 파일명, 페이지 클래스명, 테스트 파일명, 테스트 시나리오명, 테스트 케이스명, 브랜치 명명 규칙, PR 요청 방식 등을 모두 논의하고 결정했다. 이후 나는 논의한 내용을 따로 Confluence 문서에 정리해두었다. 이제 본격적으로 코드 작성을 시작할 차례다!

---

📌 4/28 - 11일차 회고 (초안 통합 기반 기본 환경 세팅 완료)

 

오늘은 주말 동안 팀원 분들께서 작성하신 .env, capabilities.json, conftest.py, helpers.py 초안을 합치는 작업을 진행했다. 그리고 별도로, 오늘 강의에서 배운 내용을 참고해 helpers.py 안에 있던 요소 찾기/클릭 관련 기능을 BasePage.py로 분리하는 작업도 추가로 진행했다. 그런데 여전히 helpers 구조가 마음에 들지 않는다. 아무리 생각해도 utils의 helpers가 BasePage를 상속하는 건 적절하지 않은 것 같다. 이 부분을 고민하느라 하루가 다 가버렸고, 어느새 오후 11시를 넘겼다. 시간은 많이 들였지만 뾰족한 해결책을 찾지 못해 아쉽다.
 
그래도 .env와 capabilities.json 구성은 꽤 만족스럽다. os.getenv를 사용해 .env 파일의 변수를 불러오는 방법을 새로 알게 되었고, 드라이버 생성/삭제 과정과 로그인 흐름까지 자연스럽게 연결된 점도 마음에 든다. 결국 지금 가장 큰 과제는 helpers 구조를 제대로 정리하는 것이다.

---

📌 4/29 - 12일차 회고 (helpers 개선 & 자동화 코드 작성 시작)

 

점심시간을 이용해서 어제 하루종일 고민했던 개선 사항을 말씀 드렸고, 다행히 다른 팀원 분들도 공감해주셔서 나의 의도대로 수정할 수 있었다. 결국 helpers.py 내 Helper 클래스가 BasePage 클래스를 상속받는 것이 아닌, 별도의 클래스 없이 단순히 로그인 유틸 함수만 작성하는 형태로 변경했다. 이제 내가 맡은 홈 탭의 요소들을 찾고, 테스트 함수들을 작성하면 된다. 오늘은 홈 탭과 관련된 요소들을 찾고, 홈 탭 테스트를 위해 홈 페이지에 스와이프 관련 함수를 추가하고, 작성한 테스트 케이스를 바탕으로 테스트 함수도 7개정도 완성했다.

---

📌 4/30 - 13일차 회고 (요소 관련 피드백 반영 & 테스트 함수 추가)

 

오늘은 아침에 일어나자마자 어제 팀원분들이 올린 PR을 확인하고, 코드 리뷰하면서 코멘트를 달았다. 나뿐만 아니라 다른 팀원분들도 서로 피드백을 주고받으면서 각자 개선 방향을 이야기해줬고, 그 과정이 꽤 유익했다. 그중에 한 팀원분이 XPath 대신 id나 content-desc가 있는 경우에는 ACCESSIBILITY_ID로 접근할 수 있다는 꿀팁을 알려주셨다. 덕분에 내가 맡은 홈 탭 요소 중 일부를 XPath 대신 id 기반으로 깔끔하게 수정할 수 있었다. 이 부분은 확실히 가독성도 좋아지고, 테스트 안정성 측면에서도 더 나은 선택이라고 느꼈다. 요소 수정이 끝난 뒤에는 테스트 함수도 몇 개 추가했다. 그런데 인기 관광지 혼잡도 영역에서 계속 "데이터를 불러오는데 실패했습니다" 오류가 떠서 예상보다 시간이 많이 지체되었고, 결국 작업을 조금 급하게 마무리할 수밖에 없었다.
 
추가로, 몇몇 팀원분들이 요소들을 클래스 단위로 구분해서 정의하고 계셔서, 이 부분에 대해서도 어떤 방식이 더 효율적인지 코멘트를 주고받았다. 아직 명확한 기준은 없지만, 변수 단위로 할지, 관련된 요소끼리 클래스로 묶을지 더 고민해볼 필요가 있을 것 같다. 마지막으로 오늘 팀원 덕분에 @staticmethod 기능에 대해서도 새롭게 알게 되었다. 이렇게 서로 코드 보면서 자연스럽게 배워가는 흐름이 정말 좋다고 느꼈다.

---

📌 5/1 - 14일차 회고 (mark 추가 & 테스트 함수 추가)

 

오늘은 공휴일이라 오랜만에 늦잠을 자고, 하루 종일 사이드 프로젝트에 집중할 수 있었다. TMI 하나 풀자면, 비를 뚫고 공유 오피스에 도착했는데 공기계와 연결선을 깜빡하고 두고 온 거다. 왕복 30분을 허비하고 옷도 다 젖었다. 진짜 최악의 효율...
 
지금까지는 개발 및 테스트가 끝난 코드에 @pytest.mark.skip 데코레이터를 달아 구분해왔는데, 외부 요인(데이터 로딩 오류)으로 개발이 불가능한 테스트 코드도 같은 방식으로 처리하다 보니 서로 구분이 되지 않았다. 그래서 이런 경우를 따로 구분할 수 있도록 팀원분들께 새로운 mark를 추가하자고 제안드렸고, 다들 동의해주셔서 반영했다. 덕분에 테스트 상태를 더 명확히 파악할 수 있게 되었다.
 
수업이 없는 날이라 체력을 100% 사이드 프로젝트에 집중할 수 있었고, 그만큼 많은 작업을 해낼 수 있었다. 이번 주말까지는 꼭 코드 개발을 마무리하고 싶은데, 데이터 로딩 오류가 여전히 발목을 잡고 있다. 이 오류가 발생하면 요소가 꼬이거나 결과 데이터가 나타나지 않아 제대로 된 테스트 검증이 어려운 상황이다. 이 문제가 해결되어야 테스트 함수 코드 작성이나 테스트 실행이 가능할 텐데.. 걱정이 크다.
 
5월 2일 Jenkins 특강 이후에는 2차 프로젝트 관련 OT가 예정되어 있고, 이후 팀별 디스코드 채널이 개설되면 5월 7일 전까지 각 팀이 본격적인 프로젝트 준비에 들어갈 가능성이 있다. 그렇기 때문에 현재 진행 중인 사이드 프로젝트를 마무리하자고 강요할 수는 없는 상황이다. 2차 스터디는 1차보다 범위가 넓고, API 및 성능 자동화 테스트는 물론 CI/CD도 필수 요소이기 때문에 더 많은 노력이 필요할 것으로 보인다. 하지만 이번 사이드 프로젝트는 Appium 경험을 쌓기 위한 목적이었고, 그 과정에서 파일 구조를 비롯해 다양한 부분에서 발전을 이뤄냈다는 점에서 충분히 만족스럽다. 그래도 2차 스터디 전까지 최대한 해보는 걸 목표로 삼아보려 한다.

---

📌 5/2 - 15일차 회고 (데이터 로딩 오류 일부 완화로 관련 테스트 함수 추가)

 
오늘은 Jenkins 특강에 이어 2차 팀 프로젝트 OT가 진행되었고, OT 이후에는 팀원들과 오프라인 일정에 대해 이야기를 나누느라 하루 종일 정신이 없었다. 막 테스트 함수 작성을 시작하려던 찰나, 2차 팀 프로젝트 관련 노션 공지가 올라와 개발 가이드와 디렉토리 구조를 읽고 팀원들과 의견을 나누느라 많은 시간을 할애하지 못했다.
 
그나마 다행인 점은, 오늘 스터디 팀원분께서 데이터 로딩 오류가 다소 완화된 것 같다고 하셔서 확인해보았고, 실제로 인기 관광지 혼잡도 관련 데이터 로딩 문제는 해결된 상태였다. 덕분에 해당 기능에 대한 테스트 함수는 전부 완성할 수 있었다. 하지만 지역 탐방 페이지는 여전히 데이터 로딩 오류가 지속되고 있다. 로딩만 된다면 당장이라도 구현할 자신이 있는데.. 정말 답답하고 짜증 난다.

---

📌 5/3 - 16일차 회고 (홈 자동화 테스트 구현 완료)

 
오늘은 지역 탐방 페이지 관련 데이터 로딩 문제가 해결되어 자동화 테스트 함수를 작성할 수 있었다. 그런데 예상치 못한 문제가 발생했다. 시/도, 장소 유형 필터는 정상적으로 작동하는 것처럼 보였지만, 시/군/구 필터는 여전히 정상 동작하지 않아 테스트 결과가 자꾸 Fail로 뜨는 상황이었다. 물론 테스트가 실패할 때마다 짜증이 나긴 하지만, 앱 기능 자체가 정상적으로 구현되지 않았다면 어쩔 수 없는 일이다.
 
또한, 다른 탭에서 특정 동작을 수행해야만 검증이 가능한 테스트들은 자동화가 어렵기 때문에, 해당 케이스들은 Google Spreadsheet 상에서 Test Type을 '자동화'가 아닌 '수동'으로 처리하도록 기록해두었다. 그리고 추가적으로, 전국 날씨 위젯 정보가 어디에서 불러오는지, 정상적으로 불러왔는지, 인기 관광지 혼잡도는 어떤 방식으로 갱신되는지, 새로고침 버튼 클릭 시 최신 정보가 정말 반영되는지 등의 항목들은 기능 명세서나 API 문서에서 정보가 부족하여 정확한 기준을 세우기 어려웠다. 이러한 케이스들도 일단은 수동 테스트로 처리하도록 했다.
 
단, 앞서 언급한 다른 탭에서의 선행 동작이 필요한 테스트의 경우에는, 테스트 자동화 흐름 안에서 선행 시나리오를 먼저 실행하고, 그 상태에서 검증하고자 하는 테스트를 이어서 수행하는 방식으로 해결할 수 있을 것 같다. 예를 들어, 알림 관련 기능처럼 특정 조건이 선행되어야만 알림이 표시되는 경우, 그 조건을 먼저 충족시킨 뒤 테스트를 수행하는 흐름을 구성하면 자동화도 가능해진다.
 
pytest는 기본적으로 테스트 파일과 함수들을 알파벳 순서로 실행하기 때문에, 이러한 선행 조건이 필요한 테스트를 자동화하려면 파일명이나 함수명에 실행 순서를 반영하거나, pytest-order와 같은 플러그인으로 명시적인 순서 제어가 필요하다. 물론 테스트는 순서에 의존하지 않도록 설계하는 것이 가장 이상적이지만, 현실적으로는 불가피한 경우도 많기 때문에 이런 방식으로 유연하게 대응하는 것이 현실적인 접근이라 생각된다. 하지만 현재 사이드 프로젝트 일정상 시간 여유가 많지 않아, 이번에는 해당 아이디어를 직접 구현해보지는 못할 것 같다. 다음에 시간이 더 허락된다면 꼭 도전해보고 싶은 과제 중 하나다.
 
현재는 2차 팀 프로젝트 준비도 병행해야 하는 상황이라, 사이드 프로젝트에 많은 시간을 투자하기 어려운 상황이다. 그래서 오늘은 테스트 함수 작성을 마무리하는 것으로 작업을 마쳤고, 남은 기간 동안에는 parameterization으로 선언된 테스트 데이터를 testdata 폴더로 정리하고, Jenkins 연동 작업을 함께 진행할 계획이다.

---

📌 5/4 - 17일차 회고 (테스트 데이터 파일 분리)

 
하드코딩되고 반복되는 테스트 데이터를 별도 .py 파일로 분리하여 재사용성과 유지보수성 향상하고자 했다.
그래서 수업 시간에 배웠던 방식대로 json 파일로 분리하려고 했는데, 생각보다 복잡한 문제가 생겼다.
 
예를 들어 아래처럼 단순한 문자열 리스트라면 문제가 없다.

@pytest.mark.parametrize("expected_regions", [
    ["서울", "부산", "대구", "인천", "광주", "대전", "울산", "경기", "강원", "제주"]
])

 
하지만 문제는 아래와 같이 locator 객체를 포함하는 테스트 데이터에서 발생했다.

@pytest.mark.parametrize("locator, region_name", [ 
    (HomeLocator.CONGESTION_SEOUL_BTN, "서울"), # test_hp_05_05
    (HomeLocator.CONGESTION_BUSAN_BTN, "부산"), # test_hp_05_06
    # ...
])

 
json은 텍스트 기반 포맷이기 때문에 문자열, 숫자, 배열, 딕셔너리 정도만 저장할 수 있고, 파이썬의 변수나 객체는 저장이 되지 않는다.
즉, 아래와 같이 문자열로 저장하고 코드에서 getattr()으로 변환하는 번거로운 작업이 필요하다.

# json
{ "city": "REGION_TOUR_CITY_DAEGU" }

# python
getattr(HomeLocator, "REGION_TOUR_CITY_DAEGU")

 
이는 너무 귀찮다. 테스트 데이터를 분리하려다 더 복잡해지는 아이러니한 상황에 직면한 것이다.
그래서 생각을 바꿨다. 꼭 json이어야 할 이유가 없지 않나? 그냥 .py 파일에 데이터를 정의하고 import해서 쓰면 훨씬 간단하지 않을까?
 
💡 테스트 데이터를 Python 파일로 분리

from src.utils.locators import HomeLocator

# 📌 인기 관광지 혼잡도
# test_hp_05_04 (인기 관광지 혼잡도의 지역 필터 중 '전체' 필터 확인)
expected_regions = ["서울", "부산", "대구", "인천", "광주", "대전", "울산", "경기", "강원", "제주"]

# test_hp_05_05 ~ test_hp_05_14 (인기 관광지 혼잡도의 지역 필터 중 '서울/부산/대구/인천/광주/대전/울산/경기/강원/제주' 필터 확인)
locator__region_name = [ 
    (HomeLocator.CONGESTION_SEOUL_BTN, "서울"), # test_hp_05_05
    (HomeLocator.CONGESTION_BUSAN_BTN, "부산"), # test_hp_05_06
    # ...
]

 
💡 테스트 코드에서의 테스트 데이터 사용

def test_hp_05_04(...):
    ...
    assert any(region in first_result_desc for region in HomeTestData.expected_regions)

@pytest.mark.parametrize("locator, region_name", HomeTestData.locator__region_name)
def test_hp_05_05(...):
    ...

 
처음엔 expected_regions처럼 단순한 문자열 리스트까지 분리할 필요가 있을까 고민했지만, 향후 지역이 추가될 경우 해당 테스트 데이터도 수정이 필요하게 된다. 그럴 때 테스트 코드보다 데이터 파일만 수정하면 되니, 오히려 유지보수가 더 쉬워질 것이다.
 
테스트 데이터를 분리하면서 깨달은 것이 있다면, "테스트 데이터에 맞는 포맷을 사용하는 것이 자동화의 효율성과 유지보수성을 결정짓는다"는 점이다. 예를 들어 단순한 문자열이나 숫자 등은 json, csv 같은 포맷으로도 충분히 표현 가능하다. 하지만 테스트 데이터에 객체가 포함된다면 복잡한 파싱보다는 .py 파일에 정의하고 import하는 방식이 훨씬 간단하고 안전하다. 이번 경험을 통해 테스트 자동화를 할 때는 데이터의 구조, 테스트 코드의 실행 방식, 팀의 협업 방식까지 모두 고려해서 가장 유지보수성 좋은 방식으로 구조화하는 것이 중요하다는 사실을 직접 체감할 수 있었다.

---

📌 5/5 - 18일차 회고 (YAML 제작 & Jenkins 연동 & Jira 이슈 등록)

 
1차 팀 프로젝트 당시, Jenkins와 Git 연동에 성공한 경험이 있다. 처음에는 공식 Jenkins 이미지를 그대로 사용했지만, 팀 프로젝트 코드를 실행하려면 여러 도구를 설치해야 해서 번거로웠다. 이를 해결하기 위해 "Jenkins + Git Plugin + GitLab Plugin + Python3 + 가상환경 + Chrome"이 포함된 커스텀 Dockerfile을 직접 작성해 이미지로 빌드했고, 이를 통해 팀원들과 동일한 개발 환경을 빠르게 구축할 수 있었다.
 
반면, 이번 사이드 프로젝트는 GitLab이 아닌 GitHub 기반으로 진행되었고, 1차 팀 프로젝트 당시에는 잘 몰랐던 볼륨 개념이나 docker-compose.yaml 같은 구성 방식을 코치님이 진행하신 JMeter CI 연동 실습을 통해 새롭게 알게 되었다. 그래서 이번에는 단순히 Jenkins 이미지를 사용하는 데 그치지 않고, 환경 설정 자동화와 재현성까지 고려한 더 발전된 YAML 구조를 직접 작성해보려 한다.
 
⬇️ 1차 팀 프로젝트 회고 글

[엘리스 SW QA 트랙 9~10주차] 1차 팀 프로젝트 회고

 
⬇️ 1차 팀 프로젝트 당시 Dockerfile

FROM jenkins/jenkins:lts

USER root

# 필수 도구 설치
RUN apt-get update && apt-get install -y \
    python3 python3-pip python3-venv \
    git \
    curl wget unzip gnupg2 && \
    apt-get clean

# Chrome 설치
RUN wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb && \
    apt-get install -y ./google-chrome-stable_current_amd64.deb && \
    rm google-chrome-stable_current_amd64.deb

# Git, GitLab 플러그인 직접 설치
RUN jenkins-plugin-cli --plugins \
    git \
    gitlab-plugin \
    workflow-aggregator \
    credentials-binding

USER jenkins

 
🔥 dockerfile -> yaml
1차 팀 프로젝트 당시에는 Jenkins에 필요한 도구들을 직접 설치한 Dockerfile을 작성했고, 이를 바탕으로 아래처럼 수동으로 이미지를 빌드했다.

sudo docker build -t {이미지 이름} .

 
그리고 다시 그 이미지를 기반으로 컨테이너를 실행하기 위해, 아래처럼  직접 명령어를 입력해 컨테이너를 띄웠다.

sudo docker run -d -p{외부 포트}:{컨테이너 내부 포트} -p 50000:50000 --name {컨테이너 이름} {이미지 이름}

이 과정은 매번 타이핑도 번거롭고, 실수하거나 옵션을 빼먹으면 처음부터 다시 해야 하는 불편함이 있었다. 무엇보다 Jenkins 데이터를 유지하기 위한 볼륨 개념조차 모르던 시절이라, 도커 데스크탑을 켜보면 무작위 해시처럼 생긴 이름의 볼륨이나 리소스들이 떠 있었고, “이건 뭐지?” 싶어 아무 생각 없이 지운 적도 있었다. 하지만 지금은 컨테이너는 실행 환경, 볼륨은 데이터 저장소이며, 두 개념을 분리해서 이해하고 직접 이름을 붙여주는 것이 관리에 있어 얼마나 중요한지 잘 알고 있다.
 
이후, 코치님이 진행하신 JMeter CI 연동 실습을 통해 docker-compose.yaml이라는 도구를 새롭게 알게 되었고, 이제는 Dockerfile로 이미지를 정의하고, 그걸 yaml에서 참조해서 전체 실행 환경을 한 줄로 자동 구성할 수 있다는 사실을 명확히 이해하게 되었다.

docker-compose up -d --build

 
이 명령어 하나만으로 이미지 빌드부터 컨테이너 실행, 포트 설정, 볼륨 마운트까지 모두 자동화된다. 이제는 볼륨과 컨테이너에 직접 이름을 지정할 수 있기 때문에, 도커 데스크탑에서도 어떤 리소스가 어떤 역할을 하는지 쉽게 식별할 수 있게 되었고, 실수도 줄었다. 이 외에도 .gitignore에 .env 파일과 capabilities 파일이 포함되어 있기 때문에, Jenkins에서는 해당 파일들을 credentials의 Secret file로 등록해 수동으로 추가해줘야 한다.
 
⬇️ 사이드 프로젝트 Dockerfile

FROM jenkins/jenkins:lts

USER root

# 필수 패키지 + OpenCV 의존성(libGL)
RUN apt-get update && apt-get install -y \
    python3 python3-pip python3-venv \
    curl unzip git \
    libgl1-mesa-glx \
    software-properties-common apt-transport-https \
    && apt-get clean

# pip 최신화
RUN python3 -m pip install --upgrade pip --break-system-packages

# Jenkins GitHub 관련 플러그인만 설치
RUN jenkins-plugin-cli --plugins \
    git \
    github \
    workflow-aggregator \
    credentials-binding

USER jenkins

 
⬇️ 사이드 프로젝트 docker-compose.yaml

version: "3.8"

services:
  jenkins:
    image: appium_jenkins
    build:
      context: .
      dockerfile: Dockerfile
    container_name: appium_jenkins
    restart: unless-stopped
    ports:
      - "8080:8080"
      - "50000:50000"
    volumes:
      - appium_jenkins:/var/jenkins_home
      - /var/run/docker.sock:/var/run/docker.sock
    user: root

volumes:
  appium_jenkins:

 
⬇️ 사이드 프로젝트 Jenkinsfile

pipeline {
    agent any

    environment {
        ENV_FILE = credentials('env-file')                  // .env 파일
        CAP_FILE = credentials('capabilities-file')         // capabilities.json 파일
    }

    stages {
        stage('Run Appium Tests') {
            steps {
                sh '''
                    # 기존 파일이 이미 존재할 경우 삭제
                    rm -f src/config/.env
                    rm -f src/config/capabilities.json

                    # Credentials로부터 복사
                    cp "$ENV_FILE" src/config/.env
                    cp "$CAP_FILE" src/config/capabilities.json

                    # 가상환경 설정 및 테스트 실행
                    python3 -m venv venv
                    . venv/bin/activate
                    pip install -r requirements.txt
                    pytest tests/test_Home.py
                '''
            }
        }
    }
}

 
⬇️ 사이드 프로젝트 requirements.txt

pytest
Appium-Python-Client
python-dotenv
selenium
pytz
requests
opencv-python

 
이후 Appium 서버를 실행하고 기기를 연결한 뒤 Jenkins 빌드를 수행했지만, 이 과정에서 문제가 발생했다.
 
기존 .env 파일에는 다음과 같이 Appium 서버 주소가 설정되어 있었다.

APPIUM_SERVER_URL="http://127.0.0.1:4723"

 
하지만 문제는 바로 이 127.0.0.1 주소 때문이다. Appium 서버를 직접 cmd에서 실행시키면 다음과 같은 문구가 표시된다.

http://127.0.0.1:4723/ (only accessible from the same host)

즉, 이 주소는 "같은 호스트(머신) 내에서만 접근 가능하다"는 뜻이다.
 
반면, 그 아래에 나열된 다른 주소들은 다음과 같은 문구와 함께 제공된다:

You can provide the following URLs in your client code to connect to this server:
http://192.168.xx.xx:4723/ ...

이러한 IP 주소들은 실제 네트워크 상에서 접근 가능한 주소들이기 때문에, Docker 컨테이너나 Jenkins 환경, 혹은 다른 테스트 실행 환경에서도 Appium 서버에 접속할 수 있다.
 
정리하자면:

• 127.0.0.1 = 루프백 주소(localhost)
  -> Appium 서버가 실행된 같은 컴퓨터 안의 프로그램만 접근 가능
• 반면 192.168.xx.xx와 같은 주소
  -> 같은 네트워크 상의 다른 환경 (예: Docker 컨테이너, Jenkins 등)에서도 접근 가능

 
따라서 Jenkins나 pytest가 Docker 컨테이너나 다른 가상 환경에서 실행되고 있다면, 해당 환경의 127.0.0.1은 Appium 서버가 아닌 자기 자신을 가리키게 된다. 이 때문에 Appium 서버에 연결할 수 없게 되고, Connection refused 에러가 발생한 것이다.
 

주소만 수정해주니 정말 문제없이 잘 돌아간다! 이제는 Jenkins 연동이 크게 어렵지 않게 느껴질 만큼, 나 자신이 많이 성장했음을 실감한다. 지난 1차 팀 프로젝트 당시 온갖 오류를 겪으며 연동 방법을 익혔던 경험 덕분에, 이번에는 훨씬 수월하게 설정할 수 있었고 그래서 더욱 뿌듯하다. 물론 이번 사이드 프로젝트는 공유 서버를 제공받지 못해 ngrok을 이용할 수밖에 없지만, 다음 2차 프로젝트에서는 HTML 리포트까지 연동해보면 진짜 완벽한 Jenkins 자동화가 완성될 것 같다. 이번에는 YAML 작성과 Appium 연동만으로도 충분히 만족스러운 결과였다.
 

프로젝트 초반, 팀원분께서 본인이 실무에서 사용하시던 방식대로 Jira 이슈 등록용 템플릿을 미리 만들어주셨다. 거기에 더해 사용 방법도 영상으로 직접 찍어서 공유해주시고, 문서로도 정리해주셨다. 정말 능력자 그 자체였다. 사실 나도 Jira 이슈 등록을 깜빡하고 있었는데, 오늘 다른 팀원분께서 지금까지 발견된 이슈들을 Jira에 등록해두셨다고 알려주셨다. 덕분에 나도 미리 정리해둔 이슈들을 템플릿에 맞춰 아주 간단하게 등록할 수 있었다.
 

게다가 Google Spreadsheet에 버그 리포트까지 작성해두셨고, 그걸 보고 난 정말 감동해서 급히 다시 책상에 앉아 하나하나 살펴봤다. 문서 정리, 의견 전달, 자료 공유 방식까지.. 진심으로 배울 점이 너무 많았다. 솔직히 말해서, 그렇게 성실하고 열정적인 분들한테 반할 수밖에 없는 것 같다. 거짓말 하나 안 보태고, 진짜 설렜다 ㅋㅋ 이번 프로젝트를 함께한 팀원분들의 협업 방식을 보면서 ‘와.. 대박..’이라는 말이 절로 나왔다. 덕분에 정말 많이 보고 배웠고, 이런 분들과 함께할 수 있어 너무 감사했다.
 
원래 스터디 모집 당시, 2차 사이드 프로젝트는 공식적으로 2차 팀 프로젝트 시작일인 5월 7일 하루 전인 5월 6일까지 진행하기로 했었다. 하지만 2차 팀 프로젝트에 관한 Notion 글만 봐도, 그 난이도는 1차 팀 프로젝트보다 훨씬 높아 보였고, 사이드 프로젝트에 함께 참여하신 팀원분들 역시 각자의 팀 사정이 있었기 때문에, 팀 프로젝트 하루 전날은 팀 준비에 집중하기로 하고 사이드 프로젝트는 오늘까지로 조율했다.
 
물론 하루만 더 여유가 있었다면 HTML 리포트 연동, Jira 자동 티켓 생성, Slack 알림 전송까지 도전해보고 싶었지만, 나 역시 하루 전날은 2차 팀 프로젝트 준비에 집중하는 것이 맞다고 생각했다. 앞으로 오전 10시부터 오후 11시까지 약 10일간 프로젝트를 집중적으로 진행해야 하기 때문에, 약간의 휴식도 필요하다고 느꼈다. 무엇보다 일어나는 시간 조절이 제일 걱정되긴 하지만... 아무튼 초반에는 온라인으로 진행되는 사이드 프로젝트라 걱정이 많았지만, 팀원분들 덕분에 정말 만족스러운 결과로 마무리할 수 있었던 것 같다.

---

🎯 사이드 프로젝트 최종 회고

 

⬇️ GitHub 주소

GitHub - kys0529/EliceQA_Side_Project

 

✅ Appium은 생각보다 Selenium과 닮아있다

이번 사이드 프로젝트를 통해 느낀 가장 큰 인사이트는 Appium이 Selenium과 정말 크게 다르지 않다는 점이었다. 물론, 기기 기반 테스트이기 때문에 환경 설정이 까다롭고, 기기별 차이가 존재한다는 점에서 분명한 어려움이 있었다. 예를 들어, 키보드 창이 열릴 때 요소가 가려지거나 가려지지 않는 문제, 동일한 요소라도 해상도나 위치가 기기마다 다르게 보이는 현상, 각 제조사마다 갤러리 구조나 접근 방식이 다른 점 등은 테스트 자동화 시 예상치 못한 변수를 만들어냈다.
하지만 이런 점들을 제외하면, 테스트 흐름 자체는 Selenium과 매우 유사했고, 기존에 익혔던 자동화 테스트 기법들을 모바일 환경에서도 거의 그대로 활용할 수 있다는 자신감을 얻을 수 있었다.
 

✅ 구조적으로 발전한 디렉토리 설계

이번 프로젝트에서는 전체적인 디렉토리 구조도 더 성숙하게 발전시킬 수 있었다.

• .env를 통한 환경 변수 관리
• capabilities 파일 분리로 다양한 디바이스 설정 대응
• BasePage 클래스 정립과 공통 동작 함수 추출
• 각 테스트 클래스마다 driver를 자동으로 생성하고 로그인까지 자동 처리되는 fixture 구성

이러한 구조 덕분에 코드 재사용성과 유지보수성이 확실히 향상되었고, 새로운 테스트를 추가할 때도 불필요한 반복을 줄일 수 있었다.
 

✅ 시나리오 구성 방식에 대한 아쉬움

사이드 프로젝트에서는 ‘시나리오 작성’을 시도해보았다는 점에서 분명히 의미 있는 진전이 있었다. 특히 1차 팀 프로젝트에서는 버튼 하나를 누르는 단위까지 모든 테스트 케이스를 잘게 쪼개서 작성했고, 수행 절차도 거의 한 단계로 제한되는 경우가 대부분이었다. 반면 이번 프로젝트에서는 하나의 테스트 케이스에 2~3단계의 흐름이 포함된 경우도 있었고, ‘사용자 시나리오’라는 개념을 문서로 정리하려는 시도 자체는 분명 새로웠다.
 
하지만 결국 실제 구현 단계에서는 또다시 ‘하나의 테스트 케이스 = 하나의 테스트 함수’라는 구조로 진행되었고, 테스트 코드 역시 기능 단위로 쪼개진 케이스들을 반복적으로 검증하는 방식에 머물렀다. “이 흐름이라면 오히려 하나의 테스트 함수 안에서 시나리오 흐름대로 케이스를 통합하는 게 자연스럽지 않을까?” 하는 의문이 중간에 들기도 했지만, 프로젝트 초반부터 정해진 방향이 있었고, 이미 전체 구조가 그 방식에 맞춰지고 있었기에 중간에 바꾸기에는 조심스러운 분위기였다.
 
무엇보다도, 겉으로 시나리오를 문서화했다고 해서 그것이 곧 시나리오 기반 테스트가 되지는 않는다는 점을 이번 경험을 통해 확실히 느꼈다. 실제로 우리가 작성한 TC들은 시나리오에서 파생된 것이라기보다는, 그 시나리오를 다시 쪼개고 나눈 것에 가까웠고, 다양한 흐름이나 경우의 수를 고려한 테스트 시나리오라기보다는 결국 또다시 기능 중심의 분할 테스트에 가까웠다.
 
이번 사이드 프로젝트는 분명히 1차 팀 프로젝트보다는 한 단계 더 나아간 시도였고, '시나리오 기반 테스트'라는 키워드를 팀 전체가 의식하며 움직이려 했다는 점에서 큰 의미가 있다. 하지만 여전히 시나리오의 흐름을 그대로 코드 구조에 반영하거나, 시나리오 단위로 테스트를 통합적으로 설계하는 데에는 부족함이 있었다.
 
그래서 다음 프로젝트에서는 초기 설계 단계부터 사용자 흐름 중심의 시나리오를 기반으로 TC를 도출하고, 테스트 코드도 그 흐름에 맞춰 설계하는 구조를 시도해보고 싶다. 단순히 ‘시나리오를 문서화했다’에서 그치지 않고, 진짜 시나리오 중심의 테스트 자동화를 해보는 경험을 해보고 싶다.
 

✅ 온라인 환경에서도 빛난 팀워크와 기본 구조의 중요성

이번 사이드 프로젝트는 전면 온라인으로 진행되어 처음에는 소통과 협업에 대한 우려가 컸다. 이전 1차 팀 프로젝트에서는 오프라인으로 만나 직접 노트북을 보며 문제를 해결하거나, 즉각적인 피드백을 주고받을 수 있었기 때문에 온라인 환경에서의 협업이 과연 잘 될 수 있을지 걱정이 되었다.
 
하지만 그런 걱정이 무색할 정도로 팀원 분들 모두가 정말 빠르고 성실하게 소통해주셨다. 피드백은 신속하고 구체적이었고, 자료 정리, 문서 공유, 코드 리뷰, 의사소통까지 모든 부분에서 체계적이고 깔끔한 협업이 이루어졌다. 오히려 내가 더 반성하고 배워야 할 부분이 많다고 느껴질 정도였다.
 
특히 온라인 환경일수록 기본 틀의 중요성을 뼈저리게 느꼈다. 오프라인보다 작업 맥락을 파악하거나 충돌을 해결하는 데 더 많은 비용이 들기 때문에, 초반에 팀 전체가 공유할 수 있는 명확한 구조를 정해두는 것이 중요했다. 그래서 우리는 프로젝트 시작 단계에서 디렉토리 구조, 변수 및 함수 네이밍 규칙, 공통 함수 정의 등 여러 기준을 함께 논의하고 정리한 뒤 본격적인 코드 작성에 들어갔다. 예를 들어, BasePage에 공통 동작 함수를 정의할 때도 단순히 본인이 필요한 기능만 구현하는 것이 아니라, “이거 다른 분들도 자주 쓰실 것 같은데 같이 써요!” 같은 제안을 하며 기능을 공유했고, 이런 흐름이 자연스럽게 협업의 시너지를 만들었다.
 
이번 경험을 통해, 온라인 환경에서도 얼마든지 유기적인 협업이 가능하다는 것과, 그 기반이 되는 것은 결국 초기 구조 설계와 팀원 간의 적극적인 소통이라는 사실을 다시금 깨달을 수 있었다.
 

✅ 도전해보고 싶었던 Slack & Jira 연동

개인적으로 이번 프로젝트에서 꼭 도전해보고 싶었던 기능 중 하나는

• 테스트 실패 시 자동 티켓 생성(Jira)
• Slack 연동을 통한 실시간 알림 전송이었다.

하지만 2차 팀 프로젝트 준비와 병행하는 일정 탓에 끝내 시도해보지 못했다. 아쉬움이 크지만, 다음 기회에 꼭 도전해보고 싶은 목표로 남겨두었다.
 

✅ 정리하며

이번 사이드 프로젝트는 기술적으로도, 협업적으로도 의미 있는 도전이었다.

• Appium 기반의 모바일 테스트 자동화 경험
• 효율적인 디렉토리 구조 설계
• 온라인 협업의 장점과 가능성 체감
• 테스트 전략에 대한 깊은 고민

짧은 기간이었지만 그 속에서 확실한 성장을 체감했고, 앞으로 내가 QA로서 어떤 방향으로 더 발전해가야 할지에 대한 명확한 기준도 얻을 수 있었다. 함께 프로젝트를 진행한 팀원분들께 감사드리며, 이 경험을 바탕으로 더 좋은 QA가 되어가고 싶다.