ソフトウェア品質を支える テストとレビュー再考 / 吉澤 智美さん

2025/11/07開催
開発をリードする品質保証 QAエンジニアと開発者の未来を考える -Findy Online Conference -
NPO法人ASTER 副理事長・テスト設計コンテスト担当理事 / 吉澤 智美 @tuluneさん

1. ソフトウェア品質を支える テストとレビュー再考 NPO法人 ASTER 吉澤智美 © 2025, Yoshizawa Satomi 1/43 おさらい 2025.11.7 開発をリードする品質保証 -Findy Online Conference -
2. 自己紹介 名前：吉澤智美 所属：NPO法人ASTER 副理事長 お仕事：諸々のお世話係、お片付け係 NPO法人ASTER 副理事長 テスト設計コンテスト、 JaSST東京/Review実行委員、総務WG JSTQB 運営委員・技術委員、智美塾 塾長 ISO/IEC JTC1/SC7/WG26 技術委員 © 2025, Yoshizawa Satomi 2/43
3. 今日お話すること • 品質とは • テストとは • レビューとは • もっとテストを知るために • おわりに © 2025, Yoshizawa Satomi 3/43 本資料はNPO法人ASTERの「ASTERセミナー標準テキスト」を引用しています https://aster.or.jp/business/seminar_text.html 引用しているページは「ASTERセミナー標準テキストを引用」と表示しています
4. © 2025, Yoshizawa Satomi 4/43 品質とは？ 品質を分解して考える（品質の要素） 品質を良くすると何が嬉しいのか 品質を良くするには
5. 品質とは • 誰かにとっての価値である © 2025, Yoshizawa Satomi 5/43
6. 品質の定義 その変遷 • クロスビー（Philip B. Crosby）：品質とは、要件に対する適合である。精密に 測定可能で誤りは不可避ではない（Zero Defect）。 → 一般の工業プロダクトよりの定義となっている。 • ワインバーグ（Gerald M. Weinberg）：品質は誰かにとっての価値である。こ こで価値という言葉は、「人々はその要求が満たされるなら、喜んで対価を支 払う」ということを意味している。 • 石川馨（いしかわ かおる）：日本的品質管理の父と呼ばれている。 「製品の品質」は欧米の考えである「狭義の質」である。一方「広義の質」は 仕事の質、サービスの質、情報の質、工程の質、部門の質、人の質、システム の質、会社の質等、これら全てを含め捉える。品質管理は「広義の質」につい て管理することを基本姿勢とする。 © 2025, Yoshizawa Satomi 6/43 出典： ソフトウェア品質知識体系ガイド（SQuBOK Guide V2） ASTERセミナー標準テキストP.23を引用
7. 品質の定義 その変遷（続き） • 保田勝通：品質は、ユーザーにとっての価値である。 → 近代的な品質管理における品質の定義：品質は、ユーザー の満足度である。 出典： ソフトウェア品質保証の考え方と実際， 日科技連出版， 保田勝通著 • JIS Q 9000：「対象に本来備わっている特性の集まりが、要求 事項を満たす程度」と定義されている。 © 2025, Yoshizawa Satomi 7/43 ASTERセミナー標準テキストP.24を引用
8. 品質の要素 ・「ちゃんと動くこと」だけではない ・先人の知恵をまとめた諸々がある © 2025, Yoshizawa Satomi 8/43
9. 製品品質 SQuaRE(ISO/IEC 25000シリーズ) © 2025, Yoshizawa Satomi 9/43 IPA「つながる世界の利用時の品質 ～IoT時代の安全と使いやすさを実現 する設計～」より引用 https://www.ipa.go.jp/archive/files/000058465.pdf
10. 利用時の品質 SQuaRE(ISO/IEC 25000シリーズ) © 2025, Yoshizawa Satomi 10/43 IPA「つながる世界の利用時の品質 ～IoT時代の安全と使いやすさを実現 する設計～」より引用 https://www.ipa.go.jp/archive/files/000058465.pdf
11. (ちょっと脱線) ISOって何？ ISO：国際標準化機構（International Organization for Standardization） ・1947年2月23日、18ヶ国により、国家間の製品やサービスの交換を助け て標準化活動の発展を促進し、知的・科学的・技術的・経済的活動におけ る国家間協力を発展させることを目的に発足 • 本部はスイスのジュネーブ • 日本がISOに参加したのは1952年 （日本工業標準調査会(JISC)） • ハードからソフトまでいろいろ な標準があります → © 2025, Yoshizawa Satomi 11/43
12. 品質を良くすると何が嬉しいのか • バグがない→使用者に迷惑※をかけない(怒られない) • 使いやすい→使用者から感謝される • お金が儲かる(かもしれない) ↓ • 安心して眠れる © 2025, Yoshizawa Satomi 12/43 ※(例)ソフトウェアの障害により 引き起こされること • 経済的な損失 • 時間の浪費 • 信用の失墜 • 傷害や死亡事故
13. 品質を良くするには • ちゃんと作る • ちゃんと確認する © 2025, Yoshizawa Satomi 13/43
14. (ちょっと脱線) ちゃんと、とは １ 少しも乱れがなく、よく整っているさま。「部屋の中をちゃ んとかたづける」「いつもちゃんとした身なりをしている」 ２ 確実で間違いのないさま。「言われたことはちゃんとやる」 「ちゃんとした職業につく」 ３ 結果が十分であるさま。「朝食はちゃんと食べてくる」 ４ すばやく動作をするさま。さっと。 （デジタル大辞泉） © 2025, Yoshizawa Satomi 14/43
15. 品質を良くするには • ちゃんと作る ↓ 開発の話なので今回は他の方にお譲りします • ちゃんと確認する ↓ テストとレビュー、ですよね？ © 2025, Yoshizawa Satomi 15/43
16. © 2025, Yoshizawa Satomi 16/43 まずはテストの話
17. © 2025, Yoshizawa Satomi 17/43 ところでテスト、嫌いですか？
18. テストが嫌いなのはなぜ？ • テストするのはめんどくさい・つまんなそう • テスト項目書通りに手を動かしていくのはめんどくさい • テスト結果を報告するのがめんどくさい • テストで何やるのか、考えるのがめんどくさい • 俺の（私の）コードは完璧だ（テストする必要はない） • バグが見つかったら直さなきゃいけない • テストをしたことがないのでそもそもわからない © 2025, Yoshizawa Satomi 18/43 食わず嫌い、してませんか？ お客様にお渡しするものはバグないほうがいいですよね？ めんどくさいことは自動化とかも考えましょう テストをクリエイティブに、面白くすること、考えてみませんか？
19. © 2025, Yoshizawa Satomi 19/43 ということで、テストについて ちょっと説明させてください
20. ①欠陥を摘出する 開発側でのテストでは、なるべく 多くの故障を検出し、ソフトウェ ア中の欠陥を特定して修正するこ とを主目的とする。 20/43 テストの目的 ②対象ソフトウェアの品質 レベルが十分である ことを確認し、 その情報を示す テスト対象の品質に対する信頼 を積み重ねて、所定のレベルに あることを確証する。 ③意思決定のための 情報を示す ステークホルダーが意志決定でき る、特にテスト対象の品質レベル についての十分な情報を提供する。 欠陥 © 2025, Yoshizawa Satomi ④欠陥の作りこみを防ぐ ライフサイクルの初期にテス ト設計のことを考えると、 コードの中に欠陥が潜り込ま ないようにする効果がある。 ASTERセミナー標準テキストP. 19を引用
21. テストのプロセス(やり方) © 2025, Yoshizawa Satomi 21/43 • 昔はテストする、だった。 • 今はテストも設計してから実装、実行する
22. テストの時に見る(入力とする)もの 設計書だけとか、コードだけとかではないですよね？ • テストベース(仕様書とか設計書とかマニュ アルとかドキュメント一式のこと) • テスト対象およびテスト範囲 • テスト対象に関する情報 • ステークホルダー一覧 • ユーザ特性／コンシューマ特性／ペルソナ • ステークホルダー要求 • システムの完成像への要求 • テストプロジェクトへの要求 • テストタイプ • テスト手段またはアプローチ • テスト成果物の品質要求 • 開発体制／開発者関係 • 過去の類似プロジェクト／プロダクトの 状況や成果物 • 欠陥データベース • テストプロジェクトのチーム状況 • 品質ポリシー、品質計画 • ＜保守開発＞ • 保守元や母体のどこに影響があるかの分 析結果 • 母体のどこを変更するかの変更要求仕様 • 母体または保守元の品質状況 • 既存のテストケース • 解決を先送りしてきた長年の懸案事項 © 2025, Yoshizawa Satomi 22/43
23. テストで考えること • 機能テストはもちろん行いますね？ • 非機能テストと呼ばれるものにはたとえばこのようなものもあります • 操作性 • 運用性 • 性能 • 信頼性 • セキュリティ • 障害対応性 • 正常系、異常系も考えます • 異常系：エラーを引き起こす環境、インプット等を意識したテスト • 異常系の比率：ドメインによって異なるが、40～90％くらい © 2025, Yoshizawa Satomi 23/43
24. (ちょっと脱線) 組込み系のテスト設計で考慮すべきテスト観点の例 1/2 • 機能：テスト項目のトリガ • ソフトとしての機能 • 音楽を再生する • 製品全体としての機能 • 走る • パラメータ • 明示的パラメータ • 入力された緯度と経度 • 暗黙的パラメータ • ヘッドの位置 • メタパラメータ • ファイルの大きさ • ファイルの内容 • ファイルの構成、内容 • 信号の電気的ふるまい • チャタリング、なまり • プラットフォーム・構成 • チップの種類、ファミリ • メモリやFSの種類、速度、信頼性 • OSやミドルウェア • メディア • HDDかDVDか • ネットワークと状態 • 種類 • 何といくつつながっているか • 周辺機器とその状態 • 外部環境 • 比較的変化しない環境 • 場所、コースの素材 • 比較的変化しやすい環境 • 温度、湿度、光量、 • 電源、電波 © 2025, Yoshizawa Satomi 24/43 http://jasst.jp/symposium/jasst13tokyo/pdf/A2-4.pdf などから引用
25. (ちょっと脱線) 組込み系のテスト設計で考慮すべきテスト観点の例 2/2 • 状態 • ソフトウェアの内部状態 • 初期化処理中か安定動作中か • ハードウェアの状態 • ヘッドの位置 • タイミング • 機能同士のタイミング • 機能とハードウェアのタイミング • 組み合わせ • 同じ機能をいくつカブせるか • 異なる機能を何種類組み合わせるか • 性能 • 最も遅そうな条件は何か • 信頼性 • 要求連続稼働時間 • GUI・操作性 • 操作パス、ショートカット • 操作が禁止される状況は何か • ユーザシナリオ • 操作ミス、初心者操作、子供 • 出荷先 • 電源電圧、気温、ユーザの使い方 • 言語、規格、法規 • 障害対応性 • 対応すべき障害の種類 • 水没 • 対応動作の種類 • セキュリティ • 扱う情報の種類や重要度 • 守るべきセキュリティ 要件 © 2025, Yoshizawa Satomi 25/43 http://jasst.jp/symposium/jasst13tokyo/pdf/A2-4.pdf などから引用
26. (ちょっと脱線) エンプラ系のテスト設計で考慮すべきテスト観点の例 1/2 • 機能、テスト項目 • データ整合と運用 • ログ • 仮想化 • CPU割り当て数やアプリの制限 • CPU100％ • IME操作 • パラメータ • 設定組合せ • マスタ設定 • 未設定の時の動作 • 例外 • 例外処理をしているか • エラー・警告ログの対応 • プラットフォーム • SaaS/PaaS/IaaS • クラウドサービス • サーバ仮想化 • クライアント仮想化 • ネットワーク（VPN,WAN • 接続機器 （プリンタ、スキャナ、装置、etc.) • 外部環境 • 文字コードの変更 • 外部とのデータ交換 銀行、EDI(電子商取引) データ提供サービス (業界標準書式) © 2025, Yoshizawa Satomi 26/43
27. (ちょっと脱線) エンプラ系のテスト設計で考慮すべきテスト観点の例 2/2 • 状態 • 内部状態、ガベージ • HW:フェイルオーバー • タイミング • サービスの立ち上げ順序 • シャットダウン処理（OS,MW) • 組合せ（機能） • デッドロック • オンラインバッチ • Officeソフト • 性能 • 同時接続数 • Webでのクリック(連打) ←サーバへの負荷 • 信頼性 • SLA(ex. 99.9%とか） • 保守時間/周期 • GUI(UI) • マルチモニタ モニタサイズ • ウェブアクセシビリティ、統一感 • マウス/キーボード • 出荷先 • ネットワーク環境（LAN/WAN) • お客さんがSGしたソフト (セキュリティ、環境設定、バージョン) • 耐障害性 • AP異常終了 • I/F先からの想定外のデータ • 移行データに不親切なデータ • セキュリティ • ネットワーク • OS、M/W • クライアント―サーバ • Ap開発 © 2025, Yoshizawa Satomi 27/43
28. どうやってテストするのか～テスト技法～ © 2025, Yoshizawa Satomi 28/43 ASTERセミナー標準テキストP. 100を引用
29. 29/43 テスト設計 • テストは、 ◦ 時間とお金の都合を考えて、QCDF（Fは機能やフィーチャー）の バランスの取れた情報を提供する（＝どこで妥協するか）。 × 納期までの時間を優先し、残った時間でテストする。 • そこで、設計することで最も適したテストを探る。 ✔ テストケースを合理的に少なくするための技法 ・同値分割法 ・組み合わせテスト ✔ 多くの欠陥が見つかるようにするための技法 ・境界値分析 ・エラー推測 ・探索的テスト ✔ テスト対象を漏れなくテストするための技法 ・制御フローテスト ・データフローテスト ・デシジョンテー ブルテスト ・状態遷移テスト ・ユースケーステスト © 2025, Yoshizawa Satomi ASTERセミナー標準テキストP. 96を引用
30. どのくらいテストするのか • いつ終わるのか：終了基準を決めておく • 求められる品質に応じて合意しておく • それらを品質指標と呼ぶ © 2025, Yoshizawa Satomi 30/43 • 典型的な終了基準 ◦ 計画したテスト実行が完了している ◦ 定義済みのカバレッジを達成している ◦ 未解決の欠陥の件数は合意された制限内である ◦ 残存欠陥の想定数は合意された制限内である ◦ 信頼性、性能効率性、使用性、セキュリティ、 他の関連する品質特性を評価し、要求を満たし ている
31. © 2025, Yoshizawa Satomi 31/43 次はレビューの話
32. レビューの目的 • 欠陥を(早期に)見つける • 要求を確認、合意する • もっと良いやり方を見つける • 学習の場 © 2025, Yoshizawa Satomi 32/43
33. レビュー種別 レビュー種別は目的や開発プロセスの成熟度などで適切に選ぶ必要がある。 • 非形式的レビュー 「不正の検出」を主な目的とする。定義されたプロセスに従わず、文書化され たアウトプットを必要としない。 • ウォークスルー 不正の検出の他にも、レビューアの教育や合意形成などの複数の目的を達成で きる。作業成果物の作成者がミーティングを主導する。 • テクニカルレビュー 技術的な問題に関して合意を得て判断することに加えて、不正の検出や新しい アイデアの創出などを目的とする。 技術的に適格なレビューアが行い、モデ レーターが主導する。 • インスペクション 「不正を最大数発見すること」を目的とする。メトリクスを収集して、インス ペクションプロセスを含むSDLCを改善するために使用する。最も形式的なレ ビューであり、レビュープロセスに従う。 © 2025, Yoshizawa Satomi 出典： ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2023V4.0.J02 ASTERセミナー標準テキストP. 92を引用 33/43
34. © 2025, Yoshizawa Satomi 34/43 テストとレビュー
35. テストとレビューの違い • テスト：宝探し：動いて(動かして)見つける：動的 • レビュー：間違い探し：見て見つける：静的 見つけたいものの性質やプロジェクトの制約などで いつどのように確認する(テストする・レビューする)かを決める →品質保証計画 どちらも慣れてくると見つけるのがうまくなる 宝探しや間違い探しと違うのは、答えを誰も知らないこと →そのために品質指標がある © 2025, Yoshizawa Satomi 35/43
36. © 2025, Yoshizawa Satomi 36/43 テストを知るために
37. もっとテストを知るために • テストを楽しく経験する：テスト設計コンテスト • テスト/レビューを語り合う：JaSST • テスト技術を学ぶ：JSTQB • テストプロセス国際標準：ISO/IEC/IEEE 29119 • レビュー技法の国際標準：ISO/IEC 20246 © 2025, Yoshizawa Satomi 37/43
38. テスト設計コンテスト https://aster.or.jp/testcontest/ • テスト技術の教育、開発、体験の場としてASTERが開催 • いわゆるバグバッシュ(バグ出しコンテスト)ではなく、テスト をどのように行うかのテスト設計の良さを競う • 30歳以下のU-30 クラスと制限のないOPENクラスがある • 例年、春頃にチュートリアルも開催、動画配信あり https://www.youtube.com/@aster-test-design-competition • どちらのクラスも予選終了しており、決勝大会は1/24（土）、 日本科学未来館＋オンラインで開催予定。聴講無料 聴講申込みは以下から https://aster.connpass.com/event/369756/ © 2025, Yoshizawa Satomi 38/43
39. JaSST:ソフトウェアテストシンポジウム https://jasst.jp/ • ソフトウェア業界全体のテスト技術力の向上と普及を目指すソ フトウェアテストシンポジウム • 初年は東京で2003年、以来、日本各地で開催している (北海道/東北/新潟/東京/東海/関西/四国/九州/Review/Online/nano) • 近々では11/14に四国(オンラインのみ)、12/5に東海(刈谷)、3/20に東京 (ビッグサイト)を開催予定 © 2025, Yoshizawa Satomi 39/43
40. JSTQB https://jstqb.jp/ • JSTQB:Japan Software Testing Qualifications Board • 国際的にソフトウェアテスト技術者の資格認定を行っている ISTQB(https://istqb.org/)の日本のボード • Foudation(基礎)レベル、Advancedレベル、Specialistなど、 様々なシラバスを無償公開、資格試験(有償)を実施している © 2025, Yoshizawa Satomi 40/43
41. テストの国際標準 • ISO/IEC/IEEE 29119 • Part1～4がベースの標準、さらに枝番多数 • Part1：Consepts and definitions（コンセプトと定義） • Part2：Test processes（テストプロセス） • Part3：Test documentation（テスト文書） • Part4：Test techniques（テスト技法） • JIS化（翻訳）の予定は今のところない • 有志団体により、Part1～4は翻訳されている部分もある © 2025, Yoshizawa Satomi 41/43
42. レビューの国際標準 • ISO/IEC 20246 JIS化されている：JIS X 20246 ソフトウェア及びシステム技術―ソフトウェア及びシステム開発 における作業生産物のレビューのプロセス © 2025, Yoshizawa Satomi 42/43
43. おわりに ～聴講ありがとうございました～ テストに関すること、少しはつかんでいただけたでしょうか？ わかってしまえばあまり嫌いにならないかも。 好きこそものの上手なれ、ではないですが、嫌いなことをするより 好きなことをする方が良いことが多いです。 テストもクリエイティブな側面がありますし、今日は技術的なこと、 AIとか自動化とかもお話しませんでしたが、テスト技術もどんどん開発技術と 共に開発されています。 いろいろ知って、少しでも良いテストをして、良い製品やサービスを 世の中に出してください。 テスコンにも、来てくださいね © 2025, Yoshizawa Satomi 43/43