SERVICE

ITソリューション事業／テスト・品質保証

開発から独立した第三者の立場で、システムがあるべき品質を満たしているかを評価・検証します。

JSTQB Certified Gold Partner として、テストの計画から設計・実行、テスト自動化まで対応します。開発チームとは別の視点で仕様の抜けや不具合を見つけ、リリースの判断に必要な情報をお届けします。

PROCESS

第三者検証の進め方

JSTQB のテストプロセスに沿って進めます。開発チームとは別の立場で、仕様と実際の動きを照らし合わせます。

01
テスト計画
対象・範囲・品質目標・スケジュールを決める
02
分析・設計
仕様書からテスト観点とテストケースを作る
03
実装・実行
手動のテストと、画面から操作する自動テストを組み合わせて実行する
04
不具合の報告
再現手順と影響範囲を添えて報告し、修正後に再確認する
05
完了・報告
結果と残るリスクをまとめ、リリース判断の材料にする

要件定義の段階から加わると、仕様の抜けや矛盾をテストの前に見つけられます

TEST AUTOMATION

テスト自動化

開発側のコードや CI には触れず、検証環境で動いているシステムを画面から確かめます。受け入れのたびに、同じ範囲を同じ手順で確かめられるようにします。

画面から操作する回帰テスト
Selenium や Playwright で、画面を外から操作する回帰テストを検証側で作り、新しい版を受け入れるたびに既存の機能が壊れていないかを確かめます。
検証側で持つテスト資産
観点表・テストケース・自動テスト・実行の記録は、検証側で管理します。開発側のリポジトリや CI には置かず、開発の変更に左右されない基準として保ちます。
結果と処理時間の記録
実行ごとの合否と処理時間を残し、前回の受け入れと比べて、遅くなった操作や新しく失敗した操作を報告します。

AS-IS / TO-BE

あるべきテスト自動化

テスト自動化でよく起きているのは、コードが変わるたびに自動テストが動かなくなることです。止まるたびに直す前提ではなく、変更に追いついていける自動テストにします。

AS-IS

自動テストが、変更のたびに動かなくなる

画面の項目名や配置が変わるたびに、自動テストが止まる
直す手が追いつかず、失敗したままのテストが増えていく
失敗が不具合なのか、テストが壊れただけなのか、見分けがつかない
結局、手作業の確認に戻り、自動化にかけた工数が生きない

TO-BE

仕様書を正本にして、変更に追いついていく

テストの正本は、画面の作りではなく、仕様書に書いた「操作と期待する結果」に置く
失敗したら、不具合かテストの壊れかを切り分けてから報告する
テストの壊れは、次の受け入れまでに直し、検証側の回帰テストに戻す
受け入れのたびに、同じ範囲を同じ手順で確かめられる状態を保つ

WHY IT STALLS

なぜ、自動テストは追いつけないのか

直すべきことは分かっていても、変更の速さに、テストの修正が追いつきません。

01
変更に、テストの修正が追いつかない
第三者検証では開発側のコードを見ないので、画面が変わったことは、テストが止まって初めて分かる。
02
切り分けと修正に、人の手がかかる
失敗のたびに、画面の記録を見て原因を切り分け、スクリプトを直す。テストを書ける人の手が空かない。

回らない原因

AI でこうする

01変更に、テストの修正が追いつかない
Selenium や Playwright を土台に、AI が Computer Use で、仕様書に書いた操作を画面の表示を読み取りながら実行する。項目名や配置が変わっても、止まりにくい。
02切り分けと修正に、人の手がかかる
失敗したときは、AI が画面の記録と仕様書を照らし、不具合かテストの壊れかの候補を出す。壊れたスクリプトの修正案も AI が書き、人がレビューして戻す。

AI に何が見えるかは、下の段のとおり、お客様と一緒に決めます。

SERVICES

テスト・品質保証サービス

工程や目的に合わせて、必要なサービスを選べます。

01
第三者検証・アジャイル QA
開発チームから独立した立場でテストを設計・実行します。リリースの頻度が高いアジャイル開発にも対応します。
02
品質コンサルティング・品質 PMO
品質目標とテスト計画を一緒に決め、プロジェクト全体の品質管理を進めます。
03
ゲームテスト
ゲームの操作性や不具合を、プレイヤーの視点で検証します。
04
負荷テスト
アクセスが集中したときの耐性を測り、応答が遅い箇所の改善案を出します。
05
帳票の回帰テスト
帳票の出力を正解データと照合し、意図しない変化を見つけます。

AIOps × 第三者評価・検証

AIOPS FOR THIRD-PARTY TESTING

仕様書を正本に、変更に追いついていく自動テスト

この段で
伝えていること

第三者検証では、開発側のコードは見ず、変更もしません。そのため、画面が変わったことは、自動テストが止まって初めて分かります。テストの正本を、画面の作りではなく、仕様書に書いた「操作と期待する結果」に置き、AI が Computer Use で画面の表示を読み取りながら実行します。止まったときは、不具合なのかテストの壊れなのかの候補を AI が出し、壊れたテストの修正案も書きます。合否と判断は、第三者として人が持ちます。仕様書が実際の動きから離れて古くなったときは、AI が更新案をつくり、人が確かめて確定します。

工程JSTQB のテストプロセス

AI下書き・候補・実行

人（HITL）第三者として判断する

