GENZ, Inc.

テスト外注の選定基準 アンケートアプリの品質を、第三者のテストで確かめる

検証範囲を文書として残し、リリース判定会議で「どこまで見たか」を説明できる状態へ。回答画面からポイント付与・集計まで、開発主体から独立した立場で検証します。

支援事例

支援実績5,000件以上

支援実績を示す企業ロゴ 01
支援実績を示す企業ロゴ 02
支援実績を示す企業ロゴ 03
支援実績を示す企業ロゴ 04
支援実績を示す企業ロゴ 05
支援実績を示す企業ロゴ 06
支援実績を示す企業ロゴ 07
支援実績を示す企業ロゴ 08
支援実績を示す企業ロゴ 09
支援実績を示す企業ロゴ 10
支援実績を示す企業ロゴ 11
支援実績を示す企業ロゴ 12
支援実績を示す企業ロゴ 13

この記事はソフトウェアテストの専門家が監修しています

監修枡井 愼治株式会社GENZ 代表取締役

GENZは創業以来、5,000件以上のソフトウェアテスト・第三者検証を手がけてきたプロフェッショナルです。品質に関する課題やお悩みに、真摯に寄り添います。

代表取締役 枡井 愼治 株式会社GENZ 〒101-0062 東京都千代田区神田駿河台2-3-11 ヒューリック御茶ノ水ビル3F TEL:03-5244-4711
01 ISSUES

アンケートアプリ開発に潜む検証の詰まり

設問分岐、端末条件、ポイント付与、集計の四つで、検証範囲の欠落が生じます。説明の材料なしに公開へ進んだ結果、修正と問合せの往復が増えます。

設問の分岐が仕様どおりに動いているか確かめきれない

設問の分岐条件は仕様書の記述から数えきれず、検証すべき経路の総数が分からないまま実装が進み、動いた組み合わせだけが確認済みとして扱われます。

設問の分岐経路

機種や画面サイズの違いをどこまで見るか決められない

端末の機種と画面サイズの組み合わせは増え続けるため、どこまで見たかを説明できません。削った範囲の根拠も「時間がなかった」としか書けません。

端末組み合わせ

ポイントや特典の付与量を公開前に確かめる手立てがない

付与量の算出条件はサービスごとに異なり、実装が仕様どおりかの確認と業務として妥当かの確認を区別できません。公開前に確かめる手立てもありません。

付与量の妥当性

集計結果と蓄積された回答の一致を人手で突き合わせている

蓄積された回答データと集計結果の一致を人手で突き合わせるため、差異は発見のたびに目視で追い、再集計と修正が個別対応として繰り返されます。

集計と回答の突合

公開直前になって確認する範囲を勘で絞っている

公開判定の会議に上程する材料を作る側が、検証の優先順位を勘で決めるため、削った経路が設問分岐のどこに当たるのかを説明できないまま上程します。

公開判定の根拠
02 RISK

検証が足りないまま公開したときに起きること

設問の分岐、ポイントの付与、集計は連動し、不具合は公開後まで表面に出ません。範囲を勘で絞って公開すると、影響は回答者にも依頼者にも広がります。

業務上の問題対応を行う担当者の様子を写した写真。
03 REVIEW

いまのテストの進めかたを点検するための観点

設問分岐や端末条件の組み合わせが増えるほど、検証範囲は担当者の勘に頼りがちです。公開後の問合せや集計の訂正を減らすには、いまの進めかたのどこに抜けがあるかを五つの観点で点検します。

経路の総数が把握されないまま公開すると、未検証の分岐で付与漏れや表示崩れが起き、公開直後の問合せとして表面化するおそれがあります。

テスト設計が仕様書の記述のどこまでを覆っているか

設問の分岐条件が仕様書から機械的に数えきれないまま実装が進むと、検証すべき経路の総数を誰も把握できません。テスト設計が仕様のどの記述までを覆っているか、対応表で確かめます。

確認する資料
  • 仕様対応表
  • 分岐経路一覧
  • 設計カバレッジ
