QAアーキテクチャの設計による説明責任の高いテスト・品質保証

1. © NISHI, Yasuharu QAアーキテクチャの設計による説明責任の高いテスト・品質保証 Vector Testing User Day 2016/10/24（月）電気通信大学大学院情報理工学研究科情報学専攻経営・社会情報学プログラム西康晴（Yasuharu.Nishi@uec.ac.jp）

2. © NISHI, Yasuharu2 Profile Assistant professor: the University of Electro-Communications, Tokyo, Japan General chair: IEEE International Conference on Software Testing 2017 Tokyo (ICST 2017 Tokyo) 2017/3にGoogleからテスト自動化の基調講演/NASA&ESA&JAXAからIV&Vの講演 - http://aster.or.jp/conference/icst2017/ President: Association of Software Test Engineering, Japan - Nonprofit organization (ASTER) President: Japan Software Testing Qualifications Board (JSTQB) National delegate: ISO/IEC JTC1/SC7/WG26 Software testing (ISO/IEC/IEEE 29119 etc.) Founder: Japan Symposium on Software Testing (JaSST) Founder: Testing Engineers’ Forum (Japanese community on software testing) Judgement Panel Chair / member: Test Design Contest Japan, Test Design Competition Malaysia (TDC) Vice chair: Software Quality Committee of JUSE (SQiP) Vice chair: Society of Embedded Software Skill Acquisition for Managers and Engineers (SESSAME) Advisor: Software Testing Automation Research group (STAR)

3. © NISHI, Yasuharu3 講演の流れ • 現状のソフトウェアのテストや品質保証の問題 • テスト観点によるテストアーキテクチャの設計 • テスト開発方法論：VSTeP • レビュー観点によるレビューアーキテクチャの設計 • 品質保証アーキテクチャの設計 • まとめ

4. © NISHI, Yasuharu4 現状のソフトウェアのテストや品質保証の問題 • 仕様書のコピペにすぎないテスト設計 – 何をテストしているのかちっとも分からないのに時間ばかりかかり、現場が楽にならない – 使わなくてはいけないテスト技法があるが、何に適用すればよいか分からない – ○○テストという社内標準はあるが、記述が粗すぎて役に立たない • 属人化したレビュー – 粗いチェックリストや単なる不具合事例集を用いているため役に立たず、 “有識者”による経験ベースの指摘がレビューの質を左右してしまっている • 自己目的化した自動化 – 自動化そのものが目的となり、Garbage In, Garbage Outそのままになってしまっている • おざなりなアシュアランスケース – ○○テスト仕様書が完璧だからこの機能は安全、といったおざなりなものも散見される何をテスト／品質保証しているのか分からなくなってしまっている

5. © NISHI, Yasuharu5 現状のソフトウェアのテストや品質保証の問題 • 規格に準拠しただけの開発／機能安全プロセス – プロセスの運用に主眼が置かれ実態とかけ離れ、二重帳簿化さえ引き起こしてしまう – ハザード解析や要求仕様が完璧という危うい仮定と何の根拠もない技法提示により、レビューやテストが単なる検算に成り下がってしまっている • ハードウェア主導の品質保証組織によるピントを外した品質保証 – 技術の詳細に踏み込めないのでプロセス監査や馴染みのある技法の利用でお茶を濁す – 定量化することに意味があるかどうかを全く考えず、とにかく統計的技法を使わせようとする • テストや品質保証と開発との乖離 – テストや品質保証組織が品質を上げるための知恵を蓄積して提供したり、技術開発を進められていないため、開発組織に有用な活動も、開発組織に共感してもらえる活動をしていないプロセスは動いているが、本当にテストや品質保証できているのか自信は持てないし、説明責任も果たせていないし、開発に喜ばれていない

6. © NISHI, Yasuharu6 IoT時代におけるメーカの品質保証部門のよくある発想 • センサー付き製品がどんどん増えていくので、ソフトのバグがあったら困る • 製品がネットワークでつながるので、セキュリティは大事みたいだ • でもそういうのはソフト部門に任せておけばいい • やっぱり足腰となる「ものづくりの品質」こそ品質保証部門の考えるべきことだ

7. © NISHI, Yasuharu7 IoT時代の品質に追従できている品質保証部門は少ない • IoT = 通信 + 制御 + エネルギー + クラウド + セキュリティ？ – 個々の要素技術の品質は大事だが、その集合が本質ではない • IoTの本質とは何か？：仕様の無い世界の評価 – 人間の感性とインタラクションするデバイスのテスト » 使い心地、面白さ、安心、カワイイなどの評価 » ユーザの体験やユーザエクスペリエンス（UX）、余韻の評価 » ユーザが他のユーザを誘いたくなるかの評価 – AIやBig dataからの推論のテスト » ユーザよりもユーザを理解する：データの分布およびばらつきの設計 » ユーザよりもユーザを理解する：推論の価値や危険度の評価 – Systems of systemsのテスト » 異なる専門家で構成される複数の技術領域（メカ／エレキ／ケミカル／ソフト／サービス）が緊密に連携する一つのシステムの統合的評価 » きっちり決まっていないシステムや品の悪いシステムの接続による想定外の動作の評価 » 急に変わる／これから新たにつながるシステム要素の影響の波及の評価 – ビジネスの質の評価 » ユーザとの共創（サービスドミナントロジック）の評価 » ES（従業員満足度）の評価 » ビジネスプラットフォームとしての評価 » ビジネスのスピードと精度のバランスの評価

8. © NISHI, Yasuharu8 てんでばらばらなテストや品質保証のイメージプロセステストレビュー自動化保証ケースもやもやしてふんわりした品質コピペと刺身たんぽぽ自己目的化属人化おざなり形骸化フロントローディング重量化

9. © NISHI, Yasuharu9 きちんと連携したテストや品質保証のイメージプロセステストレビュー自動化保証ケース説明責任を果たせる高速化資産化本質的で深い議論開発からの共感フロントローディング未然防止化・軽量化品質を細かい粒度でモデリングする

10. © NISHI, Yasuharu10 品質保証アーキテクチャの設計 • 現状のテストや品質保証の問題点は、「その質は何によって決まるか」「その質をどこでどう確実に作り込んで確実に実証するか」がもやもやしてふんわりしていることである • そこで品質を細かい粒度でモデリングし、品質保証アーキテクチャを設計する – 「その質は何によって決まるか」をQA観点モデルによって明らかにする – 「その質をどこでどう確実に作り込んで確実に実証するか」とその全体像をアシュアランスパイプライン（保証の網）として設計し、それを支えるテックシェルフ（技術の棚）を構築し運用する – QAアーキテクチャに従ってプロセスとメトリクスを導出すると、そのプロセスやメトリクスによって品質がどう上がって組織が理想に近づくか、の根拠を示すことができるので、現場が幸せになっていく • 製造業のQA部門は品質保証アーキテクチャを上手に設計することによるメカ／エレキ／ケミカル／ソフト／サービス統合型QMSの構築が必須である – QA観点の特定と「支配法則」の分離による “Micro Quality Architecture” が肝となるモデルベース開発からモデルベース品質保証にステップアップする

12. © NISHI, Yasuharu12 まずはテストアーキテクチャを設計すると分かりやすい • QAアーキテクチャを意識したことがない組織がいきなりフルセットのアシュアランスパイプラインを設計するのはなかなか難しい – QA観点ってなんだろう？ – 自分たちは設計の時に何を気をつけているだろう？単なるC言語への翻訳になってるぞ？ – レビューのチェックリストになぜそういう項目が含まれてるんだろう？ – レビュー全体で一体なにをしてることになってるんだろう？ – テストケースごとに目的を把握できているだろうか？ – テストレベルとかテストタイプってなんだろう？社内標準で決まってるから従ってるだけかな？ • QAアーキテクチャを意識したことがない組織で、レビューの苦手な組織は、テストだけに絞ってテストアーキテクチャを設計するとよい – テストアーキテクチャの設計ができるようになったら、レビュー設計の向上活動とともにレビューアーキテクチャの設計に取り組み、それらを合わせたV&V観点（テスト観点やレビュー観点など）をフロントローディングして QAアーキテクチャを設計できるようにしていくとよいだろう » これをWモデルとも呼ぶ

13. © NISHI, Yasuharu13 テスト観点図によるテスト要求分析のイメージ

14. © NISHI, Yasuharu14 テストコンテナ図によるテストアーキテクチャ設計のイメージ構造テスト例外ハンドリングテストマルチバイトテスト配列境界テスト単体テスト呼び出しテスト割り込みハンドリングテスト共有メモリテストデバイス制御テスト結合テストセキュリティテストシステムテスト動作環境テスト障害対応性テスト機能テスト負荷テストテストサイクル① 機能テスト負荷テストテストサイクル② 動作環境プラットフォームネットワーク OS ハードウェア

15. © NISHI, Yasuharu15 テストアーキテクチャを設計するには？ • テスト観点を挙げ、挙げたテスト観点をテストコンテナに割り振ればよい – テストコンテナ：テストレベルやテストタイプ、テストサイクルなど » テストレベル：単体テスト、結合テスト、システムテストなど » テストタイプ：負荷テスト、動作環境変更テスト、性能テスト、セキュリティテストなど » テストサイクル：1回目の回帰テスト、2回目の性能テストなど – テスト観点を網羅的に挙げると、漏れが少なくなる – テストコンテナに適切に責務を分担すると、テストの効率や質が高くなる • テスト観点を挙げてテストアーキテクチャを設計する方法論の一つが VSTePである – テスト観点やテストコンテナのモデリングを行うことで体系的かつ実践的なテスト開発を行う方法論である – VSTePでテスト開発を実現できると、グローバルなテスト体制も同じスキームで構築できる – Reverse VSTePなど、現場の負荷を減らすために少しずつ導入することもできる

