2025年QAG入社メンバー奮闘記

この記事は KINTOテクノロジーズ Advent Calendar 2025 の14日目の記事です🎅🎄

はじめに

2025年にKINTOテクノロジーズのQAGに入社したメンバーで、アドベントカレンダーに参加しました！
入社してからこれまでのQAとして取り組んできたトピックをまとめています。
同じQAの方々にはアイデアのきっかけとして、開発の方々には「QAってこんなこともやるんだ」という認知の拡大につながればと思います。

テスト効率化のためのWebAppの作成

• 自己紹介
  とみよしです。前職でも第三者検証でQAをしていました。開発経験はほとんどありません。

• 内容
  ある日こんなことが。
  スマホ端末でチャットに文言入力するのに効率よくテストをするためにはどうすればいいだろうかという話に。
  いっそのことAIを使ってWebAppを作るか！という案が出ました。
  なので作りました！！

コピー	ペースト

仕組みとしては作業自動化ツールのZapierを使用し、
AIで生成した質問をGoogle SpreadSheetにDBとして格納、
Google App Scriptを使用してWebAppとして作成しました。

	ツール	行っていること	参考画像
1	Zapier	form画面の作成。 Zapierの機能としてInterfacesからformの作成を行うことができます。
2	Zapier	AIによる質問生成 form画面から入力された内容を元に質問を生成します。	ー
3	Zapier	Googleスプレッドシートへの連携 生成した質問をGoogleスプレッドシートに連携します。Zapierの標準機能としてこちらの連携が行えます。	ー
4	Googleスプレッドシート	DBの代わりとして使用 Zapierから連携した質問内容を保存する	ー
5	GoogleAppsScript	DBの代わりとして使用Zapierから連携した質問内容を保存する	ー

これを作成するにあたって最初はできるのか？と思いながら進めていましたが、
AIにどうすればできるのか、どうやればいけるのかなど細かく聞きながら進めていきました。

Zapierでスプレッドシートに連携することはできました。連携している内容に生成された質問JSON（D列）があります。
このJSONのquestionsの内容を一覧にして一つ一つコピーできるようなwebを作成したいです
添付：ダウンロードしたGoogleスプレッドシートのExcelファイル

もちろん一発でできるわけもなく、AIに生成してもらったコードをそのまま利用してもエラーが発生しました。
そのエラーに対してもAIに一つ一つ確認していくことで今のような形になりました。

当初は検索機能などもなかったため、利便性の面ではやや物足りない状態でした。
ただ一度に大量のことを要求することはせず、細かく機能追加を行うように指示したのが今回はうまく行った要因かと思っています。

このように行っていったおかげでコードについてもほとんど自分からは手を加えてはいません。
ひたすらこうして欲しいと言ったのを繰り返し、コードと向き合っていた期間としては1〜2日程度で作成してくれました。

このWebAppであらかじめチャットに入力する内容を登録しておき、
スマホ端末でアクセスしてコピペをするだけになったことで、
ひたすらキーボード入力するよりは効率的に実施できるようになりました。

初のWebApp作成でしたがAIと二人三脚で何とか作り上げることができました。

開発ほぼ未経験でもこうして作り上げることができるので今後も挑戦していきたいと思います。

付録

Zapier：https://zapier.com/
Googleスプレッドシート：https://workspace.google.com/intl/ja/products/sheets/
Google Apps Script ：https://developers.google.com/apps-script?hl=ja

Appium環境構築初心者の体験談を発表してきました

• 自己紹介
  ろきです。前職ではニュースアプリの会社でQAをやっていました。開発未経験です。

• 内容
  こんにちは！
  先日、Appium Meetup Tokyo #3で「Appium環境構築の初心者つまづきポイント」についてLTしてきました。
  形式はオンラインとオフライン両方。時間は15分くらいで、スライドを使って4つのポイントを紹介しました。

そもそもAppiumに興味を持ったのは、「コーディングの第一歩を踏み出せそう！」と思ったから。
とはいえ、初心者だと環境構築で詰まってしまって心が折れることもありますよね。
私自身もかなりハマったので、「同じようなところで困っている人に少しでも役立てば…」と思って発表しました。

話したポイントはこんな感じです。

• エラーはAIに聞くと意外と解決できる
• バージョン合わせはAppium公式HPを見ると確実
• 必要なツールだけ起動してツールの競合を防ぐ
• Gitコマンドは触って慣れるのが早い

登壇後、参加者の方から「あるあるばかりで共感できました！」と言ってもらえたのが嬉しかったです。
人前で話すのはやっぱり緊張しますが、終わったあとはホッとしました。
これからも少しずつコーディングに挑戦して、できることを広げていきたいです。

付録

https://speakerdeck.com/kintotechdev/appiumwodong-kasumatenotumatukihointo-chu-xin-zhe-kagan-sitariarunabi-toxue-hi

Playwrightによる自動化

• 自己紹介
  ひがしです。前職では第三者検証のQAをしていました。開発経験はほとんどありません。

