QAエンジニアの採用・選考　どう採るどう通る？連載の第5回、今回が最終回となります。 第2回・第3回では求職者側の視点、 前回(第4回) からは募集側の視点に切り替えて、QAについて何を理解すべきか、理解を深めるための具体的なアクションについて解説しました。 しかし、QAを理解し、良い募集文面を作ることができたとしても、その募集がQAエンジニアの目に触れなければ応募にはつながりません。連載の最終回となる今回のテーマは「認知」です。 採用における認知の重要性は、さまざまな調査データからも裏付けられています。 talentbook社が2024年に実施した調査 では、採用施策において「応募者認知」に課題を感じている企業が中堅企業で78.2%、大企業で70.3%にのぼりました。また、 markeTrans社の調査 では、企業名を事前に認知している人の9割が業務内容の理解まで進んでいるという結果が出ています。年代が上がるにつれて事前認知の比率が高くなる傾向もあり、中途採用においては事前認知がアドバンテージになり得ることが示唆されています。 本記事では、QAコミュニティの中で自社の認知を獲得するための具体的な手段についてご紹介します。前回の「理解する（インプット）」に続く、「知ってもらう（アウトプット）」のフェーズとしてお読みいただければ幸いです。 記事一覧：QAエンジニアの採用・選考［どう採る　どう通る］ 【第1回】QAテストエンジニア採用における募集側・求職者側のニーズと課題 ［全文公開中］ 【第2回】求職者側の課題1：求められているQA像を把握する 【第3回】求職者側の課題2：適切なアピールで「欲しい」と思わせる 【第4回】募集側の課題1：QAエンジニアの業務や考え方を理解し、敬意を伝える なぜ「認知」が必要なのか QAエンジニアは元々の母数が少なく、多くの企業が採用を競い合っている状況です。そうした中で、求人を出して待っているだけでは、QAエンジニアの選択肢にすら入ることが難しくなっています。 ここでいう「認知」とは、単なる企業の知名度のことではありません。QA採用における認知とは、「この会社は品質に対する取り組みをしている」「QAに対する理解がありそうだ」といった、品質への姿勢が伝わっている状態を指しています。 では、どの程度の認知を目指すべきなのでしょうか。いきなり「この会社で働きたい」と思ってもらうことを期待するのは、とくにまだQAエンジニアがいない企業の場合は現実的ではありません。まずは「社名を聞いたことがある」、できれば「あの会社は品質に力を入れているらしい」「QAとしてどんなことが求められそうか、なんとなく想像がつく」くらいのレベルを目指すのが妥当だと考えています。 私自身の体験として、事業会社に転職した後に外部のイベントに参加したり登壇したりしていたところ、「QAがいたんですね！」「募集してたんですね！」「御社の人をあまり外でお見かけしないので」と言われたことがありました。裏を返せば、それまではQAコミュニティの中で社名が認知されていなかったということです。外に出て顔を見せるようになってから、少しずつ「あの会社にはQAがいる」ということが広まっていった実感があります。即効性があるわけではありませんが、じわじわと効いてくるものだと感じています。 QAコミュニティでの認知を獲得する手段 ここからは、QAコミュニティの中で自社の認知を獲得するための具体的な手段をご紹介します。 スカウト・ダイレクトリクルーティング——「攻め」の認知 ビズリーチやFindyなどの媒体を通じてスカウト等を送ることは、応募を獲得するための手段として広く知られています。しかし、スカウトにはもう一つの側面があります。それは「認知を獲得する手段」としての効果です。 いちエンジニアの立場で正直なところを言うと、スカウトに返事をしないことは多いです。（転職するつもりがない場合は特に。）しかし、メールに含まれる文面は読んではいますし、社名も頭に残っています。「あの会社、QA採用してるんだな」という印象が積み重なることで、いざ転職を考えたときに選択肢に入る可能性が生まれます。 ただし、ここには大きな注意点があります。テンプレ感の強いスカウトや、まったく関係のないロールでの「いいね」は逆効果です。一方で、自分のこれまでのアウトプットを見てくれていたり、得意領域を踏まえたうえでの打診であれば、たとえ応募に至らなかったとしても印象は良いです。 面白いのは、経歴について具体的に言及されていてもテンプレ的に感じる文章もあれば、短くてもこちらのことを理解してくれていると感じるスカウトもある、ということです。この違いは言語化が難しい、感覚的な部分ではありますが、候補者側には良くも悪くも伝わっています。 これは前回の記事で述べた「QAを理解すること」と直接つながっています。QAという職種やその人のキャリアに対する理解が浅いままスカウトを送ると、それは候補者に見抜かれてしまいます。理解に裏打ちされたスカウトであればこそ、返事がなくても良い認知につながるのだと思います。 SNS・技術ブログでの発信——「蓄積する」認知 DevRelやHRのSNSアカウントが活発で、タイムラインでよく見かける企業は、それだけで認知につながります。「あの会社、よく発信しているな」という印象は、採用において意外と大きな力を持っています。 「でもうちにはまだQAエンジニアがいないので、QAに関する発信ができない」と感じる方もいるかもしれません。しかし、QAがいない段階でもできる発信はあります。 たとえば、開発組織のトップ（CTOやVPoEなど）の名前で、品質に対する課題意識や今後の方針を発信するという方法があります。これはQAエンジニアにとって「この会社は品質に対して経営層レベルで意識を持っている」「入社したときに後ろ盾がありそうだ」というメッセージになります。QAとして入社するにあたって、経営層の理解と後押しがあるかどうかは非常に重要なポイントです。 また、開発者がテストに関する取り組みを発信することも効果的です。テスト自動化の導入、品質改善の施策、テスト設計の工夫など、QAエンジニアがいなくても開発者自身が品質に向き合っている姿を見せることができます。QAエンジニアから見て、「品質に対して何もしていない会社」と「QAはまだいないけれど、開発者が自分たちでテストに取り組んでいる会社」では印象が大きく異なります。後者のほうが入社後のイメージも湧きやすいです。 大切なのは、「品質に課題があります」という発信だけでなく、「今、こういうことに取り組んでいます」という部分も含めることです。課題の認識が適切にできていること自体がアピールになりますし、取り組みの内容を伝えることで「この会社は本気で品質に向き合おうとしている」という印象を与えることができます。 このほか、QA系のイベントに参加した後に感想ブログを書くのも有効な方法です。学びの姿勢を示しつつ、発信もできるという一石二鳥のアクションと言えます。 イベントへの参加・スポンサー——「存在感を示す」認知 JaSSTなどQA系イベントのスポンサーになっている企業を見ると、「この会社は品質に力を入れているんだな」という印象を持ちます。スポンサーは認知獲得の有力な手段の一つです。 とはいえ、いきなりスポンサーになるのはハードルが高い場合もあると思います。まずはイベントに参加して、QAコミュニティの空気感を知ることから始めるのも良い方法です。前回の記事でも「学びの姿勢で」と述べましたが、認知獲得においても同じスタンスが大切です。 懇親会への参加も、QAエンジニアとの自然な接点を作る機会になります。ただし、注意すべきなのは「採用目的で懇親会に来ている」「採用目的の声がけをたくさんしている」とならないようにすることです。これらは候補者であるエンジニアの間で印象が悪くなってしまうので、あくまでも交流や、QAコミュニティの空気感を知るためのスタンスを守ることが重要です。 また、開発者やDevRelの方がイベントに参加し、その感想をブログに書くというのも認知獲得につながります。「うちの会社の人がQA系イベントに関心を持っている」ということ自体が、QAコミュニティに対するメッセージになるからです。 合同ミートアップの開催——「双方向」の認知 最近では、複数社（3〜4社程度）が合同でミートアップを開催するケースも見られます。各社からのLTやパネルディスカッションを通じて取り組みを紹介し、参加者に「面白そうだな」「この会社で働いてみたいな」と感じてもらうことを狙ったイベントです。 ただし、この手段には難しさもあると感じています。採用目的を前面に出してしまうと、参加すること自体が転職意思の表明のように見えてしまい、エンジニア側からすると気軽に参加しづらくなります。一方で、あくまでも技術イベントというスタンスで開催すると、エンジニア側は気軽に参加できる反面、採用のためのアピールがしづらくなる可能性があります。このように、開催側の意図と建前と、参加者側の思いとが、噛み合いきらない部分があるように見受けられます。 認知獲得の手段の一つとして選択肢に入れておく価値はありますが、設計の難しさは認識しておいたほうが良いでしょう。 QAがまだいない企業の場合 ここまでご紹介した手段の中には、QAエンジニアがまだ社内にいない企業にとってはハードルが高く感じるものもあるかもしれません。 そうした場合は、 前回の記事 でご紹介した「副業QA」の活用が、認知獲得の土台を作る手助けになります。副業QAが社内にいることで発信の内容に説得力が増しますし、イベント参加やスカウト文面の作成においても、QAの専門家の視点を取り入れることができます。 まずは小さく始めて、少しずつQAコミュニティの中での認知を広げていくことが大切です。 連載のまとめ 本記事では、QAコミュニティの中で自社の認知を獲得するための手段として、スカウト・ダイレクトリクルーティング、SNS・技術ブログでの発信、イベントへの参加・スポンサーなどをご紹介しました。それぞれの手段にはそれぞれの特性がありますが、共通して重要なのは、前回お伝えした「QAを理解すること」が前提になっているという点です。理解が浅いままの発信やスカウトは、候補者には伝わってしまいます。 また本連載では、全5回にわたってQAエンジニアの採用について、求職者側・募集側の双方の課題を取り上げてきました。連載を通じて一貫してお伝えしたかったのは、採用活動を「なんとなく」や「他職種と同じように」進めてしまうと、うまくいかないことが多い、ということです。 求職者であれば、募集側がどんな背景でどんなQA像を求めているのかを理解し、それを踏まえてアピールすること。募集側であれば、QAという職種の幅広さや文化を理解し、その理解をもとに認知を獲得していくこと。どちらの立場であっても、相手の行動原理や思いを理解し、汲み取ったうえで行動することが大切です。 この「理解」こそが、QA採用を成功に近づける鍵ではないかと考えています。本連載が、QAエンジニアの採用に関わるすべての方にとって、何かしらのヒントになれば幸いです。 【連載】QAエンジニアの採用・選考［どう採る どう通る］ 【第1回】QAテストエンジニア採用における募集側・求職者側のニーズと課題 ［全文公開中］ 【第2回】求職者側の課題1：求められているQA像を把握する 【第3回】求職者側の課題2：適切なアピールで「欲しい」と思わせる 【第4回】募集側の課題1：QAエンジニアの業務や考え方を理解し、敬意を伝える The post 【最終回】募集側の課題2：QAの中での認知を獲得する first appeared on Sqripts .