16. © NISHI, Yasuharu16 テストアーキテクチャ設計テスト開発ライフサイクルモデルテスト実施テスト設計（or テスト計画 or テスト実施準備）テスト要求の獲得と整理・テスト要求モデリングテストアーキテクチャモデリング手動／自動化テストスクリプト（テスト手順）の記述テスト項目の抽出テスト詳細設計テスト実装テスト実施テスト技法の適用によるテストケースの列挙テスト要求分析

17. © NISHI, Yasuharu17 テスト開発ライフサイクルの基本的考え方 • テストケースを開発成果物と捉え、ソフトウェア開発ライフサイクルとソフトウェアテスト開発ライフサイクルを対応させようソフト要求分析＝テスト要求分析ソフトアーキテクチャ設計＝テストアーキテクチャ設計ソフト詳細設計＝テスト詳細設計ソフト実装＝テスト実装 • テストケースがどの工程の成果物かを考えるために、各ライフサイクルの成果物を対応させようソフト要求仕様（要求モデル）＝テスト要求仕様（要求モデル）ソフトアーキテクチャモデル＝テストアーキテクチャモデルソフトモジュール設計＝テストケースプログラム＝手動／自動化テストスクリプト（テスト手順）

18. © NISHI, Yasuharu18 テスト設計とテスト開発は何が違うの？ • いきなりコーディングすることと、ソフトウェア開発を行うことの違いと同じである – コーディングは、アルゴリズムとプログラミング言語を分かっていればできる » （従来の）テスト設計も、テスト設計技法と文書フォーマットを分かっていればできる » 経験豊富でセンスのある人が規模の小さいプログラムを書くのであれば別に構わない – ソフトウェア開発は、要求を把握し設計原則を理解・適用して、段階的に詳細化しながら順序立てて進めていく必要がある » テスト開発も、テスト要求を把握しテスト設計原則を理解・適用して、段階的に詳細化しながら順序立てて進めていく必要がある » これまで皆の経験とセンスを結集して規模の大きなソフトウェアを開発することである » 経験とセンスを結集するために、様々なソフトウェア工学上の概念や技術、方法論が必要となる • テストの開発のための方法論の一つがVSTePである – ほかにもHAYST法やゆもつよメソッドなど色々あり、それぞれに強みがある – テスト開発プロセスがもう一つ理解できない場合は、 ASTER主催のテスト設計コンテストのU-30クラスのチュートリアル資料で勉強会を開催するとよいだろう » http://aster.or.jp/business/contest/tutorialu30.html

19. © NISHI, Yasuharu19 テスト開発ライフサイクルとは何か • ソフトウェアの高品質化・大規模化・複雑化に伴い、ソフトウェアテストの高品質化・大規模化・複雑化も急務である – 10万件を超える様々な観点による質の高いテストケースを、いかに体系的に開発するか、が課題である • しかしテスト計画やテスト戦略立案という工程は未成熟である – テストケースという成果物の開発と、テストのマネジメントとが混同されている » テスト計画書にテストケースもスケジュールも人員アサインも全て記載される – テストケースの開発という工程が見えにくくなっており、そこで必要となる様々な工程が混沌として一体的に扱われている » テスト（ケース）開発という用語はほとんど使われず、テスト計画、テスト仕様書作成、テスト実施準備といった用語が使われている » テスト戦略という用語もイマイチよく分からない • そこで「テスト開発ライフサイクル」という概念が必要となる – テストケースを開発成果物と捉え、開発プロセスを整備する必要がある » 高品質・大規模・複雑なテストケースを開発するために必要な作業を明らかにする » 本来はテスト実施以降やテスト管理のプロセスも必要だが、今回は省略する – テスト設計コンテストでは基本の考え方である

21. © NISHI, Yasuharu21 要するにVSTePってなに？ • テストケースをざっくり考えてから具体化する方法 – 「○○機能に△△人のアクセスを与えて□□秒のレスポンスが…」といきなり細かく考えるのではなく「負荷をかけたいなー、でも他にテストすることないかなー」とまずはざっくり考える » いきなり細かく考えると、大きな抜け漏れが発生しやすくなる » ざっくりしたテストケース（「負荷」）を「テスト観点」と呼び、少しずつ詳細化していく · Excelの大項目・中項目・小項目のようなものだと考えてよい » 詳細化の過程や結果をテスト観点図として残しておく – Excelの表だと全体像が見えにくいので、UMLっぽい図に書いて全体像を把握する » 全体像を把握できると、網羅してる実感を持ちやすくなったり、テスト計画やテスト戦略を立てたり改善しやすくなる » 全体像を把握できると、みんながムダなくテストできるし、上流や顧客とも合意しやすいざっくり考えてから少しずつ詳細化して図にすると見やすいし整理しやすい

22. © NISHI, Yasuharu22 VSTePの簡単な流れ • テスト要求分析 – テスト観点を思い浮かべて、線でつなげよう • ・テストアーキテクチャ設計（コンテナ設計） – テストコンテナにまとめて並べよう • テストアーキテクチャ設計（フレーム設計） – テストケースのひな形（テストフレーム）を作ろう • テスト詳細設計 – テストケースのひな形に具体的な値を入れよう » 普通のやり方と同じでよい • テスト実装 – テストケースをテスト手順に具体化しよう » 普通のやり方と同じでよい

23. © NISHI, Yasuharu23 NGT/VSTePの概要 • NGT/VSTePとは何か – テスト観点を基盤としたテスト開発のための記法とテスト開発プロセス » NGT（Notation for Generic Testing）：テスト開発のための記法 » VSTeP（Viewpoint-based Test Engineering Process）：テスト開発プロセス – テスト観点（図）、テストコンテナ（図）、テストフレームをつくることで、質の高いテストケースやテスト手順を作成する方法 • テスト観点とは？ – テストケースごとの「テストの意図」である – テストケースの（一部）を抽象化したものになる • テストコンテナとは？ – テストレベルやテストタイプ、テストサイクルをまとめたものである » テストレベル：単体テスト、結合テスト、システムテストなど » テストタイプ：負荷テスト、構成テスト（動作環境変更テスト）、セキュリティテストなど » テストサイクル：時間的な区切りでテストをまとめたもの • テストフレームとは？ – テストケースのひな形である

24. © NISHI, Yasuharu24 テスト観点図のイメージ

25. © NISHI, Yasuharu25 テストコンテナ図とテストフレームのイメージ構造テスト例外ハンドリングテストマルチバイトテスト配列境界テスト単体テスト呼び出しテスト割り込みハンドリングテスト共有メモリテストデバイス制御テスト結合テストセキュリティテストシステムテスト動作環境テスト障害対応性テスト機能テスト負荷テストテストサイクル① 機能テスト負荷テストテストサイクル② 動作環境プラットフォームネットワーク OS ハードウェアデータ量残メモリ量性能

26. © NISHI, Yasuharu26 NGTによるテスト観点図の記述 • NGT/VSTePではテスト観点図を中心にして進めていく – NGT (Notation for Generic Testing) という記法を定義している – テスト観点を階層的に記述していく – はテスト観点、はテスト対象を表す – は詳細化関係を表す – は組み合わせテストの必要性などテスト観点間の関連を表す – は順序依存関係を表す – 新たな関係や詳細な関係を定義したり分かりやすくするために <<stereotype>> （ステレオタイプ）を使ってもよい

27. © NISHI, Yasuharu27 NGT: 記法のまとめ

28. © NISHI, Yasuharu28 • テスト観点という用語はロールに依存しないからであるなぜ「テスト観点」と呼ぶのか？テスト目的じゃないか？要求でしょ！因子だよ因子テスト条件だよテスト環境な気がする SE（要求担当）テストマネジャーテストエンジニア組み合わせテスト設計者テストオペレータ

29. © NISHI, Yasuharu29 テスト観点の例：組込みの場合 • 機能：テスト項目のトリガ – ソフトとしての機能 » 音楽を再生する – 製品全体としての機能 » 走る • パラメータ – 明示的パラメータ » 入力された緯度と経度 – 暗黙的パラメータ » ヘッドの位置 – メタパラメータ » ファイルの大きさ – ファイルの内容 » ファイルの構成、内容 – 信号の電気的ふるまい » チャタリング、なまり • プラットフォーム・構成 – チップの種類、ファミリ – メモリやFSの種類、速度、信頼性 – OSやミドルウェア – メディア » HDDかDVDか – ネットワークと状態 » 種類 » 何といくつつながっているか – 周辺機器とその状態 • 外部環境 – 比較的変化しない環境 » 場所、コースの素材 – 比較的変化しやすい環境 » 温度、湿度、光量、電源