削った範囲の根拠を説明できないままだと、対象外の端末で不具合が起きた際に、検証の判断そのものが問い直されるおそれがあります。

端末と回答条件の組み合わせをどう選んでいるか

端末の機種と画面サイズの組み合わせを「時間がなかった」で絞ると、削った範囲の根拠を受け入れ判定の場で説明できません。回答条件と併せて、選定の基準と除外の理由を記録に残します。

確認する資料
  • 端末選定基準
  • 除外理由記録
  • 回答条件一覧
業務観点の確認を担う工程がないと、付与量の誤りが公開後に残り、回答者への補填と問合せ対応の人件費として短期のコスト増につながるおそれがあります。

付与量と集計値の確認をどの工程が担っているか

ポイント付与量や集計値の正しさは、実装が仕様どおりかの確認とは別に、業務として妥当かの確認が必要です。付与条件の変更や交換先の条件変更が入る改修で、どの工程がその確認を担うかを決めます。

確認する資料
  • 付与条件定義
  • 集計確認手順
  • 工程分担表
事象の記録が引き継がれないと、運用側と品質担当の往復が増え、次の改修でも検証設計に手が回らない状態が繰り返されるおそれがあります。

見つかった不具合の記録が次の改修へ引き継がれているか

公開直後に寄せられた問合せの再現条件が記録に残らないと、同じ構造の不具合が次の改修で繰り返されます。事象の切り分け結果を不具合票として蓄積し、改修時の検証設計へ引き継ぐ形にします。

確認する資料
  • 不具合票
  • 切り分け記録
  • 引き継ぎ一覧
説明できる記録が残っていないと、納品後の訂正への説明が推測を含み、継続取引の判断材料として弱くなるおそれがあります。

テスト結果を社内と取引先へ説明できる形に残せているか

集計値の訂正が発生した際、原因がアプリ側か設問設計かを切り分ける記録がなければ、取引先への説明は推測を含みます。検証範囲と結果を、社内の合議と取引先への報告の双方で使える形に残します。

確認する資料
  • 検証範囲報告書
  • 実施結果記録
  • 残存リスク一覧
  • 原因切り分け表
04 TEST DESIGN

アンケートアプリのテストでお引き受けする範囲

検証範囲が膨らむ改修でも、GENZは機能範囲・端末条件・データ範囲の三つでスコープを区切り、引き受ける範囲を明文化します。

STEP 01 相談と対象範囲のすり合わせ機能・端末・データの三つで範囲を区切る
どう確かめるか

設問の回答経路をたどって組み立てるテスト設計

設問分岐や回答経路は、仕様書の記述だけでは総数を数え切れません。GENZは設問と分岐条件から経路を列挙し、どの経路を検証し、どの経路を削ったかを根拠付きで一覧化します。

  • 01検証対象となる設問・機能・改修箇所の範囲を整理します
  • 02対象とする端末と基本ソフトの版を利用実態から絞ります
  • 03スコープ外とする範囲と、除外の根拠をあわせて合意します
OUTPUTテスト計画書と設計書
STEP 02 テスト計画とテスト設計の作成検証する経路と優先順位を一覧に落とす
どう確かめるか

端末と実行環境を分けて進める実機での回答確認

スマートフォンの機種と画面サイズの組み合わせは、時間切れで削ると説明の根拠が残りません。GENZは利用実態に近い端末を優先順位付けし、実機で回答から送信までの挙動を確認します。

  • 01設問の分岐条件をたどり、検証すべき経路を列挙します
  • 02付与と交換の条件ごとに期待値と確認手順を定義します
  • 03経路ごとの優先順位と、必要工数の考えかたを示します
OUTPUT検証対象範囲の一覧表
STEP 03 テストの実施と不具合の報告不具合は発生条件と再現手順つきで報告する
どう確かめるか

付与量と集計値の突き合わせによる業務観点の検証

ポイント付与条件の変更は、回答と集計の突き合わせが欠けると差異として表面化します。GENZは付与・交換の条件ごとに期待値を置き、意図的に発生させて検証し、集計結果と照合します。

  • 01実機で回答の入力から送信までの一連の経路を検証します
  • 02付与量と集計値の突き合わせを、条件ごとに実施します
  • 03不具合は発生条件と再現手順、影響範囲を添えて報告します