• 内容
  僕が入社して印象深かった経験は『テスト自動化』です。
  前職では全くしたことがありませんでしたが、上長と先輩社員から「やってみる？」とお話を頂いた時は「ぜひ！」と二つ返事するくらいワクワクでいっぱいでした！

ジョインした案件では、様々な申込条件で申込完了までの一連のフローを確認するリグレッションテストが必要となりました。
そこで、それを自動化で実施するために、この案件専用のリグレッションテスト用スクリプトを作成することになりました。

また、僕の所属チームでは、E2Eテスト自動化のためのツールとして『Playwright』を採用しており、
既に先輩社員がデータ作成用やリグレッションテスト用のスクリプトをある程度完成させている状態でした。
それらのスクリプトを参考に、指定された申込条件のスクリプトを作成するお手伝いをさせていただきました。

参照するスクリプトがあるものの、
プルダウンの選択値やテキストボックスの入力値、押下するチェックボックスやボタンなど、コンポーネントの操作が1つ異なるとそこで要素取得エラー等が出て、
なかなか思うように作業を進めることができないことがありました…。
そこで僕がお世話になったPlaywrightの機能が『コード生成機能』です。
この機能は、ブラウザ操作を録画し、その操作に対応する自動化用コードを出力してくれるものになります。
この機能を使い、一度申込条件に沿ったブラウザ操作を行なってみることで、
初心者でもすごく簡単にコード生成および要素の取得ができ、エラーを解決することができました。

(例：”取扱車種一覧を見る”をクリックする操作を録画)

他にもまだ知らないPlaywrightの便利な機能があると思いますので、
先輩社員に尋ねたり自身で調べながら少しずつ使用できるようになり、徐々にPlaywrightに慣れていきたいです。

Appium周りの対応と開発ルール周り整備を行った話

• 自己紹介
  mです。KTC入社と同時にQAへジョブチェンジしました！前職まではAndroidアプリの開発をしていました。

• 内容
  最近、Appiumを用いたE2Eテストの自動化に挑戦する機会がありましたのでその内容についてです。
  主に2つのポイント、単体テストとE2Eテストの違いと所感、そして開発ルール周りの整備について触れます。

1. AppiumによるE2Eテストの導入

E2Eテストとはユーザーが実際に行う操作を端末上で再現し、アプリ全体の動作を検証するものです。
Appiumを使ってAndroidアプリとiOSアプリのE2Eテストの作成に取り組みました。

その中で特に課題となったのが実行にかかる時間です。
E2Eテストでは待機時間の発生が避けられません。具体的には、以下のような待機時間が発生します。

• UI操作の待機
• 画面描画の待機
• 通信処理の待機

待機時間の増加に伴い、テスト実行時間とコストも増大します。
そのため、どのシナリオからテストを優先するかの判断や、外的要因によってテストが正常に実行できない場合に備えたリトライ処理の設計が重要になります。

現在は相互レビュー時に処理内容について相談することで、実行速度の高速化を進めています。
その結果、一部処理の負荷軽減を実現できました。引き続き検討と対応を進めていきたいと思います。

2. 開発ルール周りの整備について

プロジェクトのメンバーが増えてきたため、ブランチ戦略やブランチ保護の設定見直し、PRのルール策定など開発にまつわるルールの整備を行いました。

ブランチ戦略の変更

以前はGitHub Flowを採用していましたが、現在はGit Flowに変更しました。
この変更の主な理由は、利用するアプリのバージョンごとにリリースを管理したかったためです。
Git Flowを採用することで、機能開発やリリースの管理が明確になり、複数のバージョンを同時に扱う際の混乱を軽減できます。

ブランチ保護の設定見直し

実運用環境で動作しているmainブランチで、
自身含めて新規でアサインがあった開発者の各個人の環境によって動作しない事象が発生していました。そのため、mainおよびreleaseブランチへのPR作成時に
GitHub Actionsのワークフローを利用して
自動的に動作確認（全テスト実行）が通るかどうか確認できた場合のみマージ可能とする設定に変更しました。

PRのルール策定

開発者がそれぞれ以前のPRで何を対応していたかを明確にするため、
以下の項目を含むPRテンプレートを用意しました。

• 対応内容概要
• 詳細
• 動作確認した内容
• レビュー時に確認して欲しいこと

このテンプレートにより、PRの内容が整理されレビューが効率的になることを目指しています。
これにより、さらに安定・安全に開発を進めるための基盤を整えることができました。チーム全体で協力し、より良い開発環境を作り上げていきたいと思っています。

今回ご紹介したようなAppiumを用いたE2Eテスト自動化の取り組みや、
QA観点での開発ルール整備については社内イベントでも継続的に発信しています。

大阪支社(Osaka Tech Lab)にてCO-LAB Tech Nightというイベントを毎月実施しておりますのでぜひご参加ください、、、！
QA回で登壇させていただいたときの様子です。

最後に

最後まで読んでいただきありがとうございます。
今回の内容が皆様のQA活動のきっかけの一つになれば幸いです。