30. © NISHI, Yasuharu30 テスト観点の例：組込みの場合 • 状態 – ソフトウェアの内部状態 » 初期化処理中か安定動作中か – ハードウェアの状態 » ヘッドの位置 • タイミング – 機能同士のタイミング – 機能とハードウェアのタイミング • 性能 – 最も遅そうな条件は何か • 信頼性 – 要求連続稼働時間 • セキュリティ • GUI・操作性 – 操作パス、ショートカット – 操作が禁止される状況は何か – ユーザシナリオ、10モード – 操作ミス、初心者操作、子供 • 出荷先 – 電源電圧、気温、ユーザの使い方 – 言語、規格、法規 • 障害対応性 – 対応すべき障害の種類 » 水没 – 対応動作の種類 • ハザードや作り込みそうな欠陥テスト観点はテストケースの「意図」を表している

31. © NISHI, Yasuharu31 テスト観点を挙げる時の注意点 • 仕様書に書いてある仕様や文、単語を書き写してもテスト観点は網羅できない – 仕様書は通常不完全で、（特に致命的な）バグは仕様書に書かれていないテスト観点でしか見つけられないことがある » ここまで例に挙げたテスト観点は、皆さんの組織の仕様書に全て書いてありましたか？ • テスト観点は多面的に挙げる – 入力に関するテスト観点だけを挙げたり、期待結果やその観測に関するテスト観点だけを挙げたり、品質特性だけをテスト観点として採用すると、漏れが発生する • テスト観点を挙げただけでバグが見つかることがある – 開発者が考慮していなかったテスト観点はバグの温床であり、テストしなくてもバグだと分かることも多々ある – 期待結果に関するテスト観点を挙げたり詳細化すると、仕様の抜けが分かることがある » テストケースにも期待結果を必ず書くのを忘れないこと » 「正しく動作すること」は期待結果ではない！ • 網羅した風のテスト観点の文書や納品物を作るのが本質ではなく、網羅しようと多面的に様々なことを考え尽くすのが本質である

32. © NISHI, Yasuharu32 テスト観点とテストケースとテスト手順を区別する • テスト観点とテストケースとテストスクリプトをきちんと区別する – テスト観点 » 何をテストするのか（テストケースの意図）のみを端的に記述したもの · 例）正三角形 – テストケース » そのテスト観点でテストするのに必要な値などのみを特定したもの · 例）(1,1,1), (2,2,2), (3,3,3)… » 通常は、網羅基準に沿って特定される値などのみから構成される » テストケースは基本的にシンプルになる – テストスクリプト（テスト手順） » そのテストケースを実行するために必要な全てが書かれたもの · 例）1. PCを起動する 2. マイコンピュータからC:sampleMyers.exeを起動する… » 手動でのテスト手順書の場合もあれば、自動テストスクリプトの場合もある » 複数のテストケースを集約して一つのテストスクリプトにすることもある • これらを区別し、異なる文書に記述し、異なる開発工程に割り当てることによって、テスト観点のみをじっくり検討することができるようになる

33. © NISHI, Yasuharu33 テスト観点図の描き方の例：トップダウン型 • トップダウン型 – おもむろにテスト観点を挙げ、詳細化していく » 三角形のテストには、三角形の構造に関する観点が必要だ » 三角形の構造には、成立、直線、不成立の3つがあるな » 成立する場合には、正三角形、二等辺三角形、不等辺三角形があるな – 実際にはトップダウンとボトムアップを循環させながらモデリングする三角形成立直線不成立正三角形二等辺三角形不等辺三角形三角形成立直線不成立三角形

34. © NISHI, Yasuharu34 テスト観点図の描き方の例：ボトムアップ型 • ボトムアップ型 – まず思いつくところからテストケースを具体的に書き、いくつか集まったところで抽象化し、テスト観点を導き出していく » (1,1,1) なんてテスト、どうかな » (2,2,2) とか、(3,3,3) もあるな » これって要するに「正三角形」だな » 他に似たようなのあるかな、う～ん、二等辺三角形とかかな – 実際にはトップダウンとボトムアップを循環させながらモデリングする三角形の種類正三角形二等辺三角形不等辺三角形正三角形 (1,1,1) (2,2,2) (3.3.3)(1,1,1) (1,1,1) (2,2,2) (3.3.3)

35. © NISHI, Yasuharu35 テスト観点の詳細化：親観点と子観点 • テスト観点は階層的に詳細化できる – 詳細化は、近くからモノを見る（ズームインする）ようなことである – 踏み込んでモデリングする場合は、継承（is-a）、合成集約（部分：has-a）、属性化、原因－結果など詳細化すべき理由をステレオタイプで表す » ステレオタイプごとに分けて詳細化を行うとMECE性（網羅性）を保証しやすくなる • 階層の最上位のテスト観点を「（トップ）ビュー」と呼ぶ – ビューは、そのサブツリーが全体として何をテストするのか、を表している – どのようなトップビューで構成するか（テスト要求モデルの全体像）はテストエンジニアによってかなり異なる • 階層の最下位のテスト観点を「ボトムビューポイント」と呼ぶ – そのテスト観点を見れば、何をどのように網羅すればよいかが一目で分かる詳細度、がボトムビューポイントである – ボトムビューポイントはテスト詳細設計でのテスト条件となる » 例えば同値クラスになる動作環境プラットフォームネットワーク OS ハードウェア

36. © NISHI, Yasuharu36 組み合わせテストが必要なら観点同士を関連で結ぶ • 複数の観点を組み合わせるテストを「関連」で示す – 例）負荷テストでは、搭載メモリ量という観点と、投入データ量という観点を組み合わせてテスト設計を行う » 搭載メモリ量と投入データ量のバランスによって、テスト対象のふるまいが変化するからである – 組み合わせテストの場合のように順序依存性のない関連は、テスト観点間の矢頭の無い曲線で表す » 順序依存性のある関連は → のように開き矢尻の矢印で表す – 新たな関係や詳細な関係を定義したり分かりやすくするために <<stereotype>>（ステレオタイプ）を使ってもよい GUIパス数 OSの種類機能性能 <<combination>> <<sequence>>

37. © NISHI, Yasuharu37 テストコンテナとは • 大規模なテスト設計では、複数のテスト観点をグルーピングして扱いたい時がある – 複数のテスト観点をグルーピングしたものをテストコンテナと呼ぶ » テストタイプやテストレベル、テストサイクルなどを表現する – テストコンテナは包含関係を持つことができる » テストコンテナに含まれるテスト観点を比べるとテストコンテナ間の役割分担を明確に把握できる · 負荷テストと性能テストなど、違いがよく分からないテストタイプも区別できる · 単体テストと結合テストなど、役割分担がよく分からないテストレベルも区別できる動作環境プラットフォームネットワーク OS ハードウェア構成テストボリュームストレージ高頻度ロングラン負荷テスト

38. © NISHI, Yasuharu38 テストコンテナ図 • 大規模なテスト設計では、テストコンテナの図で表すと全体像を把握しやすくなる – テストコンテナ（レベルやテスト、サイクル）を用いるとテストアーキテクチャを俯瞰できる » 先に設計/実施しておくべきコンテナを後に回してしまう、といったトラブルが防げる » 保守や派生しやすいテストが可能になる構造テスト例外ハンドリングテストマルチバイトテスト配列境界テスト単体テスト呼び出しテスト割り込みハンドリングテスト共有メモリテストデバイス制御テスト結合テストセキュリティテストシステムテスト動作環境テスト障害対応性テスト機能テスト負荷テストテストサイクル① 機能テスト負荷テストテストサイクル② 動作環境プラットフォームネットワーク OS ハードウェア

39. © NISHI, Yasuharu39 テストフレームとは • 実際のテスト設計では、複数のテスト観点をまとめてテストケースを設計したい場合が多い – この条件のテストは、テスト対象のどの部分に行うんだろう？ – この部分に対するテストでは、どの品質特性を確認するんだろう？ – この品質特性をテストするには、どの操作を行えばいいんだろう？ • テストケースの構造（スケルトン）をテスト観点の組み合わせで示すことで、複数のテスト観点によるテストケースを設計する – テストケースの構造を表すテスト観点の組み合わせを「テストフレーム」と呼ぶ » <<frame>> というステレオタイプの関連を用いる » シンプルな構造のテストケースで十分であれば、テストフレームを組まなくてもよい – テストフレームの例： » 下の図では、テスト条件＋テスト対象＋振る舞いをテストフレームとしている » 組み合わせテストを設計しようとしているわけではない点に注意するデータ量残メモリ量 <<frame>> 性能 <<frame>>

40. © NISHI, Yasuharu40 テスト詳細設計 • テスト観点を十分詳細化しテストフレームを組んだら、テストケースを生成する – 十分詳細化したテスト観点に対応するテスト詳細設計モデルを定め、網羅アルゴリズムと網羅基準にしたがって具体的な値や機能、組み合わせを列挙し、テストケースとする » 例）状態モデルに対して、C0の遷移網羅基準で、深さ優先探索法を用いて生成する » テストフレームの各テスト観点を列見出しにしたExcelの表を埋めてもよい » ボトムビューポイント、網羅アルゴリズム、網羅基準の3者が明確であれば、モデルベースドテストとしてテストケース生成を自動化できる可能性が高い – テストケースに対応するテスト観点を常に明確にすることができる » 目的のよく分からない漫然と設計されるテストケースを撲滅できる – テスト詳細設計は機械的に行っていくのが基本である » 可能な限り自動化すると、Excelを埋める単純作業を撲滅できる » テスト詳細設計を機械的にできないところは、網羅基準が曖昧だったり、テスト観点が隠れていたりする