01テスト計画
AI下書き・候補・実行
過去の不具合と変更の範囲から、リスクの高い箇所の候補を挙げる
人（HITL）第三者として判断する
範囲・品質目標・優先度を決める
02分析・設計
AI下書き・候補・実行
仕様書から観点・境界値・異常系・権限の組み合わせを洗い出し、テストケースを下書きする。仕様の矛盾や曖昧な記述の候補も挙げる
人（HITL）第三者として判断する
観点の過不足を判断し、テストケースを確定する
03実装・実行
AI下書き・候補・実行
仕様書に書いた操作を、AI が Computer Use で画面の表示を読み取りながら実行する。画面が変わっても止まりにくい。操作ごとの処理時間も記録する。テストデータを作るスクリプトを書く
人（HITL）第三者として判断する
探索的テストと、使い勝手の評価。処理時間が基準に収まっているかを判断する
04不具合の報告
AI下書き・候補・実行
失敗したとき、画面の記録と仕様書を照らし、不具合かテストの壊れかの候補を出す。壊れたテストの修正案と、不具合の報告を下書きする
人（HITL）第三者として判断する
不具合かテストの壊れかを判断し、重大度と影響範囲を決める
05完了・報告
AI下書き・候補・実行
結果を集計し、残るリスクの要約を下書きする
人（HITL）第三者として判断する
リリース判断の材料をまとめ、責任を持って報告する

基準何に照らすか

正本：仕様書・要件・受入基準AI の下書きや実行の結果も、人の判断も、すべてここに照らして確かめる

第三者検証で AI を使うときに守ること

01
正本は、仕様と要件
確かめる基準は、開発側のコードやテストではなく、仕様書・要件・受入基準です。開発側のコードは見ず、動いているシステムを仕様に照らして確かめます。
02
開発と同じ前提で確かめない
開発側も AI で実装やテストを書くことが増えています。同じ前提の AI に確かめさせると、同じ見落としを重ねます。観点は仕様から、検証側で独立して立てます。
03
合否と判断は、人が持つ（HITL）
AI が担うのは下書き・候補・テストの実行です。合否・重大度・リリースの判断材料は、第三者として人が決め、責任を持って報告します。

AI に見えるもの

AI が Computer Use で画面を操作するとき、画面に表示された内容は AI に渡ります。検証環境のデータは架空のものにし、本番のデータは使いません。画面や仕様書を AI に見せること、どこで AI が処理するかは、お客様と一緒に決めます。

AI のタスク	AI に見えるもの	扱い
画面を操作してテストを実行する（Computer Use）	検証環境の画面と、そこに表示されるテストデータ	テストデータは架空のものにし、本番のデータは使わない。画面を AI に見せることを、お客様と確認する
テストケースを下書きする	仕様書・要件・受入基準	社外秘の仕様書を AI に渡してよいかを、お客様と確認する
不具合の報告を下書きする	再現手順、画面の記録、ログ	画面とログに実在のデータが映っていないことを確かめてから渡す
テストデータを作るスクリプトを書く	データの形（項目名とダミーの例）	そのまま渡せる
仕様書の更新案をつくる	仕様書と、動きとの食い違い・不具合の記録	仕様書と同じ扱い

具体例をコードで見る

01
実行する
仕様書に書いた操作を、AI が Computer Use で画面を読み取りながら実行する
02
切り分ける
失敗したとき、画面の記録と仕様書を照らし、不具合かテストの壊れかの候補を AI が出す。人が判断する
03
直す
不具合は報告して回帰テストに加える。テストの壊れは、AI が修正案を書き、人がレビューする
04
回帰テストに戻す
直したテストを、受け入れのたびに実行する検証側の回帰テストに戻す

↺ 次の受け入れでは、直したテストで同じ範囲を確かめる。画面が変わっても、止まったままにしない

01
仕様書の操作を、AI が人と同じように実行する
これまで受け入れのたびに、担当者が同じ画面操作を目視と手作業で繰り返し確認している。
AI を組み込むとSelenium や Playwright を土台に、AI が Computer Use で、仕様書に書いた操作を検証環境の画面を読み取りながら実行する。操作ごとの処理時間も記録する。開発側のコードには触れない。
手で確かめていた操作が、毎回同じ手順で走り、処理時間も残る
```
# 実行の記録（請求書の CSV 出力）01 ログインする 1.2s OK02 請求書一覧を開く 0.8s OK03 CSV 出力を押す 3.4s OK（基準 2.0s を超過）04 ダウンロードを確かめる 0.5s OK
```
02
画面が変わって止まったテストを、直す
これまでボタンの名前が「出力」から「CSV ダウンロード」に変わり、自動テストが止まる。担当者が原因を調べ、スクリプトを書き直す。
AI を組み込むと失敗したときの画面の記録と仕様書を AI が照らし、「仕様どおりの変更で、テストの壊れ」と候補を出す。スクリプトの修正案も書き、人がレビューして戻す。
止まったテストが、次の受け入れまでに戻る
```
# 検証側の回帰テスト（請求書の CSV 出力）- await page.click("text=出力")+ await page.click("text=CSV ダウンロード")+ // 切り分け: 仕様書の文言の変更に合わせた修正（不具合ではない）
```
03
見つけた不具合を、回帰テストにする
これまで修正された不具合が、その後の版で再発していないかを手作業で確認し直している。
AI を組み込むと報告した不具合の再現手順から、AI が画面から操作する回帰テストを作り、検証側の回帰テストに加える。
一度見つけた不具合は、次の受け入れで必ず確かめる
```
# 検証側の回帰テスト（ログイン後の戻り先）// 不具合: ログイン後に元のページへ戻らないtest("ログイン後に元のページへ戻る", async ({ page }) => {  ...})
```