First Steps in Automation: Experiments, Failures, and Growth

The starting point for QA automation was the problem that manual testing centered on outsourced personnel was consuming too many resources. E2E testing verifies the entire flow but carries heavy maintenance, while API testing has low volatility and can be automated relatively quickly, so this direction was chosen first.

Initially, the structure was set up based on Jenkins, following the company's automation history. The flow involved receiving test items from Zephyr, running Postman Script, and sharing results via Slack.

However, this required directly building and operating a Jenkins server, understanding of the AWS EC2 environment was needed, and configuration complexity was high. For these reasons, based on prior experience with web E2E automation, a PoC was conducted switching the structure to GitHub Actions.

The PoC verified the following flow:

• Writing Postman API Scripts related to login and sign-up
• Confirming 200 response for normal input and 400 response for incorrect ID/PW input
• Merging the script from the feat/slack-api branch into main
• Creating a YAML file for GitHub Actions
• Running newman on a cloud runner
• Notifying execution results via a Slack channel

Comparison results showed that Jenkins carried a heavy burden of server management, plugin compatibility, backup, and maintenance, while GitHub Actions was much simpler since CI/CD could be managed within the repository without a separate server. To persuade the team, the structure was reorganized and the PoC was shared, and onboarding sessions were conducted directly for team members unfamiliar with Git and GitHub Actions usage.

The results of the adoption were clear. The expected period for building a new environment was reduced from 4 months to 1 month, shortening the work period by about 75%. As a result, a foundation for API test automation and a regular execution system aligned with the deployment cycle could be established.

However, limitations also emerged. The domain intended for application had a structure mixing gRPC and REST API, and Postman-centered scripts were optimized for REST calls, making it difficult to cover the entire flow and state transition verification. Ultimately, rather than automating the entire scope, the approach shifted to gradually expanding from areas with the greatest impact, such as test data generation, precondition setup, and automation of repetitive tasks.