41. © NISHI, Yasuharu41 テスト実装 • テストケースが生成できたら、テスト実装を行う – テスト対象のシステムやソフトウェアの仕様、テストツールなどに合わせてテストケースをテストスクリプトに具体化していく » 手動テストスクリプトの場合もあるし、自動化テストスクリプトの場合もある – テスト実装は、テスト対象のUI系の仕様や実行環境、ユーザのふるまいに関するノウハウが必要である • 集約 – テスト実施を効率的に行うため、複数のテストケースを１つのテストスクリプトにまとめる作業を集約と呼ぶ – 同じ事前条件や同じテスト条件、同じテストトリガのテストケース、あるテストケースの実行結果が他のテストケースの事前条件やテスト条件になっている場合は集約しやすい » テストトリガとは、テスト条件を実行結果に変えるためのきっかけとなるイベントである • キーワード駆動テスト – 自動化テストスクリプトを“クリック”といった自然言語の「キーワード」で記述することにより、保守性を高めたり自動生成をしやすくする技術である – テスト観点とキーワードを対応させると、キーワード駆動テストを実現しやすくなる » NGT/VSTePをベースにして自動テストスクリプトの自動生成を目指すことができる

42. © NISHI, Yasuharu42 VSTePの簡単なまとめ • テスト要求分析 – テスト観点を思い浮かべて、線でつなげよう • ・テストアーキテクチャ設計（コンテナ設計） – テストコンテナにまとめて並べよう • テストアーキテクチャ設計（フレーム設計） – テストケースのひな形（テストフレーム）を作ろう • テスト詳細設計 – テストケースのひな形に具体的な値を入れよう » 普通のやり方と同じでよい • テスト実装 – テストケースをテスト手順に具体化しよう » 普通のやり方と同じでよいざっくり考えてから少しずつ詳細化して図にすると見やすいし整理しやすい！

43. © NISHI, Yasuharu43 VSTePに取り組む価値のない組織 • テストは仕様書通りに動かして証拠作りをする（ので軽作業派遣でいい）と思っている組織 – 仕様をなぞって画面キャプチャ、の無限ループにコストをかけなくてはいけない組織 » 開発由来の場合とお客様由来の場合がある – 考慮すべきことは上流で全て考慮しているので下流は確認すればいい、というトップダウンな規格に疑問なく従っている組織 • 巨大なExcelの表を埋めることに凄まじい愛情を注げる組織 • パートナーにテストを丸投げしていて特に不自由のない組織 • なんでやるのか分からないテストケースでも自動化して大量に実行すれば何かした気になれる組織 • テストが属人化していても、ずっと同じ組織でずっと同じアサインができるからむしろもっと属人化させたい組織 • なにかコンサルの言うことに従っていれば頭を使わなくてもよいテストができると期待している組織 – VSTePは、自組織の誰も経験したことのないことを「予言」するような方法ではない

44. © NISHI, Yasuharu44 VSTePに取り組む価値のない組織このままでいいや、とどこかで思っている組織

45. © NISHI, Yasuharu45 VSTePに取り組む価値のある組織 • 仕様のコピペでテストケースが肥大化し収拾が付かなくなっている組織 • 技法やテストタイプなどのテストの社内標準はあるけど意味ないと思っている組織 • テストケース表のExcelの大中小項目がフリーダム過ぎる組織 • パートナーがダメ、もしくはパートナーに依存してしまっている組織 • テストの知恵を貯めてテストを改善したい組織、さらにはレビューや開発も改善したい組織 • 異なる部署や異なる組織、異なる国をまたいで効果的にテストを行いたい組織 • 説明責任の高いテストを行うことで監査や審査と闘いたい組織 • よいテスト設計とよいテスト自動化を融合させたい組織

46. © NISHI, Yasuharu46 VSTePに取り組む価値のある組織このままじゃダメだ、と強く思っている組織

47. © NISHI, Yasuharu47 VSTePの意義 • 丸や四角と線で絵を描くとエンジニアのように見える – エンジニア魂を刺激して「自分は軽作業派遣ではなくクリエィティブなエンジニアなんだ」と自覚してもらいモチベーションを上げてもらえる • テスト条件（や期待結果）を抽象化することで、全体像をコミュニケーションしやすくなったり知恵を蓄積しやすくなる – プロジェクト個別の情報を削除して、知恵づくりに必要な情報だけを残すことができる – 全体像を把握しやすいように可視化されるのでコミュニケーションしやすくなる – 知恵の質がモデルによって比較可能になる – ソフトウェアエンジニアリングの様々な技術を応用しやすくなる – テストだけでなく、レビューや開発上流も含めた開発考慮事項を蓄積できるようになる • 頭を使うところと手を動かせばいいところを明確に分離できる – 違う頭を使うところは異なる工程になっている – 頭を使うことを鍛えるという意識が無いと、テストがよくならない » 銀の弾丸を求めている組織には向いていない – 単純作業は自動化することに頭を使うようにする

48. © NISHI, Yasuharu48 VSTePの意義 • 現場でのリーンスタートアップがしやすくなる – 段階的／改善的導入や一部導入がしやすい – 自組織がいま使っているフォーマットをベースにできる – ダメなテスト設計をしている組織は当初ダメなモデルが可視化されてやる気を失うかもしれない » VSTePは万能の道具ではないので、頭を使わずにダメなテスト設計を改善することはできない • VSTePはメソドロジ・プラットフォームである – 自社のテストのやり方を尊重したまま、VSTePで問題点を整理・改善することができる » ・例）改良型ゆもつよメソッド powered by VSTeP – 様々なプロジェクトのテストのバリエーションを統一的に整理することができる » 自社の各部門や開発子会社、海外拠点などを統一的にマネジメントできるようになる – 知恵を貯めてVSTePを自社内で成長させ、自分たちの身体に馴染む「自社版VSTeP」に仕立て上げることが重要である

49. © NISHI, Yasuharu49 VSTePは何でないか • VSTePは頭を使わずにテストできる魔法の道具ではない – 「この表を埋めればテストケースが完成です！」とか「とにかく探索的テストをすればバグが見つかります」みたいなまやかしではない – 「あなたの組織で誰も想定できなかった想定外を想定できます」みたいな詐欺ではない • VSTEPはエンジニアを孤立させるものではない – ひたすら一人でフォーマットを埋めるようなぼっちめしではない • VSTePは思考停止してテストできるプロセスマニュアルではない – 分厚い手順書とフォーマットのような無能コンサルの納品物ではない – 膨大な文書群とトレーサビリティを必要とするプロセススパゲッティではない • VSTePはエンジニアを奴隷にするものではない – 意図の分からないテストケースをひたすら書いて実行して誰も見ないスクリーンショットを積み上げる賽の河原ではない – 役に立っている実感の無い施策をやらされ感満載で強制される経営者の自己満足の道具ではない • VSTePは全部入りではない – バグのパターン化や各種テスト技法などは別途アドオンしていく必要がある

50. © NISHI, Yasuharu50 VSTePとは何か VSTePはエンジニアがクリエィティブな作業に集中し納得感を共感することでよりよいテストを継続的に行っていくための道具立てである

51. © NISHI, Yasuharu51 補足：VSTePにおけるモデリングの基本 • モデリングに正解は無い、納得の共感による説明責任の確保があるだけだ – 納得感の得られないモデルや、共感できないモデルは、往々にして質が低い – その組織のエンジニアが皆「こんなもんだ」と思い、それで過去に問題がなかったのなら、モデリングはその程度で終わりでよい – 仕様書とのトレーサビリティにばかり囚われるとよいモデルにならない • 各（中間）成果物の抽象度をどこまで落とすべきか、は意外に難しい問題である – テスト観点、テストコンテナ、テストフレーム、テストケース、テスト手順をそれぞれどこまで具体的に書けばいいのか、は一概には言えない • 類似した構造を見抜き、テストデザインパターンとしてパターン化して蓄積することが重要である – VSTePは抽象化されているのでパターン化しやすいが、パターンを掘り出そうという意志を常に持つこと一番重要である • 複数の派生製品のテスト開発をする際は、派生製品全体をまたいで（テストの）プロダクトラインモデルを構築するとよい

52. © NISHI, Yasuharu52 補足：テスト要求モデルの全体像の種類 • ある一つの側面からのみ構成されるモデルは、あまりよいモデルではない – 仕様ベースモデル – 機能ベースモデル – 画面ベースモデル – 品質特性モデル – 正常系異常系モデル • 経験ベースだが整理されてないモデルは使いやすいが合意しづらい – 一般テストタイプモデル • テストケースの構造に合わせたモデルは使いやすい – CIBFWモデル » Condition / Item / Behaviour / Fault / World • テスト対象や品質の構造に合わせたモデルは使いやすい – ラルフチャート（HAYST法） – 三銃士モデル（ゲーム向け） » 世界観・コンテキスト・実装＋ユーザ感情

53. © NISHI, Yasuharu53 補足：テスト観点モデリングのテクニック • 仕様書を書き写すことで網羅性を高めようとしない – 仕様書に書いてないテスト観点をテストでも漏らしてしまうことになる » 仕様書がそんなに質や完成度が高かったら苦労しない • 同じテスト観点名を皆が同じように理解しているとは限らない – 子観点が明示すると理解の齟齬は解消しやすい • 観点が通り一遍で関連が多いモデルは理解度が低いことが多い – 不安だから／責任を取りたくないから組み合わせておかなきゃ、と発想していることが多い – なぜその関連をテストすべきだと思ったのか、という掘り下げを行い、可能なら関連をテスト観点に変換すると、よりテストの意図が明確になる • 詳細化のステレオタイプを明示すると網羅しやすい – 異なるステレオタイプの詳細化が混ざっていると網羅しにくい • 抽象度は丁寧に落として（具体化して）いく – 認知的マジックナンバーの範囲内にできるとよい • 網羅できた確信が持てないところにはノートを貼っておく – 抜け落ちの危険性が消失することが一番怖い • チャーターの記述とテストの（気づいた点の）記録はテスト観点モデルを用いると表現しやすい