OUTPUT不具合報告と再現手順
STEP 04 結果の報告と次回の改修への引き継ぎ次回以降の改修でも使える記録として残す
どう確かめるか

リリース判定の説明に使える形で残すテスト結果の整理

検証結果は、実施した範囲と見なかった範囲を分け、経路・端末・条件の単位で記録します。リリース判定会議や取引先への説明で、そのまま根拠として使える形に調えてお渡しします。

  • 01検証済みの範囲と未検証の範囲を分けた形で報告します
  • 02残存するリスクを数えられる形へ整理してお渡しします
  • 03次回以降の改修で再利用できる記録として引き継ぎます
OUTPUT説明に使える検証結果報告書
05 RATIONALE

アンケートアプリの検証を外部に任せた現場の変化

固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。

OUTSOURCING RATIONALE THIRD-PARTY VERIFICATION

必要な時に必要な分だけ

人日単位のアサインで固定費を抱えず、繁忙期に増減できます。

独立した視点で品質を底上げ

独立した検証で偏りを排し、監査に使える客観的な記録を残せます。

専門ノウハウを即戦力で

JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。

ノートPCを前に担当者同士が相談しているオフィスの写真。

専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット

  • 検証範囲の根拠を文書で残せ、リリース判定で説明できます
  • 機種と画面サイズを根拠付きで選び、実機確認を進められます
  • 仕様どおりかの確認と業務上の妥当性の確認を分けて設計できます
  • 検証記録が証跡として残り、取引先や役員へ経緯を示せます
06 SERVICE

GENZが提供するテストの支援内容

「どこまで検証したかを説明できる状態にしたい」という課題に対し、GENZはテスト計画から実施、報告までを引き受けます。回答画面に加えてポイント付与や集計も対象に含め、開発主体とは独立した立場で検証します。

SVC 01

開発の進行に伴走して行なうテスト

スプリントに合わせてテストを組み込み、検証範囲と結果を文書に残します。リリース判定で「どこまで見たか」を説明できる状態をつくります。

リスク要因と優先順位を示す無文字の図解。
SVC 02

規模の大きい基盤に対する検証範囲の設計

端末の機種と画面サイズの組み合わせを、利用実態を根拠に選び、実機で確認します。規模の大きい対象でも、範囲の決定に裏付けを持たせます。

複数のシステムや連携先にまたがる確認範囲を示す無文字の図解。
SVC 03

開発の担当から独立した立場での実施

開発ベンダーと切り離した第三者の視点で検証します。実装が仕様どおりかの確認と、付与量が業務として妥当かの確認を別工程として設計します。

計画から報告までの流れを示す無文字の図解。
SVC 04

テストの記録を整理して保管する運用

検証の記録を証跡として整理し、あとから参照できる形で保管します。取引先や役員へ経緯を示すとき、記録に基づいて説明できる状態を保ちます。

確認対象の領域を区分して示す無文字の図解。
07 FLOW

ご相談から報告までの進みかた

外注の進め方に社内の前例がなくても、現状の共有から報告まで各段で合意の形を決めながら進めます。

お問合せと現在の検証状況の共有

検証範囲の決めかたや過去の事象記録など、手元の資料をご共有いただきます。

対象範囲と実施体制の見積のご提示

回答画面から付与・集計までの範囲を整理し、体制と費用の見積をお出しします。

テスト計画にもとづく検証の実施

合意した計画に沿ってテストを設計・実施し、端末条件ごとの結果を記録します。

検証結果のご報告と改善のご提案

検証結果と残存リスクを報告書にまとめ、改善の進め方をご提案します。

アンケートアプリのテスト外注のご相談

アンケートアプリのテストを、外部の目で確かめませんか

検証範囲をどう定めるかから話し合いを始められます。対象とすべき機能の範囲と優先順位、回答画面に限るか付与と集計まで含めるかを、第三者の視点で整理してご案内します。