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

お引き受けする検証の進行と体制

診療予約アプリの検証は、開発の進行に合わせて伴走し、リリース判断に使える証跡まで残す形で請け負います。

STEP 01 テスト計画と対象範囲のすり合わせ設定差分を含め対象範囲を確定します
どう確かめるか

改修ごとに開発スプリントへ伴走してテストを実施する

実装の完了を待たず、仕様が固まり次第テスト設計に着手します。リリース直前に検証が集中する状態を避け、改修のたびに伴走して確かめます。

  • 01対象となる機能と設定差分の範囲を漏れなく洗い出します
  • 02これまでの回帰テストの積み残しと未収束の不具合を整理します
  • 03実施の優先順位と着手の順序、必要な要員を貴社と決めます
OUTPUTテスト計画書・範囲一覧
STEP 02 テスト設計と設計内容のレビュー設計内容を貴社と確認してから進めます
どう確かめるか

予約から受付・会計までを一連の流れで確かめる

予約・受付・診察・会計まで、利用者の操作が連なる範囲を一連の流れとして検証します。画面単位では見えない、画面遷移と前提条件の抜けを洗い出します。

  • 01画面遷移と前提条件を洗い出し、テスト項目へ落とし込みます
  • 02開発側の結合テストの範囲と突き合わせ、抜けを調整します
  • 03設計した内容を貴社とのレビューで確認してから実施へ移ります
OUTPUTテスト設計書・項目表
STEP 03 テストの実施と不具合の起票発生させて検証し不具合を起票します
どう確かめるか

開発の指揮系統から切り離した体制で検証を担当する

開発ベンダーとは別の系統で検証を担当します。開発側の結合テストと範囲を突き合わせ、重なりと抜けを調整したうえで、第三者の視点で確かめます。

  • 01計画したテスト項目を、決めた優先順位の順に検証します
  • 02見つかった不具合は、再現手順と発生条件を添えて起票します
  • 03修正が入った範囲について、再度の確認までを実施します
OUTPUT不具合報告・起票一覧
STEP 04 報告書の提出と次回への引き継ぎ未収束事項と次回範囲を引き継ぎます
どう確かめるか

そのまま提出できる形式でテストの証跡を管理する

実施した範囲と未収束の不具合を、合議体や審査にそのまま出せる形式で残します。担当者ごとの手元メモを集めて組み立てる手間を省きます。

  • 01実施した範囲と結果を、提出できる形式の報告書にまとめます
  • 02未収束の不具合と、リリース判断に必要な材料を示します
  • 03次のリリースで確かめる検証範囲と優先順位を提案します
OUTPUTテスト報告書・証跡一式
05 RATIONALE

お引き受けしてきた診療予約アプリの検証領域

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

OUTSOURCING RATIONALE THIRD-PARTY VERIFICATION

必要な時に必要な分だけ

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

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

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

専門ノウハウを即戦力で

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

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

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

  • 診療科ごとの予約条件の差分を、設定単位で整理して検証します
  • 改修のたびに膨らむ回帰テストを、外部の体制で回しきります
  • 家族分のまとめ予約や受付通知の分岐を、操作の順序から検証します
  • 権限設計と個人情報の参照範囲を、合議体へ出せる記録で残します
06 SERVICE

ご用意しているテストの委託メニュー

回帰テストの実施量を外部の体制で吸収し、開発から独立した立場で検証を担います。設定差分ごとの確認から提出用の検証記録の作成まで、品質保証の工程に合わせた委託メニューを用意しています。

SVC 01

機能テストの観点整理と設計・実施

要件と仕様からテスト観点を整理し、テストケースの設計から実施までを担います。開発の視点から独立した設計として第三者の目で組み立てます。

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

回帰テストの項目整備と実施の運用

設定差分ごとに増える回帰テストの実施を外部の体制で引き受けます。リリースが重なる期間に合わせて増減させ、繁忙時の実施量を吸収します。

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

受け入れテストと検証記録の作成支援

実施した範囲と結果を、合議体や権限設計の確認へそのまま提出できる形式で整理します。説明責任を担う際の根拠資料としてご活用いただけます。

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

テスト自動化の導入と定着の支援

テスト自動化の対象選定から導入の開始までを支援します。項目が安定した領域を見極め、維持の手間が新たな負荷にならない形をご提案します。

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

お問合せから検証開始までの流れ

お問合せから検証開始までの流れは以下のとおりです。現状の確認から着手まで、段階を追って進めます。

フォームまたは電話でのお問合せ

フォームまたは電話から、検証したい対象と困りごとをお知らせください。

現状と検証対象の範囲のヒアリング

アプリの構成と検証対象の範囲、既存のテスト実施状況を確認します。

テスト範囲のご提案とお見積の提出

テスト範囲と優先順位、必要工数の根拠を添えて見積を提出します。

ご契約と検証計画の策定から着手まで

ご契約後、開発チームと連携しながら検証計画を立て、着手します。

開発の指揮系統から独立した検証体制

診療予約アプリの検証について、まずはご相談ください

診療予約アプリの検証は、どこまでを対象とし、どの順で進めるかが分かれ目です。GENZにご相談いただければ、テスト範囲と優先順位、必要工数の目安、関連テストの要否まで整理します。