54. © NISHI, Yasuharu54 補足： VSTePにおける網羅の考え方 • 基本的な考え方：まず全体像を網羅して、次に明示的に減らす – 網羅とは証明することではなく、納得感を共感することである » ソフトウェアのテストは、現実的には無限or工数オーバーになるので網羅はできない » しかしまず全体像を網羅しておいて、何がどのように無限or工数オーバーになるのでこういう考え方でここを減らす、ということを整理して明示的に把握しておけば現実的に問題の無いテストが可能になる » テスト観点を用いて抽象化しているので、網羅する工数はそんなに増えない » テスト漏れが怖いのではなく、漏れがどこにあるのか分からないのが怖いのである • VSTePにおける網羅は以下の4つから構成される – テスト観点とそれらの組み合わせの網羅 – テスト観点図の納得感の共感で担保する » 納得感を上げるためにテスト要求モデル（テスト観点図）のリファインを繰り返すことが肝要 – テストケースの網羅 – テストフレームの明示で担保する » 網羅を確実に行うためにモデルベースドテスト（テスト詳細設計の自動化）に取り組むとよい – テスト手順の確実な遂行 – テストケースとテスト手順の分離によって促進する • VSTePにおける網羅は以下の考え方で行われる – 全網羅 – 規模が非常に小さいときのみ可能 - 「確定」で網羅性を担保する – トレードオフ – 「剪定」やペアワイズ/直交配列表などで行う – ピンポイント – バグのパターン化（ex. 不具合モード）など別途技術が必要 – リスクベースドによる優先度付け - 今回の講演では意図的に省略している

55. © NISHI, Yasuharu55 補足：テスト要求モデルのリファインの例 • 質の高いモデルにするために様々なリファインを行う – 網羅化：MECE分析 » 子観点がMECEに列挙されているかどうかをレビューし、不足している子観点を追加する » MECEにできない場合、必要に応じて「その他」の子観点を追加し非MECEを明示する » 子観点をMECEにできるよう、適切な抽象度の観点を親観点と子観点との間に追加する – 網羅化：ステレオタイプ分析 » MECE性を高めるために、詳細化のステレオタイプを明示し子観点を分類する – 整理 » 読む人によって意味の異なるテスト観点を特定し、名前を変更する » テスト観点や関連の移動、分割、統合、名前の変更、パターンの適用、観点と関連との変換、観点と網羅基準との変換などを行う » 本当にその関連が必要なのかどうかの精査を行う必要もある – 剪定 » ズームイン・アウト、観点や関連の見直し、網羅基準や組み合わせ基準の緩和によって、テスト項目数とリスクとのトレードオフを大まかに行う – 確定 » 子観点および関連が全て網羅的に列挙されているかどうかをレビューすることで、テスト要求モデル全体の網羅性を明示し、見逃しリスクを確定する

56. © NISHI, Yasuharu56 補足：テストコンテナモデリングのテクニック • テストアーキテクチャ設計方針／テストアーキテクチャの品質特性を明示的に考慮し、複数案を作れるとよい – テストアーキテクチャ設計のどの部分を取っても、そこがそうなっている理由や意図を説明できるようになっていなければならない – 複数案を作ると、コンテナモデリングの重要性が腹落ちできる • コンテナの前後依存関係は最も基本的なテストアーキテクチャである – （リスクベースドテストの）リスクは、後先だけでなくコンテナごとの規模にも影響するので、リスクだけでコンテナの前後依存関係を考えるのはよくない • テスト設計方針／テストアーキテクチャの（内部）品質特性の例 – 結合度と凝集度、保守性、自動化容易性、環境依存性、開発との一貫性、想定欠陥修正容易性、記述容易性、設計方向性、リズムなど色々ある • トップダウンのモデリングとボトムアップのモデリング – 必ず一度はボトムアップでコンテナモデルを構築してみること – 探索的テストは観点が動的に決まる／変わるため、コンテナとして出し忘れやすいので気をつける

57. © NISHI, Yasuharu57 補足：設計方針／（内部）品質特性によって異なるテストアーキテクチャの例テスト要求モデル保守性重視国際化重視単純に分割

58. © NISHI, Yasuharu58 補足：テストデザインパターンによるテストアーキテクチャのリファインの例 • いくつかのテストデザインパターンを用いてリファインを行った例が以下である – 左右の図は両者とも準ミッションクリティカルシステムのソフトウェアである » マインドマップを使っているので記法はNGTに従っていない – 左図をリファインして右図のテストアーキテクチャモデルにした – 右図のテストアーキテクチャは全体の把握やテスト詳細設計がしやすくなっていると感じられるリファイン

59. © NISHI, Yasuharu59 補足：Reverse VSTePによるテストの改善 • Reverse VSTeP: テスト設計をリバースモデリングする手法 – 要求からテストスクリプトを作成していく流れをForward VSTeP、逆をReverse VSTePと呼ぶ – Reverse VSTePとは、既存の（十分設計されていない）テストケース群からテスト観点モデルをリバースモデリングして改善する手法群である » 実際のテストケースを分析して、どういうテスト観点や関連でテストしようとしているかを列挙・整理し改善する » 実際に見逃したバグや検出されたバグ、テストケース外で検出されたバグを分析して、どういうテスト観点や関連が足りなかったかを列挙・整理し改善する · テスト観点を網羅したつもりでも、解釈が曖昧だったり不適切な場合や、剪定に失敗してしまった場合もある – リバースしないVSTePをForward VSTePと呼ぶこともある • カバレッジ分析による改善 – 見逃したバグや検出できたバグ、実際のテストケースなどを分析して、テスト観点は特定できているのにカバレッジ基準・達成率が低すぎた場合や、特異点が存在してしまった場合、不適切なリスク値（工数不足）の場合といった原因を明らかにし、カバレッジ基準・目標率、不足した・誤った前提、リスク値判定基準などを改善したり、テスト観点や関連を改善する » 仕様で示された同値クラスが必ずしも設計・実装上の同値クラスと一致するとは限らないため、テスト設計時の「前提」が重要となる » 関連よりもテスト観点として取り扱う方がよい場合もある

60. © NISHI, Yasuharu60 補足：Reverse VSTePによるテストの改善 • ステレオタイプ分析による改善 – テスト観点モデルの各詳細化関係の種類やMECE性を分析し、テスト観点が適切かつ網羅的に詳細化されるように子テスト観点を追加したりモデルをリファクタリングして改善する • 不具合モード分析による改善 – 見逃したバグや検出されたバグをパターン化して、ピンポイント型のテスト観点を追加・整理し改善する • ディレイ分析によるテストアーキテクチャの改善 – 見逃したバグや検出されたバグを分析して、実際のテストレベルやテストタイプをリバースされたテスト観点モデルにマッピングし、テストアーキテクチャ設計（テストレベルの設計）をレビューし改善する • 傾向分析によるリスク値の改善 – 見逃したバグや検出されたバグを分析して、各テスト観点のリスク値（利用頻度、致命度、欠陥混入確率など）を改善する

61. © NISHI, Yasuharu61 補足： VSTePにおけるモデリングの基本モデリングに正解は無い、納得の共感による説明責任の確保があるだけだ

63. © NISHI, Yasuharu63 テストアーキテクチャの次はV&Vアーキテクチャ • テスト観点のいくつかは、テストで検証するよりもレビューやフォーマルメソッドで検証する方がよいことに気づく – 競合状態やデッドロックなどはテストで検出しきろうとするとコストがかかりすぎてしまう – テスト観点やテストフレーム、テストケースを質問するだけでバグを見つけられることがある • したがって「レビュー設計」が必要なことが分かる – レビューは非常に属人的もしくはダメチェックリスト依存になっており、テストとレビューで責務の分担などできないのが現状である – レビューの改善は「会議術の改善」に留まり、レビューケースの改善まで行き着かない » 「テストケース」にあたるものに名前が付いていない組織もよく見られる · レビューケース？指摘項目？指摘事項？質問項目？議事録のセリフ？ – テストと同じように、レビュー観点を挙げてレビューアーキテクチャを設計すればレビューケースも体系的に設計できるし、レビューの知恵も蓄積して再利用しやすくなる » テストは網羅型にバランスが傾くことが多いが、レビューはピンポイント型にバランスが傾くことが多い » テストは不具合検出が主な役割だが、レビューはそれ以外に多くの（副次的）役割がある » レビューチェックリストは、レビュー設計を効率的に行うためのレビュー設計リファレンスである