はじめに こんにちは、Checkout Reliabilityチームでバックエンドエンジニアをしているかがの（ @ykagano ）です！ Checkout Reliabilityチームはカートの信頼性を向上させるためのチームです。 今回、BASEのカート機能を安定的に提供するために、継続的な負荷テスト環境を構築しましたので第1回として、本記事では全体像を紹介します。 全3回の記事を予定していますので、よろしくお願いします。 BASEの負荷テスト BASEではこれまで負荷テストは必要に応じて都度実施していました。 k6 というオープンソースソフトウェア（以降OSS）の負荷テストツールを使って、BASEのカートへの商品追加から購入完了までのシナリオの負荷テストを行い、負荷が高まっても機能的な問題がないことを確認していました。 しかし、この都度実施の負荷テストには以下の課題がありました。 負荷テストの課題 1. 以前作成したテストシナリオがシステムの仕様変更で動かない状態になっている k6のテストシナリオはJavaScriptで書けるのですが、例えば購入可能な状態にするために必要なAPIやパラメータが一つ増えていたりすると修正が必要になります。 2. 外部APIの仕様変更で、外部APIに見立てたモックのコード修正が必要になっている 商品を購入する際には、BASEから社外の決済APIを呼び出しているのですが、開発環境とはいえ、社外の決済APIに負荷をかけるわけにはいかないため、決済APIの応答に見立てたモックを用意しています。そのため、この社外APIの仕様が変更になるとモックの方もコード修正が必要となります。 3. 新機能を作成した後、改修の度に負荷テストを行っておらず、現在のキャパシティ（負荷に対する許容量）が分からない 当時行った負荷テストの記録は残っているのですが、仕様変更があった今も同じキャパシティを維持できているのかは負荷テストをしてみないと分かりません。しかし、再度負荷テストをするためには、前述のハードルがあります。 これらの課題を解決して、継続的に負荷テストを行えるようにしよう、というのが今回の取り組みです。 負荷テスト環境の要件 継続的な負荷テスト環境として求めた要件は以下となります。 1. 負荷テストを自動で定期実行し、結果をレポートできる 定期的に負荷テストを行うことで、仕様変更によるエラー等を早期に検知できることを求めました。 2. 負荷生成ツールもモックもスケールアウトできる k6のようなシステムに負荷を与えるためのツールを負荷生成ツールと呼びます。この負荷生成ツールとモックの両方を今後システム規模が大きくなっても追従して高負荷を与えられるように、負荷生成ツールやモックの台数を増やす機能を求めました。 3. モックがノーコードで更新できる これまで使っていたモックはPHPによる独自実装をしていました。これだと仕様が変わるとコードの変更が必要です。今回はOSSのモックツールを使用することで、コードの変更をせずにモックの仕様を更新できる機能を求めました。 ベストプラクティスの調査 これらの要件に加え、負荷テスト環境としてのベストプラクティスを調査したところ、下記の記事を見つけました。 引用： 負荷テストの全体像を理解しよう｜AWS（第1回/全3回） ベストプラクティスの部分を抜粋します。 実際のワークロードを使用して負荷テストを行い、自身のワークロードが本番環境でどう動作するのかを確認すること 本番環境同等のサイズの環境を利用して試験を行うこと。また、本番環境同等の量・バリエーションのデータを、本番環境データを匿名化したり模擬的に作成したりして用意すること ユーザーの実際の行動をリプレイ、もしくはプログラム的に再現することで、大規模にアーキテクチャ全体に対して負荷をかけること デリバリーパイプラインの一環として負荷テストを自動的に実行し、事前に定義した性能目標と比較して評価し、要求性能を満たせるかどうかを継続的に保証すること ベストプラクティスに書かれていることは、私が負荷テスト環境に求めた要件とほとんど同じですが、負荷テストの考え方が間違っていない裏付けとして非常に参考になりました。 負荷テストツールの選定 こうした考え方を元に、継続的な負荷テスト環境の要件を満たすための負荷テストツールを選定しました。 負荷生成ツールには Locust を選定しています。 また外部APIのリクエストを受けるために WireMock を選定しました。 それぞれの詳細については第2回以降の記事で説明したいと思います。 負荷テスト環境の構成 最終的に負荷テスト環境の構成は下図となっています。 左が負荷生成ツールとモックツールを使用する負荷テストツール。 右が既存のBASEシステムと同等の負荷検証システム（簡略）となります。 負荷テスト環境のシステム構成図 実際のリクエストと同様にインターネットを跨いでリクエストを処理するようにしています。 ここからは負荷テストの構築にあたり進めた内容についてお話しします。 キャパシティプランニング 負荷テスト環境を構築するために、キャパシティプランニングを行いました。 まず以下の2点を確認しました。 BASEのGMV（流通取引総額）がこの先どれぐらい増加する想定なのか 現時点での本番環境での最大負荷はいくつなのか 1に関しては事業計画を参照すれば分かりますが、2に関しては、どこの負荷を基準とするかを検討しました。 BASEのカート機能には注文APIがありますので、そのAPIに対する負荷を基準にすることにしました。 またBASEではこれまでrpm（requests per minute）を基準にしていましたが、今回は高負荷状態を基準にするため、rps（requests per second）を基準にすることにしました。 ここでは注文APIの過去の最大負荷を仮に1,000rpsとします。 また事業計画として2年後のGMVが仮に1.5倍になるとします。 そうすると、2年後にはrpsも1.5倍の1,500rpsが最大負荷として想定されます。 しかし、あくまで成り行きで増える見積もりとなるため、上ブレすることも考えて多めに見積もりを行いました。 増加分の500rpsを2倍にして上振れ含め1,000rpsになるため、 2,000rpsを目標値 とします。 このような考え方で、今回構築するシステムの負荷テスト可能なキャパシティとして設定しました。 負荷テスト環境の構築 キャパシティプランニングでは、注文APIの負荷を仮に2,000rpsと設定しましたが、2,000rpsはあくまで注文API単体の負荷となります。 今回購入のワークロードを対象としているため、そのワークロードでは20を超えるAPIを利用しており、全体としては数万rpsの負荷が想定されました。 こうした要素を加味して、負荷テスト環境のシステム要件を決めていきました。 Gold環境 本番と同等の負荷検証システムは、既に以前から使っているGoldという名前の環境があったため、それを今回も利用することにしました。 しかしこのGold環境は、本番と同等のDBを使用するため、本番相当のデータ量の準備に数時間かかるという課題がありました。 負荷テスト環境は最終的に負荷テストの定期実行までを見据えていました。 負荷テスト環境の起動後、負荷テストを実行し、負荷テスト環境の破棄まで行う想定です。 しかし、定期実行が準備だけで数時間かかるとなると、コンテンツのデリバリー途中でタイムアウトする可能性もあります（実際にこのデータ準備の処理が何度か止まっていることがありました）。 再実行が頻繁に必要になってくると定期実行に支障が出ます。 DBが巨大すぎるため、Gold環境での定期実行は難しいことが分かってきました。 巨大なDBは存在するだけで多大なコストがかかるため、定期的に数時間利用するだけでも多大なコストがかかります。 定期実行ではこの課題を解決する必要がありました。 Bronze環境 本番同等の環境で負荷テストを行うというベストプラクティスには反するのですが、Gold環境での定期実行の課題を解決するため、負荷テストを自動で定期実行し、結果をレポートするための環境として本番よりスペックの低い縮小環境も今回用意することにしました。 この縮小環境には Bronze と名付けました。 命名理由としてはすでにSilver環境を別用途で使っていたためです。 このBronze環境があれば、テストシナリオの修正と確認もBronze環境で容易に行えます。 最終確認としての負荷テストはあくまでGold環境を使用しますが、定常的に必要最小限のキャパシティを担保するには、Bronze環境でも十分要件を満たせると考えました。 Bronze環境では開発環境のデータベースをそのまま流用することにしました。システムの仕様としては、本番環境の構成を縮小した形で仕様を決めていきました。 Gold環境とBronze環境の比較 項目 Gold環境 Bronze環境 目的 本番想定の最終的な負荷検証 継続的な負荷テスト・定点観測 スペック 本番同等 本番より縮小 データ量 本番同等（大規模） 開発環境のデータを流用 起動時間 数時間（データ準備に時間がかかる） 比較的短時間 コスト 高い 低い 実行頻度 必要に応じて実施 定期実行（週次） 主な用途 最終確認・性能限界の検証 早期検知・継続的な品質担保 メリット 本番に近い精度の検証が可能 手軽に何度でも実行できる デメリット コスト・準備時間が大きい 本番との差異がある Bronze環境で継続的に異常検知を行い、最終的な性能検証はGold環境で行う、という役割分担にしています。 チームでの構築 今回、チームで負荷テスト環境の構築を進めていきました。 草案は私の方で作成しましたが、設計は全員で行いました。 その後、Bronze環境の構築、AWSインフラとLocust環境の構築、WireMock環境の構築と3つに分かれて構築を行いました。 私は主にBronze環境の構築を行ったのですが、BASEのテスト環境を1セット作成する作業のため、BASEのシステムに対する解像度を上げることができ、非常に良い経験を得られました。 Bronze環境での継続的負荷テスト 毎週月曜に以下のスケジュールで負荷テストを自動実行しています。 時刻 内容 AM3:00 アプリケーションの自動デプロイ AM7:00 負荷テストの自動実行 負荷テストの自動実行はGitHub Actionsのワークフローで行っています。 以下のジョブが40分程度で実行されます。 負荷テスト開始の通知 Bronze環境の起動 負荷テストツールの起動 負荷テストの実行（メインシナリオ1） 負荷テスト結果の通知 負荷テストの実行（メインシナリオ2） 負荷テスト結果の通知 負荷テストツールの停止 Bronze環境の停止 負荷テスト完了の通知 負荷テスト結果はSlackに投稿されます。 以下はレポート内容の例ですが、注文API（post_orders）に対するrpsとAPI全体（aggregated）のrpsを見れるようにしています。 post_orders: requests=2000 failures=0 avg_time=20ms avg_rps=8.0, aggregated: requests=80000 failures=400 avg_time=500ms avg_rps=300.0 これで毎週最新のアプリケーションでキャパシティの定点観測ができる状態になりました。 本番と同等の挙動ではないですが、もしパフォーマンスの低下があれば週次で検知できます。 また今後負荷テストを実施したい場合にも、すぐに使える環境があるため、負荷テスト実施のハードルも下がってくれるのではないかと期待しています。 Gold環境での本番想定の負荷テスト Gold環境での負荷テストは当初パフォーマンスが想定したよりも出ませんでした。 本番と同等の環境ではありますが、本番と仕様や設定が一部異なっていたため、それらを本番と揃える作業が必要でした。 また本番と挙動が異なる部分もありました。 これは外部APIの通信時間を細かく本番と合わせたり、外部APIが本来持っているRate Limit（一定時間内にリクエスト回数の上限を設ける機能）の機能を再現するための仕組みを入れることで徐々に解決していきました。 負荷テストは実行してパフォーマンスが出ない場合にどこが原因か調査しボトルネックを見つけることも大事ですが、パフォーマンスをもっと出すためにはどうすればいいかは、仮説を立てる必要があります。 そのため、負荷テストの実施前に負荷改善の仮説DBをNotionに作成し、この辺りを改善すればより早くなるのではないか、といった仮説をチーム内で思い付いたものがあれば、確度が低くても良いのでどんどんDBに入れていくことにしました。 今後はこの負荷テストの結果と仮説を元に、BASEのカートの安定性をより高めるための施策を実施していく予定です。 おわりに 今回の記事では、継続的な負荷テスト環境の全体像と設計方針について紹介しました。 第2回では負荷生成ツールの構築と運用について、第3回ではモックツールの構築と運用についてお話しする予定です。 順次公開しますので、ご期待いただければと思います。 このようなシステム環境で働きたいエンジニアの方はぜひ採用情報をご覧ください！ binc.jp

