Downloaded 278 times
![© NISHI, Yasuharu187
忘れられがちな改善ポイント
• テスト項目の粒度
– 粒度とはテスト項目の記述の詳細度
» ログインする／ユーザ名にNsh、次にパスワードにESECと入力し[OK]を押す
– テスト実施担当者のスキルによって粒度を変える必要がある
– 期待結果やチェックポイントの粒度も問題になる
» 「きちんと動作すること」は、どこの何を見れば分かるのか？
» 粒度を細かくすると設計工数がかかるが実施時に悩む時間は減る
· 粒度を粗くしてテスト実施者の自由度を組み込むこともある
• モチベーションも重要
– 集中力を落とさないようにテスト実施順序を工夫する必要がある
– 単純作業に感じさせないように目的や責任、権限を与える必要がある
• テスト技術者に必要な才能
– 誠実さ／忍耐／細部まで観察できる能力／経験をパターン化する能力
／組み合わせの概算力／他の人の気持ちが分かること など](https://image.slidesharecdn.com/cosco160627-160627152500/85/slide-187-320.jpg)
Uploaded byYasuharu Nishi
ソフトウェアの品質保証の基礎とこれから
製造業のQA部門におけるソフトハウスの品質保証の問題点の典型例を示し、品質保証戦略およびQAアーキテクチャ設計の概要について述べる。またソフトウェアの品質保証の概略について述べる。補足としてVSTePとWモデルについて説明している。日本規格協会 品質経営システム研究会（COSCO）の2016/06/28の資料。http://www.slideshare.net/YasuharuNishi/ss-63412458 のアップデート版です。
More Related Content
![[3rd 長崎QDG] チームで、長期間で、たくさんのソフトウェアを快適に開発し、価値を生み続けるためのエンジニアリング](https://cdn.slidesharecdn.com/ss_thumbnails/nagasakiqdg2018-teams-180208122831-thumbnail.jpg?width=640&height=640&fit=bounds)
ソフトウェアの品質保証の基礎とこれから
- 1. © NISHI, Yasuharu ソフトウェアの品質保証の基礎とこれから 日本規格協会品質経営システム研究会 2016/6/27（月） 電気通信大学 大学院情報理工学研究科 情報学専攻 経営・社会情報学プログラム 西 康晴
- 2. © NISHI, Yasuharu2 講演の流れ •自己紹介 • IoT時代で品質保証部門は何を考えていけばいいのか？ • 製造業のソフト開発部門の品質保証の問題点の例 • 役に立たないソフトハウスのQAの例 • ソフトウェアとハードウェアの違い • ソフト開発部門／ソフトハウスには品質保証戦略の立案が必要 • 品質保証アーキテクチャの設計 • ソフトウェアの品質管理の基本的アクティビティの概要 • まとめ • 補足：テスト開発方法論VSTePの概要とWモデル
- 3. © NISHI, Yasuharu3 自己紹介 •身分 – ソフトウェア工学の研究者 » 電気通信大学 大学院情報理工学研究科 総合情報学専攻 経営情報学コース » ちょっと「生臭い」研究／ソフトウェアテストやプロセス改善など – 先日までソフトウェアのよろず品質コンサルタント • 専門分野 – ソフトウェアテスト／プロジェクトマネジメント ／ＱＡ／ソフトウェア品質／ＴＱＭ全般／教育 • 共訳書 – 実践ソフトウェア・エンジニアリング／日科技連出版 – 基本から学ぶソフトウェアテスト／日経ＢＰ – ソフトウェアテスト293の鉄則／日経ＢＰ • もろもろ – TEF: テスト技術者交流会 / ASTER: テスト技術振興協会 – WACATE: 若手テストエンジニア向けワークショップ – SESSAME: 組込みソフトウェア管理者技術者育成研究会 – SQiP: 日科技連ソフトウェア品質委員会 – 情報処理学会 ソフトウェア工学研究会 / SE教育委員会 – ISO/IEC JTC1/SC7/WG26（ISO/IEC 29119 ソフトウェアテスト） » 2016/7/15（金）に29119シリーズの解説セミナーをやります
- 4. © NISHI, Yasuharu4 TEF:Software Testing Engineer’s Forum • ソフトウェアテスト技術者交流会 – 1998年9月に活動開始 » 現在1800名強の登録 » MLベースの議論と、たまの会合 – http://www.swtest.jp/forum.html – お金は無いけど熱意はあるテスト技術者を 無償で応援する集まり – 「基本から学ぶソフトウェアテスト」や 「ソフトウェアテスト293の鉄則」の翻訳も手がける » ほぼMLとWebをインフラとした珍しいオンライン翻訳チーム – 技術別部会や地域別勉強会が実施されている » プリンタ、Web、AVなど » 東京、関西、九州、東海、札幌など » TestLinkというオープンソースツールの日本語化部会もある
- 5. © NISHI, Yasuharu5 ASTER:Association of Software Test EngineeRing • ソフトウェアテスト技術振興協会 – テストを軸にして、ソフトウェア品質向上に関する教育や 調査研究、普及振興を行うNPO法人 » 2006年4月に設立／理事・会員は無給 – ソフトウェアテストシンポジウム（JaSST）を開催している » 実行委員は手弁当／参加費は実費＋α » 毎年4Qに東京で開催／例年のべ1500名前後の参加者 » 東北・四国・関西・北海道・九州・東海・新潟でも開催／会場はほぼ満席 – ソフトウェアテストの資格試験（JSTQB）を運営している » Foundation Levelは21,548名の受験者・11,958名の合格者 » Advanced Level（テストマネージャ）を2010年8月に開始・361/1,486名の合格 » Advanced Level（テストアナリスト）を2016年2月に開始・43/351名の合格 – ソフトウェアテスト設計コンテストを開催している » テスト設計の質の高さを競うコンテスト／今年は全国から15チームの参加 » 主要な成果物は無償で公開／毎年レベルが向上／マレーシアでも開催 – 各地でソフトウェアテストの教育を行っている » テストのスキル標準（test.SSF）をIVIAと共同で開発している » セミナーや勉強会などを支援することで、地場の産業振興の定着を図る – アジア各国とテスト技術の交流（ASTA）を行っている » アジャイル・バグ分析・ゲームテスト・テストプロセス改善など
- 6. © NISHI, Yasuharu6 SESSAME:組込みソフトの育成研究会 • 組込みソフトウェア技術者管理者育成研究会 – Society for Embedded Software Skill Acquisition for Managers and Engineers – 2000年12月に活動開始 » 200名強の会員／MLベースの議論と、月イチの会合 – http://www.sessame.jp/ • 中級の技術者を10万人育てる – ＰＣソフトウェアのような「そこそこ品質」ではダメ » 創造性型産業において米国に劣り、コスト競争型産業でアジアに負ける » ハードウェアとの協調という点で日本に勝機があるはず – 育成に必要なすべてを開発する – オープンプロダクト／ベストエフォート » 文献ポインタ集、知識体系（用語集）、初級者向けテキスト、スキル標準など » 7つのワークグループ：組込みMOT・演習・MISRA-C・ETSS・子供・高信頼性 – セミナーだけでなく、講師用セミナーも実施
- 7. © NISHI, Yasuharu7 Safeware翻訳プロジェクト •2009年11月に翻訳版を刊行した – Nancy Leveson（MIT）著 – 翻訳チーム：松原友夫・片平真史（JAXA）・吉岡律夫（日本機能安全） ・青木美津江（電気通信大学） ・西康晴（電気通信大学） – 翔泳社 発行 第1部 リスクの性質 第1章 近代社会におけるリスク 第2章 コンピュータとリスク 第3章 事故の階層的考察 第4章 事故の根本原因 第5章 ヒューマンエラーとリスク 第6章 自動化システムにおける人間の役割 第2部 システム安全への序論 第7章 システム安全の基礎 第8章 システム安全の基本 第3部 定義とモデル 第9章 用語 第10章 事故とヒューマンエラーモデル 第4部 セーフウェアプログラムの要素 第12章 システムとソフトウェア安全プロセス 第13章 ハザード分析 第14章 ハザード分析モデルと技法 第15章 ソフトウェアハザードと要求分析 第16章 安全性のための設計 第17章 ヒューマンマシンインタフェースの設計 第18章 安全性の検証 付録 付録A．医療機器：Therac-25の歴史 付録B．航空宇宙：アポロ13号、DC-10型機、 チャレンジャー号 付録C 化学産業：セベソ、フリックスボロー、ボパール 付録D 原子炉事故:ウィンズケール、 スリーマイル島、及びチェルノブイリ
- 8. © NISHI, Yasuharu8 SQiP：SoftwareQuality Profession • 名称： – 日本科学技術連盟・ソフトウェア品質委員会 • 目的 – SQiPは、ソフトウェア品質技術・施策の調査・研究・教育を通じて、 実践的・実証的なソフトウェア品質方法論を確立・普及することにより、 ソフトウェア品質の継続的な向上を目指す • ３つの視点 – ソフトウェア品質・実践・普及啓蒙 • 主軸とする活動 １．実践的・実証的なソフトウェア品質方法論の確立 ２．ソフトウェア品質方法論の普及促進・資格認定 ３．ソフトウェア品質向上のための国際協力の推進 • 活動方針 １．ソフトウェア品質追究の重要性訴求 ２．日本での実践的・実証的ソフトウェア品質方法論の形式知化 ３．グローバルな視野での活動 ４．新しい課題へのチャレンジ
- 9. © NISHI, Yasuharu9 （ソフトウェア）品質に対する欧米的な考え方 •PMBOK: Project Management Body Of Knowledge – 品質とは、「本来備わっている特性がまとまって、要求事項を満たす度合い」である（ASQ） » 8章冒頭 – プロジェクト品質マネジメントプロセスには、品質計画、品質保証、品質管理がある。品質管 理 － 特定のプロジェクト結果が適切な品質規格に適合しているかどうかを判断するために 、結果を監視し、不満足なパフォーマンスの原因を除去するための方法を特定する » 8章冒頭 • SWEBOK: SoftWare Engineering Body Of Knowledge – よく読むと、品質の定義を巧妙に避けている » ユーザ要求に対する適合性（Crosby）、利用に対する適合性において優れたレベルを達成する（ Humphrey）、顧客満足度（ＩＢＭ、MB賞）、本質的特性の集成体が要求を満たす度合い（ISO9001- 00） » 11章序説 – SQMプロセスは、与えられたプロジェクトにおいて、より良いソフトウェア品質を確証すること を助ける。SQMプロセスは、その副産物として、全ソフトウェアエンジニアリングプロセスの品 質表示など、マネジメントに対する一般的な情報を提示する » 11.2/ソフトウェア品質マネジメントプロセス
- 10. © NISHI, Yasuharu10 品質とコスト・納期はトレードオフであるという誤解 •品質に対する欧米的な考え方 – 顧客の要求に対する合致度といった「開発の結果」である » PMBoK：「本来備わっている特性がまとまって、要求事項を満たす度合い」（ASQ） » SWEBOK：よく読むと、品質の定義を巧妙に避けているが、要するに顧客満足度 – コストや納期などと同列の、もしくは後回しの、単なる指標である – 品質向上活動によって現場が楽にならない » 行き当たりばったりの活動をしていたり、流行を追っている » 自組織の弱点を把握せず解決策に目を奪われている » 目的を見失い現場の信頼も失う – 経営指標ではない » 顧客の要求の達成どころか、 自分の仕事の言い訳にしか使わない輩もいる • 品質とコスト・納期はトレードオフであるというのは誤解である – 品質を上げるとコストが上がり納期は長くなる » 品質は検査や監査で確保する – 最適品質を狙い、過剰品質は避けるべきである
- 11. © NISHI, Yasuharu11 （ソフトウェア）品質に対する日本的な考え方 •SQuBOK: Software Quality Body Of Knowledge – 仕事の質，サービスの質，情報の質，工程の質，部門の質，人の質，システムの質，会社の 質など，これら全てを含めた「質」 » 1.1.1.7/品質の定義：石川馨 – 組織を長期的・安定的に存続させるには，組織の活動の主たるアウトプットである製品・サー ビスを顧客に提供し，それによって対価を得て，そこから得られる利益を再投資して価値提 供の再生産サイクルを維持することが必須である。そのためには，組織が提供する製品・ サービスが長期的に幅広い顧客に満足を与え続けなければならない。これを実現するため の武器が「品質のマネジメント」である。 » 1.2/品質のマネジメント 「品質」は技術力そのものであり、 組織の持続的な強みの源泉である
- 12. © NISHI, Yasuharu12 （ソフトウェア）品質に対する日本的な考え方 •品質とは – 単なる開発の結果ではなく、組織が目指すべき軸である » 欠陥、価値（円）、満足度、喜び、導き » ブランド力、ヒット商品を生み、感受性や予測が必要である – 組織における技術・マネジメント・ひとの持続的成長の源泉である » 顧客、経営、現場の３者を同時によくする – 現場が楽になるように品質向上活動をする » 中長期的な成長のプランを持ち、成果を現場に見えるように出すことで 現場の信頼を得て継続的にカイゼンする » 自組織の弱点を把握して、適切な解決策を選びカスタマイズしたり、 本質的な解決策を設計する » 絶えざる目的指向が備わるようになる – ロバストな経営指標である » 大きな失敗は無い 品質を上げようとすると コストは下がり納期は短くなる
- 13. © NISHI, Yasuharu13 SQuBOKにみられる日本的TQMの特徴 •「品質」 – 仕事の質，サービスの質， 情報の質，工程の質，部門の質，人 の質，システムの質， 会社の質など， これら全てを含めた「質」 • 「品質保証」 – お客様に安心して使って頂ける ような製品を提供するための すべての活動 » プロダクトとプロセスが、 特定された要求に合致している かどうかという十分な確信を 提供する活動ではない • 「改善」 – 不十分でもとにかく動き出して 全員が今より高いところを 目指してプロセスそのものを 改善しながら進める » 欧米流の、プロセスを定義して その通りに実行していることを 確認することではない • 「品質第一」 – 品質を高めることによって 手戻りや作業のムダを省き， 継続的な納期の短縮や コストダウンにつなげていく » 納期を厳守するために 必要な作業を省くのではない
- 14. © NISHI, Yasuharu14 SQuBOKにみられる日本的TQMの特徴 •「品質の作り込み」 – より上流で“悪さ”の知識を子細に活 用し障害を排除していく » ただ単にきちんと作る、 という意味ではない • 「次工程はお客様」 – 他の工程を助けるような改善を進め， 全体最適へと向かっていく • 「人間性尊重」 「組織活性化」 • 「小集団活動」 • 「5ゲン主義」 – 現場・現物・現実 – 原理・原則 • 「全員参加」 – 品質管理はスタッフだけではなく、 現場も経営陣も一丸となって 進めなければならない – 現場の関係者全員が納得して ベクトルをあわせ，目標達成の ために取り組む – 現場中心のため隅々まで 改善が行き届くとともに， 全員が自ら考えて行動する 組織を構築できる
- 15. © NISHI, Yasuharu15 講演の流れ •自己紹介 • IoT時代で品質保証部門は何を考えていけばいいのか？ • 製造業のソフト開発部門の品質保証の問題点の例 • 役に立たないソフトハウスのQAの例 • ソフトウェアとハードウェアの違い • ソフト開発部門／ソフトハウスには品質保証戦略の立案が必要 • 品質保証アーキテクチャの設計 • ソフトウェアの品質管理の基本的アクティビティの概要 • まとめ • 補足：テスト開発方法論VSTePの概要とWモデル
- 16. © NISHI, Yasuharu16 IoT時代で品質保証部門は何を考えていけばいいのか？ •センサー付き製品がどんどん増えていくので、ソフトのバグがあったら困る • 製品がネットワークでつながるので、セキュリティは大事みたいだ • でもそういうのはソフト部門に任せておけばいい • やっぱり足腰となる「ものづくりの品質」こそ品質保証部門の考えるべきことだ
- 17. © NISHI, Yasuharu17 IoT時代での品質を考えるための例 •単体のビジネスホテルの品質にはどのようなものがあるか？ • ビジネスホテルチェーンの品質にはどのようなものがあるか？ • 顧客アクティビティ用のスマートデバイスを使う 顧客滞在型リゾートの品質にはどのようなものがあるか？ • 民泊ビジネスの品質にはどのようなものがあるか？
- 18. © NISHI, Yasuharu18 IoT時代での品質を考えるための例 •単体のビジネスホテルの品質 – 清潔度、ベッドの質、スタッフの導線、マニュアル通りの言葉遣い、など • ビジネスホテルチェーンの品質 – 顧客情報のセキュリティ・プライバシーの確保、個々のホテルシステムの相互接続性 – 大量の予約情報や顧客クレームすなわちビッグデータから抽出できる品質情報、など • 顧客アクティビティ用のスマートデバイスを使う顧客滞在型リゾートの品質 – お客様がスマートデバイスにカワイイと思ってくださるか – お客様がスマートデバイスでどれだけリゾートを楽しんでくださるか – お客様が家に帰ってからもリゾートの話をずっとしたくなってくださるか – お客様が他の方にリゾートを積極的に進めてくださるか、など • ・民泊ビジネスの品質 – ビジネスプラットフォームとして便利か – お客様にホテルの供給側になって喜びや誇りを感じてくださるか – お客様が他の方をホテルの供給側として誘ってくださるか – 自分たちのプラットフォームが標準になるために何をすればよいか、など » 他の業者が乗ってきやすいか、乗っていて快適か
- 19. © NISHI, Yasuharu19 IoTは組織のソフトウェア化を否が応にも進めて行く •製品にソフトウェアが入り込み、製品同士や本社がネットワークでつながる – ネットワーク型組み込みソフト？ • 製品から送られてくるデータを本社側で解析しビジネスの質の向上につなげる – 組み込みソフト連動型業務システム？ • 製品から送られてくるデータを使った 新しい機能や製品、サービス、ビジネスを機動的に展開するため、 事業部門がソフトウェア開発部門を持たなくてはならなくなる – 事業部門が業務システムや組み込みソフトに深く関与していくようになる • ビジネススピードに追従するために事業部門がソフトウェア主体となっていく – 事業部門が業務システムや組み込みソフトを内製化するようになっていく – ソフト化された事業部門が自分たちで機動的に融合しどんどん形を変えていく • Industrie4.0のその先は？ – ソフトウェアによる製品そのもの、生産、設計、調達の融合 → 財務金融（資金調達）？ – 生産、工場立地選定、物流、販売、アフターサービスの融合 → 中古市場での価値創造？ – 価値の流れ、モノの流れ、情報の流れ、ヒトの流れ、カネの流れがソフト化され 機動的に融合しどんどん形を変えていく？ – 事業部門も企業も業種も機動的に融合しどんどん形を変えていく？ • そんな世界を見据えて製造業の品質保証部門は何を考えていけばいいのか？
- 20. © NISHI, Yasuharu20 講演の流れ •自己紹介 • IoT時代で品質保証部門は何を考えていけばいいのか？ • 製造業のソフト開発部門の品質保証の問題点の例 • 役に立たないソフトハウスのQAの例 • ソフトウェアとハードウェアの違い • ソフト開発部門／ソフトハウスには品質保証戦略の立案が必要 • 品質保証アーキテクチャの設計 • ソフトウェアの品質管理の基本的アクティビティの概要 • まとめ • 補足：テスト開発方法論VSTePの概要とWモデル
- 21. © NISHI, Yasuharu21 製造業のソフト開発部門の品質保証の問題点の例 •不勉強で固有技術の違いを理解しようとしない QCの専門家を自称する管理屋・統計屋が 自分たちの知ってることを押しつけようとする – プロセスで作り込む、を誤解して、プロセスという名の手順とハンコを押しつけようとする » 手順とハンコを標準化と誤解してしまうような文化で、標準化ガーと叫ぶ – 事実で管理する、を誤解して、無根拠のメトリクスを押しつけようとする » 相関が高くなりようがない回帰分析をするために現場に測定を押しつける · ex) レビュー密度と出荷後バグ率 » 7つ道具、特に層別はさせずに管理図を描かせる – 未然防止、を誤解して、教条的ななぜなぜ分析を押しつけようとする » なぜを5つ書かせて工程欠落に誘導し、工程増加かダブルチェックを経て二重帳簿化させる – とにかく自分たちの知ってることと似たことを探したら直交表を見つけたので 直交表による組み合わせテストをソフトQAの銀の弾丸だと信じ込む » 直交表による組み合わせテストはソフトQAのごく一部に過ぎない – 見かけ上は全社共通のQMSを持っていることになっているが、 実際は固有技術や工程ごとにバラバラのQMSになってしまっている
- 22. © NISHI, Yasuharu22 製造業のソフト開発部門の品質保証の問題点の例 •ソフトウェアなんて部品の一種だと思う – 出羽守に騙されて本社におかしなリーン化をしてしまい、ソフトハウスの罠にはまる » ソフトウェア開発部隊を子会社化する » ソフトウェア開発部隊をリソースプール化する – 協力会社に丸投げしたが品質が悪くカイゼンの見込みもない » そもそも自社でソフトの技術開発も改善活動もできてないので協力会社の指導ができない » 契約的・金銭的制裁を行うが、ソフトハウスのビジネスモデルを全く理解していないので ダメなエンジニアを寄こされて、もしくは手抜きの仕事をされて、さらに窮地に陥る » 丸投げしてるため調達部門の管轄になっており、カネの付き合いしかできず カイゼン活動をしてもらえない » 自社の仕様も母体の制約や不具合も何もかも協力会社が知っているので、 協力会社との関係がズブズブになっている » 実質的にソフトの品質プロセスを協力会社に握られている • 何をやっていいか分からないからひたすら猫の手になり、 なんの目的も無いテストという名のチェック作業の手伝いをずっと行う – 「刺身タンポポ」的品質保証になってしまっている
- 23. © NISHI, Yasuharu23 製造業のソフト開発部門の品質保証の問題点の例 •品質保証部門が自己矮小化してしまっている – 経営からは生産だけでなく設計もソフトも見ろと言われるが、 設計やソフトでの品質管理では結果を出せないので、 ひたすら生産の品質管理のやり方を設計やソフトに押しつける – 設計やソフトからは軽んじられ、自分たちは生産の品質管理でこそ輝くとか思ってしまう » 生産の品質あってこその日本のものづくり力だ、とかいう昭和な記事に感情移入してしまう – どう作るかの品質管理はできても、作るべきものがどんな品質を持つべきか、 作るべきものがどう変わっていってるのか、そもそも品質ってなんだ、という 検討が全くできていないし、する予定もないし、する気もない – だから「過剰品質」という悪口に言い返せない – 会社の体質や組織文化そのものに問題があるが、 それは自分たちの仕事では無いと思っている
- 24. © NISHI, Yasuharu24 講演の流れ •自己紹介 • IoT時代で品質保証部門は何を考えていけばいいのか？ • 製造業のソフト開発部門の品質保証の問題点の例 • 役に立たないソフトハウスのQAの例 • ソフトウェアとハードウェアの違い • ソフト開発部門／ソフトハウスには品質保証戦略の立案が必要 • 品質保証アーキテクチャの設計 • ソフトウェアの品質管理の基本的アクティビティの概要 • まとめ • 補足：テスト開発方法論VSTePの概要とWモデル
- 25. © NISHI, Yasuharu25 役に立たないソフトハウスのQAの例（背景編） •現場や営業、客先から品質保証やカイゼンのリクエストは通常出てこない – 品質が低くて生産性が高い方が工数がかかるのでダメな開発で稼働損を減らせば儲かる、 というビジネスエッセンスの罠にはまっている » 実は客先は品質の低さや生産性の低さに嫌気がさしており、 客先担当者はダンピングをしてくるし、客先担当者の上司の上司は業者変更をしたいと思っている – 現場はカイゼンしたいとか技術を高めたいとか言うと誰も賛成しないし、 以前やったら失敗したから雰囲気悪いし、業務時間外にやれとか言われるので 誰もカイゼンしたいと言い出さないし、誰かが言い出しても無視する » 現場はどんどん自律性を失って下請根性の塊に成り下がってしまう • しかし現場をよくしたい、とは別の妙な理由で 品質保証やカイゼンめいたものをしなくてはいけなくなる – 厳しい顧客（＝カネを持っている顧客）に新規開拓したい営業などから、 標準プロセスくらい持ってないと発注しない／受注できないと言われる » 規格を受注条件やバッジだと思っている顧客から、とにかく規格を取れと言われる – トラブった現場の客先から営業がクレームを食らい、 再発防止して定量的に結果をお見せしなくちゃいけなくなる – 経営戦略など持ってない経営陣がどっかからプロセス系の話を聞いてきて、 うちの会社でもやれとか急に言い出す
- 26. © NISHI, Yasuharu26 役に立たないソフトハウスのQAの例（実態編） •プロセスを構築したりメトリクスを測ろうにも、 現場の仕事の実態をQAは掴んでいない – エンジニアから話を聞こうにも客先にずっと常駐しているし、 自社に戻ってきてもらうと売り上げが下がるし、自分が行くのはめんどくさい – そもそも現場で使えないヤツがQAに回されて書類仕事ばかりなのでクサっているし、 普段から役に立つ仕事が出来てないので現場からQAは尊敬されてない • 現場のためでなく、自分たちのアイデンティティのために 仕事をしている／しようとする – 年に1度程度の部門計画や部門報告の際に 仕事をしたことにしないとクビが危ないので、 自分は手を動かさないが報告しやすい仕事ばかりしようとする – 事業部門や開発部門から役に立つと思われてないので、QAに人を回してもらえず、 手持ちの人員でできる程度の仕事しかできないと言い訳をする – 現場の役に立たない仕事をしていることを正当化するために、 CMMiとかPMOとか社外のバズワード的な監査系の仕事を導入しようとする • それがQAの仕事であり、そういうものだと自己矮小化している
- 27. © NISHI, Yasuharu27 役に立たないソフトハウスのQAの例（結果編） •営業時に顧客に見せる、もしく経営陣に見せるために、 かっこいいだけで根拠のないプロセスや帳票を作りメトリクスを測ろうとする – 現場のためになることを指向していないので、 QAの仕事の根拠をそのプロセスとメトリクスに依存するようになり、 根拠のない押しつけを日常的に吐くようになる » 「決めたんだから使え！」 「『測定なくして改善なし』とケルビン卿が言ってるんだよ！」 「ばらつきを減らすのが品質管理なんだ！」 「プロセスで品質を作り込むんだ！」 – 現場の仕事と乖離するかどうかはどうでもいいので、外部の権威に頼ろうとする • プロセスや帳票、メトリクスができたのだから動かせ、と経営陣に言われる – しかし現場の仕事と乖離しているから現場は言うことを聞かない • 現場に無視されたまま現場はバカだと言い訳をするか、 会社指揮命令系統を通じて無理に現場に使わせようとする – 後者の場合、現場は不要な作業、不要な帳票、不要な測定、不要な印鑑を しなくてならなくなり、効率が下がりモチベーションが落ち、2重帳簿を作り始める – もともとそこそこorギリギリで上手く行っていたはずの現場の仕事が回らなくなる • トラブルが発生して仕事を切られて単価が下がる • 景気のせいにしてほっかむりを決め込む
- 28.
- 29. © NISHI, Yasuharu29 講演の流れ •自己紹介 • IoT時代で品質保証部門は何を考えていけばいいのか？ • 製造業のソフト開発部門の品質保証の問題点の例 • 役に立たないソフトハウスのQAの例 • ソフトウェアとハードウェアの違い • ソフト開発部門／ソフトハウスには品質保証戦略の立案が必要 • 品質保証アーキテクチャの設計 • ソフトウェアの品質管理の基本的アクティビティの概要 • まとめ • 補足：テスト開発方法論VSTePの概要とWモデル
- 30. © NISHI, Yasuharu30 ソフトウェアは物理的実体もばらつきもない •ソフトウェアには「生産」プロセスがない – 実装／コーディング／プログラミングプロセスは、 ハードウェアにおける詳細設計プロセスである » 完成したプログラムをCDやROMに焼くプロセスはソフトウェア開発として考慮しない » いわゆる工場メタファによる属人性の排除は幻想である • ソフトウェアは劣化しない – 物理的実体の性質変動を考慮する必要が（あまり）無い » 組込みにおけるハードウェア、エンプラにおけるプラットフォームは必要 • ソフトウェアは物理化学法則に従わない – 不具合の原因は論理性の欠如であり、物理化学法則に対応づかない » 支配法則が異なる：社会学や認知科学的法則、モチベーションが大きく関係する » 故障モードの把握が難しい：ユニットの機能不動作ではない » ファクトコントロールは、データで示すことではなく、論理性の確保である • ソフトウェアには「検査」プロセスがない – 物理的実体のばらつきを公差の範囲内に収めるために、 何かの値を測定しある基準値によって振り分けるような、単純作業は無い
- 31. © NISHI, Yasuharu31 ソフトウェアは複雑である •規模が大きい – 747の部品点数は600万点(?)、カーナビのステップ数は数百万行 • 協調すべき数・種類が多い – 乗用車に搭載されるECUは数年後に200を超えると言われている – 組込みの場合は、プラットフォームが極めて多様である • 開発人数が多く、開発期間は短い – ある携帯電話は200万ステップで1800人月である • 分割統治原則が必ずしも機能しない – 空間的ないし物理的な分割が不可能である » 例えばOSにメモリ保護などの機能はあるが、 不具合の伝播を物理的に食い止めることができない – 性能や省メモリのために、実装の詳細が隠蔽できない場合が少なくない • 論理性が高い – ロジックが入り組んでおり、条件組み合わせが複雑で、並行動作を行う – バグはフェーズを経るごとに指数関数的に増加していく
- 32. © NISHI, Yasuharu32 ソフトウェアは開発しにくい •確立した開発方法論が無い – 構造化分析／設計、状態遷移設計、オブジェクト指向、アジャイル開発．．．？ – いわゆるSQC（統計的品質管理）手法はほぼ全く適用できない • 要求が曖昧で記述しにくく、かつ変化してしまう – 暗黙の要求や「使ってみて始めて分かる」要求が少なくない – ビジネスのスピードが速くなり、ソフトは簡単に追加・変更できると思われている • 再利用が難しい – 再利用に最適な機能分割・構造分割・粒度設定が難しい – 開発技術やプラットフォームがどんどん変化する – もともと再利用を想定していない成果物をベースに再利用しようとする – 再利用しやすい標準部品を使うと、競争力は無くなっていく？ • 品質が低く、性能が予測しにくい部品が多い – 部品の受け入れテストや部品との組み合わせテスト、 個々の部品向けのパッチコードが必要となる – 品質保証されていない「オープンソース」を使う場合も増えてきている
- 33. © NISHI, Yasuharu33 「ソフトウェア」品質保証が誤解している点 •見習うべきはハードウェアの設計工程であり、 大量生産工程ではない – ハードの設計工程は基本的に一品ものであり、派生開発である – ハードの設計工程でも定量的管理は夢見ているほど上手くいかない – ハードの設計も作業標準どおりにやれば上手くいく世界ではない – ハードの設計も品質が低い部品やプラットフォームを使わざるを得ないことはある – ハードの設計でも設計ミスなどの人間の誤りは発生する – ハードの設計でも大規模な製品はあるし、協力会社もオフショアも活用する – ハードの設計でも製品企画の段階から要求が固まっていることなど無い – ハードの設計でもほんの小さな設計ミスが大きな影響を及ぼすこともある • 大事なことは、 TQMが培ってきた知恵を原理原則まで分解して再構成し ソフトウェアに適用することであり、 TQMの技法をそのまま劣化コピーすることではない
- 34. © NISHI, Yasuharu34 日本のソフトウェア産業構造の特徴 •多重下請け構造のため誰が責任を取るのか分かりにくい – 請負契約が多いため、不具合を作り込んで修正する工数でも オカネがもらえるので、品質や技術力を上げるインセンティブが働かない • セットメーカやSIerが技術力を失ってきている – セットメーカやSIer、高次請けが工数管理しかしない（できない）ため、 協力会社に対する技術指導をできなくなってきている – セットメーカが自社のソフトウェア開発部門を企画機能を残して 子会社化・売却してしまい、ソフトウェア由来の革新的進化も ソフトウェア起因のトラブル解決もできなくなっている • ソフトハウスも技術力を失ってきている – もらった仕様書をプログラミング言語に翻訳するのが 仕事だと思っているソフトハウスも多い – 自社での技術向上や教育を行っているソフトハウスは 驚くほど少ない – 価格ではなく技術力で海外を選ぶケースも増えてきている
- 35. © NISHI, Yasuharu35 講演の流れ •自己紹介 • IoT時代で品質保証部門は何を考えていけばいいのか？ • 製造業のソフト開発部門の品質保証の問題点の例 • 役に立たないソフトハウスのQAの例 • ソフトウェアとハードウェアの違い • ソフト開発部門／ソフトハウスには品質保証戦略の立案が必要 • 品質保証アーキテクチャの設計 • ソフトウェアの品質管理の基本的アクティビティの概要 • まとめ • 補足：テスト開発方法論VSTePの概要とWモデル
- 36. © NISHI, Yasuharu36 ソフト開発部門／ソフトハウスには品質保証戦略の立案が必要 •いきなり自組織の問題点を洗い出そうとするとどうなるか – それはそうなんだけど、これではにっちもさっちもいかない » 「PCが遅いです」 » 「窓やトイレが汚いです」 » 「残業が多いです」 » 「給料が安いです」 » 「なんかみんな幸せそうに見えません」 • 品質保証戦略の立案が必要になる – ビジネスエッセンスの見直し – 経営に対して寄与する品質の把握：品質コンセプトパッケージング – 経営に対する品質の寄与の把握：品質ポジション分析 – 問題構造の分析とアクティビティの設計 – 伝播戦略の立案 • 品質保証戦略を練るために頭数は必要ない – QAに人を割いてもらえない、というグチは必要ない
- 37. © NISHI, Yasuharu37 品質保証戦略でないもの •そもそも品質（保証）に戦略などない – 「うちはみんな常駐なので、 全社としてのQA戦略なんて考えようがないのですよ」 • それは品質ではない – 「そもそも営業が無理な案件を受注していたのが品質低下の原因なので、 案件受注審査を厳しくするというのがQA戦略です」 • スローガン – 「品質こそ我が社のブランド、というのがQA戦略です」 • 目標数値 – 「5年で品質を倍にする、のがQA戦略です」 • 組織構造・体制図・権限 – 「これがISO9000用に描いた体制図で、QA戦略を表しています」 – 「品質保証部の地位や発言力の向上です」 • 機能を並べたもの – 「プロセス改善、レビュー、テスト、メトリクスがQA戦略の軸です」 • 単なる取り組みの列挙 – 「XDDPとHAYST法とAutomotive SPICEがQA戦略の構成要素です」 • 個別の取り組み – 「不具合率算出の精度向上のために○△分析をすることにしました」
- 38. © NISHI, Yasuharu38 ビジネスエッセンスの見直し •品質保証をするには、自分たちのビジネスが分かっていないといけない – 誰に何を売っているか – その質は何によって決まるか – その質をどこでどう確実に作り込んで確実に実証するか – 誰が喜ぶか • ビジネスエッセンスを矮小化しているソフト開発部門やソフトハウスが多い – 元請けに労働時間を売っている – 元請けに言われたことに従っている雰囲気を出せば文句を言われないし、 元請けが知りたくない細かいことを知っていると重宝される – 現場で個々のエンジニアが文句言わずに働けばよい – 文系的経営陣と営業部長が喜ぶ » 同じ現場でずっと文句言わずに黙々と働いているので、 営業はノークレームで新規開拓コストが少ないので喜ぶ » 経営は稼働損が少ないので喜ぶ • 矮小化されたビジネスエッセンスに従うと、 役に立たないQAが必然的に出現する
- 39. © NISHI, Yasuharu39 ビジネスエッセンスを見直す際のソフトハウスの例 •例えばこんな、同業他社より単価の高いソフトハウスがある – セットメーカーに「派生しやすさ」を売っている – 「派生しやすさ」の質は、エンジニアの設計技術力によって決まる – 自社内の教育によって設計技術力を上げ、 その技術力を活かして「派生しやすさ」を設計工程で作り込み、 質の高いレビューで不具合を防止している – 派生しやすいので製品開発速度が上がり手戻りコストが減るのでお客様が喜び、 単価が上がるので営業と経営が喜び、腕が上がるので技術も喜ぶ – こんな組織では、どんなQAが必然的に出現するでしょう？
- 40. © NISHI, Yasuharu40 ビジネスエッセンスを見直す際のソフトハウスの例 •例えばこんな、同業他社より単価の高いソフトハウスがある – 元請けに「カイゼン力」を売っている – 「カイゼン力」の質は、エンジニアのカイゼン技術力やカイゼン経験によって決まる – 自社内のカイゼン活動で技術力と経験を高め、常駐している客先でカイゼンを提案し、 PDCAを回してきちんと遂行し、客先のカイゼンのよいところを自社に持ち帰り 自社のカイゼンをカイゼンしている – カイゼンによって元請けの開発力が上がるので元請けの偉い人が喜び、 単価が上がるので営業と経営が喜び、カイゼンによって現場の雰囲気がよくなるので 元請けのエンジニアも自社のエンジニアも喜ぶ – こんな組織では、どんなQAが必然的に出現するでしょう？
- 41.
- 42. © NISHI, Yasuharu42 品質コンセプトの構築 •品質とは何か、をきちんと分かっている組織は極めて少ない – 欧米的な考え方： » 顧客の要求に対する合致度といった「開発の結果」である – 日本的な考え方： » 仕事の質，サービスの質，情報の質，工程の質，部門の質，人の質，システムの質， 会社の質など，これら全てを含めた「質」 • TQMを支える思想 – 品質第一の考え方、データ・事実に基づく管理、人間性尊重 – よく考えると、ものの「質」にだけ着目しているわけではない » 価値的側面、思考様式的側面、人間的側面の3つに着目している » JIS Q 9005 における質マネジメントの12原則：顧客価値創造、社会的価値創造、 ビジョナリーリーダーシップ、コアコンピタンスの認識、人々の参画、パートナーとの協働、 全体最適、プロセスアプローチ、事実に基づくアプローチ、組織及び個人の学習、 俊敏性（アジリティ）、自律性 • 「質」とは、多様な側面から成り立つ複合概念である – 結果的側面、価値的側面、思考様式的側面、行動様式的側面、 内部技術的側面、組織的側面、人間的側面など – 単一の側面にのみ着目しても上手くいかない • 自社にとっての品質というコンセプトの意味を掘り下げないといけない
- 43. © NISHI, Yasuharu43 品質コンセプトを構成する多様な側面と要素概念の例 •「質」を構成する多様な側面と要素概念を表すキーワードの例 – 結果的側面 » 結果不具合の少なさ、非機能特性、要求合致度など – 価値的側面 » 感性品質、顧客価値、顧客の顧客の価値、社会的価値など – 思考様式的側面 » （価値）創造、目的指向、全体俯瞰、融合、アーキテクチャ、事実に基づくアプローチ、 正味作業時間、本質、コアコンピタンス、水平展開、厳密性、納得感、分割統治など – 行動様式的側面 » カイゼン、学習、アジリティ、自律、チャレンジ、少ない手戻り、フロントローディング、 未然防止、標準化、正確さ、再現性など – 内部的技術的側面 » 欠陥の少なさ、設計のよさ、スジのよさ/グッドノウハウ、悪さのなさなど – 組織的側面 » 全員参加、一体感、気配り、パートナーとの協働、顧客巻き込み、リーダーシップ、 フォロワーシップ、上意下達など – 人間的側面 » 人間性、やりがい/働きがい、よろこび、ワクワク感、プライド
- 44. © NISHI, Yasuharu44 品質コンセプトパッケージング •自分たちにとっての「品質コンセプト・パッケージ」を形作る – 品質コンセプト・パッケージとは、自分たちにとっての「質」とは何か、を 「質」を構成する多様な側面から選び取ってパッケージングしたものである » 自分たちの組織コンセプトを表すことになる – 品質コンセプト・パッケージには、できるだけ多くの側面を含めるべきである – 要素概念には、容易には相容れないものがある » 例）アジリティと厳密性 – 容易に相容れない要素概念群をパッケージ化するためのグルー概念がある » 例）自律、本質、スジのよさ – グルー概念を軸にできるだけ多くの要素概念群をパッケージ化する際に、 自分たちのドメインや社風などと照らし合わせて取捨選択することが重要である » 何でもかんでも詰め込んでしまうと齟齬を押さえきれない – 軸となる少数のグルー概念や要素概念を用いて コンセプト・パッケージに名前をつけてやるとよい – 「質」というよりも、技術力などと表現する方がしっくりくる組織もある • 品質コンセプトパッケージの例 – カイゼン型組織、品質第一、アジャイル、コマンドアンドコントロールなど • 品質コンセプトが一貫していないと、品質保証アクティビティがチグハグになる – 自律的な小集団的カイゼン活動にコマンドアンドコントロール型の測定と管理をしたりする
- 45. © NISHI, Yasuharu45 品質ポジション分析：品質マネタイズ分析 •そもそも、「質」にカネを払いたいドメインで、 もしくは「質」にカネを払いたいお客様と仕事をしなければ、 「質」を高めるインセンティブは働かない – しかしそのドメインやお客様がカネを払いたい「質」というのは、 結果的側面だけとは限らない – そこで品質マネタイズ分析を行い、 「質」にカネを払いたいドメインやお客様なのかを判断する • まず、ドメインやお客様に 提供容易な「質」と提供困難な「質」に分ける – 提供容易な「質」： » 結果的側面、価値的側面 – 提供困難な「質」： » 思考様式的側面、行動様式的側面、内部的技術的側面、組織的側面、人間的側面
- 46. © NISHI, Yasuharu46 品質ポジション分析：品質マネタイズ分析 •次に、ドメインやお客様が「質」にカネを払いたいかどうかを判定し、 自分たちの品質保証戦略の方向性を決める – 払いたい → 自分たちが直接的に「質」の向上に投資する – 払いたくない → 1) “提供容易な「質」”をカネに換えるロジックを探し当てて、 直接的に「質」の向上に投資する 例） 高品質をブランドとして高単価を提示するために投資する → 2) “提供困難な「質」”をカネに換えるロジックを探し当てて、 直接的に「質」の向上に投資する 例） 行動様式的側面の販売： カイゼン力を売るために投資する 例） 内部的技術的側面の販売： バグパターンを売るために投資する → 3) 「質」以外にお客様がカネを払う特性へのロジックを探し当て、 間接的に「質」の向上に投資する 例） スピード向上を販売するために、自社のカイゼンに投資する • 品質保証部長は「質」の向上に投資してもらうために、 ロジックの意味やつながりを投資元（お客様や自社の経営陣）に きちんと説明し納得感を得なければいけない
- 47. © NISHI, Yasuharu47 品質ポジション分析：品質ファイブフォース分析 •お客様が「質」にカネを払ってくれるとしても、 「質」に対する投資が実を結びやすいドメインやお客様と、 そうでないところがある – 「質」の向上を促進するドメイン（やお客様）なのかどうかは、 少なくとも5つの要素の相互作用によって成り立っている » お客様がカネを払ってくれないところは「質」の向上がやりにくい » 「質」向上の技術を獲得しにくいところは「質」の向上がやりにくい » 多くの開発技術を必要とするところは「質」の向上がやりにくい » 開発技術の革新が激しいところは「質」の向上がやりにくい » 「質」以外の価値を重視するところは「質」の向上がやりにくい – そこで品質ファイブフォース分析を行い、 「質」に対する投資が実を結びやすいドメインやお客様かどうかを判断する » 「質」に対する投資が実を結ぶかどうかを、 「質」向上技術が開発技術との“競争”に勝利する、と捉える – 品質ファイブフォース分析は、 「質」に対する投資が実を結びにくいドメインやお客様に 品質マネタイズ分析ほど明確な戦略的指針を提示できないのが弱みである » 品質マネタイズの強化や、コミュニティの活性化、「待ち」といった感じになってしまう
- 48. © NISHI, Yasuharu48 品質ポジション分析：品質ファイブフォース分析 •「質」の向上を促進するファイブフォース – 顧客が「質」を高く買ってくれるか » お客様がカネを払ってくれるところは「質」の向上がやりやすい » ポーターモデルにおける買い手 – 「質」向上技術の獲得容易度 » 「質」向上の技術を獲得しやすいところは「質」の向上がやりやすい · フレームワーク、標準、コンサルタント、学術成果物、コミュニティが活発なところはやりやすい » ポーターモデルにおける供給業者 – 開発技術の数や難易度 » 開発技術が少ないところは「質」の向上がやりやすい · 状態遷移図とC言語でガリガリ作っているだけのところは相対的にやりやすい » ポーターモデルにおける競争業者（直接競合） – 開発技術の革新度 » 開発技術が枯れているところは「質」の向上がやりやすい · 最先端のWebサービスは相対的にやりにくい » ポーターモデルにおける新規参入業者 – 「質」以外の特性（スピードなど）をお客様が重視するか » 「質」以外の価値を重視しないところは「質」の向上がやりやすい · リリーススピードが命のところは相対的にやりにくい » ポーターモデルにおける代替品（間接競合）
- 49. © NISHI, Yasuharu49 問題構造の分析とアクティビティの設計 •不適切なビジネスエッセンスと一貫していない品質コンセプトによって 現場および組織の至るところで問題が発生している • 発生している問題や原因、原因の原因などの因果関係を 関係者で一緒に作成し、納得し、共感することを、QA活動の一歩目にする – 因果関係を図にする手法はたくさんある » 問題を直接記述するタイプ：SaPID by 安達賢二、フロー型なぜなぜ分析、N7（新QC7つ道具） » プロセスを記述するタイプ：PFD by 清水吉男、PNA（プロセスネットワーク分析） by 金子龍三 – それっぽいものをおざなりに作成するのが目的なのではなく、 関係者があーでもないこーでもないと議論したり不満をぶちまけたり 思いをぶつけあったりしながら、全員が腹落ち（強い納得）をして共感するのが目的である – 典型的なパターンは、やりっぱなしを示す一方向の図と、 様々な問題が鶏と卵のループ図になっているものである • 見直したビジネスエッセンスと一貫した品質コンセプトにしたがって、 品質アクティビティダイナミクスモデルを設計する – 複数のQAのアクティビティ（SPI、バグ分析、メトリクス、レビュー、テストなど）が 相乗効果を及ぼすようなQAアクティビティの全体像をデザインする – 継続的にQAがよくなるようにループ図が含まれていないといけない
- 50.
- 51. © NISHI, Yasuharu51 品質アクティビティダイナミクスモデリング •「質」の向上のための複数の取り組み（アクティビティ）が 相乗効果を生み出せない組織が多い – 多様な側面を持ち、多様な品質特性から構成される 「質」を単一のアクティビティだけで向上することはできない – 多くの組織では、複数の品質向上の取り組みを採用しているが、 アクティビティ同士がバラバラなため相乗効果を生み出せなかったり、 場合によっては打ち消し合ってしまってさえいる – 異なるアクティビティを同期させるためにスローガンや目標数値を示すものの、 バラバラなものはバラバラなままである • アクティビティ間の関係を俯瞰的に把握しデザインすることで、 多様な側面や品質特性を継続的に向上させる必要がある – 品質向上の様々なアクティビティが相乗効果や相互強化を行い、 持続的でムリ無く品質、競争力、経営をよくし続けていけるような ストーリーやモデルを構築する – 問題構造図を品質アクティビティに置き換えたモデルを使ってデザインする » 問題構造図法はアクティビティデザインの図法を持っていることがある » この講演では品質アクティブティダイナミクスモデリングを説明する
- 52.
- 53. © NISHI, Yasuharu53 よいQA戦略が構築・実践されている組織のモデル ひと 技術管理 品質 コスト 納期 プロダクト プロセス 品質文化 悪さの知識：リスク をフィードバック 悪さの知識：バグ をフィードバック チームモチベーション の向上 個人モチベーション の向上
- 54. © NISHI, Yasuharu54 品質アクティビティダイナミクスモデリング •アクティビティ間の関係を俯瞰的に把握しデザインすることで、 多様な側面や品質特性を継続的に向上させる必要がある – アクティビティダイナミクスモデルを記述して、俯瞰的に把握してデザインする » アクティビティ（取り組み）、アーティファクト（成果物）、リソースプール（能力蓄積）の３つで表す · 矢印の意味は因果関係的なものを意味するが、曖昧である » アーティファクトによってアクティビティ間の論理関係を補強し、 リソースプールによって（ポジティブ）フィードバック構造を見抜く – そのアクティビティによって何が起こるか、という 因果関係の流れをきちんと把握するのが目的である » １枚の図に時間的因果関係（ダイナミクス）を描き、全体像を把握する » アクティビティ間の因果関係に甘い見通しを立ててはいけないが、 例外ばかり考えて本筋を見失ってはいけない – ポジティブフィードバック構造が発生していると 持続的な「質」の向上を見込める戦略になる – クリティカル・コア（キラーパス、キーストーン）となる アクティビティがあると、模倣困難なモデルとなる » クリティカル・コアなアクティビティは割と非常識的である » モデルを部分的に（理解不足で）模倣すると失敗に向かう » バグパターン化戦略や、フルスタックモデル化戦略、 多能工化戦略はよい例だろう リソースプール （能力蓄積） アーティファクト （成果物） アクティビティ （取り組み）
- 55. © NISHI, Yasuharu55 バグパターン戦略のアクティビティダイナミクスモデル バグ分析による パターン化の促進 レビューの 改善 バグパターン ごとの 開発ROIの測定 バグパターン化への 投資の経営判断 開発ガイドラインの 作成若手への 教育内容の 明確化 バグ パターン 増加 品質向上活動への やる気向上 RvwCL/ DevGL 強化 投資増強の 経営判断 新たな バグ 短いサイクルで 因果関係の 明確な開発ROI 教育部門の コンテンツ増強 教育部門の ROI向上 開発者の実質的な 技術力向上の実感 手戻りの低減による 超過作業の低下と 前向き作業の増加 特定パターンの バグの撲滅 クリティカル・コア
- 56. © NISHI, Yasuharu56 フルスタックモデル化戦略のADモデル 設計のモデル化の 増強 モデル化された 設計 設計ノウハウ 向上設計不具合 低減 モデル化への 投資の経営判断 投資増強の 経営判断 開発ROIの 向上 設計ベーステストの 自動化 ソースコード生成 の自動化 実装不具合 低減 工数削減 モデル化 しにくい仕様 要求定義 工程の改善 よりモデル化 しやすい仕様 仕様不具合 低減 仕様のモデル検査 クリティカル・コア
- 57.
- 58. © NISHI, Yasuharu58 伝播戦略の立案 •適切なビジネスエッセンス、一貫した品質コンセプト、 相乗効果を生む品質アクティビティを組織全体に伝播させる必要がある – QA部門からの通達や押しつけの経路でも、部門成果を数値で他部門に示すことでもない – 関係者があーでもないこーでもないと議論したり不満をぶちまけたり 思いをぶつけあったりしながら、全員が腹落ち（強い納得）をして共感するのが目的である » 当然ながら時間も手間もかかるが、これをおろそかにすると全てが台無しになる » この過程を経てこそ、技術中心文化や品質文化が醸成される – 「説明無責任」のために説明することは厳に慎む » 説明無責任： 自分が責任を回避するために言葉を尽くして説明をすることであり、 そこに自分の仕事が皆の役に立つことを伝えるという意志は微塵もない • 伝播戦略には様々な仕掛けが必要となる – トップダウンとボトムアップだけでなく、ミドルダウンアップも必要である » QA部門は全社組織だからといって、全社を一律にカイゼンしようとしてはいけない – DD（Developer’s Delight）を向上するという姿勢を忘れない – カイゼンは「いまダメでも少しずつ変わっていけばいい」という赦しである » ダメなものやムダなものを少しずつよくしていきましょう、というのは明日から取り組める » しかしカイゼンはイノベーションのトレーニングでもある – 管理指標や人事施策は会社からの非言語的だが明確なメッセージであることを認識する » 稼働率から直行率へと管理指標を変えると、率先してダメやムダを取る行動様式になり、 稼働していない時にカイゼン活動や技術向上活動をするようになる – 「Fearless Changeの48のパターン」はよい意味で泥臭く参考にできる
- 59. © NISHI, Yasuharu59 カイゼンとイノベーション •カイゼンとイノベーションは対立するものか？ – 欧米かぶれの経営者や管理者は対立すると言ったりする – 現場でしっかりカイゼンしている技術者や管理者は対立すると感じない » 両方とも「変化」であり、その種類が異なるだけ » 対立すると言う人の多くは、改善の範囲が小さくイノベーションを銀の弾丸だと考えている • カイゼンとイノベーションを両立する組織が良い組織 – カイゼンは既存ベース、イノベーションはゼロベース » 変化の結果が目標を超えられるのならカイゼンでよく、 超えられないのならイノベーションにトライする · ゼロベース思考は確かにコツが必要なので、両者をバランスよくできる必要がある » いつでもイノベーションにトライできるように「仕込み」が必要 · 技術調査、可能性検討、小規模トライアル、社内情報交換など » カイゼンでもイノベーションでもビジョンが必要 – カイゼンはイノベーションのトレーニングでもある » カイゼンしない個人／組織は変化そのものを怖れるのでイノベーションなどできない » 変化するためには自分の技術の確立が必要：論文執筆などで自分の軸を定めていく » カイゼンできない組織は単に自己矮小化しているだけである
- 60. © NISHI, Yasuharu60 FearlessChangeの48のパターン • 全体に関わるパターン – Evangelist : エバンジェリスト(1) – Small Successes : 小さな成功(2) – Step by Step : ステップバイステップ(3) – Test the Waters : 予備調査(4) – Time for Reflection : ふりかえりの時間(5) • 序盤の活動に関わるパターン – Ask for Help : 協力を求める(6) – Brown Bag : ブラウンバッグ・ミーティング(7) – Connector : コネクター(8) – Do Food : 何か食べながら(9) – e-Forum : 電子フォーラム(10) – Early Adopter : アーリーアダプター(11) – External Validation : 外部のお墨付き(12) – Group Identity : グループのアイデンティティ(13) – Guru on Your Side : 達人を味方に(14) – In Your Space : 空間を演出する(15) – Innovator : イノベーター(16) – Just Do It : やってみる(17) – Just Say Thanks : 感謝を伝える(18) – Next Steps : 次のアクション(19) – Personal Touch : 個人的な接触(20) – Piggyback : 便乗(21) – Plant the Seeds : 種をまく(22) – The Right Time : 適切な時期(23) – Stay in Touch : 定期的な連絡(24) – Study Group : 勉強会(25) • 序盤の活動に関わるパターン（続） – Tailor Made : テイラーメイド(26) – Big Jolt : 著名人を招く(27) • 中盤以降の活動に関わるパターン – Corporate Angel : 経営層の支持者(28) – Dedicated Champion : 正式な推進担当者(29) – Early Majority : アーリーマジョリティ(30) – Guru Review : 達人のレビュー(31) – Hometown Story : 体験談の共有(32) – Involve Everyone : みんなを巻き込む(33) – Just Enough : ちょうど十分(34) – Local Sponsor : 身近な支援者(35) – Location, Location, Location : 場所重要(36) – Mentor : メンター(37) – Royal Audience : 謁見(38) – Shoulder to Cry On : 相談できる同志(39) – Smell of Success : 成功の匂い(40) – Sustained Momentum : 勢いの持続(41) – Token : トークン(42) • 抵抗と付き合うためのパターン – Bridge-Builder : 橋渡し役(43) – Champion Skeptic : 懐疑派代表(44) – Corridor Politics : 根回し(45) – Fear Less : 怖れは無用(46) – Trial Run : お試し期間(47) – Whisper in the General’s Ear : 将軍の耳元でささやく(48) Fearless Change： アジャイルに効く アイデアを組織に広めるための 48のパターン https://www.amazon.co.jp/ dp/462108786X
- 61. © NISHI, Yasuharu61 安直な標準化は組織を硬直化させ現場を不幸にする •標準化を“バラツキの低減”と考えると失敗する – ソフトウェア開発のような考える技術において、 バラツキの低減は低技術化と管理コストの増加を招く – バラツキの低減は内向きの標準化を指向するようになり、 組織全体が官僚的かつ非可視化に向かうリスクがある » 成功するメカの生産現場ではカイゼン活動のようなクリエィティブな活動を同時に行う – 標準化とは、よいやり方を知らないことによる失敗を減らすことである » 標準化はグローバル化とオープン化だと捉えた方がよい • よい標準化はグローバル化とオープン化であり、技術向上を牽引する – 最新の技術だけでなく、技術パラダイムや技術動向に馴染むことができる » 技術開発に必要なのはむしろ技術パラダイムや技術動向である – よいやり方だと説明しなくてはならないので組織に説明責任能力がつき仕事の可視化が進む – 社外のクリエィティブな人材と交流することで、 自組織の官僚性を批判し打破できるようになる » 技術者の社外活動率を測定してみると、 自組織がいかに内向きかが分かる • 外モジュラー・内インテグラルをいかに実現するかが重要である – 自社内だけで通用するツールや方法論で勝負できる時代ではない » 外モジュラー：オープンなツールや方法論を使うことで顧客や競争相手と 価値共創できるようになり、自社の技術力にレバレッジをかけることができる » 内インテグラル：オープンなツールや方法論を用いつつ、自組織で経験した 良い／悪い仕事をパターン化する習慣をつけて組織能力を継続的に高められる – オープン化によって仲間を増やし自社技術の存在感を増しつつ、 一朝一夕に真似できないカイゼン習慣によるパターン化で優位性を保つ ？
- 62. © NISHI, Yasuharu62 講演の流れ •自己紹介 • IoT時代で品質保証部門は何を考えていけばいいのか？ • 製造業のソフト開発部門の品質保証の問題点の例 • 役に立たないソフトハウスのQAの例 • ソフトウェアとハードウェアの違い • ソフト開発部門／ソフトハウスには品質保証戦略の立案が必要 • 品質保証アーキテクチャの設計 • ソフトウェアの品質管理の基本的アクティビティの概要 • まとめ • 補足：テスト開発方法論VSTePの概要とWモデル
- 63. © NISHI, Yasuharu63 品質保証アーキテクチャの設計 •品質保証をするには、自分たちのビジネスが分かっていないといけない – 誰に何を売っているか – その質は何によって決まるか – その質をどこでどう確実に作り込んで確実に実証するか – 誰が喜ぶか • 無根拠型プロセス・メトリクス依存QAの問題点は、 「その質は何によって決まるか」 「その質をどこでどう確実に作り込んで確実に実証するか」 が不明確な（無根拠）なことである • そこで品質保証アーキテクチャを設計する – 「その質は何によって決まるか」をQA観点モデルによって明らかにする – 「その質をどこでどう確実に作り込んで確実に実証するか」とその全体像を アシュアランスパイプライン（保証の網）として設計し、 それを支えるテックシェルフ（技術の棚）を構築し運用する – QAアーキテクチャに従ってプロセスとメトリクスを導出すると、 そのプロセスやメトリクスによって品質がどう上がって組織が理想に近づくか、 の根拠を示すことができるので、現場が幸せになっていく
- 64. © NISHI, Yasuharu64 QA観点モデル：何の質を保証すればよいのか？ •IoT化における品質保証とはなにか？ – 結局ものづくりなのだから品質保証は不変であるのでいままでと同じことをすればよい、 というのは自己矮小化に基づく誤解である • IoT特有の固有技術や品質特性だけでなく、 UXやユーザ感情、SDLにまで広げなくてはならない – IoT特有の固有技術や品質特性を考える必要がある » ソフトウェア、ネットワーク » セキュリティ・プライバシー、相互接続性 » ビッグデータ、AI／ディープラーニング – UX（ユーザエクスペリエンス）やユーザ感情にまで 品質保証の扱う範囲を広げなくてはならない – プラットフォーム化や顧客共創／SDL（サービスドミナントロジック）といった ビジネスの質にまで品質管理の扱う範囲を広げなくてはならない • そのために組織のアジリティやスピード化、 自己変化頻度・速度、改革性も高めねばならない – IoT化に合った品質コンセプトの改善・再構築が必要となる
- 65. © NISHI, Yasuharu65 QA観点モデル •直接品質を保証するために プロダクトやサービスにどのような観点が必要なのか、 をすべて書き出して整理したものがQA観点モデルである – レビューのチェックリストやテストの大中項目などは部分的なQA観点モデルである – ISO/IEC25000sの品質特性もQA観点モデルである – バグ分析の結果もQA観点モデルである – プロセスや組織のよさやメトリクスは、直接品質を保証しないのでQA観点モデルに入れない • IoT時代になって、多様なQA観点が求められるようになってきた – 機能仕様だけでなく非機能仕様も考えないといけないな » 特にセキュリティや相互運用性は大事な気がする – IoTになってソフトウェアの仕様だけを考えるような自己矮小化をしていられなくなってきた » 使い心地、面白さ、安心などといったユーザ感情やUX（ユーザエクリペリエンス） » 顧客共創、サービスドミナントロジック、プラットフォーム特性 • 適切なQA観点モデルを描くためには、 製品やサービスを提供する開発部門や顧客の ビジネスエッセンスの見直しを一緒に行う能力が必要となる – そこで自社のビジネスエッセンスの見直しの経験が活きてくる
- 66. © NISHI, Yasuharu66 アシュアランスパイプライン（保証の網） •開発・検証の工程ごとに、 どのQA観点を作りこんでどのQA観点を検証したかを明示する – ネットワーク図のようになるので、保証の網とも呼ばれる – 工場の生産工程におけるQC工程表にあたると考えてもよい • QA観点と工程との関係を上手に割り当てることで、 特定の意図のQA観点だけを含んだ工程をつなげた アシュアランスパイプラインを構築することができる – QAが自動化できる観点の工程だけのパイプラインを作ると、 CI/CDに追随させて超高速で自動化品質保証できるQA観点と、 手動で品質保証しなくてはならないQA観点が区別できるので メリハリのついたQAが可能になる – 全製品に共通なQA観点のパイプラインから仕向地ごとのパイプラインに分岐させることで グローバルなQA体制の全体像を設計することができる
- 67. © NISHI, Yasuharu67 アシュアランスフロー •アシュアランスフローとは、 どのQA観点をどの工程でどのように作り込み、 どの工程でどのように検証したかを記述したものである – QA観点ごとにアシュアランスフローとメカニズムを明らかにして、 その観点の品質保証を確実にしていく » どう作り込むか／入り込んでしまうか、どう検証するか、のメカニズムを明らかにする » 工程ごとの作業内容や採用技術、帳票の形式、ツールの選定などが すべてアシュアランスメカニズムに基づいたものになると、 意図不明な作業の押しつけによるやらされ感が低減し、 プロセスメトリクスが機能するようになってくる 工程P1 QA観点V （作り込み） 工程P2 QA観点V （検証）
- 68. © NISHI, Yasuharu68 アシュアランスパイプライン •アシュアランスパイプライン上で工程とアシュアランスフローを整理し、 メカニズムがきちんと機能しているかを測定して管理し、 プロセスをカイゼンしていく – 自動化によって個々のフロー要素を短縮し、パイプラインをスピードアップする – アシュアラビリティ・デザインを行って検証側のフロー要素を短縮する – フロントローディングによって作り込み側のフロー要素を短縮する／無くす – フロントローディングによってフローの拡散を防ぎ、全体の工数を減らす – 以上のようなことが可能になるように、工程へのQAフローの割り付けをきちんと設計する
- 69. © NISHI, Yasuharu69 テックシェルフ（技術の棚） •アシュアランスパイプラインを支える技術のマネジメントにも QAは大きく関わらなくてはならない – プロセスは手順だけではなく、技法や方法論もツールも含まなくてはならない • ドメイン技術、要素技術、エンジニアリング技術、マネジメント技術と QA観点との組み合わせと抽象具体の関係で表現することができる – 「お勉強」の証明ではなく、自分たちで試してみて上手くいったものを棚に載せる • ポジティブナレッジとネガティブナレッジのバランスを取る – ネガティブナレッジは多く場合開発者は好きではないので、 QA部門が積極的に抽出・蓄積しないときちんと貯まらない • バッドノウハウだけでなくグッドノウハウを貯めるようにする – バッドノウハウは通常「業務知識」として自然に伝承されるが、 その製品や部品、プラットフォームが変わると不要になる » 気をつけないとテックシェルフがバッドノウハウだらけになるが、 それは技術力が低いということを意味する – グッドノウハウは多くの場合、一般的原理と支配法則に分けられる » グッドノウハウから支配法則を分離できると、統合型QMSに必要なテックシェルフに近づく » RCAやバグ／故障解析はテックシェルフの構築に重要だが、その支配法則に詳しくない分析者は たとえ分析経験が豊富でも曖昧な分析をしてしまうが見抜くのは難しい
- 70. © NISHI, Yasuharu70 ポジティブナレッジとネガティブナレッジを整理する •ポジティブナレッジ（良さの知識）だけでなく ネガティブナレッジ（悪さの知識）の整理がQAには重要 – 良さの知識：どうやればうまくいくか » 参照アーキテクチャ、デザインパターン、開発プロセスなど – 悪さの知識：どうやるとダメになるか » バグのパターン、リスクのパターンなど – 良さの知識は自然と蓄積されていくが、 それだけだとマニュアル化を導き “考えないエンジニア”を生み出す危険性がどんどん高まっていく – 悪さの知識は自然と蓄積されていかないので、 品質系の組織が主導して蓄積していかないといけない » 悪さの知識はレビューの指摘項目やテストケースの質を向上させる » 「品質の作り込み」とは、最初から良いことばかりをすることではなく、 悪さの知識をフィードバックして最初から気をつけて作ることである
- 71. © NISHI, Yasuharu71 グッドノウハウとバッドノウハウを区別する •グッドノウハウとバッドノウハウを区別する – バッドノウハウ：知らないと開発できないが本来知る必要のない制約事項 » 計算機を使っていると、何でこんなことを覚えないといけないのだ ろうか、とストレスを感じつつも、そ れを覚えないとソフトウェア を使いこなすことができないためにしぶしぶ覚えなければならない、とい った類いのノウハウは多い。そうした雑多なノウハウのことを、本来は知りたくもないノウハウという意 味で、私はバッドノウハウ と呼んでいる。…バッドノウハウがはびこる大きな理由は、ソフトウェアの開 発者に使いやすさに対するセンスを欠如していたり、場当たり的な機能拡 張が度重なって行われた り、単に開発の手を抜くために実装が楽なように仕様を決めてしまうといったところにあるが、別の理 由によ るものも根深いと私は考えている。それは、そういった使いにくいソフトウェアを使いこなす事 に対して、「奥が深い」といって喜び を見出す「奥が深い症候群」によるものである。 （高林哲） – グッドノウハウ：本質的でセンスのよい汎用的な技術や考え方 – 自分たちの技術がグッドノウハウかバッドノウハウかを判別し、 グッドノウハウを育てる文化を醸成する » 仕事を覚えるということがバッドノウハウの蓄積を意味している組織は実に多い » バッドノウハウにまみれたエンジニアは潰しがきかず、組織が硬直する » グッドノウハウやバッドノウハウを端的に表す方言があるとよい
- 72. © NISHI, Yasuharu72 ポジティブナレッジ×グッドノウハウの例：富士通の７つの設計原理 ①単純原理 -可能な限りシンプルにすること ②同型原理 - 同じものは同じように実現すること - 例外を設けないこと ③対称原理 - 対称にすること - 対になるものは対にすること - バランスを崩さないこと ④階層原理 - 階層関係、主従関係、前後関係、 本末関係などを崩さないこと - 層に穴を空けないこと ⑤線形原理 - 特異点や閾値、組み合わせによる 特殊な振る舞いが無いこと ⑥明証原理 - ロジックは直感的に 分かりやすくすること - 分からないものやふるまいがないこと - おかしなものを受け取らない、 先に送らない、無視しない、 勝手に処理しないこと ⑦安全原理 - 必然性のないところや 曖昧なところは安全サイドに 設計しておくこと
- 73. © NISHI, Yasuharu73 ネガディブナレッジ×グッドノウハウの例：不具合モード分析 •ピンポイント型（検出型）V&Vや探索的V&Vでは、 バグを分析してパターン化することが技術的基盤となる – しかしバグ分析を上手にできている組織は意外に少ない » 何かしらの分析結果は出るが、役に立たせることができない » そもそも現象なのか原因なのかなど、何を分析しているか分かっていない場合も多い » 責任追求型の裁判的犯人捜しの分析会議は隠蔽を生むだけで何もメリットは無い – バグ分析が下手な組織は、なぜなぜ分析やRCA（根本原因分析）も下手である – 同様にFMEAやFTAも下手である » 特にソフトの故障モードをきちんと理解して分析し蓄積している組織はとても少ない · 故障モードが蓄積できていないと、DRBFMは変化点解析に成り下がってしまう » モジュールの機能不動作・誤動作を故障モードと捉えても上手にパターン化はできない · 演算間違いや遅延という故障モードは役立つバグのパターンではない – バグのパターンをフィードバックしてフロントローディングして開発プロセスを 改善したり、教育組織に展開して教育コンテンツを改善する必要がある • 不具合が作り込まれやすい仕様・設計・コードのパターンを きちんと分析して蓄積する技術を確立する必要がある – 不具合が作り込まれやすいコードのパターンはMISRA-Cなどから得られる » 設計のパターンの蓄積は設計力に依存し、仕様のパターンの蓄積はより難しい
- 74. © NISHI, Yasuharu74 ネガディブナレッジ×グッドノウハウの例：不具合モード分析 •不具合が作り込まれそうな「弱点」を特定するように、 よく発生する過去のバグを分析しパターン化すると、 ソフトウェア開発のための質のよい故障モードが得られる – 当該工程だけでなく、後工程でバグを作り込む原因となりうる部分もパターン化する • 開発者がどう間違えるかに着目して 開発者が陥りやすい「罠」をパターン化する – 人間の思考の誤謬と、誤謬を引き起こしやすいパターンをセットで明らかにする » 例）後から追加された例外的な仕様は、設計漏れを引き起こしやすい » 例）優先順位の表現で1（高い）～5（低い）と5（高い）～1（低い）が混在すると混同しやすい » 例）異なるサブシステムでリソースの確保・解放を行うとリークしやすい » 例）「備考」にはバグが多い – 似たようなパターンのバリエーションをツリー状に整理する • 「共感」を軸にしてバグの分析を行う – 適切なパターン化ができた瞬間は、分析会議の参加者が 「その罠にはみんなひっかかるよね」と共感するようになる – バグを作り込んだ人という扱いではなく、罠の情報を提供してくれる人として 尊敬を前面に出すと、前向きの会議になって共感しやすくなる
- 75. © NISHI, Yasuharu75 不具合モードで頻発する不具合を未然防止する •派生開発・SPLEでは特定の種類のバグが 派生品をまたいで、かつ異なる機能で頻発することがある – 母体や開発プロセスに不具合モードもしくは不具合モードの芽があるため、 派生品を開発する度にバグを作り込んでしまう » 不具合モード「例外」：法規対応、多仕向地、機能複合型製品 » 母体の設計にそもそも難がある » 仕様書群の構造そのものに不具合モードがあったりもする – 母体の不具合モードに着目してテストを設計したり、 最初から気をつけて開発することで頻発バグを効率的に防ぐことができる
- 76. © NISHI, Yasuharu76 ネガディブナレッジ×グッドノウハウの例： ソフトウェアHAZOPのためのより詳しいガイドワード 強度強い 弱い 時期 早く 遅く 数量 多い 少ない 時間 長く 短く 増加 減少 間隔 広く 狭く 余分 不足 期間 長く 短く ある ない ゼロ 順序 さきに あとで 種類 多種 小種 同時に 並行に 規模 大きい 小さい 早く 遅く 距離 遠い 近い 逆転 反復 挿入 速度 速い 遅い タイミング 早く 遅く 高速 低速 拡張 広く 狭く 緩 急 多く 少なく 設定 許容 禁止 頻度 多く 少なく 必須 任意 高く 低く 範囲 長い 短い 程度 いつも たまに 上限 下限 回数 多く 少なく 広い 狭い 接続 つなぐ 切り離し 切り替え 最大限 最小限 方向 上へ 下へ 頻度 高い 低い 負荷 高い 低い 多い 少ない 超過 不足 限界 金額 大きい 小さい 位置 高く 低く 遠く 近く 鈴木三紀夫さん （リコーITソリューションズ）、 秋山浩一さん （富士ゼロックス） がご作成
- 77. © NISHI, Yasuharu77 ネガディブナレッジ×グッドノウハウの例： ソフトウェアHAZOPのためのより詳しいガイドワード 原則例外 正常 異常 準正常 全体 部分 通常 非通常 全部 一部 通常 例外 代替 主 従 定期 臨時 正 誤 通例 異例 常例 無事 有事 平時 非常時 緊急時 公正 不正 定常 可変 任意 強制 尋常 非常 基本 詳細 主要 一般 特別 完了 未完 普通 特殊 有効 無効 並 特異 起動 停止 鈴木三紀夫さん （リコーITソリューションズ）、 秋山浩一さん （富士ゼロックス） がご作成
- 78. © NISHI, Yasuharu78 和風のガイドワード：「」 鈴木三紀夫さん（リコーITソリューションズ）がご作成
- 79. © NISHI, Yasuharu79 不具合分析のアンチパターンと効果の薄い対策 •Vaporization（その場限りの簡単なミスとして片付けてしまう） – コーディングミス： スキルを向上させるよう教育を行う – 考慮不足： しっかり考慮したかどうかレビュー時間を増やし確認する – うっかりミス： うっかりしていないかどうかレビュー時間を増やし確認する • Exhaustion（不完全な実施や単なる不足を原因としてしまう） – しっかりやらない： しっかりやったかどうかレビュー時間を増やし確認する – スキル不足： スキルを向上させるよう教育を行う – 経験不足： 経験を補うためにスキルを向上させるよう教育を行う • Escalation（上位層に責任を転嫁してしまう） – マネジメントの責任： トップを含めた品質文化を醸成する • Imposition（外部組織に責任を転嫁してしまう） – パートナー企業の責任： パートナー企業を含めた品質文化を醸成する • Culturalization（文化的問題に帰着してしまう） – 品質意識／品質文化の欠如： 全社的な品質文化を醸成する
- 80. © NISHI, Yasuharu80 講演の流れ •自己紹介 • IoT時代で品質保証部門は何を考えていけばいいのか？ • 製造業のソフト開発部門の品質保証の問題点の例 • 役に立たないソフトハウスのQAの例 • ソフトウェアとハードウェアの違い • ソフト開発部門／ソフトハウスには品質保証戦略の立案が必要 • 品質保証アーキテクチャの設計 • ソフトウェアの品質管理の基本的アクティビティの概要 • まとめ • 補足：テスト開発方法論VSTePの概要とWモデル
- 81. © NISHI, Yasuharu81 ソフトウェアの品質管理の基本的アクティビティの概要 •プロセスサイドの主なアクティビティ – 品質戦略の立案と推進 – 開発プロセスの構築・評価・改善 – リスクマネジメント • プロダクトサイドの主なアクティビティ – 測定・メトリクス – V&V（レビュー・テスト） – バグの分析
- 82. © NISHI, Yasuharu82 開発プロセス評価・改善 •ソフトウェアプロセス改善（SPI）には、 実態駆動型改善とモデル駆動型改善がある – 実態駆動型改善： 実際の問題を解決し続ける改善スタイル – モデル駆動型改善： モデルとの差異を埋める改善スタイル » 例）CMM/CMMi、ISO/IEC15504/33Ks/AutomotiveSPICE、ISO9000s？ • 実態駆動型改善を適切に進めるには、 問題を適切に捉えて改善するという能力が必要 – PDCAやDMAIC、KPTなどの改善サイクルがあると進めやすい • モデル駆動型改善には注意が必要 – 改善モデルを軸に、あるべき姿と現状とのギャップ分析を行い、 そのギャップを埋めるように達成度を定め改善していく方法 » PRM（プロセス参照モデル）にPAM（プロセス評価モデル）を組み合わせて改善する » モデルに近づけるのが改善だ、というのがモデル駆動型改善の基本思想であるので 改善を進めても現場の問題が解決されない罠に陥りやすい – レベル５が継続的改善のスタートであり、レベル３はかえって硬直化を招きやすい » 定義したプロセスをずっと続けるという思想は監査的でありTQM的ではない
- 83. © NISHI, Yasuharu83 SoftwareEngineering -83- PAM／プロセス成熟度レベル（SW-CMMの例） • レベル１（初期レベル） – プロセスが管理状態に達していない段階 • レベル２（反復可能レベル） – 厳格なプロジェクト管理を行うことにより、 類似のプロジェクトを反復できる安定したプロセスに達している段階 • レベル３（定義されたレベル） ＩＳＯ９０００相当 – 組織としてソフトウェアのプロセスが定義されている段階 • レベル４（管理されたレベル） – ソフトウェア組織が包括的にプロセスを測定・分析できる段階 • レベル５（最適化するレベル） – プロセスの永続的な改善と最適化の基盤ができている段階
- 84. © NISHI, Yasuharu84 ソフトウェアの品質管理の基本的アクティビティ •プロセスサイドの主なアクティビティ – 品質戦略の立案と推進 – 開発プロセスの構築・評価・改善 – リスクマネジメント • プロダクトサイドの主なアクティビティ – 測定・メトリクス – V&V（レビュー・テスト） – バグの分析
- 85. © NISHI, Yasuharu85 測定・メトリクス •「計測できないものは制御できない」（ケルビン卿） – 本当にこう言ったのか？これはソフトウェア開発でも正しい示唆なのか？ – ソフトウェアは基本的に計測できないのに、どうすればいいのだろう？ » 生産性のように定義がはっきりしないメトリクスを測ろうとして不幸になる組織すらある – 統計的推測をしようとするとプロセスが固定化し改善を阻み形骸化することが多い • 自組織の開発のメカニズムに合ったメトリクスを使うべきである – ソフトウェアのメトリクスには、大きく分けて3種類ある » （経営的要求に合わせて）何も考えずに測定した結果系のメトリクス · 全体のバグ率や生産性など » 実測したデータに合うように統計式を作ったメトリクス · 式の中に何乗とか妙な項がある » ソフトウェア開発のメカニズムに合わせて（を仮定して）統計式を作ったメトリクス · バグのパターンごとの出現率と対策コスト、手戻り率（直行率）など – 誰か他の人が考えたメトリクスがそのまま自組織に適用できることはほぼ無い » もし適用できるとしても、調整項の効果の方が大きかったりする – GQM：Goal-Question-Metrics（意図－質問－メトリクス）のように メトリクスの意図やメトリクスの表すメカニズムをきちんと考える必要がある » すなわち、外部で定義されたメトリクスを探し回るよりも、自組織で何が起きているか、 何が問題でどう解決しようとしてるのかを、トコトン考える方が先でありはるかに実り多い
- 86. © NISHI, Yasuharu86 V&V •レビューやテストなど、プロダクトサイドの品質評価を V&V（Verification & Validation）と呼ぶ – V&Vは主に、レビューとテストから構成される – V&Vは主に、バグなどの要改善点を見つけるのが目的である » レビューという活動自体にV&V以外の目的を与えている組織がほとんどではある – 基本的には、プログラムを実行して行うのがテストであり、 実行せずに行うのがレビューである » プログラムを実行しないものも静的テストと呼ばれたり、 テスト設計時にバグを見つけることもあるので、厳密な境界線ではない
- 87. © NISHI, Yasuharu87 V&Vの大事な考え方：V&Vの違い・網羅とピンポイント •VerificationとValidationの違い – Verificationは入力成果物と出力成果物の一致確認であり、 Validationは目的達成評価である • 網羅とピンポイント／保証型と検出型 – V&Vには網羅とピンポイントという2つの相反する目標がある » 2つの相反する目標のバランスを取るのがとても重要である – 網羅とは、V&Vしなければバグは見つからないという考え方の基に、 漏れなくV&Vを行うことで動作実績を積み上げる「保証型」のV&Vである » 何も考えずにひたすらV&Vに時間を費やすことは、網羅とは呼ばない – ピンポイントとは、全てはV&Vできないので大事なところから行うという考え方の 基に、少ない手間でたくさん危険なバグを検出する「検出型」のV&Vである » バグの多そうなところや、大事そうなところからV&Vを行う
- 88. © NISHI, Yasuharu88 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の設計を行うと改善しやすい » テスト（ケース）の設計はよく知られているが、 レビューケース（レビューの指摘項目）の設計も重要である · レビューケース設計のガイドとしてのチェックリストの設計も同様に重要である » レビュー設計に着目せずにレビューを改善すると、会議術の改善以上にはならない
- 89. © NISHI, Yasuharu89 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ではない
- 90. © NISHI, Yasuharu90 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対象物の種類や粒度、順序関係などによる分類 · 要求レビュー、仕様レビュー、アーキテクチャレビュー、詳細設計レビュー、コードレビュー、 単体テスト、結合テスト、システムテストなど » V&Vタイプ：V&Vの意図や観点、技術などによる分類 · 割込処理レビュー、ウォークスルー、インスペクション、負荷テスト、環境変更テスト、 性能テスト、形式検証、自動テストなど » V&Vサイクル：類似のV&Vコンテナを繰り返す際の分類 · やり直しレビュー、回帰テストなど » テストの役割は割と明確だが、レビューの（副次的）役割は多岐に渡る
- 91. © NISHI, Yasuharu91 レビューの（副次的）役割 •確認の役割 – 仕様との一致 – 標準との一致 – 意図した役割（顧客満足？） • 指摘の役割 – 不具合の指摘 – 弱点の指摘 – 設計考慮事項の指摘 – リスク評価・不具合影響評価 • 設計改善の役割 – よりよい設計の提案 – 問題解決策の提案 – 代替案・回避策の提案 • マイルストーンの役割 – 進捗の報告 – 工程完了の判定 • コミュニケーション・合意の役割 – 開発者同士 – 開発者とリーダ・マネジャー – 開発チームとステークホルダー – 開発者と顧客 • 教育の役割 – 技術の伝達 – 良い設計を見せる – 不具合指摘の着眼点を伝える – トレードオフのバランスを伝える • 監査の役割 • 作業改善・プロセス改善の役割 – 原因の検討と改善 – 申し送り事項（簡易設計ガイドラ イン）の作成と周知徹底 – 次回プロジェクトへの改善
- 92. © NISHI, Yasuharu92 品質や信頼性の高いシステムに対するテストの誤解 •品質や信頼性の高いシステムを開発している組織でも誤解は多い – 規格に書かれている技術を単に使用して、 ハザード解析や要求仕様を“実確認”するのが安全性のテストである – テストプロセスは開発プロセスに埋め込まれているもので、 テスト計画でテスト仕様を決めて実行し、 単体/結合/システムテスト・安全要求検証と進めるが普通のテストプロセスだ – テストはとにかく工数がかかるから自動化は難しい – 安全性は信頼性や品質とは別だから、安全性を高める作業を純増させるべき であり、品質改善サイクルなどとは関係ない – テストは開発の従属物だから、テストの改善モデルなんて意味が無いし、 テストで開発が改善するわけがない – テストは単価の安い外注に頼みたいから、上流から参加させたくない – 悩んでいる組織は、新しい方法を外部から導入して改革しなくてはいけない – バグの分析は簡単だ – ソフトウェアのFMEAやDRBFMで故障モードは気にしなくていい
- 93. © NISHI, Yasuharu93 テストの大きな敵：丸投げ •丸投げとは、何を委託しているかもよく分からず、 委託先が何をしているかもよく分からずに、 仕事を委託することである – 丸投げは、作業委託量の多さではなく、「納得度」の低さを意味している – 発注側メーカーの納得度が低いと、 残念ながらいつしか委託先ソフトハウスも質の低い仕事をするようになる » 別に委託先SHだって発注側メーカーを出し抜いてやろうと意志があるわけではない » 発注側メーカーに納得させる必要の無い仕事は、 委託先ソフトハウス自身の納得度も低いため、質の低い仕事になりやすい » 納得度の低い仕事でオカネをもらうには「頑張りました」というしかなく、 その説明を一度始めてしまうと二度と納得度は上がらない » 酷い委託先ソフトハウスに当たると、納得度の低さという足元を見られ、 スキルの低いエンジニアを割り当てられ品質トラブルが多発したり、 単価を引き上げられたりしてしまう 丸投げの本質は、納得感の欠如である
- 94. © NISHI, Yasuharu94 テストは何のために行うのか ×スタンス１：テストとは行動である – 「テストでは何も証明できない、ただバグを見つけるだけである」 » 行動の内容と結果だけを提示する · 何時間テストしました、何千件テストしました » 見つけたバグが全てだと思うあまり、探索型などという言葉を隠れ蓑にして “食い散らかす”だけのテストを導いてしまったりする × スタンス２：テストとは説明である – 「テストとは仕様通り動くことを実証することである」 » 行動の根拠や行動の妥当性も提示する · この仕様書の網羅性は100％です » 自分達はこれに従ってこれをやりました、だから問題はないでしょう、 という“説明無責任”のテストを導いてしまったりする ○ スタンス３：テストとは納得する/してもらうことである – 納得する/してもらうために技術と知性（とまごころ）を尽くして初めて 説明責任を果たすことができる » 自分が納得できる/相手に納得してもらいやすいように理解しやすく提示する · これがテストの全体像なんですが、いくつか選択肢やメリットデメリットがあるので、 一緒に検討していきましょう
- 95. © NISHI, Yasuharu95 品質や信頼性の高いシステムに対するテストの進め方 •安全性、信頼性、品質を保証することが必要 – 規格認証や規制と関係が深いため、 説明責任を果たせる包括的かつ緻密なテスト設計が必要 » テスト観点・NGT/VSTeP • 説明責任を果たしやすいテストプロセスも必要 – 人間が頭を使ったりノウハウが必要な部分と、 機械的／自動的に行う部分とが分離され、 グローバル開発にも適した独立なテストプロセスモデルが必要 » VSTeP、ISO/IEC/IEEE29119シリーズ、テスト自動化（KDT） • 派生開発を前提としたテストが必要 – ワンオフのテスト設計やテストプロセスではなく、現状のテストを活かしながら、 継続的にテストを改善し、かつテストによって開発を改善することで、 派生開発の度に設計力やプロセス力を成長させられる技術やプロセスが必要 » Reverse VSTeP、テスト改善モデル（ISO/IEC33063、TPI、TMMi）、 不具合モード、Wモデル
- 96. © NISHI, Yasuharu96 モダンなソフトウェアテストのパラダイム •クラシックなソフトウェアテストのパラダイム – テストは実施するもので、検算のようなものである。だから簡単だ。 – テストはテストケースを実施してバグを見つけるものである。 – テストはバグを見つけるものだ。だから仕様への適合が第一だ。 – テストはソースコードベースのホワイトボックスと ユーザ・仕様ベースのブラックボックスの２つがある。 – テストは下流でバグを見つける活動である – テストケース数は爆発するので網羅できない • モダンなソフトウェアテストのパラダイム – テストは設計するもので、分析も必要である。だから難しくクリエイティブだ。 – テストは実施でもバグを見つけるが、設計の過程でもバグを見つける。 – テストは製品・システムの総合的な品質を評価するものである。 だから「よいシステムとは何か」を分析することが第一だ。 – ホワイトとブラックを上手く融合したグレーボックステストが重要だ。 そしてコードやユーザ、仕様、バグなどのテスト観点の考慮が重要だ。 – テストは上流から開発と並行してバグを見つけていき、バグを予防する活動である – テストケース数が爆発しないよう、どこまでどう網羅するかを検討するのが重要だ
- 97. © NISHI, Yasuharu97 まとめ •自己矮小化から脱して • ビジネスの質の向上に貢献するために • TQMが培ってきた知恵を原理原則まで分解して再構成し • 統合型QMSの構築を目指す
- 98. © NISHI, Yasuharu 胸を張って品質立国日本を再興させましょう！ 電気通信大学西 康晴 http://qualab.jp/ Yasuharu.Nishi@uec.ac.jp
- 99.
- 100. © NISHI, Yasuharu100 CPM法（コピー＆ペースト＆モディファイ法）の悩み •CPM法とは – 仕様書の文章をコピーしてExcelにペーストし、 語尾を「～する」から「～すること」に変更することで テストケースを作成する方法 – 複数のテストケースをコピー＆ペーストし、 置換コマンドを使って機能名などをまとめて変更することで テストケースを増殖する方法 • CPM法の問題点 – テストケースがどんどん増殖していき、収集がつかなくなる – テストケースの趣旨が分からないためテストの終了判定ができず、 頑張って徹夜して消化できたところまでで勘弁してもらうことが常態化する – 何のために存在しているのか分からないテストケースが 派生開発の度に増えていき、怖くて誰も減らせない
- 101. © NISHI, Yasuharu101 固定３レイヤー法の悩み •固定３レイヤー法とは – テストケースを大項目・中項目・小項目のフォーマットに従って設計していく方法 大項目 中項目 小項目 テストケース 機能レベル１ 機能レベル２ 機能レベル３ 機能レベル１０ 機能レベル１ 機能レベル８ 機能レベル９ 機能レベル１０ 機能 環境 データ 機能＋環境＋データ 機能 データ GUI 機能＋データ＋GUI 機能 データ 前提条件 機能＋データ 機能 状態 イベント 状態＋イベント テストカテゴリ 機能 データ 機能＋データ 組み合わせ 機能① 機能② 機能①×機能②
- 102. © NISHI, Yasuharu102 固定３レイヤー法の問題点 •詳細化のレベルが飛んでいる・揃わないので網羅できない – レイヤー間の距離が大きくなるほど漏れが発生しやすい – エンジニアによって偏った詳細化をしてしまう – テストケース群ごとに詳細化の偏りにばらつきがある • 異なるテスト観点の組み合わせを詳細化だと考えてしまう – 機能＋環境＋データ、機能＋データ＋GUI • テスト設計で考慮する必要の無いものが入ってしまう – 機能＋データ＋前提条件 • 異なるテスト観点にぶら下げているので網羅できない – 機能＋状態＋イベント » 本来は状態遷移網羅をすべきであり、機能網羅で代用すべきではない • テスト観点の詳細化を行わない – テストカテゴリ＋機能＋データ » 負荷にも色々あるはず．．．。 • 組み合わせテストを押し込んでしまう – n元表を使うべきである
- 103. © NISHI, Yasuharu103 よくあるテスト技法（境界値テストなど）の悩み •よくあるテスト技法とは – 「何をテストすればいいか」が分かっているという前提で、 具体的なテスト条件を挙げる方法 • よくあるテスト技法の問題点 – テスト技法そのものは理解したが、 そもそも「何をテストすればいいか」が分からないので どこにどう適用すれば分からず、 結局CPM法と固定３レイヤー法でテストケースを増殖させてしまう » 機能の網羅はちゃんと出来たけど、 動作環境が色々あるのは気づかなかった » 境界値テストを設計したけど、 そもそも同値クラスが浮かばなかった » 直交表を使ってテストを設計したけど、因子が抜けてしまった この「何をテストすればいいか」を “テスト観点” と呼ぶ
- 104. © NISHI, Yasuharu104 テスト設計には実に多くの観点が必要：組込みの例 •機能：テスト項目のトリガ – ソフトとしての機能 » 音楽を再生する – 製品全体としての機能 » 走る • パラメータ – 明示的パラメータ » 入力された緯度と経度 – 暗黙的パラメータ » ヘッドの位置 – メタパラメータ » ファイルの大きさ – ファイルの内容 » ファイルの構成、内容 – 信号の電気的ふるまい » チャタリング、なまり • プラットフォーム・構成 – チップの種類、ファミリ – メモリやFSの種類、速度、信頼性 – OSやミドルウェア – メディア » HDDかDVDか – ネットワークと状態 » 種類 » 何といくつつながっているか – 周辺機器とその状態 • 外部環境 – 比較的変化しない環境 » 場所、コースの素材 – 比較的変化しやすい環境 » 温度、湿度、光量、電源
- 105. © NISHI, Yasuharu105 テスト設計には実に多くの観点が必要：組込みの例 •状態 – ソフトウェアの内部状態 » 初期化処理中か安定動作中か – ハードウェアの状態 » ヘッドの位置 • タイミング – 機能同士のタイミング – 機能とハードウェアのタイミング • 性能 – 最も遅そうな条件は何か • 信頼性 – 要求連続稼働時間 • セキュリティ • GUI・操作性 – 操作パス、ショートカット – 操作が禁止される状況は何か – ユーザシナリオ、10モード – 操作ミス、初心者操作、子供 • 出荷先 – 電源電圧、気温、ユーザの使い方 – 言語、規格、法規 • 障害対応性 – 対応すべき障害の種類 » 水没 – 対応動作の種類 非常に多くの観点を整理して扱う方法が必要である
- 106. © NISHI, Yasuharu106 テストタイプ・テストレベルの悩み •テストタイプ・テストレベルとは – テストタイプ：性能テスト、動作環境変更テスト、負荷テストなど – テストレベル：単体テスト、結合テスト、システムテスト、受け入れテストなど – 多くの組織では、標準的なテストタイプやテストレベルを定義している • ある組織の例 – 負荷テストとストレステストの両方のテストタイプが必要だとされていた – それぞれこんな記述になっていた » 負荷テスト：ストレスをかける » ストレステスト：負荷をかける • テストタイプやテストレベルの問題点 – テストタイプやテストレベルの記述が粗いため、 結局のところ一体何をテストしているのか誰も分かっていない – 隣接するテストタイプやテストレベルが依存しあっていたり、 重なっていたり、両方から漏れていたりする
- 107. © NISHI, Yasuharu107 パートナー（協力会社）との悩み •テストをパートナーに投げる理由 – テストは誰でもできるので安い単価でパートナーに投げればよい、と判断する – テストは誰でもできるので丸投げしても問題無い、と判断する • テストをパートナーに投げることの問題点 – パートナーのテストがイマイチなので追求してみると、 自分たちが作成しているテスト計画がスカスカだったことに気付く » テストは誰でもできる、は幻想だったと後悔する – 丸投げしているのでパートナーがどんなテストをしているのか分からず、 自分たちに全くテストの技術力が残らないので、 気がつくとパートナーにテストを依存し抜け出せなくなってしまう » 「首根っこをつかまれた」状態になっている – 頭を使うところと機械的にできるところの区別がつかず、 かつパートナーが工数精算のため自動化を嫌がるので、 いつまで経ってもテストの自動化に取り組めない
- 108. © NISHI, Yasuharu108 よくあるテストの現場の悩みのまとめ •CPM法： – テストケースの趣旨が分からない • 固定３レイヤー法： – 詳細化が飛んでいる・揃わない・おかしい • よくあるテスト技法： – テスト観点が列挙・整理されていない • テストタイプ・テストレベル： – テストタイプ・テストレベルが整理されていない • パートナー： – 自分たちにテストの技術は残しつつ コストダウンしたいし自動化もしたい
- 109. © NISHI, Yasuharu109 ではどんなテストの方法論があればよいのか •【悩み】テストケースの趣旨が分からない → 【解決策】テストケースとテスト観点とを必ず結びつけるようにテスト設計する • 【悩み】詳細化が飛んでいる・揃わない・おかしい → 【解決策】親子関係をきちんと明示し網羅性を保証する • 【悩み】テスト観点が列挙・整理されていない → 【解決策】テスト観点を列挙・整理し全体像を把握する • 【悩み】テストタイプ・テストレベルが整理されていない → 【解決策】 テストタイプ・テストレベルをテスト観点でより詳細に表して図示し、 テストタイプやテストカテゴリ間の重複や漏れ、 不要な依存関係を減らす • 【悩み】自分たちにテストの技術は残しつつ コストダウンしたいし自動化もしたい → 【解決策】テスト観点を列挙し整理する高度に頭を使う作業と、 機械的に網羅するだけの単純作業とを峻別し、 前者を自らに残し、後者を少しずつ自動化していく
- 110. © NISHI, Yasuharu110 ソフトウェアテスト開発プロセスが必要である •ソフトウェアの高品質化・大規模化・複雑化に伴い、 ソフトウェアテストの高品質化・大規模化・複雑化も急務である – 10万件を超える様々な観点による質の高いテストケースを、 いかに体系的に開発するか、が課題である • しかしテスト計画やテスト戦略立案という工程は未成熟である – テストケースという成果物の開発と、テストのマネジメントとが混同されている » テスト計画書にテストケースもスケジュールも人員アサインも全て記載される – テストケースの開発という工程が見えにくくなっており、 そこで必要となる様々な工程が混沌として一体的に扱われている » テスト（ケース）開発という用語はほとんど使われず、 テスト計画、テスト仕様書作成、テスト実施準備といった用語が使われている » テスト戦略という用語もイマイチよく分からない • そこで「ソフトウェアテスト開発プロセス」という概念が必要となる – テストケースを開発成果物と捉え、開発プロセスを整備する必要がある » 高品質・大規模・複雑なテストケースを開発するために必要な作業を明らかにする » 本来はテスト実施以降やテスト管理のプロセスも必要だが、今回は省略する – ASTER／智美塾でエキスパートが議論している » 我々はVSTeP(Viewpoint-based Software Test Engineering Process)を提案している
- 111. © NISHI, Yasuharu111 テスト観点を構成要素としてモデリングを行う •テスト観点のモデリングを行ってテストを開発すべきである – モデリングを行うと、テストで考慮すべき観点を一覧でき、 俯瞰的かつビジュアルに整理できる » 10万件を超えるテストケースなど、テスト観点のモデル無しには理解できない » モデルとして図示することで、大きな抜けや偏ったバランスに気づきやすくなる » 複数のテストエンジニアでレビューしたり、意志を共有しやすくなる – テスト要求分析では、テスト要求モデルを作成する » テスト対象、ユーザの求める品質、使われる世界などをモデリングする » ボトムビューポイントが特定できるまで丁寧に段階的に詳細化する – テストアーキテクチャ設計では、 テスト詳細設計・実装・実行しやすいようにテスト要求モデルをリファインする » 適切なテストタイプやテストレベルそのものを設計する » 見通しのよいテストアーキテクチャを構築する » よいテスト設計のためのテストデザインパターンを蓄積し活用する – VSTeP(Viewpoint-based Software Test Engineering Process)では、 NGT(Notation for Generic Testing)という記法でテスト観点のモデリングを行う » ツリー型の記法を用いるため、Excelで表を埋めるよりも“エンジニアリング”っぽい
- 112. © NISHI, Yasuharu112 VSTePに取り組む価値のない組織 •テストは仕様書通りに動かして証拠作りをする （ので軽作業派遣でいい）と思っている組織 – 仕様をなぞって画面キャプチャ、の無限ループにコストをかけなくてはいけない組織 » 開発由来の場合とお客様由来の場合がある – 考慮すべきことは上流で全て考慮しているので下流は確認すればいい、 というトップダウンな規格に疑問なく従っている組織 • 巨大なExcelの表を埋めることに凄まじい愛情を注げる組織 • パートナーにテストを丸投げしていて特に不自由のない組織 • なんでやるのか分からないテストケースでも 自動化して大量に実行すれば何かした気になれる組織 • テストが属人化していても、ずっと同じ組織でずっと同じアサインができるから むしろもっと属人化させたい組織 • なにかコンサルの言うことに従っていれば 頭を使わなくてもよいテストができると期待している組織 – VSTePは、自組織の誰も経験したことのないことを「予言」するような方法ではない
- 113.
- 114. © NISHI, Yasuharu114 VSTePに取り組む価値のある組織 •仕様のコピペでテストケースが肥大化し収拾が付かなくなっている組織 • 技法やテストタイプなどのテストの社内標準はあるけど 意味ないと思っている組織 • テストケース表のExcelの大中小項目がフリーダム過ぎる組織 • パートナーがダメ、もしくはパートナーに依存してしまっている組織 • テストの知恵を貯めてテストを改善したい組織、 さらにはレビューや開発も改善したい組織 • 異なる部署や異なる組織、異なる国をまたいで 効果的にテストを行いたい組織 • 説明責任の高いテストを行うことで監査や審査と闘いたい組織 • よいテスト設計とよいテスト自動化を融合させたい組織
- 115.
- 116. © NISHI, Yasuharu116 NGT/VSTePの概要 •NGT/VSTePとは何か – テスト観点を基盤としたテスト開発のための記法とテスト開発プロセス » NGT（Notation for Generic Testing）：テスト開発のための記法 » VSTeP（Viewpoint-based Test Engineering Process）：テスト開発プロセス – テスト観点（図）、テストコンテナ（図）、テストフレームをつくることで、 質の高いテストケースやテスト手順を作成する方法 • テスト観点とは？ – テストケースごとの「テストの意図」である – テストケースの（一部）を抽象化したものになる • テストコンテナとは？ – テストレベルやテストタイプ、テストサイクルをまとめたものである » テストレベル： 単体テスト、結合テスト、システムテストなど » テストタイプ： 負荷テスト、構成テスト（動作環境変更テスト）、セキュリティテストなど » テストサイクル： 時間的な区切りでテストをまとめたもの • テストフレームとは？ – テストケースのひな形である
- 117. © NISHI, Yasuharu117 要するにVSTePってなに？ •テストケースをざっくり考えてから具体化する方法 – 「○○機能に△△人のアクセスを与えて□□秒のレスポンスが…」 といきなり細かく考えるのではなく 「負荷をかけたいなー、でも他にテストすることないかなー」とまずはざっくり考える » いきなり細かく考えると、大きな抜け漏れが発生しやすくなる » ざっくりしたテストケース（「負荷」）を「テスト観点」と呼ぶ » Excelの大項目・中項目・小項目のようなものだと考えてよい – Excelの表だと全体像が見えにくいので、UMLっぽい図に書いて全体像を把握する » 全体像を把握できると、網羅してる実感を持ちやすくなったり、 テスト計画やテスト戦略を立てたり改善しやすくなる » 全体像を把握できると、みんながムダなくテストできるし、上流や顧客とも合意しやすい ざっくり考えて図にすると 見やすいし整理しやすい！
- 118. © NISHI, Yasuharu118 VSTePの簡単な流れ •テスト要求分析 – テスト観点を思い浮かべて、線でつなげよう • ・テストアーキテクチャ設計（コンテナ設計） – テストコンテナにまとめて並べよう • テストアーキテクチャ設計（フレーム設計） – テストケースのひな形（テストフレーム）を作ろう • テスト詳細設計 – テストケースのひな形に具体的な値を入れよう » 普通のやり方と同じでよい • テスト実装 – テストケースをテスト手順に具体化しよう » 普通のやり方と同じでよい
- 119. © NISHI, Yasuharu119 テスト設計とテスト開発は何が違うの？ •いきなりコーディングすることと、 ソフトウェア開発を行うことの違いと同じである – コーディングは、アルゴリズムとプログラミング言語を分かっていればできる » （従来の）テスト設計も、テスト設計技法と文書フォーマットを分かっていればできる » 経験豊富でセンスのある人が規模の小さいプログラムを書くのであれば別に構わない – ソフトウェア開発は、要求を把握し設計原則を理解・適用して、 段階的に詳細化しながら順序立てて進めていく必要がある » テスト開発も、テスト要求を把握しテスト設計原則を理解・適用して、 段階的に詳細化しながら順序立てて進めていく必要がある » これまで皆の経験とセンスを結集して規模の大きなソフトウェアを開発することである » 経験とセンスを結集するために、 様々なソフトウェア工学上の概念や技術、方法論が必要となる • テストの開発のための方法論の一つがVSTePである – ほかにもHAYST法やゆもつよメソッドなど色々あり、それぞれに強みがある
- 120.
- 121.
- 122. © NISHI, Yasuharu122 VSTePの簡単な流れ •テスト要求分析 – テスト観点を思い浮かべて、線でつなげよう • ・テストアーキテクチャ設計（コンテナ設計） – テストコンテナにまとめて並べよう • テストアーキテクチャ設計（フレーム設計） – テストケースのひな形（テストフレーム）を作ろう • テスト詳細設計 – テストケースのひな形に具体的な値を入れよう » 普通のやり方と同じでよい • テスト実装 – テストケースをテスト手順に具体化しよう » 普通のやり方と同じでよい
- 123. © NISHI, Yasuharu123 テスト開発プロセスの基本的考え方 •テストケースを開発成果物と捉え、 ソフトウェア開発プロセスと ソフトウェアテスト開発プロセスを対応させよう ソフト要求分析 ＝ テスト要求分析 ソフトアーキテクチャ設計 ＝ テストアーキテクチャ設計 ソフト詳細設計 ＝ テスト詳細設計 ソフト実装 ＝ テスト実装 • テストケースがどの工程の成果物かを考えるために、 各プロセスの成果物を対応させよう ソフト要求仕様（要求モデル） ＝ テスト要求仕様（要求モデル） ソフトアーキテクチャモデル ＝ テストアーキテクチャモデル ソフトモジュール設計 ＝ テストケース プログラム ＝ 手動／自動化テストスクリプト（テスト手順）
- 124. © NISHI, Yasuharu124 テスト アーキテクチャ 設計 旧来のテスト設計を細かく分けたのがテスト開発プロセス テスト実施テスト設計（orテスト計画 or テスト実施準備） テスト要求の 獲得と整理・ テスト要求 モデリング テストアーキテクチャ モデリング 手動／自動化 テストスクリプト （テスト手順）の 記述 テスト項目の抽出 テスト 詳細設計 テスト 実装 テスト 実施 テスト技法の 適用による テストケースの 列挙 テスト 要求分析 【VSTePの流れ】 【旧来の流れ】
- 125. © NISHI, Yasuharu125 NGTによるテスト観点図の記述 •NGT/VSTePではテスト観点図を中心にして進めていく – NGT (Notation for Generic Testing) という記法を定義している – テスト観点を階層的に記述していく – はテスト観点、 はテスト対象を表す – は詳細化関係を表す – は組み合わせテストの必要性などテスト観点間の関連を表す – は順序依存関係を表す – 新たな関係や詳細な関係を 定義したり 分かりやすくするために <<stereotype>> （ステレオタイプ）を 使ってもよい
- 126. © NISHI, Yasuharu126 •テスト観点という用語はロールに依存しないからである なぜ「テスト観点」と呼ぶのか？ テスト目的 じゃないか？ 要求でしょ！ 因子だよ因子 テスト条件だよ テスト環境 な気がする SE（要求担当） テストマネジャー テストエンジニア 組み合わせ テスト設計者 テストオペレータ
- 127. © NISHI, Yasuharu127 テスト観点の例：組込みの場合 •機能：テスト項目のトリガ – ソフトとしての機能 » 音楽を再生する – 製品全体としての機能 » 走る • パラメータ – 明示的パラメータ » 入力された緯度と経度 – 暗黙的パラメータ » ヘッドの位置 – メタパラメータ » ファイルの大きさ – ファイルの内容 » ファイルの構成、内容 – 信号の電気的ふるまい » チャタリング、なまり • プラットフォーム・構成 – チップの種類、ファミリ – メモリやFSの種類、速度、信頼性 – OSやミドルウェア – メディア » HDDかDVDか – ネットワークと状態 » 種類 » 何といくつつながっているか – 周辺機器とその状態 • 外部環境 – 比較的変化しない環境 » 場所、コースの素材 – 比較的変化しやすい環境 » 温度、湿度、光量、電源
- 128. © NISHI, Yasuharu128 テスト観点の例：組込みの場合 •状態 – ソフトウェアの内部状態 » 初期化処理中か安定動作中か – ハードウェアの状態 » ヘッドの位置 • タイミング – 機能同士のタイミング – 機能とハードウェアのタイミング • 性能 – 最も遅そうな条件は何か • 信頼性 – 要求連続稼働時間 • セキュリティ • GUI・操作性 – 操作パス、ショートカット – 操作が禁止される状況は何か – ユーザシナリオ、10モード – 操作ミス、初心者操作、子供 • 出荷先 – 電源電圧、気温、ユーザの使い方 – 言語、規格、法規 • 障害対応性 – 対応すべき障害の種類 » 水没 – 対応動作の種類 テスト観点はテストケースの「意図」を表している
- 129. © NISHI, Yasuharu129 テスト観点とテストケースとテスト手順を区別する •テスト観点とテストケースとテストスクリプトをきちんと区別する – テスト観点 » 何をテストするのか（テストケースの意図）のみを端的に記述したもの · 例）正三角形 – テストケース » そのテスト観点でテストするのに必要な値などのみを特定したもの · 例）(1,1,1), (2,2,2), (3,3,3)… » 通常は、網羅基準に沿って特定される値などのみから構成される » テストケースは基本的にシンプルになる – テストスクリプト（テスト手順） » そのテストケースを実行するために必要な全てが書かれたもの · 例）1. PCを起動する 2. マイコンピュータからC:sampleMyers.exeを起動する… » 手動でのテスト手順書の場合もあれば、自動テストスクリプトの場合もある » 複数のテストケースを集約して一つのテストスクリプトにすることもある • これらを区別し、異なる文書に記述し、 異なる開発工程に割り当てることによって、 テスト観点のみをじっくり検討することができるようになる
- 130. © NISHI, Yasuharu130 テスト観点図の描き方の例：トップダウン型 •トップダウン型 – おもむろにテスト観点を挙げ、詳細化していく » 三角形のテストには、三角形の構造に関する観点が必要だ » 三角形の構造には、成立、直線、不成立の3つがあるな » 成立する場合には、正三角形、二等辺三角形、不等辺三角形があるな – 実際にはトップダウンとボトムアップを循環させながらモデリングする 三角形 成立 直線 不成立 正 三角形 二等辺 三角形 不等辺 三角形 三角形 成立 直線 不成立 三角形
- 131. © NISHI, Yasuharu131 テスト観点図の描き方の例：ボトムアップ型 •ボトムアップ型 – まず思いつくところからテストケースを具体的に書き、 いくつか集まったところで抽象化し、テスト観点を導き出していく » (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)
- 132. © NISHI, Yasuharu132 テスト観点の詳細化：親観点と子観点 •テスト観点は階層的に詳細化できる – 詳細化は、近くからモノを見る （ズームインする）ようなことである – 踏み込んでモデリングする場合は、 継承（is-a）、合成集約（部分：has-a）、 属性化、原因－結果など 詳細化すべき理由をステレオタイプで表す » ステレオタイプごとに分けて詳細化を行うとMECE性（網羅性）を保証しやすくなる • 階層の最上位のテスト観点を「（トップ）ビュー」と呼ぶ – ビューは、そのサブツリーが全体として何をテストするのか、を表している – どのようなトップビューで構成するか（テスト要求モデルの全体像） はテストエンジニアによってかなり異なる • 階層の最下位のテスト観点を「ボトムビューポイント」と呼ぶ – そのテスト観点を見れば、何をどのように網羅すればよいかが 一目で分かる詳細度、がボトムビューポイントである – ボトムビューポイントはテスト詳細設計でのテスト条件となる » 例えば同値クラスになる 動作環境 プラットフォーム ネットワーク OS ハードウェア
- 133. © NISHI, Yasuharu133 組み合わせテストが必要なら観点同士を関連で結ぶ •複数の観点を組み合わせるテストを「関連」で示す – 例）負荷テストでは、搭載メモリ量という観点と、 投入データ量という観点を組み合わせてテスト設計を行う » 搭載メモリ量と投入データ量のバランスによって、 テスト対象のふるまいが変化するからである – 組み合わせテストの場合のように順序依存性のない関連は、 テスト観点間の矢頭の無い曲線で表す » 順序依存性のある関連は → のように開き矢尻の矢印で表す – 新たな関係や詳細な関係を定義したり分かりやすくするために <<stereotype>>（ステレオタイプ）を使ってもよい GUIパス数 OSの種類 機能 性能 <<combination>> <<sequence>>
- 134. © NISHI, Yasuharu134 テストコンテナとは •大規模なテスト設計では、 複数のテスト観点をグルーピングして扱いたい時がある – 複数のテスト観点をグルーピングしたものをテストコンテナと呼ぶ » テストタイプやテストレベル、テストサイクルなどを表現する – テストコンテナは包含関係を持つことができる » テストコンテナに含まれるテスト観点を比べると テストコンテナ間の役割分担を明確に把握できる · 負荷テストと性能テストなど、違いがよく分からないテストタイプも区別できる · 単体テストと結合テストなど、役割分担がよく分からないテストレベルも区別できる 動作環境 プラットフォーム ネットワーク OS ハードウェア 構成テスト ボリューム ストレージ 高頻度 ロングラン 負荷テスト
- 135. © NISHI, Yasuharu135 テストコンテナ図 •大規模なテスト設計では、 テストコンテナの図で表すと全体像を把握しやすくなる – テストコンテナ（レベルやテスト、サイクル）を用いるとテストアーキテクチャを俯瞰できる » 先に設計/実施しておくべきコンテナを後に回してしまう、といったトラブルが防げる » 保守や派生しやすいテストが可能になる 構造テスト 例外 ハンドリング テスト マルチバイト テスト 配列境界 テスト 単体テスト 呼び出しテスト 割り込み ハンドリング テスト 共有メモリ テスト デバイス制御 テスト 結合テスト セキュリティ テスト システムテスト 動作環境テスト 障害 対応性 テスト 機能テスト 負荷テスト テスト サイクル① 機能テスト 負荷テスト テスト サイクル② 動作環境 プラットフォーム ネットワーク OS ハードウェア
- 136. © NISHI, Yasuharu136 テストフレームとは •実際のテスト設計では、複数のテスト観点をまとめて テストケースを設計したい場合が多い – この条件のテストは、テスト対象のどの部分に行うんだろう？ – この部分に対するテストでは、どの品質特性を確認するんだろう？ – この品質特性をテストするには、どの操作を行えばいいんだろう？ • テストケースの構造（スケルトン）をテスト観点の組み合わせで示すことで、 複数のテスト観点によるテストケースを設計する – テストケースの構造を表すテスト観点の組み合わせを「テストフレーム」と呼ぶ » <<frame>> というステレオタイプの関連を用いる » シンプルな構造のテストケースで十分であれば、テストフレームを組まなくてもよい – テストフレームの例： » 下の図では、テスト条件＋テスト対象＋振る舞いをテストフレームとしている » 組み合わせテストを設計しようとしているわけではない点に注意する データ量 残メモリ量 <<frame>> 性能 <<frame>>
- 137. © NISHI, Yasuharu137 テストアーキテクチャ設計 •テストアーキテクチャ設計とは、 テストスイートの全体像を把握しやすくしつつ 後工程や派生製品、後継プロジェクトが作業しやすくなるように テスト要求モデルを整理する工程である – 1) テストコンテナモデリング » テスト要求モデルを分割し、 同じまとまりとしてテストすべきテスト観点を 同じテストコンテナにまとめることで整理する · テストコンテナ：テストレベルやテストタイプ、テストサイクル · テストレベルやテストタイプそのものを、テスト観点を用いて設計する · モデルのリファイン（整理）も行っていく » テスト観点よりも粒度の粗いテストコンテナを用いるので テストスイートの全体像の把握や全体に関わる設計がしやすい » 自社で定められているテストレベルやテストタイプの趣旨を理解し、 きちんと全体像を設計できるようになる » テストにも保守性など特有の「テスト品質特性」があるが、 どのようなテスト品質特性を重視するかによって異なるテストアーキテクチャとなる – 2) テストフレームモデリング » （同じテストコンテナ内で）複数のテスト観点をまとめて テストケースの構造（スケルトン）を定義し、 テスト詳細設計をしやすくする データ量 残メモリ量 <<frame>> 性能 <<frame>>
- 138. © NISHI, Yasuharu138 •同じ時期にテストすべきテスト観点をテストレベルとしてまとめる – テスト観点には、テスト観点同士の順序依存関係や欠陥特定の絞り込みのための順序依存関 係、プロジェクトの制約としての時期依存関係がある » 例）機能テスト観点の実施情報を用いて負荷テストを設計したい » 例）モジュール内設計のテストを実施した後にモジュール間設計のテストを実施しないと 欠陥特定の工数がかかりすぎてしまう » 例）特殊なテスト環境が揃うのが後半なので構成テストは最後に回したい • 同じ趣旨を持ってるテスト観点をテストタイプとしてまとめる – 例）負荷テストタイプは複数のテスト観点からなるが、 負荷をかけるという同じ趣旨を持っている • 繰り返しのテストや回帰テストが必要なテスト観点を テストサイクルとしてまとめる – 同じテスト観点を繰り返しているようでいて、 実は意味が異なったりすることがあるので注意すること • 複数のテストタイプからなるテストレベル、 サブレベルを持つテストレベルなどのように、 他のテストコンテナを包含しながらまとめることもできる テストアーキテクチャ設計：1) コンテナモデリング
- 139. © NISHI, Yasuharu139 •テストコンテナを用いてテストアーキテクチャを表現するメリット – テスト観点よりも粒度の粗いテストコンテナを用いるので、俯瞰して把握しやすい – テストコンテナ間に含まれるテスト観点を比べると、役割分担を明確に把握できる » 現場で経験的に用いているテストコンテナの妥当性を評価したり改善できるようになる · 負荷テストと性能テストなど、違いがよく分からないテストタイプも区別できる · 単体テストと結合テストなど、役割分担がよく分からないテストレベルも区別できる – サブレベルなどを階層的に表現できる – テストスイートの品質特性（保守性や自動化容易性など）を意識して テスト設計に反映できる • テストコンテナを設計する際のポイント – テストが小規模で単純な場合、テスト要求モデルのビュー（サブツリー）を そのままテストコンテナにしてしまってよい場合も多い – テストコンテナの趣旨が把握しやすいようにモデリングする – テストコンテナ間の関係がなるべく少なくなる（疎になる）ようにモデリングする – テスト要求モデルでは単一のテスト観点を分割することもある – マネジメント的要求からテストスイートの品質特性を抽出し、 それらを達成できるようにモデリングする » 例）保守性を高めたいというテストスイートの品質特性がある場合、 変更があまり入らないテストコンテナと変更が頻繁に入るテストコンテナに分割する • テストアーキテクチャ設計：1) コンテナモデリング
- 140. © NISHI, Yasuharu140 •実際のテスト設計では、複数のテスト観点をまとめて テストケースを設計したい場合がある – この条件のテストは、テスト対象のどの部分に行うんだろう？ – この部分に対するテストでは、どの品質特性を確認するんだろう？ – この品質特性をテストするには、どの操作を行えばいいんだろう？ • テストケースの構造（スケルトン）をテスト観点の組み合わせで示すことで、 複数のテスト観点によるテストケースを設計する – テストケースの構造を表すテスト観点の組み合わせを「テストフレーム」と呼ぶ » <<frame>> というステレオタイプの関連を用いる » シンプルなテストケースで十分であれば、テストフレームを組まなくてもよい – テストフレームの例： » テスト条件＋テスト対象＋振る舞いをテストフレームとしている » 組み合わせテストを設計しようとしているわけではない点に注意する データ量 残メモリ量 <<frame>> 性能 <<frame>> テストアーキテクチャ設計：2) フレームモデリング
- 141. © NISHI, Yasuharu141 テスト詳細設計 •テスト観点をボトムビューポイントまで詳細化し、 テストフレームを組んだら、テストケースを生成する – ボトムビューポイントに対応するテスト詳細設計モデルを定め、 網羅アルゴリズムと網羅基準にしたがって 具体的な値や機能、組み合わせを列挙し、テストケースとする » 例） 状態モデルに対して、C0の遷移網羅基準で、 深さ優先探索法を用いて生成する » テストフレームの各テスト観点を列見出しにしたExcelの表を埋めてもよいだろう » ボトムビューポイント、網羅アルゴリズム、網羅基準の3者が明確であれば、 モデルベースドテストとしてテストケース生成を自動化できる可能性が高い – テストケースに対応するテスト観点を常に明確にすることができる » 目的のよく分からない漫然と設計されるテストケースを撲滅できる – テスト詳細設計は機械的に行っていくのが基本である » 可能な限り自動化すると、Excelを埋める単純作業を撲滅できる » テスト詳細設計を機械的にできないところは、網羅基準が曖昧だったり、 テスト観点が隠れていたりする
- 142. © NISHI, Yasuharu142 テスト実装 •テストケースが生成できたら、テスト実装を行う – テスト対象のシステムやソフトウェアの仕様、テストツールなどに合わせて テストケースをテストスクリプトに具体化していく » 手動テストスクリプトの場合もあるし、自動化テストスクリプトの場合もある – テスト実装は、テスト対象のUI系の仕様や実行環境、ユーザのふるまいに関する ノウハウが必要である • 集約 – テスト実施を効率的に行うため、 複数のテストケースを１つのテストスクリプトにまとめる作業を集約と呼ぶ – 同じ事前条件や同じテスト条件、同じテストトリガのテストケース、 あるテストケースの実行結果が他のテストケースの事前条件やテスト条件に なっている場合は集約しやすい » テストトリガとは、テスト条件を実行結果に変えるためのきっかけとなるイベントである • キーワード駆動テスト – 自動化テストスクリプトを“クリック”といった自然言語の「キーワード」で 記述することにより、保守性を高めたり自動生成をしやすくする技術である – テスト観点とキーワードを対応させると、キーワード駆動テストを実現しやすくなる » NGT/VSTePをベースにして自動テストスクリプトの自動生成を目指すことができる
- 143. © NISHI, Yasuharu143 まとめ：VSTePの簡単な流れ •テスト要求分析 – テスト観点を思い浮かべて、線でつなげよう • ・テストアーキテクチャ設計（コンテナ設計） – テストコンテナにまとめて並べよう • テストアーキテクチャ設計（フレーム設計） – テストケースのひな形（テストフレーム）を作ろう • テスト詳細設計 – テストケースのひな形に具体的な値を入れよう » 普通のやり方と同じでよい • テスト実装 – テストケースをテスト手順に具体化しよう » 普通のやり方と同じでよい ざっくり考えて図にすると 見やすいし整理しやすい！
- 144.
- 145.
- 146. © NISHI, Yasuharu146 VSTePにおけるモデリングの基本 •モデリングに正解は無い、 納得の共感による説明責任の確保があるだけだ – 納得感の得られないモデルや、共感できないモデルは、往々にして質が低い – その組織のエンジニアが皆「こんなもんだ」と思い、 それで過去に問題がなかったのなら、モデリングはその程度で終わりでよい – 仕様書とのトレーサビリティにばかり囚われるとよいモデルにならない • 各（中間）成果物の抽象度をどこまで落とすべきか、 は意外に難しい問題である – テスト観点、テストコンテナ、テストフレーム、テストケース、テスト手順を それぞれどこまで具体的に書けばいいのか、は一概には言えない • 類似した構造を見抜き、テストデザインパターンとして パターン化して蓄積することが重要である – VSTePは抽象化されているのでパターン化しやすいが、 パターンを掘り出そうという意志を常に持つこと一番重要である • 複数の派生製品のテスト開発をする際は、派生製品全体をまたいで （テストの）プロダクトラインモデルを構築するとよい
- 147. © NISHI, Yasuharu147 テスト要求モデルの全体像の種類 •仕様ベースモデル • 機能ベースモデル • 画面ベースモデル • 正常系異常系モデル • 品質特性モデル • 一般テストタイプモデル • CIBFWモデル – Condition / Item / Behaviour / Fault / World • 三銃士モデル – 世界観・コンテキスト・実装＋ユーザ感情
- 148. © NISHI, Yasuharu148 テスト観点モデルのテクニック •仕様書を書き写すことで網羅性を高めようとしない – 仕様書に書いてないテスト観点をテストでも漏らしてしまうことになる » 仕様書がそんなに質や完成度が高かったら苦労しない • 同じテスト観点名を皆が同じように理解しているとは限らない – 子観点が明示すると理解の齟齬は解消しやすい • 観点が通り一遍で関連が多いモデルは理解度が低いことが多い – 不安だから／責任を取りたくないから組み合わせておかなきゃ、と発想していることが多い – なぜその関連をテストすべきだと思ったのか、という掘り下げを行い、 可能なら関連をテスト観点に変換すると、よりテストの意図が明確になる • 詳細化のステレオタイプを明示すると網羅しやすい – 異なるステレオタイプの詳細化が混ざっていると網羅しにくい • 抽象度は丁寧に落として（具体化して）いく – 認知的マジックナンバーの範囲内にできるとよい • 網羅できた確信が持てないところにはノートを貼っておく – 抜け落ちの危険性が消失することが一番怖い • チャーターの記述とテストの（気づいた点の）記録は テスト観点モデルを用いると表現しやすい
- 149. © NISHI, Yasuharu149 VSTePにおける網羅の考え方 •基本的な考え方： まず全体像を網羅して、次に明示的に減らす – 網羅とは証明することではなく、納得感を共感することである » ソフトウェアのテストは、現実的には無限or工数オーバーになるので網羅はできない » しかしまず全体像を網羅しておいて、何がどのように無限or工数オーバーになるので こういう考え方でここを減らす、ということを整理して明示的に把握しておけば 現実的に問題の無いテストが可能になる » テスト観点を用いて抽象化しているので、網羅する工数はそんなに増えない » テスト漏れが怖いのではなく、漏れがどこにあるのか分からないのが怖いのである • VSTePにおける網羅は以下の4つから構成される – テスト観点とそれらの組み合わせの網羅 – テスト観点図の納得感の共感で担保する » 納得感を上げるためにテスト要求モデル（テスト観点図）のリファインを繰り返すことが肝要 – テストケースの網羅 – テストフレームの明示で担保する » 網羅を確実に行うためにモデルベースドテスト（テスト詳細設計の自動化）に取り組むとよい – テスト手順の確実な遂行 – テストケースとテスト手順の分離によって促進する • VSTePにおける網羅は以下の考え方で行われる – 全網羅 – 規模が非常に小さいときのみ可能 - 「確定」で網羅性を担保する – トレードオフ – 「剪定」やペアワイズ/直交配列表などで行う – ピンポイント – バグのパターン化（ex. 不具合モード）など別途技術が必要 – リスクベースドによる優先度付け – そのテストケースを省いた場合のリスクを考える
- 150. © NISHI, Yasuharu150 テスト要求モデルのリファインの例 •質の高いモデルにするために様々なリファインを行う – 網羅化：MECE分析 » 子観点がMECEに列挙されているかどうかをレビューし、不足している子観点を追加する » MECEにできない場合、必要に応じて「その他」の子観点を追加し非MECEを明示する » 子観点をMECEにできるよう、適切な抽象度の観点を親観点と子観点との間に追加する – 網羅化：ステレオタイプ分析 » MECE性を高めるために、詳細化のステレオタイプを明示し子観点を分類する – 整理 » 読む人によって意味の異なるテスト観点を特定し、名前を変更する » テスト観点や関連の移動、分割、統合、名前の変更、パターンの適用、 観点と関連との変換、観点と網羅基準との変換などを行う » 本当にその関連が必要なのかどうかの精査を行う必要もある – 剪定 » ズームイン・アウト、観点や関連の見直し、網羅基準や組み合わせ基準の緩和によって、 テスト項目数とリスクとのトレードオフを大まかに行う – 確定 » 子観点および関連が全て網羅的に列挙されているかどうかをレビューすることで、 テスト要求モデル全体の網羅性を明示し、見逃しリスクを確定する
- 151. © NISHI, Yasuharu151 テストコンテナモデリングのテクニック •テストアーキテクチャ設計方針／テストアーキテクチャの品質特性を 明示的に考慮し、複数案を作れるとよい – テストアーキテクチャ設計のどの部分を取っても、 そこがそうなっている理由や意図を説明できるようになっていなければならない – 複数案を作ると、コンテナモデリングの重要性が腹落ちできる • コンテナの前後依存関係は最も基本的なテストアーキテクチャである – （リスクベースドテストの）リスクは、後先だけでなくコンテナごとの規模にも影響するので、 リスクだけでコンテナの前後依存関係を考えるのはよくない • テスト設計方針／テストアーキテクチャの（内部）品質特性の例 – 結合度と凝集度、保守性、自動化容易性、環境依存性、開発との一貫性、 想定欠陥修正容易性、記述容易性、設計方向性、リズムなど色々ある • トップダウンのモデリングとボトムアップのモデリング – 必ず一度はボトムアップでコンテナモデルを構築してみること – 探索的テストは観点が動的に決まる／変わるため、 コンテナとして出し忘れやすいので気をつける
- 152. © NISHI, Yasuharu152 テストアーキテクチャの例 •テスト設計コンテストの応募作を分析すると、 様々なテストアーキテクチャが構築されていた – テスト対象構造型テストアーキテクチャ – 伝統的テストタイプ型テストアーキテクチャ – 階層型テストアーキテクチャ – フィルタ型テストアーキテクチャ – 複合型テストアーキテクチャ Function Layer Service Layer Platform Layer 階層型 テスト アーキテクチャ Logical Bugs Detecting Filter Easy Bugs Detecting Filter Stress Bugs Detecting Filter Exhaustive Testing Filter フィルタ型テストアーキテクチャ Master CPU Money Ctrl CPU Can Rack Ctrl CPU Button Ctrl CPU Slot Sensor CPU Prize Mgmt CPU Driver Layer Driver Layer App. Layer Driver Layer App. Layer Driver Layer App. Layer Driver Layer App. Layer Driver Layer App. Layer Manager Layer 複合型テストアーキテクチャ
- 153. © NISHI, Yasuharu153 テスト設計コンテストの応募作のテストアーキテクチャ •一見似たようなレイヤードアーキテクチャだが、 実は異なっていた – 階層の切り口もレイヤ数も様々だった Application Layer Manager Layer Driver Layer Function Layer Service Layer Platform Layer Multi Function Layer Functional Collision Layer Single Function Layer Support Function Layer Functional Collision Layer Fundamental Function Layer Main Function Layer システム アーキテクチャ型 階層 ソフトウェア アーキテクチャ型 階層 機能型階層 - 3階層 機能型階層 - 4階層
- 154. © NISHI, Yasuharu154 Kettle Safety Evaluation Kettle Scenario Testing Kettle Mis-usecase Testing Kettle Usability Evaluation Understandability Evaluation Learnability Evaluation Kettle Operational Interruption Testing Hot-water SupplyControl Functional Testing Supply Locking Functional Testing Hot-water Supplying Functional Testing Hot-water Supplying Performance Evaluation Temperature Control Functional Testing Heat Keeping Func. T Boiling Func. T Idling Func. T Temperature Display Functional Testing Water-level Meter Functional Testing Cover open/close Functional Testing Service Layer Function Layer Platform Layer Default Configuration and Display Functional Testing HK Start Func. T HK Stop Func. T Eco mode Perf. E B Start Func. T B Stop Func. T Boiling Perf. E De-chlorine Perf. E Time Perf. E Timer Functional Testing
- 155.
- 156. © NISHI, Yasuharu156 テストアーキテクチャレベルのテストデザインパターン •パターンを上手に使うと、すっきりしたテストアーキテクチャになる – 例）クラスタ分割： » ごちゃごちゃしたテストコンテナを、凝集度の高いテストコンテナと、 コンテナ間の組み合わせテストを表すコンテナに分割して整理するパターン 観点A 観点B 観点C 観点P 観点Q 観点R 観点A 観点B 観点C 観点P 観点Q 観点R 観点B 観点Q コンテナW コンテナX コンテナY コンテナZ
- 157. © NISHI, Yasuharu157 パターンによるテストアーキテクチャのリファインの例 •いくつかのテストデザインパターンを用いてリファインを行った – 左右の図は両者とも準ミッションクリティカルシステムのソフトウェアである » マインドマップを使っているので記法は厳密にはNGTに従っていない – 左図をリファインして右図のテストアーキテクチャモデルにした – 右図のテストアーキテクチャは全体の把握や テスト詳細設計がしやすくなっていると感じられる リファイン
- 158. © NISHI, Yasuharu158 ウォーターフォールプロセス？反復型プロセス？ •VSTePはウォーターフォール型の開発やテストが向いているのか？ – VSTePに限らず体系立ててプロセスの説明をすると 説明の順がウォータフォールになりがちなので、 プロセスの中身もウォーターフォール限定ではないかと勘違いされることがある – テスト対象の要求やテストプロジェクトの制約、メンバのスキルや理解度によって、 ウォーターフォール的が適しているか反復的マネジメントが適しているかは異なる » 要求信頼性 » 耐監査度 » 開発全体が反復的かどうか » テストオペレータのテスト対象の理解度 » ソフトウェア設計やコードの質 » など – VSTePを反復型開発に適用する際にはコツがある
- 159. © NISHI, Yasuharu159 反復開発におけるVSTePのコツ •イテレーションごとに テスト要求モデルとテストアーキテクチャモデルを改善していきながら、 イテレーションナビゲーションを行う – イテレーションごとに何をテストするのかを、テストコンテナ図を使ってナビゲーションしていく » 保証できたテスト観点の種類と程度によって次に何をするかを動的に決める » コンテナに色をつけていくと直感的になる – 最初は曖昧なコンテナ図になっても構わないが、進むに従って地図の精度を上げていく – 後半は横串を通すようなテストが増えてくるため、イテレーションごとの開発規模を減らすか、 テストチームによるテスト用のイテレーションをつくるか、などの選択が必要になるので、 コンテナ図を用いるなどして早めに予想して事前に仮判断しておく • 1回のイテレーションコンテナに、スクリプトテストと探索的テストを両方入れる – スクリプトテストの深掘り的な探索ばかりすると仕様の後追いになりがちでよくない – イテレーションの時期に応じてスクリプトテストと探索的テストのバランスを変える » バグの状況が把握しやすく余裕がある時は“スクリプト重→探索重→スクリプト重”のパターンで、 把握しにくく余裕が無い時は“探索重→スクリプト重→探索重”のパターンになる • 1回のイテレーションで必ずテスト観点リフレクションの時間を取る – リフレクションによって観点図やテストコンテナ図を書き換えて（書き加えて）いく – モデルの質を高く保っておかないとすぐに何をテストしているのか分からなくなる
- 160. © NISHI, Yasuharu160 VSTeP導入のコツ •組織文化を変えようとせずにVSTePを導入しても上手くいかない場合がある – 何かに従っていれば仕事をしたことになる文化 – 頭を使わない文化 » 「テスト開発方法論 ＝ 概念／記法＋プロセス＋モデリング技術」なので、 記法とプロセスを文書化して整備しても、モデリング技術を鍛えないと使いこなせない • 導入推進者はVSTePのTIPSだけではなく、 VSTePを適用している現場の悩みの理解も必要である – 導入そのものの改善をマネジメントする必要がある • プロセス改革的なトップダウンのアプローチよりも、 改善型のボトムアップのアプローチの方が、 時間がかかるが上手くいくことが多い – リーンスタートアップで現状の問題点や改善の成果を実感してもらいながら進める方がよい » Reverse VSTeP – リバース→フォワード→リバース…という導入ができるとよい • テストの改善だけで終わらせず、 レビューの改善や開発の改善まで長期的視野に入れる方が根付きやすい
- 161. © NISHI, Yasuharu161 ReverseVSTePによるテストの改善 • Reverse VSTeP: テスト設計をリバースモデリングする手法 – 要求からテストスクリプトを作成していく流れをForward VSTeP、逆をReverse VSTePと呼ぶ – Reverse VSTePとは、既存の（十分設計されていない）テストケース群から テスト観点モデルをリバースモデリングして改善する手法群である » 実際のテストケースを分析して、 どういうテスト観点や関連でテストしようとしているかを列挙・整理し改善する » 実際に見逃したバグや検出されたバグ、テストケース外で検出されたバグを 分析して、どういうテスト観点や関連が足りなかったかを列挙・整理し改善する · テスト観点を網羅したつもりでも、解釈が曖昧だったり不適切な場合や、剪定に失敗してしまった場合もある – リバースしないVSTePをForward VSTePと呼ぶこともある • カバレッジ分析による改善 – 見逃したバグや検出できたバグ、実際のテストケースなどを分析して、 テスト観点は特定できているのにカバレッジ基準・達成率が低すぎた場合や、 特異点が存在してしまった場合、不適切なリスク値（工数不足）の場合と いった原因を明らかにし、カバレッジ基準・目標率、不足した・誤った前提、 リスク値判定基準などを改善したり、テスト観点や関連を改善する » 仕様で示された同値クラスが必ずしも設計・実装上の同値クラスと 一致するとは限らないため、テスト設計時の「前提」が重要となる » 関連よりもテスト観点として取り扱う方がよい場合もある
- 162. © NISHI, Yasuharu162 ReverseVSTePによるテストの改善 • ステレオタイプ分析による改善 – テスト観点モデルの各詳細化関係の種類やMECE性を分析し、 テスト観点が適切かつ網羅的に詳細化されるように 子テスト観点を追加したりモデルをリファクタリングして改善する • 不具合モード分析による改善 – 見逃したバグや検出されたバグをパターン化して、 ピンポイント型のテスト観点を追加・整理し改善する • ディレイ分析によるテストアーキテクチャの改善 – 見逃したバグや検出されたバグを分析して、 実際のテストレベルやテストタイプを リバースされたテスト観点モデルにマッピングし、 テストアーキテクチャ設計（テストレベルの設計）をレビューし改善する • 傾向分析によるリスク値の改善 – 見逃したバグや検出されたバグを分析して、各テスト観点のリスク値 （利用頻度、致命度、欠陥混入確率など）を改善する
- 163. © NISHI, Yasuharu163 テスト観点のリバースは技術力把握にも有効 •テスト観点をリバースするとテスト設計者の意図が透けて見えてしまうので、 テスト設計者の技術力が分かってしまう – この3つのモデルは、同じ組織・同じ経験・同じテストスキルを持っていると主張する 3名のエンジニアの負荷テストの設計モデルである 仕様 境界 負荷テスト 性能 負荷 負荷テスト 境界 仕様 境界 負荷テスト 性能 負荷 負荷に 弱い設計 様々な 負荷のかけ方が 漏れる 負荷に弱い設計の 性能低下が漏れる 技術力が高い
- 164. © NISHI, Yasuharu164 VSTePの応用 •VKDT：VSTeP + KDT（キーワード駆動テスト） – VSTePをベースにテストの自動化を行うと、 テストケースの自動生成からKDTを通じて自動実行までシームレスにつながるので、 （さほど大きくない）仕様変更や設計変更に対する確認テストをターンキーにできる • レビュー観点や開発考慮事項へのフロントローディング（VSPI／Wモデル） – レビューの改善というと会議術の話ばかりで、レビューの中身の質につながらない » 一回一回のレビューがやりっ放しになっていて、知恵の蓄積がされていない » 参加者が思いつきを言うだけの会になってしまったりするので、ちっともまとまらない » 全体としてどんなレビュー（群）をすべきなのか、というレビュー（群）の全体像を誰も掴んでいない – VSTePを応用して、レビュー観点をベースにレビューケースの設計や レビューアーキテクチャの可視化を行うことができる – さらにフロントローディングすると、開発で考慮すべき事項をモデリングできるようになる » Wモデルの一形態である • グローバル開発におけるテストの組織化 – ソフトウェア開発のグローバル化は進んでいるが、テストやQAはこれからという組織が多い – VSTePをベースにすると、日本HQ、海外開発センター、 現地ソフトハウスの役割分担の見通しがよくなる
- 165. © NISHI, Yasuharu165 VSTePによるテストの自動化：VKDT(KDT+MBT) •テストの自動化は、人間が頭を使わないといけない作業を明確にしてくれる – こうした作業を明確にしないと、どこまで網羅できたのかを説明しにくくなる – 自動化には4つの技術レベルがある » よいツールはKDTまでカバーしているが、何でも自動化できると思ってはいけない • 自動操作ツールによるキャプチャ＆リプレイ（C&R）世代 – キャプチャが必要となるため、多くのバリエーションをテストするには手間がかかる • データ駆動テスト（DDT）世代 – 全く同じ操作でデータだけが異なる場合は、ツールが自動でデータの書かれた Excelファイルを読み込んでバリエーションを自動で作成し実行してくれる » しかし単純な操作の組み合わせのようなバリエーションは、自動化テストスクリプト そのものを変更しなくてはならないため依然として手間がかかる • キーワード駆動テスト（KDT）世代 – 単純な操作（キーワード）をスクリプトライブラリと関連づけておくと、 テストケースをキーワード名で書くだけで、自動化テストスクリプトを意識しなくても ツールがテストケースのバリエーションを自動で作成し実行してくれる » 操作レベルの詳細なテストケースが必要なため、仕様変更にすぐに追従できない • KDT+MBT（モデルベースドテスト）世代: VKDT – テストケースの自動生成からKDTを通じて自動実行までシームレスにつなげることで、 （さほど大きくない）仕様変更や設計変更に対する確認テストがターンキーになる – 自動化すべきところとすべきでないところ、しやすいところとしにくいところの弁別が重要 – 自動化を前提とした開発上流の仕様調整やモデル化とテストプロセスの整備も重要
- 166.
- 167. © NISHI, Yasuharu167 グローバル開発におけるテストの組織化 日本HQ/DC 北米DC欧州DC アジアDC 現地SH現地SH現地SH 現地SH現地SH ・テスト観点ベースの 参照アーキテクチャ／パターン ・参照テストプロセスモデル ・他DCでの不具合モード ・テスト観点ベースの 各拠点のテストアーキテクチャ事例 ・各DCでのテストプロセステーラリング事例 ・各DCでの不具合モード ・各現地SHに対して指示する個別テスト観点 および不具合モード ・29119に準拠した テスト詳細設計／実装／実行プロセス ・探索型テストのチャーター ・指示された個別テスト観点に対する テストケースやテスト手順、テスト結果 ・プロセス起因の生産性阻害要因 ・探索して新たに見つかったテスト観点 や不具合モード
- 168. © NISHI, Yasuharu168 グローバル開発におけるテストの組織化 日本HQ/DC 北米DC欧州DC アジアDC 現地SH現地SH現地SH 現地SH現地SH ・テスト観点ベースの 参照アーキテクチャ／パターン ・参照テストプロセスモデル ・他DCでの不具合モード ・テスト観点ベースの 各拠点のテストアーキテクチャ事例 ・各DCでのテストプロセステーラリング事例 ・各DCでの不具合モード ・各現地SHに対して指示する個別テスト観点 および不具合モード ・29119に準拠した テスト詳細設計／実装／実行プロセス ・探索型テストのチャーター ・指示された個別テスト観点に対する テストケースやテスト手順、テスト結果 ・プロセス起因の生産性阻害要因 ・探索して新たに見つかったテスト観点 や不具合モード 拠点の責務と 取り扱う設計情報・プロセス情報の粒度を 適切に設計することで、 ノウハウを掘り出して活きた標準に落とし込み、 組織全体で改善サイクルを回すことができる
- 169. © NISHI, Yasuharu169 VSTePの意義 •丸や四角と線で絵を描くとエンジニアのように見える – エンジニア魂を刺激して 「自分は軽作業派遣ではなくクリエィティブなエンジニアなんだ」 と自覚してもらいモチベーションを上げてもらえる • テスト条件（や期待結果）を抽象化することで、 全体像をコミュニケーションしやすくなったり知恵を蓄積しやすくなる – プロジェクト個別の情報を削除して、知恵づくりに必要な情報だけを残すことができる – 全体像を把握しやすいように可視化されるのでコミュニケーションしやすくなる – 知恵の質がモデルによって比較可能になる – ソフトウェアエンジニアリングの様々な技術を応用しやすくなる – テストだけでなく、レビューや開発上流も含めた開発考慮事項を蓄積できるようになる • 頭を使うところと手を動かせばいいところを明確に分離できる – 違う頭を使うところは異なる工程になっている – 頭を使うことを鍛えるという意識が無いと、テストがよくならない » 銀の弾丸を求めている組織には向いていない – 単純作業は自動化することに頭を使うようにする
- 170. © NISHI, Yasuharu170 VSTePの意義 •現場でのリーンスタートアップがしやすくなっている – 段階的／改善的導入や一部導入がしやすい – 自組織がいま使っているフォーマットをベースにできる – ダメなテスト設計をしている組織は 当初ダメなモデルが可視化されてやる気を失うかもしれない » VSTePは万能の道具ではないので、頭を使わずにダメなテスト設計を改善することはできない • VSTePはメソドロジ・プラットフォームである – 自社のテストのやり方を尊重したまま、VSTePで問題点を整理・改善することができる » ・例）改良型ゆもつよメソッド powered by VSTeP – 様々なプロジェクトのテストのバリエーションを統一的に整理することができる » 自社の各部門や開発子会社、海外拠点などを統一的にマネジメントできるようになる – 知恵を貯めてVSTePを自社内で成長させ、 自分たちの身体に馴染む「自社版VSTeP」に仕立て上げることが重要である
- 171. © NISHI, Yasuharu171 VSTePは何でないか •VSTePは頭を使わずにテストできる魔法の道具ではない – 「この表を埋めればテストケースが完成です！」とか 「とにかく探索的テストをすればバグが見つかります」みたいなまやかしではない – 「あなたの組織で誰も想定できなかった想定外を想定できます」みたいな詐欺ではない • VSTEPはエンジニアを孤立させるものではない – ひたすら一人でフォーマットを埋めるようなぼっちめしではない • VSTePは思考停止してテストできるプロセスマニュアルではない – 分厚い手順書とフォーマットのような無能コンサルの納品物ではない – 膨大な文書群とトレーサビリティを必要とするプロセススパゲッティではない • VSTePはエンジニアを奴隷にするものではない – 意図の分からないテストケースをひたすら書いて実行して 誰も見ないスクリーンショットを積み上げる賽の河原ではない – 役に立っている実感の無い施策をやらされ感満載で強制される 経営者の自己満足の道具ではない • VSTePは全部入りではない – バグのパターン化や各種テスト技法などは別途アドオンしていく必要がある
- 172.
- 173. © NISHI, Yasuharu173 テストプロセスの国際規格：ISO/IEC/IEEE29119 • UK提案の重量級のテストプロセスおよびテスト文書モデル – 5つのパートと1つの関連標準から構成される » Part 1: 用語と概念、Part 2: テストプロセス、Part 3: ドキュメント、Part 4: 技法、 Part 5: キーワード駆動テスト、ISO/IEC 33063: テストプロセスアセスメントモデル – テストプロセスが未成熟な組織が教科書として読む分にはよくできている » きちんと適用するにはトレーサビリティ管理などが必要となる – IEEE829はもう更新されず、ISO/IEC/IEEE29119-3に一本化される » ISO/IEC/IEEE29119-3はAutomotive SPICEのver3から参照されるようになった – Part 1～4は国際標準として発行され、Part 5は今年中に発行されるだろう • ３つの特徴がある – ３階層モデル » 組織横断的なテストポリシー・テスト戦略、PJごとのテスト計画、PJごとのテスト実行 – リスクベースドアプローチ » テストの意図や間引きのデメリットを明示的に検討する – 汎用的なテストプロセス記述 » 異なるテストタイプもテストレベルも同じ構造のプロセスモデルで記述している
- 174. © NISHI, Yasuharu174 テストプロセスの国際規格：ISO/IEC/IEEE29119 • ISO/IEC/IEEE29119の考え方 – 製品提供企業が全体的なテストポリシーやテスト戦略を定め、 ブレークダウンしていくテストのプロセスである » PJ横断的なテストポリシーやテスト戦略に従って、プロジェクトごとのテスト計画を立て、 テスト実行していく考え方のテストプロセスモデルである » テストポリシーやテスト戦略からテスト計画、テスト設計へのトレーサビリティと共に、 きちんとブレークダウンされていることを自分たち自身が納得する必要がある » テストケースの意図を把握し、間引きのデメリットを納得する必要がある – 製品提供企業が発注先企業を厳密に報告させて承認したり、 単に監査して（見かけだけの）ガバナンスを達成するプロセスではない » テストのゴールとして何を達成したいのか、どういうテストが必要になるのか、 どういうリスクが発生すると（テストを間引くと） どういうまずいことになりどう対処するのか、 などを製品提供企業と発注先企業できちんと納得し合わないと上手くいかない – 銀の弾丸（魔法の杖）のように29119を導入すれば上手くいく、と考えてはいけない
- 175.
- 176. © NISHI, Yasuharu176 グローバル開発におけるテストの組織化 日本HQ/DC 北米DC欧州DC アジアDC 現地SH現地SH現地SH 現地SH現地SH ・テスト観点ベースの 参照アーキテクチャ／パターン ・参照テストプロセスモデル ・他DCでの不具合モード ・テスト観点ベースの 各拠点のテストアーキテクチャ事例 ・各DCでのテストプロセステーラリング事例 ・各DCでの不具合モード ・各現地SHに対して指示する個別テスト観点 および不具合モード ・29119に準拠した テスト詳細設計／実装／実行プロセス ・探索型テストのチャーター ・指示された個別テスト観点に対する テストケースやテスト手順、テスト結果 ・プロセス起因の生産性阻害要因 ・探索して新たに見つかったテスト観点 や不具合モード
- 177. © NISHI, Yasuharu177 グローバル開発におけるテストの組織化 日本HQ/DC 北米DC欧州DC アジアDC 現地SH現地SH現地SH 現地SH現地SH ・テスト観点ベースの 参照アーキテクチャ／パターン ・参照テストプロセスモデル ・他DCでの不具合モード ・テスト観点ベースの 各拠点のテストアーキテクチャ事例 ・各DCでのテストプロセステーラリング事例 ・各DCでの不具合モード ・各現地SHに対して指示する個別テスト観点 および不具合モード ・29119に準拠した テスト詳細設計／実装／実行プロセス ・探索型テストのチャーター ・指示された個別テスト観点に対する テストケースやテスト手順、テスト結果 ・プロセス起因の生産性阻害要因 ・探索して新たに見つかったテスト観点 や不具合モード 拠点の責務と 取り扱う設計情報・プロセス情報の粒度を 適切に設計することで、 ノウハウを掘り出して活きた標準に落とし込み、 組織全体で改善サイクルを回すことができる
- 178. © NISHI, Yasuharu178 テスト改善の技術 •実態駆動型テスト改善 – 実際のテスト漏れ、工程内検出バグ、テストスイートなどから テスト分析・設計をリバースし、テストを改善していく方法 – 難しいことをわざわざ勉強しなくても適用できるが、 改善の方向性をしっかり考えることが必要になる – ひたすらカバレッジ率を上げて個別最適に突き進む罠に陥りやすい • モデル駆動型テスト改善 – テスト改善モデルを軸に、 （多くはプロセス単位で）あるべき姿と現状とのギャップ分析を行い、 そのギャップを埋めるように達成度を定めテストを改善していく方法 » 基本的思想は開発プロセス改善モデルと同様 » TPIやTMMi、ISO/IEC33063がある · ISO/IEC 33063は29119-2をプロセス参照モデルとしたSPICE(15504s/33000s) – テスト改善モデルの思想や方向性、技術、用語などを しっかり理解する必要がある » 欧米発のテスト改善モデルは上流への貢献という思想が弱い – 改善を進めても現場の問題が解決されない罠に陥りやすい
- 179. © NISHI, Yasuharu179 実態駆動型テスト改善の例：ReverseVSTeP • テスト観点モデルのリバースモデリングによる改善 – 実際のテストケースを分析して、 どういうテスト観点や関連でテストしようとしているかを列挙・整理し改善する – 実際に見逃したバグや検出されたバグ、テストケース外で検出されたバグを 分析して、どういうテスト観点や関連が足りなかったかを列挙・整理し改善する » テスト観点を網羅したつもりでも、解釈が曖昧だったり不適切な場合や、 剪定に失敗してしまった場合もある • カバレッジ分析による改善 – 見逃したバグや検出できたバグ、実際のテストケースなどを分析して、 テスト観点は特定できているのにカバレッジ基準・達成率が低すぎた場合や、 特異点が存在してしまった場合、不適切なリスク値（工数不足）の場合と いった原因を明らかにし、カバレッジ基準・目標率、不足した・誤った前提、 リスク値判定基準などを改善したり、テスト観点や関連を改善する » 仕様で示された同値クラスが必ずしも設計・実装上の同値クラスと 一致するとは限らないため、テスト設計時の「前提」が重要となる » 関連よりもテスト観点として取り扱う方がよい場合もある
- 180. © NISHI, Yasuharu180 ReverseVSTePによるテストの改善 • ステレオタイプ分析による改善 – テスト観点モデルの各詳細化関係の種類やMECE性を分析し、 テスト観点が適切かつ網羅的に詳細化されるように 子テスト観点を追加したりモデルをリファクタリングして改善する • 不具合モード分析による改善 – 見逃したバグや検出されたバグをパターン化して、 ピンポイント型のテスト観点を追加・整理し改善する • ディレイ分析によるテストアーキテクチャの改善 – 見逃したバグや検出されたバグを分析して、 実際のテストレベルやテストタイプを リバースされたテスト観点モデルにマッピングし、 テストアーキテクチャ設計（テストレベルの設計）をレビューし改善する • 傾向分析によるリスク値の改善 – 見逃したバグや検出されたバグを分析して、各テスト観点のリスク値 （利用頻度、致命度、欠陥混入確率など）を改善する • ジャックナイフ型テストプロセスによるテスト設計の改善 – 探索型テストやテストケース外で検出されたバグを進行中に分析し、 テスト設計やテストプロセスの改善に結びつけていく
- 181. © NISHI, Yasuharu181 モデル駆動型テスト改善の例：TPIのKeyArea 1. テスト戦略 A: 単一高位レベルテスト B: 高位レベルテストの組み合わせ C: 高位レベルテストに低位レベルテスト or評価の組み合わせ D: 全てのテストレベルと評価レベルの 組み合わせ 2. ライフサイクルモデル A: 計画、仕様化、実行 B: 計画、準備、仕様化、実行、完了 3. 関与の時点 A: テストベースの完成時点 B: テストベースの開始時点 C: 要求定義の開始時点 D: プロジェクトの開始時点 4. 見積もりと計画 A: 実証された見積もりと計画 B: 統計的に実証された見積もりと計画 5. テスト仕様化技法 A: 非公式の技法 B: 公式の技法 6. 静的テスト技法 A: テストベースのインスペクション B: チェックリスト 7. 尺度 A: プロジェクト尺度（成果物） B: プロジェクト尺度（プロセス） C: システム尺度 D: 組織尺度（複数システム） 8. テストツール A: 計画ツールと制御ツール B: 実行ツールと分析ツール C: テストプロセスの自動化強化
- 182. © NISHI, Yasuharu182 モデル駆動型テスト改善の例：TPIのKey Area 9. テスト環境 A: 管理され制御された環境 B: 最適環境におけるテスト C: 要求に即応できる環境 10. オフィス環境 A: 適切かつタイムリーなオフィス環境 11. コミットメントと意欲 A: 予算と時間の割り当て B: プロジェクト組織に統合されたテスト C: テストエンジニアリング 12. テスト役割と訓練 A: テスト管理者とタスク B: （公式の）手法的、技法的、 機能的支援、管理 C: 公式の内部品質保証 13. 方法論の展開 A: プロジェクトで固有 B: 組織で共通 C: 組織で最適化、研究開発 14. コミュニケーション A: 内部コミュニケーション B: プロジェクト内コミュニケーション （欠陥、変更管理） C: テストプロセスの品質についての 組織内コミュニケーション 15. 報告 A: 欠陥 B: 進捗（テストと成果物のステータス）、 アクティビティ（コスト、時間、 マイルストーン）、欠陥と優先度 C: リスクと提言、尺度による実証 D: ソフトウェアプロセス改善特性への提言
- 183. © NISHI, Yasuharu183 モデル駆動型テスト改善の例：TPIのKey Area 16. 欠陥管理 A: 内部欠陥管理 B: 柔軟な報告機能による 広範な欠陥管理 C: プロジェクト欠陥管理 17. テストウェア管理 A: 内部テストウェア管理 B: テストベースとテスト対象物の外部管理 C: 再利用可能なテストウェア D: テストケースに対する 追跡性システム要求 18. テストプロセス管理 A: 計画と実行 B: 計画、実行、監視、調整 C: 組織における監視と調整 19. 評価 A: 評価技法 B: 評価戦略 20. 低位レベルテスト A: 低位レベルテストライフサイクルモデル （計画、仕様化、実行） B: ホワイトボックス技法 C: 低位レベルテスト戦略 Tim Kooman / Martin Pol 著, 富野壽監訳: “テストプロセス改善 - CMM流実務モデル” を邦訳 注意点： － 鵜呑みにしない －現実・現場の問題点を見る －改善を回すプロセスが重要
- 184.
- 185. © NISHI, Yasuharu185 モデル駆動型テスト改善の例：TMMi 1. 実施されたレベル 2. 管理されたレベル – テストのポリシーと戦略 – テストの計画 – テストの監視と制御 – テストの設計と実施 – テストの環境 3. 定義されたレベル – テストの組織 – テストの教育訓練 – テストのライフサイクルと統合 – 非機能テスト – ピアレビュー 4. 定量的に管理されたレベル – テストの測定 – ソフトウェアの品質評価 – 進んだピアレビュー 5. 最適化しているレベル – 欠陥予防 – テストプロセスの最適化 – 品質管理 TMMi Foundation: “Test Maturity Model Integration (TMMi) Version 2.0” を邦訳 注意点： － 鵜呑みにしない －現実・現場の問題点を見る －改善を回すプロセスが重要
- 186. © NISHI, Yasuharu186 テストプロセス改善の実施例 •泥臭いが効果的である – テストチームへの受け入れテストを行う » バグが多すぎるとレポート作成に時間を取られてテストが進まない – テスト環境の構築を十二分に考慮してプロジェクトを進めておく » 開発環境で動いた機能をテスト環境で動かすには想像以上に時間がかかる » テスト環境と実機の差異をできるだけ減らすようにする – 仕様書をきちんと作成し保守しておく » 仕様書が無いとリバースエンジニアリングになる » 期待結果を調べるだけで時間がかかる – 不具合の切り分けでテストがストップしないようにする » あらかじめ切り分け担当者を配置しテストと並列で実施する » 切り分けが楽になるよう実機テストにソフト単体のバグを持ち込まない – ドキュメント作成の手間を減らす » フォーマット／テンプレート／例文を準備しておく – 再現性を確保し手戻りを減らすように記録をきちんと取っておく
- 187. © NISHI, Yasuharu187 忘れられがちな改善ポイント •テスト項目の粒度 – 粒度とはテスト項目の記述の詳細度 » ログインする／ユーザ名にNsh、次にパスワードにESECと入力し[OK]を押す – テスト実施担当者のスキルによって粒度を変える必要がある – 期待結果やチェックポイントの粒度も問題になる » 「きちんと動作すること」は、どこの何を見れば分かるのか？ » 粒度を細かくすると設計工数がかかるが実施時に悩む時間は減る · 粒度を粗くしてテスト実施者の自由度を組み込むこともある • モチベーションも重要 – 集中力を落とさないようにテスト実施順序を工夫する必要がある – 単純作業に感じさせないように目的や責任、権限を与える必要がある • テスト技術者に必要な才能 – 誠実さ／忍耐／細部まで観察できる能力／経験をパターン化する能力 ／組み合わせの概算力／他の人の気持ちが分かること など
- 188. © NISHI, Yasuharu188 テストプロセスで改善すべきポイントの例 •テスト設計／実装時のポイント – 仕様にモレ、不明確、矛盾といった問題があるため、 正しいと思われる仕様の検討と策定に時間がかかってしまう – 仕様変更や設計変更、品質要件の変更によって、 テストの再設計や再実装が必要になったり、 テスト環境の追加による手配や環境構築に時間がかかってしまう – テスト担当者間にスキルの差があり、 テストの質が一定に保てないためテスト結果が信頼できなくなってしまう • テスト実施時のポイント – 担当者の操作ミスによるテスト項目の再実施や、操作ミスによるデータベースなど 状態変化のため初期状態からの再テストに時間がかかってしまう – テスト担当者のモチベーションの低下や疲れなどから、実施効率が低下したり、 質の低い不具合報告書の手戻り作業に時間がかかってしまう – 不具合の影響が大きく、テストが進まない状態になってしまう （テストブロックやショーストッパーと呼ぶ） – 開発チームとテストチームが作業実施環境を共有している場合、 予想外の不具合などの発生により、テストチームでの作業ができなくなってしまう – 不具合の発生によりマシンやOS、ミドルウェアなどが破損してしまい、 修復に時間がかかってしまう
- 189. © NISHI, Yasuharu189 不具合が検出された際に増える作業 •期待結果の作成に関する作業 – 仕様書の調査や開発側へのヒアリング – 仕様書との突き合わせ • 検出された不具合に関する作業 – 検出された不具合の再現性を確認するための再現テスト – 検出された不具合の発生範囲を切り分けるための探索テスト – 検出された不具合に関するデータの収集と整理、 および不具合報告書の作成 – 口頭やミーティングでの不具合の内容に関する報告 • その後のテスト作業の調整に関する作業 – そのテスト項目が動作しないことによって 実施不能になるテスト項目の検討 – 同様の不具合を検出するための テストの再設計および再実装に関する検討 不具合率が 高いのは 大きなリスクである
- 190. © NISHI, Yasuharu190 信頼度成長曲線によるテストプロセス改善 •バグの分布と均一なテストを仮定して、 残存バグ数を統計的に推定する方法 – ゴンペルツ曲線やロジスティック曲線を当てはめる » 「ソフトウェア信頼性モデル－基礎と応用」，山田茂著，日科技連出版 » フリーや商用のツールがある – 統計的に信頼できるほどプロセスが定まっておらず 過去のデータもないのであれば、残存バグ数推定などは難しい – そもそも適切にテストが設計できてないので大きな抜けなどがある – 中身をきちんと考慮しないと統計値で出荷判断してはいけない こうなると言われているが こうなることの方が多い バグの分布のムラとテストのムラを きちんと考慮しないといけない
- 191. © NISHI, Yasuharu191 信頼度成長曲線によるテストプロセス改善 •最低限何を考えるべきか：統計値が全てではない – どんなテストをどの程度設計したか » 要求カバレッジ、仕様カバレッジ、設計カバレッジ、実装カバレッジ » テスト設計技法の持つ特徴など – どんなテストをどの程度実施したか » 実施カバレッジ、テスト密度、テスト粒度 » テストサイクル数、テスト件数など – どんなバグがどの程度見つかったか » バグの致命度、バグの数、発生頻度、発生条件 » 発生場所の偏り、類似のバグの数、原因特定時間など – どんな修正をどの程度直したか » 修正にかかる時間、修正にかかる時間のばらつき » 類似のバグをどの程度修正したか、デグレードの程度 » 未修正バグの数、未修正バグの重要度など • 信頼度成長曲線を運用する前に 管理図でプロセスを定量化してみるとよいだろう – ただしばらつき管理や出荷基準として用いるのではなく、 パターン認識で「悪さ」の兆候を見抜くツールとするのがよいだろう
- 192. © NISHI, Yasuharu192 テストプロセス改善のツール：バグ管理図 •テスト項目の消化とバグの検出数のバランスを 折れ線グラフで管理する手法 – テストの改善が進むと実現できる – 右のグラフは以下を示唆している » テストの質が悪い » テストが偏っている » テストが粗すぎる » 品質がよい？ – 定量的推定よりは形による パターン認識の方が効果的 バグ摘出 予定線 テスト項目 消化予定線 バグ摘出 実績線 テスト項目 消化実績線 出展：「ソフトウェア品質保証の考え方と実際」 保田勝通著／日科技連出版社
- 193. © NISHI, Yasuharu193 テストプロセス改善のツール：バグ管理図 •テスト項目の消化とバグの検出数のバランスを 折れ線グラフで管理する手法 – 右のグラフは以下を示唆している » 作り込んだバグの量が多く テストが進まない » デグレードが多発している » テストの質がよい？ バグ摘出 予定線 テスト項目 消化予定線 バグ摘出 実績線 テスト項目 消化実績線 出展：「ソフトウェア品質保証の考え方と実際」 保田勝通著／日科技連出版社
- 194. © NISHI, Yasuharu194 テストプロセス改善のツール：バグ管理図 •テスト項目の消化とバグの検出数のバランスを 折れ線グラフで管理する手法 – 右のグラフは以下を示唆している » テストの要員不足や環境未整備 によりテストが進まない » バグ修正が迅速に行われないので テスト要員が待ち状態になっている » 仕様が未整備のため結果判定に 手間を取られテストが進まない バグ摘出 予定線 テスト項目 消化予定線 テスト項目 消化実績線 出展：「ソフトウェア品質保証の考え方と実際」 保田勝通著／日科技連出版社 バグ摘出 実績線
- 195. © NISHI, Yasuharu195 テストプロセス改善のツール：バグ管理図 •テスト項目の消化とバグの検出数のバランスを 折れ線グラフで管理する手法 – 右のグラフは以下を示唆している » 同じようなバグを何度も摘出している » 理想的なパターン？ バグ摘出 予定線 テスト項目 消化予定線バグ摘出 実績線 出展：「ソフトウェア品質保証の考え方と実際」 保田勝通著／日科技連出版社 テスト項目 消化実績線
- 196. © NISHI, Yasuharu196 テストによる改善 •テストの改善を進めると、プロセス全体の改善が必要だと気づく – テスト容易性設計 » テストが容易になるよう気遣うことで、設計をスッキリさせる – 同値クラス漏れの分析・設計へのフィードバック » 分析・設計での同値クラスの考慮不足を改善する – 同値クラスの確定のためのレビュー » テスト設計で想定した通りに例外的な処理をしないよう改善する – Ｗモデルの導入 » 分析・設計・実装とテスト設計とを同時に進めることにより、 レビューを改善するとともに、依存関係を減らして設計をスッキリさせる – 不具合モードによるレビュー・開発の改善 » バグが作り込まれやすいところをレビューしたり、 バグを作り込まないように開発ガイドラインを作る テストの改善をきっかけにして、 そもそもバグを作り込みにくい 開発プロセスに改善していく
- 197. © NISHI, Yasuharu197 テストと開発が協調した開発プロセス：Wモデル 要求分析 基本設計 詳細設計 実装 単体テスト の実施 結合／機能テスト の実施 システムテスト の実施 コードインスペクション の実施 システムテストの設計 結合／機能テストの設計 単体テストの設計 コードミスの 逐次検出 AndreasSpillner: “The W-MODEL – Strengthening the Bond Between Development and Test” を修正 Wモデルによってテストを前倒しし、 プロダクト的な悪さの知識を フィードバックする
- 198. © NISHI, Yasuharu198 Wモデル：テストと開発が協調した開発プロセス Andreas Spillner: “The W-MODEL – Strengthening the Bond Between Development and Test” STAREAST2002
- 199. © NISHI, Yasuharu199 Wモデルを支えるテスト技術 •基本的なテスト技術 – 体系的なテスト技法の活用、期待結果の導出 – 網羅テストの段階的詳細化 – テストレベルの設計もしくは解釈 • 進んだテスト技術 – 組み合わせテスト設計、Critical Combination Analysis、禁則分析 – テスト観点の抽出・整理・体系化 – 不具合モード分析・後工程不具合リスク分析 – リスクベースドテスト – グレーボックステスト – 探索型テスト • 開発全般に関わる テスト技術 – テスト容易性設計 – 出荷判定基準の明確化 基本設計 詳細設計 実装 単体テスト の実施 コードインスペクション の実施 システムテストの設計 結合／機能テストの設計 単体テストの設計 コードミスの 逐次検出 テストの改善をきっかけにして、 そもそもバグを作り込みにくい 開発プロセスに改善していく
- 200. © NISHI, Yasuharu200 Wモデルの効果：タイプ１ •単純に作業順序を入れ替えるだけだが、 上流でテストを設計することで細かく考えることができ、 抜け漏れ矛盾を減らすことができる – テスト設計をきちんと行うことで検出できる不具合を、 下流まで遅らせることなく上流で検出することにより、 不具合の伝播や増殖、不要な設計変更などのムダを省くことができる » 開発者は開発時に主要な仕様や設計を考えるに留まり、 実は細かくは考えていないことが多い » 仕様や設計が複数の組織やバージョンに由来し、整合性を取れていないことがある » テストに頼る風土の組織では、一貫性すらきちんと確認していないことがある • テスト設計の質を少しだけ向上することができる – 仕様や設計を行った直後にテストを設計するような手順にすると、 極めて単純なテストの抜け漏れだけは防ぐことができる » テストの抜け漏れが何でも防げるわけではない
- 201. © NISHI, Yasuharu201 Wモデルの効果：タイプ１の注意点 •テスト設計をきちんと行っていない組織では効果が出ない – アドホック型やコピー＆ペースト＆モディファイ型のテスト設計では、 テスト設計時に不具合が検出できることが少ないため、 テスト設計を上流にシフトしても効果は少ない » 何をどれくらい網羅し、どういう理由でどのくらい間引くかを 明示していない組織では、抜け漏れ矛盾を見つけることができない • レベル１に留まったままだと逆に問題が起きやすい – 開発上流で膨大なテストケースを記述することになるため、 仕様変更・設計変更時に膨大なテストケースの書き直し作業が必要となり、 工数超過を起こしてしまう » 仕様の書き方をそもそも改善しないといけない » テストケース生成ツールで自動生成させたくなるが、 自動生成させると抜け漏れ矛盾が見つかりにくくなる » 結局のところ「テスト設計とは何か」をきちんと考えないといけない
- 202. © NISHI, Yasuharu202 Wモデルの効果：タイプ２ •開発組織がいま持っている観点できれいに作る （汚く作らせまいとする）よう圧力をかけることができる – 開発者は「もっとすっきりさせたいが時間がない」というジレンマを抱えている » 上流で（組み合わせ）テスト項目数を概算することで「もっとすっきりさせないと、 テストで膨大な時間がかかる」と圧力をかけることができる – （組み合わせ）テスト設計を上流で行うことで、 仕様や設計、コードがすっきりし、不具合を減らすことができる » 組み合わせテスト設計で結合度の低下や依存関係の存在をきちんと把握するので 開発時に予期していない副作用（組み合わせ不具合の芽）を防ぐことができる » 不必要な依存関係や禁則を持った仕様を減らすことができる – テスト容易性を検討でき、作り込むことができる » テスト設計しやすい仕様・設計・コードは、 可読性が高く複雑度が低いうえに、ふるまいを予測しやすい • テスト設計の質を向上することができる – すっきり作ってあれば依存関係を追いやすく例外事項が少ないため、 工数を増やさずに抜け漏れを少なくできる
- 203. © NISHI, Yasuharu203 Wモデルの効果：タイプ３ •開発組織がいま持っていないような 多面的な観点から気をつけて作ることができる – 開発者はあらゆる観点から検討しているようで、 採用した開発のやり方に固有の観点抜けが出てしまう » 例）制御系の開発では状態遷移の検討の抜けが発生しやすい – テスト設計の際に観点を俯瞰的・多面的に列挙し整理することで、 開発者が気づいていない観点を示唆することができる » テスト技術者は過去の不具合の分析などにより、 抜けやすい観点を知っている場合がある » 開発者は開発対象に必要な観点を絞り込むように頭を使うが、 テスト技術者はテスト対象を俯瞰的・多面的に捉えようとする – 必ずしもテストケースを詳細に記述する必要はない • テスト設計の質を向上することができる – 開発時に検討した観点をテストで共有することで、 特に内部構造に関するテスト設計の質を向上できる
- 204. © NISHI, Yasuharu204 Wモデルの効果：タイプ４ •開発組織が忘れがちな、要求分析・設計・実装工程の 「由来」と「行く末」を常に意識し、両者の乖離を防ぐことができる – 開発者は意外に「なぜそういう設計をしているのか」や 「こういう設計変更を行うとシステム全体としてはどういう振る舞いをするのか」 などを考えずに開発しているため、「由来」と「行く末」が乖離してしまう – テスト設計の際に網羅型テストの段階的詳細化を行うことにより、 由来（要求や制約、根拠）をイメージバックしながら開発できるようになる » どのような要求群から成り立つのか、どのような制約がありうるのか、 などを常に考えながら作るようになる – テスト設計の際に出荷判定基準の明確化や期待結果の導出を行うことにより、 行く末（出荷基準やトリアージ順位、ふるまい）を イメージフォワードしながら開発できるようになる » どのような出荷基準になっているのか、どのようなトリアージ順位になっているのか、 などを常に考えながら作るようになる – 由来と行く末が乖離する開発に歯止めをかけることができるようになる • テスト設計の質を向上することができる – テスト目的を常に意識するため、心配だからという理由のテストが減っていく
- 205. © NISHI, Yasuharu205 Wモデルの効果：タイプ５ •開発組織の持っている弱点を明確にし防ぐことができる – 下流で不具合モード分析を行って当該工程の弱点をフィードバックしてもらう ことにより、頻発する不具合を防止した開発ができるようになる » 下流での不具合モード分析により、 自分たちが作り込みやすい不具合のパターンや ドメイン特有の作り込みやすい不具合のパターンを把握し、 最初から気をつけて開発することができる » 「上流からの品質の作り込み」とは、 必要なノウハウを必要な時期に必要なだけ駆使することであり、 最初から矛盾の無いものを作って矛盾の無いように自動生成することではない – 上流で後工程不具合リスク分析を行って、上流で気付いていた「心配事」を 当該工程にフィードフォワードしてもらうことにより、 分かっていたのに起きてしまった検討漏れを減らすことができるようになる » 上流での後工程不具合リスク分析により、 工程が進んだ後に不具合になる リスキーな仕様・設計・コードの情報をもらうことができ、 リスキーな部分に常に気をつけて開発することができる • テスト設計の質を向上することができる – 不具合が作り込まれている確率の高いところからテストすることができる
- 206. © NISHI, Yasuharu206 Wモデルの進化：フィードバック時間の減少 •各タイプの効果をあげるように テスト技術を進化させ前倒しすることで 開発上流から品質の作り込みを行っていく 1. 開発者が開発（仕様策定、設計、実装）を行った後で、 すぐにテスト技術者がテスト設計を行いフィードバックする 2. 開発者が開発を行った後で、 すぐに開発者が自らテスト設計を行いフィードバックする 3. 開発者が開発を行うと同時に、 テスト技術者が独立にテスト設計を行いフィードバックする 4. 開発者が開発を行うと同時に、 テスト技術者が開発者とワイガヤしフィードバックしながら テスト設計を行う 5. 開発者が開発を行いながら、 開発者が自らテスト設計を行い両者を同時に改善していく 6. 開発者が開発を行う前にテストについても思索を深め、 はじめからバグの無い開発を行う フィードバック 時間小 フィードバック 時間ゼロ フィードバック 時間マイナス
- 207. © NISHI, Yasuharu207 Wモデルの目指すべき姿 •全ての工程でノウハウを生みだし共有し駆使する開発プロセス – ノウハウの抽出・蓄積・共有・駆使・改訂がプロセスに埋め込まれるようになる – 開発チームが開発進行中に自分達でプロセス改善をするようになる – 幅と遠さの両方で、開発者の見通しをよくすることができるようになる » 開発者は一般的に分割統治・詳細隠蔽の原則で発想することが多いので、 テスト設計者と一緒に設計検討をすると見通しがよくなることが期待できる – ソフトウェア開発者の多能工化が進む • 開発者が「最もよいやり方で考える」ことに近づけていくプロセス – テストについて深く洞察することで、 テストを実施することなく品質を高められるようになる – 開発者の気づきのフィードバックサイクルが極限まで小さくなり、 開発予測力が高まっていく » リスクベースドテストをきちんと運用できる技術力が備わっていく – よい開発をするという点において、 開発者とテスト技術者のゴールは同じである
- 208. © NISHI, Yasuharu208 Wモデルの導入へのアプローチ •プロセス“改革”アプローチ – スタッフ部門や上級管理職が主導でWモデルのプロセスマニュアルを作り、 各部門に展開して導入する » 私見だが、いきなり“改革”を現場に押しつけても多分うまくいかない » プロセスの“改善”をextremeに行った結果、プロセスイノベーションが起きただけである • レビュー強化アプローチ – レビューを強化しようという運動として導入する » 私見だが、レビューの指摘項目の設計の強化にはつながらず、 結局プロセスをいじって終わってしまうと思う • 工程順序変更アプローチ – テスト設計を改善し、テスト設計時に不具合を見つけてもらうことで、 下流のテスト設計まで不具合検出を遅らせるムダを意識してもらい、 工程順序を変更する圧力を自発的に発生させる » 定着しやすいが時間がかかる • 設計ノウハウ蓄積・活用アプローチ – 設計者同士のノウハウ共有という運動として不具合モードを蓄積し、 それを全工程で活かすようにする » すぐに実行できるが、開発者が忙しいと停滞しやすい
- 209. © NISHI, Yasuharu209 Wモデルの導入へのアプローチ •技術の発展は癒着→剥離→融合の段階を経ることを意識し、 剥離させずに融合させようとしても定着しないことを理解する – 自分達は何を分かっており何を分かっていないのかを きちんと理解したうえで、適切な技術やノウハウを駆使できるようにする » 癒着：個々の技術を意識せず、したがって技術成熟度が上がらないまま、 様々な技術を暗黙的かつKKDで組み合わせて利用している状態 » 剥離：個々の技術を意識して区別することで技術成熟度を上げる状態 » 融合：複数の技術を意識的に組み合わせることで ムダを省き全体最適を実現している状態 • 自分たちがきちんと仕事をすれば責任は無い、 というカルチャーやコンセプトで導入すると、 Wモデルは順序入れ替え以上の効果を及ぼさない – Wモデルは（静的な）プロセスモデルというよりも、 プロセス進化のモデルであることを理解する » 次工程はお客様、TOC、自工程完結などの コンセプトの理解が重要となる