64. © NISHI, Yasuharu64 補足：V&Vの大事な考え方 • VerificationとValidationの違い – Verificationは入力成果物と出力成果物の一致確認であり、Validationは目的達成評価である • 網羅とピンポイント／保証型と検出型 – V&Vには網羅とピンポイントという2つの相反する目標がある » 2つの相反する目標のバランスを取るのがとても重要である – 網羅とは、V&Vしなければバグは見つからないという考え方の基に、漏れなくV&Vを行うことで動作実績を積み上げる「保証型」のV&Vである » 何も考えずにひたすらV&Vに時間を費やすことは、網羅とは呼ばない – ピンポイントとは、全てはV&Vできないので大事なところから行うという考え方の基に、少ない手間でたくさん危険なバグを検出する「検出型」のV&Vである » バグの多そうなところや、大事そうなところからV&Vを行う • 探索的V&V – 事前にV&V観点を明示せず、V&Vを行いながらV&V観点を明らかにしていくV&Vを、探索的V&Vと呼ぶ » 担当者の経験やセンス、勘に大きく依存するので、限られた人でしか効果を発揮しない » 大まかな狙いを「チャーター」として与えるとよい – 暗黙的ないし動的なV&V観点を狙っているため、探索後のV&V観点のリバースによって改善につなげることが大事である » 経験から得られた暗黙的なバグのパターンを狙っている場合や、インタビュー時のレビュイーの反応や実行時のおかしなプログラムのふるまいから推理する場合などがある » 探索的V&Vを行った後でV&V観点のリバースを行い、フィードバックしてフロントローディングすることで、 V&Vや開発全体の改善につなげる必要がある – 何も考えずに丸投げで行うV&Vは、決して探索的V&Vではない » ダメな探索的テストを、モンキーテストと呼ぶ

65. © NISHI, Yasuharu65 レビュー観点によるレビュー（ケースの）設計 • レビュー観点を明示してレビューケースの設計を行う必要がある – レビューとはただひたすら読み込んで質問したりチェックリストと突き合わせるものではなく、何かに着目して網羅したり、何かをピンポイントで狙ったり、何かを探索したりするものである » 網羅したいものやピンポイントで狙いたいもののことを「レビュー観点」と呼ぶ » レビュアーが発するの質問や指摘項目を「レビューケース」と呼ぶ – レビューケースを体系的につくりだすことを「レビュー（ケースの）設計」と呼ぶ » テストの設計をしている組織は多くなってきたが、レビューの設計を意識している組織はまだ少ない » チェックリストはレビュー設計のガイド、もしくは参照モデルである » レビューはテストよりもピンポイントで探索的である – レビュー観点は、個々のレビューケースの意図を示している » レビュー観点は、レビュアーの持つ技術力を示している · レビュー観点を蓄積していない人や組織がレビューすると、誤字脱字チェックなどの重箱の隅レビューになる » レビュー観点の不明なレビューは、意図の分からないレビューになるため、往々にして時間がかかる割に意味の無いレビューになる – レビュー観点をきちんと列挙したりモデリングすることが、モダンなレビューでは必須である » ダメなレビューチェックリストはレビュー観点が不明だったり偏っていることが多い » レビュー観点の粒度や関係を適切に把握することも大事である » レビュー設計に着目せずにレビューを改善すると、会議術の改善以上にはならない

66. © NISHI, Yasuharu66 レビュー観点によるレビューアーキテクチャの設計 • どのようなタイプやレベルのレビューを行うことによって、どんな品質をどう保証するのか／どんなバグを検出するのか、の全体像を描く活動をレビューアーキテクチャと呼ぶ – マスターレビュープランやレビュー戦略とも呼ぶ – 個々のレビューのアクティビティ（≒レビュー会議）をレビューコンテナと呼ぶ » 例） ○○サブシステムに対する性能レビュー、○○サブシステムレビュー、性能レビュー » それぞれのレビューアクティビティでどのレビュー観点を分担するのか、を明示する – レビューコンテナ間の順序関係や依存関係を明示して、レビューの全体像を描き把握する – レビューコンテナ内のレビュー観点、レビューコンテナで用いる技術や必要な技術レベル、レビューコンテナの（副次的）役割などをはっきりさせる » レビューレベル：レビュー対象物の種類や粒度、順序関係などによる分類 · 要求レビュー、仕様レビュー、アーキテクチャレビュー、詳細設計レビュー、コードレビュー、サブシステムレビュー、モジュールレビュー、派生部位レビュー、母体レビューなど » レビュータイプ：レビューの意図や観点、技術などによる分類 · 割込処理レビュー、ウォークスルー、インスペクション、性能見積もり、セキュリティ設定確認、形式検証など » レビューサイクル：類似のレビューコンテナを繰り返す際の分類 · ○○レビュー第2回、やり直しレビューなど » テストの役割は割と明確だが、レビューの（副次的）役割は多岐に渡る – レビューアーキテクチャとテストアーキテクチャを合わせたV&Vアーキテクチャを用いると、開発工程の進捗に合わせてどのように品質が保証されていくのかが可視化できる » V&Vアーキテクチャが無いと、メトリクスやプロセスで「代替保証」せざるを得ず、“ふんわり”になる

67. © NISHI, Yasuharu67 レビューの（副次的）役割 • 確認の役割 – 仕様との一致 – 標準との一致 – 意図した役割（顧客満足？） • 指摘の役割 – 不具合の指摘 – 弱点の指摘 – 設計考慮事項の指摘 – リスク評価・不具合影響評価 • 設計改善の役割 – よりよい設計の提案 – 問題解決策の提案 – 代替案・回避策の提案 • マイルストーンの役割 – 進捗の報告 – 工程完了の判定 • コミュニケーション・合意の役割 – 開発者同士 – 開発者とリーダ・マネジャー – 開発チームとステークホルダー – 開発者と顧客 • 教育の役割 – 技術の伝達 – 良い設計を見せる – 不具合指摘の着眼点を伝える – トレードオフのバランスを伝える • 監査の役割 • 作業改善・プロセス改善の役割 – 原因の検討と改善 – 申し送り事項（簡易設計ガイドライン）の作成と周知徹底 – 次回プロジェクトへの改善

70. © NISHI, Yasuharu70 きちんと連携したテストや品質保証のイメージプロセステストレビュー自動化保証ケース説明責任を果たせる高速化資産化本質的で深い議論開発からの共感フロントローディング未然防止化・軽量化品質を細かい粒度でモデリングする

71. © NISHI, Yasuharu71 品質保証アーキテクチャの設計 • 現状のテストや品質保証の問題点は、「その質は何によって決まるか」「その質をどこでどう確実に作り込んで確実に実証するか」がもやもやしてふんわりしていることである • そこで品質を細かい粒度でモデリングし、品質保証アーキテクチャを設計する – 「その質は何によって決まるか」をQA観点モデルによって明らかにする – 「その質をどこでどう確実に作り込んで確実に実証するか」とその全体像をアシュアランスパイプライン（保証の網）として設計し、それを支えるテックシェルフ（技術の棚）を構築し運用する – QAアーキテクチャに従ってプロセスとメトリクスを導出すると、そのプロセスやメトリクスによって品質がどう上がって組織が理想に近づくか、の根拠を示すことができるので、現場が幸せになっていく • 製造業のQA部門は品質保証アーキテクチャを上手に設計することによるメカ／エレキ／ケミカル／ソフト／サービス統合型QMSの構築が必須である – QA観点の特定と「支配法則」の分離による “Micro Quality Architecture” が肝となるモデルベース開発からモデルベース品質保証にステップアップする

72. © NISHI, Yasuharu72 QA観点モデル（QFD - 品質機能展開の応用） • 直接品質を保証するためにプロダクトやサービスにどのような観点が必要なのか、をすべて書き出して整理したものがQA観点モデルである – レビュー観点やテスト観点がQA観点となる » レビュー観点やテスト観点をフロントローディングすると「開発考慮事項」になる – ISO/IEC25000sの品質特性やバグ分析の結果もQA観点となる – プロセスや組織のよさやメトリクスは、直接品質を保証しないのでQA観点モデルに入れない – テストケースやレビューケースとシームレスに対応づくように粒度を細かくする • IoT時代になって、多様なQA観点が求められるようになってきた – IoTになってソフトウェアの仕様だけを考えるような自己矮小化をしていられなくなってきた » 複雑で多岐に渡る非機能特性 · セキュリティや相互運用性 » メカ／エレキ／ケミカル／サービスの品質との連携 · 使い心地、面白さ、安心などといったユーザ感情やUX（ユーザエクリペリエンス） · 顧客共創、サービスドミナントロジック、プラットフォーム特性 – 適切なQA観点モデルを描くためには、製品やサービスを提供する開発部門や顧客とビジネスエッセンスの見直しを一緒に行う能力が必要となる場合がある

73. © NISHI, Yasuharu73 アシュアランスパイプライン（保証の網 / QC工程表の応用） • 開発・検証の工程ごとに、どのQA観点を作りこんでどのQA観点を検証したかを明示する – ネットワーク図のようになるので、保証の網とも呼ばれる – 工場の生産工程におけるQC工程表にあたると考えてもよい – 精度の高い保証ケースを工程に対応づけたものであると考えてもよい • QA観点と工程との関係を上手に割り当てることで、特定の意図のQA観点だけを含んだ工程をつなげたアシュアランスパイプラインを構築することができる – QAが自動化できる観点の工程だけのパイプラインを作ると、 CI/CDに追随させて超高速で自動化品質保証できるQA観点と、手動で品質保証しなくてはならないQA観点が区別できるのでメリハリのついたQAが可能になる – 全製品に共通なQA観点のパイプラインから仕向地ごとのパイプラインに分岐させることでグローバルなQA体制の全体像を設計することができる