アプリ開発の現場において、リリース後にユーザーから予期せぬ不具合報告が相次ぎ、対応に追われる経験はないでしょうか。 原因を振り返ると、テスト設計の不十分さや、ユーザー視点での検証不足に気づかされることも少なくありません。 アプリテストの本来の役割は、単にバグを見つけることだけではなく、プロダクトが提供すべき価値を保証し、ユーザー体験を最大化することにあります。 しかしWebとモバイルでの検証観点の違いや、膨大なテスト項目の優先順位付け、さらには自動化の判断基準など、実務レベルで品質を安定させるには多くの壁が存在します。 今回はアプリ開発のリーダー候補として品質改善に取り組むエンジニアに向けて、テストの種類や具体的な進め方、そして効率化のベストプラクティスを詳しく解説します。 属人化を排除し、チーム全体で高品質なアプリを継続的にリリースできる体制を構築するためのステップを一緒に見ていきましょう。 import haihaiInquiryFormClient from "https://form-gw.hm-f.jp/js/haihai.inquiry_form.client.js";haihaiInquiryFormClient.create({baseURL: "https://form-gw.hm-f.jp",formUUID: "927d2c4e-f06c-45b1-bd36-0240e55ccf72",}) ▼アプリ開発の基本について知りたい方はこちら▼ アプリ開発とは？種類・流れ・必要スキル・費用感まで初心者向けにわかりやすく解説 アプリテストとは？なぜ必要なのか アプリテストの目的は「不具合発見」だけではない アプリテストの主要な目的として、まず挙げられるのが品質保証です。 これは、単にプログラム上のバグを見つけることにとどまらず、プロダクトが仕様を満たし、本来提供すべき価値を正しく届けられているかを確認する一連のプロセスを指します。 開発の初期段階からテストを組み込むことで、リリース直前や運用開始後に重大な欠陥が発覚する事態を防ぎ、結果として修正コストの増大を抑制することができます。 また、ユーザー体験の向上も欠かせない視点です。 操作のしやすさや応答速度といったストレスのない利用環境を担保することで、ユーザーの離脱を防ぎ、信頼性の高いサービスとしての地位を確立できます。 さらに、多種多様な環境で正しく動作するかを確かめる互換性の確認や、外部攻撃から情報を守るためのセキュリティリスクの低減も、現代のアプリ開発においては必須の項目です。 不具合報告が相次ぐような状況を改善するには、これらの要素を網羅的に捉え、単なる動作確認を超えた品質管理の体制を構築することが重要となります。 Webアプリとモバイルアプリでテスト観点が変わる理由 開発対象がWebアプリかモバイルアプリかによって、重点を置くべきテスト観点は大きく異なります。 Webアプリの場合は、ChromeやSafariといったブラウザの種類やバージョンの違いによる挙動の変化が中心となりますが、モバイルアプリの場合は考慮すべき変数が飛躍的に増加します。 まずiOSとAndroidというOSの違いだけでなく、各メーカーが独自にカスタマイズした端末特有の依存関係が品質に強く影響します。 画面サイズや解像度のバリエーションも豊富なため、レイアウト崩れが起きていないかを詳細に確認しなければなりません。 さらに、モバイル特有の挙動であるプッシュ通知の受信、位置情報の利用許可、あるいは他のアプリへの切り替えに伴う中断と再開といったシナリオも検証の対象となります。 屋外での利用を想定した不安定な通信環境下での動作や、バッテリー消費の激しさなども、ユーザー満足度に直結する重要な要素です。 こうしたモバイルならではの物理的な制約や利用環境をシミュレートすることで、現場で発生しがちな「特定の条件下でだけ発生する不具合」を未然に防ぎ、再現性の高い品質基準を設けることが可能になります。 手動テストと自動テストの違い テストを効率化し、チーム全体の生産性を高めるためには、手動テストと自動テストの特性を理解して使い分けることが求められます。 手動テストは、人間が実際にアプリを操作して直感的に違和感を探る手法であり、特に新規機能のユーザーインターフェースや操作感の評価に向いています。 仕様が頻繁に変更される開発初期や、探索的な視点が必要な場面では、人の判断力による柔軟な対応が最大の武器となります。 一方で自動テストは、回帰テストのように何度も繰り返される定型的な検証において真価を発揮します。 プログラムによって高速かつ正確にテストを実行できるため、深夜や休日など時間を問わずに品質チェックを回し続けることが可能です。 これにより、人的ミスによる確認漏れを排除し、チームがより高度な設計や改善に注力できる環境を整えられます。 属人化を解消し、誰が実行しても同じ結果が得られる体制を構築するためには、まずは安定した機能から順次自動化を取り入れ、手動テストと組み合わせたハイブリッドな運用を推進するのがベストプラクティスです。 アプリテストの主な種類一覧 開発工程ごとのテストの種類 アプリ開発において品質を担保するためには、開発の流れに沿って段階的にテストを実施することが基本です。 まず行われるのが単体テスト（ユニットテスト）です。これはプログラムを構成する最小単位である関数やクラスが、設計通りに動作するかを確認する工程です。 不具合を早期に発見することで、後続工程での手戻りを最小限に抑える効果があります。 次に、個別のモジュールを組み合わせて正しくデータが受け渡されるかを検証するのが結合テスト（統合テスト）です。 複数の機能が連携した際に発生する矛盾や予期せぬ挙動を洗い出します。 さらに、アプリ全体を本番に近い環境で動かし、システム全体の要件を満たしているかを確認するのがシステムテスト（総合テスト）です。 ここでは性能や負荷といった側面も検証対象となります。 最後に、最終的な利用者が実際に操作を行い、ビジネス上の要件や使い勝手が満たされているかを判断するのが受け入れテスト（UAT）です。 エンジニア視点だけでなくユーザー目線での検証を徹底することで、リリース後の「期待していたものと違う」というミスマッチを防ぎます。 これらの工程を積み重ねることが、チーム全体の開発プロセスを標準化し、再現性の高い品質管理を実現するための第一歩となります。 観点別に見るテストの種類 機能が正しく動作するかを確認する機能テストは基本ですが、高品質なアプリをリリースするためには多角的な観点からの検証が欠かせません。 例えばUIテストでは、ボタンの配置や画面遷移が直感的に操作できるか、デザイン崩れがないかを確認します。 また、現代のアプリ開発において欠かせないAPIテストでは、バックエンドとの通信が正しく行われ、正確なデータが返却されるかを検証します。 さらに大量のアクセスがあった際に応答速度が低下しないかを見るパフォーマンステストや、脆弱性を突いた攻撃から情報を守るためのセキュリティテストも、信頼されるアプリ作りには必須です。 モバイルアプリ特有の課題である端末やOSごとの動作差分を確認する互換性テスト、そしてユーザーが迷わず目的を達成できるかを評価するユーザビリティテストも重要です。 これらのテストを網羅することで、特定の環境でしか発生しない不具合や、使い勝手の悪さに起因するユーザー離脱を未然に防ぐことができます。 リーダー候補としてプロジェクトを統括する際には、どのテストにリソースを割くべきかを論理的に判断し、効率的な検証計画を立てることが求められます。 初心者が混同しやすいテストの違い 現場で混乱を招きやすいのが、似たような名称や役割を持つテストの境界線です。 まず単体テストと結合テストの違いは、検証の範囲にあります。 単体テストはロジックの正しさを個別に確認するものですが、結合テストはそれらを繋ぎ合わせたときの「インターフェース」の不整合を見つけるものです。 また、システムテストとE2Eテストも混同されがちです。 システムテストはシステム全体が仕様通りかを検証するのに対し、E2Eテストはユーザーの最初から最後までの一連の操作（フロー）を網羅することに重点を置きます。 さらに、UIテストと受け入れテストの違いも明確にする必要があります。 UIテストは見た目や操作の挙動を確認する技術的な側面が強いですが、受け入れテストはビジネス要件を満たしているかという目的の達成に主眼を置きます。 そして、機能テストと非機能テストの違いも重要です。 機能テストは「何ができるか」を確認し、非機能テストはパフォーマンや安全性といった「どのように動作するか（品質特性）」を評価します。 これらの違いを正しく理解し、チーム内で定義を統一することは、属人化を排除し、スムーズなコミュニケーションを促進するために不可欠です。 明確な基準を設けることで、メンバー全員が同じ品質目標に向かって動けるようになり、結果としてリリース後のトラブルを大幅に削減することが可能になります。 アプリテストのやり方｜実務で迷わない進め方 1. テスト対象と目的を明確にする 効率的なテストを実施するためには、まず「どの機能を何のために確認するのか」を定義することが不可欠です。 限られたリソースの中で全ての機能を網羅的に検証するのは現実的ではないため、ビジネスへの影響度が高い重要機能や、過去に不具合が頻発した障害影響の大きい領域から優先順位をつけます。 この段階でコア機能の安定性を最優先にする方針をチーム内で共有しておけば、リリースの直前になって致命的な不具合に直面するリスクを大幅に軽減できます。 また、検証項目を洗い出す際に「自動化する対象」と「しない対象」を切り分けることも重要です。 例えば、頻繁に繰り返し実行される基本機能の確認は自動化の候補となりますが、UIの微細な調整や新機能の使い勝手といった人間による感覚的な評価が必要な項目は、手動テストとして残すべきです。 このように目的を明確化し、リソースの配分を論理的に決定することで、属人化を防ぎ、チーム全体が納得感を持って作業を進められる土台が整います。 2. テスト観点を洗い出す テストの漏れを防ぎ、ユーザー視点での品質を確保するためには、多角的な観点からの洗い出しが欠かせません。 まず基本となるのは、仕様通りに正しく動くことを確認する正常系です。 しかし、実際の現場で不具合の引き金となるのは、想定外の操作を検証する異常系や、仕様の閾値となる境界値の確認不足である場合がほとんどです。 最小値や最大値、あるいはその前後の値を入力した際に予期せぬ挙動をしないか、徹底的に確認する必要があります。 さらに入力値のバリエーションやユーザー権限ごとの動作、状態遷移の整合性も重要な観点です。 特にモバイルアプリにおいては、電波の遮断といった通信エラーや、操作中の着信による中断など、スマホ特有の挙動が品質に直結します。 こうしたイレギュラーな状況をあらかじめリストアップしておくことで、現場の問題に対する不安を解消し、誰が担当しても一定の品質を保てる再現性のある検証が可能になります。 3. テストケースを作成する テストケースの作成では、一貫性と客観性が求められます。 原則として「1つのケースに対して、期待される結果は1つ」という構成を徹底し、合否判定に迷いが生じないようにします。 操作手順、入力値、そして期待される具体的な結果を明確に記述することで、経験の浅いメンバーでも正確にテストを遂行できる環境を作ります。 手順が曖昧だと再現性が失われ、後の不具合調査で混乱を招く原因になるため注意が必要です。 また検証に必要となるテストデータや実行環境は、本番環境と切り離して事前に準備しておきます。特定のユーザー状態や決済履歴が必要な場合、テストが始まってから用意していては効率が大幅に低下します。 あらかじめ必要な条件を整理し、クリーンな環境で検証を行えるように準備を整えることで、テスト工程そのものの品質が向上します。 こうした標準化されたプロセスを導入することが、将来的にプロジェクト全体を統括するリーダーとしての信頼にもつながります。 4. 実行・記録・不具合管理を行う テストの実行フェーズでは、単に結果を記録するだけでなく、不具合が発生した際の「再現条件」を詳細に残すことが極めて重要です。 どのような手順で、どのような環境下で、どのような入力を行った際に問題が起きたのかを正確に記述することで、開発エンジニアの調査コストを劇的に下げることができます。 スクリーンショットやログを併記する運用をチーム内で徹底すれば、不具合報告の精度が上がり、修正のスピード感も向上します。 修正が完了した後は、該当箇所が正しく直っているかを確認する再テストに加え、その修正が他の機能に悪影響を及ぼしていないかを確認する影響範囲の検証（回帰確認）が不可欠です。 一つの修正が別の場所で新たなバグを生む「デグレード」は、リリース後のトラブルの大きな要因となります。 記録を確実に残し、修正から確認までのプロセスを管理ツールなどで可視化することで、品質改善の進捗を客観的に把握できるようになります。 5. 回帰防止のために自動化を組み込む 継続的なリリースを行いながら品質を維持するためには、再テストの負担を軽減するための自動化が鍵となります。 特にバージョンアップのたびに繰り返し実行される基本的なシナリオは、自動テストの格好の候補です。 自動化を始める際は、期待結果がイエス・ノーで明確に定義できるものや、ビジネスインパクトが大きいコア機能から着手するのが成功のコツです。 ただし、全てのテストを自動化しようとすると、かえってメンテナンスコストが増大し、開発の足を引っ張る恐れがあります。 常に費用対効果を見極め、変更が頻繁な画面周りなどはあえて自動化を避けるといった柔軟な判断も必要です。 自動テストをCI/CD（継続的インテグレーション／継続的デリバリー）のパイプラインに組み込むことで、不具合の早期発見を仕組み化し、障害対応に追われる日々から脱却して、より価値の高い開発に時間を割ける体制を目指します。 モバイルアプリテストで必ず押さえたいチェック項目 1. インストール・起動・更新まわりのテスト アプリがユーザーの端末に無事に届き、正しく動き出すまでのプロセスは、第一印象を左右する極めて重要な工程です。 まず各プラットフォームのストアから正常にインストールできるかを確認し、ホーム画面に表示されるアイコンが指定通りのデザインで、ぼやけや欠けがないかを確認します。 起動時間については、ユーザーがストレスを感じない許容範囲内に収まっているかを実機で計測することが不可欠です。 特に現場でトラブルになりやすいのが、アプリアップデート時の挙動です。 新バージョンへ更新した際に、これまでの設定値やログイン状態、保存済みのデータが意図せず消去されることなく保持されるかを徹底して検証します。 またアンインストールを実行した後に、不要なキャッシュファイルや一時データが端末内に残ってストレージを圧迫し続けないかも確認ポイントです。 これらの項目を網羅することで、利用開始直後の離脱を防ぎ、信頼性の高いサービス提供が可能になります。 2. 画面操作・UIのテスト ユーザーが直接触れるUIの検証では、論理的な設計通りの動作と、視覚的な正確さの両面からチェックを行います。 ボタンの反応やメニュー遷移が仕様通りであることはもちろん、多種多様なアスペクト比の端末でレイアウト崩れが起きていないかを細かく見ていきます。 フォントの種類やサイズ、色のコントラスト、さらには誤字脱字といった細部まで確認を怠らないことが、プロダクト全体の質感を高める鍵となります。 モバイル特有の観点として、端末の縦横回転を切り替えた際に表示が崩れたり、入力内容がリセットされたりしないかの確認も欠かせません。 入力欄のバリデーションについては、空欄送信の防止、最大文字数制限、絵文字や記号などの特殊文字の扱い、日付や数値のフォーマット指定が適切に機能するかを一つずつ検証します。 こうした泥臭い確認の積み重ねが、リリース後の不具合報告を半減させる着実な一歩となります。 3. 通信・端末・利用環境のテスト モバイルアプリは常に安定した通信環境で使われるとは限りません。 そのため、電波が極端に弱い場所や、Wi-Fiとモバイル通信が切り替わるタイミングなど、通信が不安定な状況下でもアプリがフリーズせずに適切なエラーメッセージを表示するかを検証します。 通信エラーが発生した際のハンドリングが不十分だと、ユーザーに「壊れている」という印象を与えてしまうため、タイムアウト処理などの確認は必須です。 また、Android端末に代表される多種多様な端末差・OS差への対応も大きな課題です。 特定のメーカーやバージョンでのみ発生する表示崩れや動作不良がないか、実機やシミュレーターを駆使して互換性を確認します。 さらに、カメラや写真ライブラリへのアクセス、プッシュ通知といったデバイス固有の機能との連携がスムーズか、権限の許可・拒否設定が正しく反映されるかについても、利用環境をシミュレートしながら漏れなくチェックします。 4. 中断・再開・バックグラウンド時のテスト スマートフォンの利用シーンでは、アプリ操作中に着信やアラーム、他アプリからの通知によって操作が中断されることが日常的に起こります。 このような割り込みが発生した際でも、アプリが異常終了することなく、再開時に入力途中の内容や遷移状態が保持されているかを確認します。 バックグラウンドから復帰した瞬間に画面が真っ白になったり、データが初期化されたりする不具合は、ユーザー満足度を著しく低下させる要因です。 加えて、端末が低電力モードに入っている場合や、メモリなどのリソースが不足している低スペック端末での挙動も検証対象に含めます。 システムによってプロセスが強制終了された後の復帰プロセスが正しく設計されているかを確認することで、予期せぬクラッシュを未然に防ぎます。 こうした「動いて当たり前」の挙動を保証することが、現場のエンジニアが抱える不安を解消し、安定した運用体制を築くための土台となります。 5. 見落としやすい非機能テスト 機能が正しく動くだけでは、真に品質の高いアプリとは言えません。 性能面では、長時間利用した際のメモリリークの有無や、画面遷移のレスポンス速度といったパフォーマンスを評価します。 セキュリティ面では、重要な情報の暗号化や不必要なログの出力がないかを確認し、リスクを最小限に抑えます。 これらはリリース後に問題化すると修正コストが膨大になるため、設計段階からの意識が求められます。 また最新OSだけでなく旧バージョンとの互換性や、アプリがクラッシュせずに動き続ける安定性も重要です。 そして最後に、初めて触るユーザーでも迷わず操作できるかというユーザビリティの観点から全体を見直します。 エンジニア視点では見落としがちなこれらの非機能要件をプロセスに組み込むことで、属人化を排除した再現性のある開発体制が整います。 結果としてチーム全体の評価が高まり、テックリードやマネージャーへのキャリアアップを支える確固たる実績につながります。 アプリテストを効率化するコツと自動化の始め方 自動化に向いているテスト・向いていないテスト テスト自動化を成功させる鍵は、リソースを投入すべき対象を正しく見極めることにあります。 自動化に最も適しているのは、リリースのたびに繰り返し実行される定型的なテストや、入力値に対して期待される結果が論理的に明確なテストです。 一方で、使い心地やデザインの微細なニュアンスといった感覚的な評価が求められるUI/UXの検証は自動化には向きません。 また仕様が頻繁に変更される開発初期の機能も、スクリプトの修正コストが膨らむため、手動で柔軟に対応するほうが効率的です。 まずはコードレベルの正しさを保証する単体テストや、外部システムとの連携を確認するAPIテスト、そしてアプリの核となる主要フローの回帰テストから着手するのが定石です。 これらを自動化することで、人的ミスを防ぎながら高速に品質をチェックできる体制が整います。 現場のエンジニアが抱える「修正によるデグレード」への不安を払拭し、論理的な裏付けを持って開発を進めるための第一歩となります。 自動テスト導入の基本ステップ 自動テストを導入する際は、闇雲にコードを書くのではなく、段階的なプロセスを踏むことが重要です。 最初のステップは自動化対象の識別です。 頻度や重要度を軸に、どのテストを自動化すれば最大の効果が得られるかを判断します。 次に、検証に必要なテストデータの準備とテストケースの整理を行います。 手順や期待結果が曖昧なままでは自動化は失敗するため、誰が見ても明快な形にドキュメント化しておく必要があります。 続いて、プロジェクトの特性に合ったツールを選定し、開発フローに組み込むためのCI/CD連携を進めます。 一度構築して終わりではなく、アプリの進化に合わせてスクリプトを更新し続ける継続運用とメンテナンスの仕組み作りも欠かせません。 この一連の流れを標準化することで、属人化を排除し、チーム全体で品質を底上げできる再現性の高い開発基盤が構築されます。 ツール選定で見るべきポイント ツール選定においては、単なる機能比較だけでなく、実務での運用負荷を考慮することが不可欠です。 まずWebアプリだけでなくiOSやAndroidといったモバイル環境への対応状況を確認します。 さらに、チームの技術スタックに応じて、スクリプトを書くプログラミング型か、非エンジニアでも扱いやすいノーコード・ローコード型かを選択します。 リーダー候補としては、自分だけでなくチーム全員が使いこなせる「共有のしやすさ」も重要な評価基準となります。 また、既存のCI/CD環境との連携のしやすさや、テストコードの保守性が高いかどうかも見極めるべきポイントです。 メンテナンスに時間が取られすぎて開発が停滞しては本末転倒なため、将来的な拡張性を含めて論理的に比較検討します。 適切なツールを導入し、品質管理を仕組み化することは、プロジェクト全体を統括するマネージャーとしての視点を養う絶好の機会にもなります。 手動テストだけで終わらせない運用体制 テストを「リリース前の一時的な作業」として終わらせず、継続的な改善サイクルに組み込むことが品質向上の極意です。 不具合が発生した際には、その傾向を蓄積・分析し、テスト観点そのものをアップデートし続ける文化を醸成します。 なぜそのバグが漏れたのかを振り返り、新たな検証項目として追加することで、次回リリースでの不具合発生率を確実に下げることができます。 さらに、テストケースや知見を個人の頭の中に留めず、チームの共通資産としてドキュメント化・共有する仕組みを作ります。 これにより、特定の担当者がいないと検証が進まないといった属人化を防ぎ、常に一定の品質を保てる体制へと進化します。 トラブル対応に追われる現状を脱却し、ユーザー満足度の向上に直結する価値の高い開発に時間を投資できるよう、組織としての品質意識を高めていくことが求められます。 まとめ 高品質なアプリを安定してリリースし続けるためには、開発工程ごとに適切なテストを配置し、漏れのない検証観点を持つことが不可欠です。 単体テストから受け入れテストまでの流れを標準化し、モバイル特有の「中断・再開」や「通信環境」といったユーザー視点の項目を網羅することで、リリース後の致命的な不具合は大幅に抑制できます。 また、手動テストの柔軟性と自動テストの継続性を賢く組み合わせることは、チームの生産性を向上させるだけでなく、エンジニアがより価値の高い開発業務に集中できる環境作りにも直結します。 今回ご紹介したプロセスやチェックリストを実務に適用し、不具合の傾向を蓄積してテスト設計をアップデートし続けてみてください。 品質改善の実績は、チームからの信頼獲得や、将来的にテックリードやマネージャーとしてプロジェクトを統括するための強力な武器となるはずです。 まずは次回のリリースに向けて、優先度の高い機能のテスト設計から見直してみることをおすすめします。 QA業務効率化ならPractiTest テスト管理の効率化 についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで 工数を20%削減できる 総合テスト管理ツール「 PractiTest 」がおすすめです！ PractiTest (プラクティテスト) に関する お問い合わせ トライアルアカウントお申し込みや、製品デモの依頼、 機能についての問い合わせなどお気軽にお問い合わせください。 お問い合わせ この記事の監修 Dr.T。テストエンジニア。 PractiTestエバンジェリスト。 大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。 2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。 記事制作： 川上サトシ （マーケター、合同会社ぎあはーと代表）