74. © NISHI, Yasuharu74 アシュアランスフロー: MicroQuality Architecture • アシュアランスフローとは、どのQA観点をどの工程でどのように作り込み、どの工程でどのように検証するかを記述したものである – QA観点ごとにアシュアランスフローとメカニズムを明らかにして、その観点の品質保証を確実にしていく » どう作り込むか／入り込んでしまうか、どう検証するか、のメカニズムを明らかにする » 工程ごとの作業内容や採用技術、帳票の形式、ツールの選定などがすべてアシュアランスメカニズムに基づいたものになると、意図不明な作業の押しつけによるやらされ感が低減し、プロセスメトリクスが機能するようになってくる – Monolithicな粗いQA観点をなんとなく保証しようとするのではなく、粒度の細かいQA観点（MicroQuality）の保証を積み上げてQAを行うパラダイムにシフトする工程P1 QA観点V （作り込み）工程P2 QA観点V （検証）

75. © NISHI, Yasuharu75 アシュアランスパイプラインによる責務の明示 • アシュアランスパイプライン上で工程の責務を整理し、個々のQAフローのメカニズムがきちんと機能しているかを測定して管理することで、プロセスをカイゼンしていく – 自動化によって個々のフロー要素を短縮し、パイプラインをスピードアップする – アシュアラビリティ・デザインを行って検証側のフロー要素を短縮する – フロントローディングによって作り込み側のフロー要素を短縮する／無くす（例：Wモデル） » フロントローディングによって、上流から品質（QA観点）を作り込む » フロントローディングをする時には、QA観点ではなく開発が馴染みやすい言葉を使った方がよい · QA観点＝開発考慮事項＋ V&V観点である – フロントローディングによってフローの拡散を防ぎ、全体の工数を減らす – 以上のようなことが可能になるように、工程へのQAフローの責務分担をきちんと設計する

76. © NISHI, Yasuharu76 アシュアランスパイプラインの整理によるQAの高速化工程の責務を整理すると、ある観点のパイプラインのみ自動化やフロントローディングによって高速化し、かつどの観点は自動化やフロントローディングによって保証されないのかを把握する、といったことが可能になる自動化で velocityを向上させリズムを生み出す

77. © NISHI, Yasuharu77 アシュアランスパイプラインの整理によるQAの高速化工程の責務を整理すると、ある観点のパイプラインのみ自動化やフロントローディングによって高速化し、かつどの観点は自動化やフロントローディングによって保証されないのかを把握する、といったことが可能になるフロントローディングフロントローディングでテストを軽量化し、品質を保ったまま velocityを向上させる

78. © NISHI, Yasuharu78 テストの自動化 • テスト技術でいま一番盛り上がっている分野である – Deployment Pipeline、TDD、KDT（キーワード駆動テスト）、MBT（モデル駆動テスト） – クラウド界隈ではSET/SWETというロールが認知されてきた » 組込みやミッションクリティカルのドメインでも今後は一般的になるだろう – テスト自動化とテスト設計、テスト開発、品質保証をつなげる技術が今後重要となる » QA側から描いたのがアシュアランスパイプラインである • テスト自動化の8原則 by テスト自動化研究会 » https://sites.google.com/site/testautomationresearch/test_automation_principle 1. 手動テストはなくならない 2. 手動でおこなって効果のないテストを自動化しても無駄である 3. 自動テストは書いたことしかテストしない 4. テスト自動化の効用はコスト削減だけではない 5. 自動テストシステムの開発は継続的におこなうものである 6. 自動化検討はプロジェクト初期から 7. 自動テストで新種のバグが見つかることは稀である 8. テスト結果分析という新たなタスクが生まれる

79. © NISHI, Yasuharu79 テックシェルフ（技術の棚） • アシュアランスパイプラインを支える技術ロジスティックスにも QAは大きく関わらなくてはならない – プロセスは手順だけではなく、技法や方法論もツールも含まなくてはならない – ある工程が効果を発揮するためには、その工程に適切に技術が供給されなければならない • ドメイン技術、要素技術、エンジニアリング技術、マネジメント技術と QA観点との組み合わせ、および抽象具体の関係で仮想化することができる – 「お勉強」の結果ではなく、自分たちで試してみて上手くいったものを棚に載せる – 仮想化によってメカ／エレキ／ケミカル／ソフト／サービス統合型QMSの構築が可能になる • ポジティブナレッジとネガティブナレッジのバランスを取る – ネガティブナレッジは多く場合開発者は好きではないので、 QA部門が積極的に抽出・蓄積しないときちんと貯まらない • バッドノウハウだけでなくグッドノウハウを貯めるようにする – バッドノウハウは通常「業務知識」として自然に伝承されるが、その製品や部品、プラットフォームが変わると不要になる » 気をつけないとテックシェルフがバッドノウハウだらけになるが、それは技術力が低いことを意味する – グッドノウハウは多くの場合、一般的原理と支配法則に分けられる » グッドノウハウから支配法則を分離できると、統合型QMSに必要なテックシェルフに近づく » RCAやバグ／故障解析はテックシェルフの構築に重要だが、その支配法則に詳しくない分析者はたとえ分析経験が豊富でも曖昧な分析をしてしまうが見抜くのは難しい

80. © NISHI, Yasuharu80 ポジティブナレッジとネガティブナレッジを整理する • ポジティブナレッジ（良さの知識）だけでなくネガティブナレッジ（悪さの知識）の整理がQAには重要 – 良さの知識：どうやればうまくいくか » 参照アーキテクチャ、デザインパターン、開発プロセスなど – 悪さの知識：どうやるとダメになるか » バグのパターン、リスクのパターン、ハザードのパターンなど – 良さの知識は自然と蓄積されていくが、それだけだとマニュアル化を導き “考えないエンジニア”を生み出す危険性がどんどん高まっていく – 悪さの知識は自然と蓄積されていかないので、品質系の組織が主導して蓄積していかないといけない » 悪さの知識はレビューの指摘項目やテストケースの質を向上させる » 「品質の作り込み」とは、最初から良いことばかりをすることではなく、悪さの知識をフィードバックして最初から気をつけて作ることである

81. © NISHI, Yasuharu81 グッドノウハウとバッドノウハウを区別する • グッドノウハウとバッドノウハウを区別する – バッドノウハウ：知らないと開発できないが本来知る必要のない制約事項 » 計算機を使っていると、何でこんなことを覚えないといけないのだろうか、とストレスを感じつつも、それを覚えないとソフトウェアを使いこなすことができないためにしぶしぶ覚えなければならない、といった類いのノウハウは多い。そうした雑多なノウハウのことを、本来は知りたくもないノウハウという意味で、私はバッドノウハウと呼んでいる。…バッドノウハウがはびこる大きな理由は、ソフトウェアの開発者に使いやすさに対するセンスを欠如していたり、場当たり的な機能拡張が度重なって行われたり、単に開発の手を抜くために実装が楽なように仕様を決めてしまうといったところにあるが、別の理由によるものも根深いと私は考えている。それは、そういった使いにくいソフトウェアを使いこなす事に対して、「奥が深い」といって喜びを見出す「奥が深い症候群」によるものである。（高林哲） – グッドノウハウ：本質的でセンスのよい汎用的な技術や考え方 – 自分たちの技術がグッドノウハウかバッドノウハウかを判別し、グッドノウハウを育てる文化を醸成する » 仕事を覚えるということがバッドノウハウの蓄積を意味している組織は実に多い » バッドノウハウにまみれたエンジニアは潰しがきかず、組織が硬直する » グッドノウハウやバッドノウハウを端的に表す方言があるとよい

82. © NISHI, Yasuharu82 ポジティブナレッジ×グッドノウハウの例：富士通の７つの設計原理 ①単純原理 - 可能な限りシンプルにすること ②同型原理 - 同じものは同じように実現すること - 例外を設けないこと ③対称原理 - 対称にすること - 対になるものは対にすること - バランスを崩さないこと ④階層原理 - 階層関係、主従関係、前後関係、本末関係などを崩さないこと - 層に穴を空けないこと ⑤線形原理 - 特異点や閾値、組み合わせによる特殊な振る舞いが無いこと ⑥明証原理 - ロジックは直感的に分かりやすくすること - 分からないものやふるまいがないこと - おかしなものを受け取らない、先に送らない、無視しない、勝手に処理しないこと ⑦安全原理 - 必然性のないところや曖昧なところは安全サイドに設計しておくこと

83. © NISHI, Yasuharu83 ネガディブナレッジ×グッドノウハウの例：不具合モード分析 • ピンポイント型（検出型）V&Vや探索的V&Vでは、バグを分析してパターン化することが技術的基盤となる – しかしバグ分析を上手にできている組織は意外に少ない » 何かしらの分析結果は出るが、役に立たせることができない » そもそも現象なのか原因なのかなど、何を分析しているか分かっていない場合も多い » 責任追求型の裁判的犯人捜しの分析会議は隠蔽を生むだけで何もメリットは無い – バグ分析が下手な組織は、なぜなぜ分析やRCA（根本原因分析）も下手である – 同様にFMEAやFTAも下手である » 特にソフトの故障モードをきちんと理解して分析し蓄積している組織はとても少ない · 故障モードが蓄積できていないと、DRBFMは変化点解析に成り下がってしまう » モジュールの機能不動作・誤動作を故障モードと捉えても上手にパターン化はできない · 演算間違いや遅延という故障モードは役立つバグのパターンではない – バグのパターンをフィードバックしてフロントローディングして開発プロセスを改善したり、教育組織に展開して教育コンテンツを改善する必要がある • 不具合が作り込まれやすい仕様・設計・コードのパターンをきちんと分析して蓄積する技術を確立する必要がある – 不具合が作り込まれやすいコードのパターンはMISRA-Cなどから得られる » 設計のパターンの蓄積は設計力に依存し、仕様のパターンの蓄積はより難しい

84. © NISHI, Yasuharu84 ネガディブナレッジ×グッドノウハウの例：不具合モード分析 • 不具合が作り込まれそうな「弱点」を特定するように、よく発生する過去のバグを分析しパターン化すると、ソフトウェア開発のための質のよい故障モードが得られる – 当該工程だけでなく、後工程でバグを作り込む原因となりうる部分もパターン化する • 開発者がどう間違えるかに着目して開発者が陥りやすい「罠」をパターン化する – 人間の思考の誤謬と、誤謬を引き起こしやすいパターンをセットで明らかにする » 例）後から追加された例外的な仕様は、設計漏れを引き起こしやすい » 例）優先順位の表現で1（高い）～5（低い）と5（高い）～1（低い）が混在すると混同しやすい » 例）異なるサブシステムでリソースの確保・解放を行うとリークしやすい » 例）「備考」にはバグが多い – 似たようなパターンのバリエーションをツリー状に整理する • 「共感」を軸にしてバグの分析を行う – 適切なパターン化ができた瞬間は、分析会議の参加者が「その罠にはみんなひっかかるよね」と共感するようになる – バグを作り込んだ人という扱いではなく、罠の情報を提供してくれる人として尊敬を前面に出すと、前向きの会議になって共感しやすくなる

85. © NISHI, Yasuharu85 不具合モードで頻発する不具合を未然防止する • 派生開発・SPLEでは特定の種類のバグが派生品をまたいで、かつ異なる機能で頻発することがある – 母体や開発プロセスに不具合モードもしくは不具合モードの芽があるため、派生品を開発する度にバグを作り込んでしまう » 不具合モード「例外」：法規対応、多仕向地、機能複合型製品 » 母体の設計にそもそも難がある » 仕様書群の構造そのものに不具合モードがあったりもする – 母体の不具合モードに着目してテストを設計したり、最初から気をつけて開発することで頻発バグを効率的に防ぐことができる

86. © NISHI, Yasuharu86 ソフトウェアHAZOPのためのより詳しいガイドワード強度強い弱い時期早く遅く数量多い少ない時間長く短く増加減少間隔広く狭く余分不足期間長く短くあるないゼロ順序さきにあとで種類多種小種同時に並行に規模大きい小さい早く遅く距離遠い近い逆転反復挿入速度速い遅いタイミング早く遅く高速低速拡張広く狭く緩急多く少なく設定許容禁止頻度多く少なく必須任意高く低く範囲長い短い程度いつもたまに上限下限回数多く少なく広い狭い接続つなぐ切り離し切り替え最大限最小限方向上へ下へ頻度高い低い負荷高い低い多い少ない超過不足限界金額大きい小さい位置高く低く遠く近く鈴木三紀夫さん（リコーITソリューションズ）、秋山浩一さん（富士ゼロックス）がご作成

87. © NISHI, Yasuharu87 ソフトウェアHAZOPのためのより詳しいガイドワード原則例外正常異常準正常全体部分通常非通常全部一部通常例外代替主従定期臨時正誤通例異例常例無事有事平時非常時緊急時公正不正定常可変任意強制尋常非常基本詳細主要一般特別完了未完普通特殊有効無効並特異起動停止鈴木三紀夫さん（リコーITソリューションズ）、秋山浩一さん（富士ゼロックス）がご作成

89. © NISHI, Yasuharu89 不具合分析のアンチパターンと効果の薄い対策 • Vaporization（その場限りの簡単なミスとして片付けてしまう） – コーディングミス：スキルを向上させるよう教育を行う – 考慮不足：しっかり考慮したかどうかレビュー時間を増やし確認する – うっかりミス：うっかりしていないかどうかレビュー時間を増やし確認する • Exhaustion（不完全な実施や単なる不足を原因としてしまう） – しっかりやらない：しっかりやったかどうかレビュー時間を増やし確認する – スキル不足：スキルを向上させるよう教育を行う – 経験不足：経験を補うためにスキルを向上させるよう教育を行う • Escalation（上位層に責任を転嫁してしまう） – マネジメントの責任：トップを含めた品質文化を醸成する • Imposition（外部組織に責任を転嫁してしまう） – パートナー企業の責任：パートナー企業を含めた品質文化を醸成する • Culturalization（文化的問題に帰着してしまう） – 品質意識／品質文化の欠如：全社的な品質文化を醸成する

90. © NISHI, Yasuharu90 技術ロジスティックス • アシュアランスパイプラインを支える技術ロジスティックスにも QAは大きく関わらなくてはならない – （本来の）プロセスは手順だけではなく、技法や方法論もツールも含まなくてはならない – ある工程でプロセスが効果を発揮するためには、（本来の）プロセスはそこのエンジニアに技術を供給するための仕組みや経路をきちんと設計し、運用しなくてはならない » 技術を供給するための仕組みや経路を「技術ロジスティックス」と呼ぶ – 外部からの知識獲得や教育、工夫の再利用、バグのパターン化など様々な仕組みがある • 技術ロジスティックスには2方向の経路があり、両方とも重要である – 動脈系：テックシェルフ（技術の棚）からプロセスに技術を供給する – 静脈系：プロセスのポジティブ／ネガティブナレッジをテックシェルフに適切に蓄積する • 技術ロジスティックスが構築・改善されてない組織は競争力を向上できない – 動脈系の技術ロジスティックスが無いと、エンジニアは現場でベストでないプラクティスを使わざるを得ず、生産性や品質を落とすことになる – 静脈系の技術ロジスティックスが無いと、エンジニアが行った工夫を技術化して蓄積して再利用できないため、仕事がやりっぱなしになり賢くならない – 技術ロジスティックスの構築やカイゼンはどうしても後回しになるので、意識して投資し時間や優秀な人財を割り当てなくてはならない » 技術ロジスティックスが貧弱なソフトハウスは労働力を売らざるを得ず、どんどん単価が下がっていく

91. © NISHI, Yasuharu91 グローバル開発におけるテストの組織化日本HQ/DC 北米DC 欧州DC アジアDC 現地SH現地SH現地SH 現地SH現地SH ・テスト観点ベースの参照アーキテクチャ／パターン・参照テストプロセスモデル・他DCでの不具合モード・テスト観点ベースの各拠点のテストアーキテクチャ事例・各DCでのテストプロセステーラリング事例・各DCでの不具合モード・各現地SHに対して指示する個別テスト観点および不具合モード・ISO/IEC/IEEE29119に準拠したテスト詳細設計／実装／実行プロセス・探索型テストのチャーター・指示された個別テスト観点に対するテストケースやテスト手順、テスト結果・プロセス起因の生産性阻害要因・探索して新たに見つかったテスト観点や不具合モード HQ: 本社 DC: 開発センタ SH：ソフトハウス

92. © NISHI, Yasuharu92 グローバル開発におけるテストの組織化日本HQ/DC 北米DC 欧州DC アジアDC 現地SH現地SH現地SH 現地SH現地SH ・テスト観点ベースの参照アーキテクチャ／パターン・参照テストプロセスモデル・他DCでの不具合モード・テスト観点ベースの各拠点のテストアーキテクチャ事例・各DCでのテストプロセステーラリング事例・各DCでの不具合モード・各現地SHに対して指示する個別テスト観点および不具合モード・29119に準拠したテスト詳細設計／実装／実行プロセス・探索型テストのチャーター・指示された個別テスト観点に対するテストケースやテスト手順、テスト結果・プロセス起因の生産性阻害要因・探索して新たに見つかったテスト観点や不具合モード拠点の責務と取り扱う設計情報・プロセス情報の粒度をグローバルなテスト／QAアーキテクチャとして適切に設計することで、ノウハウを掘り出して活きた標準に落とし込み、組織全体できちんと品質保証を行い改善サイクルを回すことができる

94. © NISHI, Yasuharu94 まとめ • 現状のテストや品質保証の問題点は、 Monolithicな粗いQAになっており各施策がてんでばらばらなことである – 「その質は何によって決まるか」、「その質をどこでどう確実に作り込んで確実に実証するか」がもやもやしてふんわりしていることが原因となっている • MicroQualityパラダイムに基づいてQAアーキテクチャを設計すると、モデルベース開発からモデルベース品質保証にステップアップでき、説明責任が高く最適な品質保証に近づいていくことができる – 品質を細かい粒度でモデリングし品質保証アーキテクチャを設計し説明責任の高いテストや品質保証をする – 自動化による高速化やフロントローディングによる軽量化、グローバル化を行えるようにアシュアランスパイプライン上で責務の整理を行う » ツールを買ってくるだけでは部分的な効果しか生み出せない – テックシェルフを分離し上手に抽象化・仮想化を行うとともに技術ロジスティックスを確立しQAが強くコミットしていくことでメカ／エレキ／ケミカル／ソフト／サービス統合型QMSを構築していく • そのために、まずテストアーキテクチャの設計技術を鍛えていこう

QAアーキテクチャの設計による 説明責任の高いテスト・品質保証

Yasuharu Nishi