LINE Developer Meetup in Tokyo #39 Presentation (modified)

イマドキのソフトウェアのテストやQAの考え方
LINE Developer Meetup in Tokyo #39
Testing & Engineering
2018/6/27（水）
電気通信大学大学院情報理工学研究科
情報学専攻経営・社会情報学プログラム
西康晴
@YasuharuNishi / Yasuharu.Nishi@uec.ac.jp
https://www.slideshare.net/YasuharuNishi/
line-developer-meetup-in-tokyo-39-presentation/

Profile
• Assistant professor:
– the University of Electro-Communications, Tokyo, Japan
• 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, 33063, 20246)
• Founder:
– Japan Symposium on Software Testing (JaSST)
• Founder:
– Testing Engineers’ Forum (TEF: 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)
• Organizer
– QA4AI Consortium
• Advisor:
– Software Testing Automation Research group (STAR)
© NISHI, Yasuharup.2

講演の流れ
• ソフトウェアQAの戦略立案
～間違った戦略によるQAは必ず失敗する
– 労働のスケールアップから知のスケールアウトへ
– 価値観や品質のパッケージング
– AQUAフレームワーク
• ソフトウェアQAのエンジニアリングアプローチ
～テストの意図をエンジニアリングしよう
– QAアーキテクチャ
– テスト要求分析とテストアーキテクチャ設計
– テストフレームとテスト詳細設計
– VSTeP導入のコツ
– 不具合モードと探索的テスト
– テストの自動化

労働のスケールアップから
知のスケールアウトへ

日本企業を取り巻く状況：パラダイムシフトへの追従
• 労働のスケールアップから知のスケールアウトへ
– 労働のスケールアップ
• 標準化、プロセス定義、手順の確認・ダブルチェック、ムダ取り、休憩の圧縮、
考えることの排除・局所化、派遣化、オフショアリング、アウトソーシング、有識者の活用…
• スケールアップなので一部の人に負担が大きくなり、スケールにより管理コストが増大してサチる
– 知のスケールアウト
• 一つ一つの知の質を高める → より本質的な価値に近づける、正解がないので早くたくさん失敗して学ぶ
• 一つ一つの知を確かにする → 納得感の共感（アジャイル）
• 知でないものを取り除く → 単純作業の機械化（CI）
• 知の強化サイクルをつくる → 正しいカイゼンサイクル、違和感のアンドン化、フロントローディング
• 知を広げる → 外プロセスとの接続による全体最適（Industrie4.0、デジタルツイン／DX）、モジュール化
• 外から知を集める → 技術の民主化、OSS、オープンイノベーション
• スケールアウトした知を圧縮する → IoT／ビッグデータ／AI
• 個々の取り組みだけに囚われると鶏と卵になりうまく進めない
– 労働のスケールアップ的パラダイムでIndustrie4.0を捉えると
単なるセンサ付き製造設備にしか見えず、
旧来の開発を無理にスケールアップする羽目になる
– オープンイノベーションを大学と始めても論文ばかり書こうとされて現場に役立てられない

間違った戦略によるQAは
必ず失敗する

間違った戦略に基づいた品質保証は失敗する
• 間違った戦略に基づいた品質保証は、どう現場が頑張っても必然的に失敗する
– 自組織は労働のスケールアップに基づいた経営をしていないか？
• 単純な「製造業企業はソフトウェア企業になれ」「Googleは偉い」論ではない点に注意すること
• 「属人化の排除」「スキルはカネで買える」「責任分解点」などを頻繁に口にする組織が多い
– ソフトウェア開発は労働のスケールアップだと捉えていないか？
• ウォーターフォールなど個別の取り組みが悪いのではない
– 知のスケールアウトのための個別のアクティビティ（＝バズワード）に振り回されていないか？
• アジャイル開発における品質保証やテストはどうするのか、と考えるので答えが出ない
• 労働のスケールアップを保証する活動はおおむね失敗するということが、
ここ5～10年の日本の製造業およびソフトウェア産業の経験則である
– 個々の技法や仕組みが労働のスケールアップ的パラダイムを招いたのではなく、
それぞれの技法や仕組みを労働のスケールアップ的に使ってきたのが問題である
• 日本企業はどうしても労働のスケールアップという発想で品質保証をしてしまいやすい
• ハードウェアの設計や品質保証は知のスケールアウトをしようとしていても、
ソフトウェアの開発や品質保証がそれを理解せずに労働のスケールアップとして表面的に真似てしまう
– 欧米で知のスケールアウトをしようとしている会社を見ても
真似ができないし、意味すら分からないことさえある

品質保証戦略ではないもの、あれこれ
• そもそも品質（保証）に戦略などない
– 「うちは各製品で全然違う／みんな常駐なので、全社としての品質保証戦略なんて考えようがないのですよ」
• それは品質ではない
– 「そもそも営業が無理な案件を受注していたのが品質低下の原因なので、
案件受注審査を厳しくするというのが品質保証戦略です」
• スローガン
– 「品質こそ我が社のブランド、というのが品質保証戦略です」
• 目標数値
– 「5年で品質を倍にする、のが品質保証戦略です」
• 組織構造・体制図・権限
– 「これがISO9000用に描いた体制図で、品質保証戦略を表しています」
• アイデンティティの確保
– 「品質保証部の地位や発言力の向上です」
• 機能や取り組みを並べたもの
– 「プロセス改善、レビュー、テスト、メトリクスが品質保証戦略の軸です」
– 「XDDPとHAYST法とAutomotive SPICEが品質保証戦略の構成要素です」
• 個別の取り組み
– 「不具合率算出の精度向上のために○△分析をすることにしました」

間違った戦略に基づく組込みのソフトウェアQAの闇
• いきなり自組織の問題点を現場で洗い出そうとするとこんなものが挙がる
– それはそうなんだけど、これではにっちもさっちもいかないよな…
• 「PCが遅いです」
• 「窓やトイレが汚いです」
• 「残業が多いです」
• 「給料が安いです」
• 「なんかみんな幸せそうに見えません」
• 自組織の状況や問題点を適切に把握できないまま
「品質保証戦略ではないもの」に従って品質保証を始めるが、
当然ながら成果は出ない
– 二言目には「品質保証のリソースが足りなくて」とグチを垂れる
• 成果の出ない品質保証という「労働」を押しつけられる現場にそっぽを向かれる
– 盲従してモチベーションを下げるか、無視するか、蛇蝎のように忌み嫌うか、のどれかが多い
• 開発が真っ向から反発する方がまだ救いがある
• それでも仕事はしなければならない
– 品質保証が仕事をしたように経営陣に見せる意味の無い工夫に血道を上げる

品質保証戦略を立てる際に考えるべきパラダイム
• 知のスケールアウトを促進するような品質保証戦略を立てるようにする
– より本質的な価値に近づける
• 自分たちがお客様に提供しているものは何かをトコトンまで考える
– それが必要なのか？そこまで必要なのか？実は他のことが必要なのではないか？
• 品質保証活動によって組織内に与える良い影響をも品質と捉え保証・促進する
– 価値観、思考様式、行動様式、技術やノウハウ、組織の質、エンジニアの感情など多岐に渡る
– 正解がないので早くたくさん失敗して学ぶ
• 実施率や充足率で管理せず、失敗を責めず、まずは思いついたことを言いやすい風土を構築する
– 労働のスケールアップに基づく組織は、言いたいことを諦め、呆れ、思考停止していることが多い
– 失敗を責めても成功率は上がらず、トライすることが減るだけである
– 人を責めるのは原因分析の姿勢が原因なのではなく、原因分析の技術が低いことが原因である
– たとえトライさせることができなくても、押しつけず、ごまかさず、
相手が納得したことを共感できるまで合理的に説明する
• 短いサイクルで完結できるように仕事をデザインする
– 仕事を単純にぶつ切りにしても全く意味は無い
– その仕事の全体像が把握でき、詳細まで覚えておくことができ、オーナーシップを持つことができ、
全員が（技術的に）何を考えているのかが理解でき、全員の納得感を共感できるサイズにする
– 一つ一つの仕事ごとに自分たちが成長できたと感じられるのが理想である
• 品質保証そのものも早くたくさん失敗して学ぶ
– 全社を一度にカイゼンしようとしない

• 知のスケールアウトを促進するような戦略を立てるようにする
– 納得感の共感を高める
• まず部長や課長がきちんと技術を理解する
– 上級管理職が管理屋の組織では知のスケールアウトは絶望的である
» その場合は、ミドルダウンアップの戦術を用いる
– 管理指標や人事施策は会社からの非言語的だが明確なメッセージであることを認識してもらう
• 進捗よりも納得感、議事録よりも（納得感の）共感をマネジメントする
– きちんと納得せずに進捗するのは不具合や技術的負債を生む
– 言った言わないの水掛け論になっている時点でその開発は本質的に失敗している
• 「説明無責任」のために言葉を尽くして言い訳をするのではなく、
相手が腹落ちしてしみじみ納得したことを共感できるように言葉を尽くす
– 客観的、定量的、数値的な説明よりも、技術的に合理的で無理のない説明を行う
» 「説明無責任」：自分が責任を回避するためだけに言葉を尽くして説明をすること。言い訳。
» メトリクスそのものよりも、その合理性や妥当性を納得し現場にその納得感を共感してもらうことが重要
• あーでもないこーでもない、と議論することは納得感を高める上でとても重要である
– 決して押しつけたり通達したり命令したり説得したりしない
• 暗黙知を無理に形式知化しようとすると暗黙知が局所化するので、暗黙知を共感できる取り組みをする
– 形式知化する際に議事録化させるのではなく、納得感を共感する分析や記述を行う
• 納得してくれたら、品質保証のミッションを開発部隊がシェアしてくれるようになる
– SET/SWETのような新しい職種が必要になるかもしれない
» SET/SWET：開発者に自分でテストしてもらうために、テストしやすくする環境を整備する職種

– 知の強化サイクルをつくる
• ソフトウェア開発を好きなエンジニアを集める／好きになってもらう
– サラリーマンエンジニアは労働のスケールアップを好む
• 違和感をアンドン化する（あれ？と思った時にすぐに口に出せるような風土にする）
– 違和感を飲み込む組織は納得感が低下し労働のスケールアップに向かっていく
• PDCAは質の高いカイゼンを素早く継続的に行うためのものであって、
怒られない理由づくりのために動きを遅くするものではない、という考え方を徹底する
– PDCAを「回す」のではなく、「自然に回る」ようになるよう感受性を高める
– カイゼンされない組織で一番怖いのは、カイゼンされないことそのものよりも、
そんなことしてもムダだと諦め、呆れ、違和感への感受性を捨て去られることである
– カイゼンは「いまダメでも少しずつ変わっていけばいい」という赦しである
• 下流から上流にフィードバックしたり、上流から下流に心配事をフィードフォワードしたり、
似たようなカイゼンを横展開し、縦横無尽の知の強化サイクルをつくる
– 単純作業を機械化する
• まずはエンジニアが多くの単純作業をしているのに気付かない、という現実をなんとかする
– 労働のスケールアップに基づく組織では、単純作業への感受性を捨て去って働いているフリをすると誉められる
• 協力会社との契約そのものを見直す
– 労働に対する支払いを行う限り、質も上がらなければ機械化もなされない
• 現行作業をそのまま機械化するのではなく、単純作業を機械化することを前提として
製品設計／ソフトウェア設計／開発プロセス／開発体制を見直していく
– そうしないと鶏と卵が発生し、いつまで経っても前に進めない時期に突入する

– 知を集める
• 外から集める前に、エンジニア一人一人が社外から学べる環境や制度を整える
– 学ぶ余裕を持ってもらうために、残業をゼロにし、就業時間内の業務に余裕を持たせる
– Github、Slack、Qiita、Slideshare/Speakerdeckなどがブロックされている会社で学べるわけがない
– エンジニアが学び議論し失敗する余裕をつくる
– 社外のカンファレンスやコミュニティに行くのを業務にし、社外への貢献を促進する
» 社外に貢献しようとするエンジニアは、感受性が高いし形式知化力も高く、
社内により貢献しようとする
– 社内でもコミュニティやカンファレンスを日常にする
– OSSは無料の外注先ではなく、学ぶ対象であり、学ぶ場であり、一緒に育っていくものである
• 大学やコンサルタントに投資し、育て、彼らとの成果をフルに活用する自分たちの姿勢を鍛える
– オープンイノベーションとは技術の調達でも外注でも丸投げでもないし、あなたたちはお客様ではない
– そもそも、自分たちが欲しい成果を今すぐ安価にきめ細かく提供してくれる便利なものはこの世に存在しない
– 知を広げる
• 開発と品質保証から教育へ、ソフトから全社へ、自社内から顧客へ、と広げていく
– 知のスケールアウトには内製化が基本であり、
それでも知を提供してくれる協力会社とは高値で付き合う
– スケールアウトした知を圧縮するのは当分先である
• 知をスケールアウトできるようになると、様々なパターンに気づけるようになる
• 自動化のチョコ停（一部だけ手動のままになる）をゼロにすると、量の変化が質の変化になる

成功する品質保証にはパラダイムシフトが重要である
労働のスケールアップというパラダイムに囚われている人たちに
辛抱強く、理論武装して、実例を見せて、寝技を駆使しながら、
知のスケールアウトというパラダイムを
理解してもらい納得してもらい共感してもらい
行動に移してもらうことが、何より重要である

FAQ: 「そんなのは品質保証の仕事じゃない！」
それはあなた（たち）が
品質保証という仕事を
勝手に矮小化しているだけです

品質とは、なんですか？

ソフトウェア品質保証の戦略
• 組織レベルQA戦略の立案と遂行
– 知のスケールアウトを行うのか労働のスケールアップに留まるのかという
組織パラダイムを決め、経営トップとコミットメントを取る
• 労働のスケールアップに留まろうとするとおおむね失敗する
– 組織全体における価値観や品質についてパッケージングする
– 経営が組織パラダイムを体現しているか、
組織全体における価値観や品質がパッケージとして実現に向かっているようQAする
– 組織のビジネスエッセンスと目標、実現可能性の検討を
経営からプロジェクト／プロダクト、個人ないしグループまで組織階層間で反復的に行い、
実現可能性が十分確保されている階層ごとのビジネスエッセンスと組織目標に展開する
• ビジネスエッセンス：自分たちは誰に何の価値を提供するのか
– 組織全体の技術ロジスティックスを設計し、きちんと循環しているようQAする
– プロジェクト／プロダクトレベルのQAで行う取り組みの母艦となる
– ソフトウェアQAそのものをQAする
• プロジェクト／プロダクトレベルQA戦略の立案と遂行
– 組織パラダイム、組織全体における価値観や品質のパッケージ、
ビジネスエッセンス、組織目標、コンテキストを分析する
– フォーカスを設計する
– 個々の取り組みを実装し、その順序、体制に落とし込む
– 浸透させる © NISHI, Yasuharup.17

価値観や品質のパッケージング
• 品質とは何か、をきちんと分かっている組織は極めて少ない
– 欧米的な考え方（PMBOKなど）：
• 顧客の要求に対する合致度といった「開発の結果」である
– 日本的な考え方（TQM）。：
• 仕事の質，サービスの質，情報の質，工程の質，部門の質，人の質，システムの質，
会社の質など，これら全てを含めた「質」
• よく考えると、ものの「質」にだけ着目しているわけではない
– TQMは価値的側面、思考様式的側面、人間的側面の3つに着目している
• JIS Q 9005 における質マネジメントの12原則：顧客価値創造、社会的価値創造、ビジョナリーリーダーシップ、
コアコンピタンスの認識、人々の参画、パートナーとの協働、全体最適、プロセスアプローチ、
事実に基づくアプローチ、組織及び個人の学習、俊敏性（アジリティ）、自律性
• 「質」とは多様な側面から成り立つ複合概念であり、組織の価値観を反映する
– 結果的側面、価値的側面、思考様式的側面、行動様式的側面、
内部技術的側面、組織的側面、人間的側面など
• 単一の側面にのみ着目しても上手くいかない
• 自組織にとっての価値観や品質の意味を掘り下げ、
それらの持つ多様な側面をパッケージとしてQAは取り扱わなくてはならない
– 自組織にとっての価値観だからこそ、QAが組織の経営に寄与する活動になる
• 多様な側面はそれぞれ複合的に影響しあうで注意が必要である

組織の価値観や品質を構成する多様な側面の例
• このように多様な側面から、相性のよいものをパッケージングする
– 結果的側面
• 結果不具合の少なさ、非機能特性、要求合致度など
– 価値的側面
• 感性品質、顧客価値、顧客の顧客の価値、社会的価値など
– 思考様式的側面
• （価値）創造、目的指向、全体俯瞰、融合、アーキテクチャ、事実に基づくアプローチ、
正味作業時間、本質、コアコンピタンス、水平展開、厳密性、納得感、分割統治など
– 行動様式的側面
• カイゼン、学習、アジリティ、小さい歩幅、自律、チャレンジ、少ない手戻り、フロントローディング、
未然防止、標準化、正確さ、再現性など
– 内部的技術的側面
• 欠陥の少なさ、設計のよさ、スジのよさ/グッドノウハウ、悪さのなさなど
– 組織的側面
• 全員参加、一体感、気配り、パートナーとの協働、顧客巻き込み、リーダーシップ、
フォロワーシップ、上意下達など
– 人間的側面
• 人間性、やりがい/働きがい、よろこび、ワクワク感、プライド

コンテキストに合わせて
ソフトウェアQAの戦略を立案しよう
～AQUAフレームワーク～
Accelerating project
Qualifying value
Unveiling weakness
Accumulating knowledge

プロジェクト／プロダクトレベルのソフトウェアQA戦略
• 知のスケールアウトを促進することがソフトウェアQAの役割となる
– 知のスケールアウトというパラダイムを社内に浸透させる
– 自分たちのプロダクトが本当に与える価値は何かをバリューチェーンの全員で考え抜く
– 早くたくさん失敗して学んだかをマネジメントする
– 納得感の共感、感受性、違和感の表出、などをマネジメントする
– 単純労働的QA活動を機械化し、労働集約的な協力会社を絞る
– エンジニア一人一人がきちんと学び成長できていることをマネジメントする
– 受け身の姿勢や上から目線では必ず失敗する
• コンテキストによってソフトウェアQAで行うべきことは異なる
– コンテキストに合わないソフトウェアQA活動を行うと失敗する
• コンテキストとは、市場でのプロダクトの存在感やポジション、
設計・ソースコードのサイズ・複雑さ、組織能力の程度などから構成される
– 例えばプロダクトを速くリリースして市場を攻略したい時期であれば、
ソフトウェア品質保証は市場の攻略や速いリリースを促進すべきであり、
じっくり検証して高い基準の信頼性を達成するゲートの役割をすべきではない
– 自分たちのコンテキストを理解した上で、
どこにフォーカスして知のスケールアウトを促すかを設計し、
個々の取り組みの実装やその順序、体制に落とし込み、
いかに浸透させていくかを検討することが、
プロジェクト／プロダクトレベルのソフトウェアQAの戦略の立案である

コンテキストに合わせてソフトウェアQAの戦略を立案する
• AQUAフレームワーク
– Accelerating project
• とにかく速く何度もリリースを行って市場で存在感を示したり、市場で学ぶべき時期に行うQA活動
– プロダクトサイズは小さく、信頼性や安全性はそれほど要求されない時期
• 主要な価値やUXが損なわれないことと、開発スピードが上がること、成長できるチームになっていること、
などに品質保証をフォーカスさせる
– Qualifying value
• プロダクトのポジションやミッションが分かってきた段階で、製品の価値を最大化するQA活動
– プロダクトサイズが徐々に大きくなり、機能は増えUXを重視するが、何を目指してるのかがブレ始める時期
• 価値が向上していることや、提供価値の多様化に追いついていること、複雑さの増加に対応できていること、
– Unveiling weakness
• 多くのユーザを獲得し、市場で存在感を確立した時期に行うQA活動
– プロダクトサイズがかなり大きく、開発体制も大規模化し、一つのバグの影響が甚大になる時期
• 大規模化に対応できていること、不具合が出やすい仕様・設計上の弱点に気づき対処できていること、
納得感を共感させる仕組みが浸透していること、などに品質保証をフォーカスさせる
– Accumulating knowledge
• 次世代、発展型、ファミリ的なプロダクトの開発を検討すべき／始めている時期に行うQA活動
– 機能の追加と、コア部分や環境の入れ替えが同時多発的に頻発し、中心メンバが入れ替わる時期
• 俯瞰し見通しよくできていること、シンプルさを保つ仕組みが保たれていること、
開発から知を獲得できていること、メンバの知が向上し循環していること、などに品質保証をフォーカスさせる

ソフトウェアQAの取り組みに落とし込む
• AQUAフレームワークの例:
– Accelerating project
• コンテキストとフォーカス
– とにかく速く何度もリリースを行って市場で存在感を示したり、市場で学ぶべき時期に行う品質保証活動
» プロダクトサイズは小さく、信頼性や安全性はそれほど要求されない時期
– 主要な価値やUXが損なわれないことと、開発スピードが上がること、成長できるチームになっていること、
• 取り組みへの例
– プロダクト／プロジェクトマネジャーとの対話の開始や、チームの／との価値観の共有を目的とした朝会への参加
– 筋のよい設計でよいコードを書いているとメンバが納得感を持てるようにするペア／モブプロの促進やDR
– 頻繁なリリースをためらわず最速の開発に近づいてもらうことを促すためのKPT/PDCAやTDD、UTレベルのCI
– 市場の求める価値の理解と、市場からのフィードバックに対する反応速度の加速のためのUSMへの参加
– Qualifying value
– プロダクトのポジションやミッションが分かってきた段階で、製品の価値を最大化する品質保証活動
» プロダクトサイズが徐々に大きくなり、機能は増えUXを重視するが、何を目指してるのかがブレ始める時期
– 価値が向上していることや、提供価値の多様化に追いついていること、複雑さの増加に対応できていること、
• 取り組みの例
– 市場の求める価値とその変化を機能やふるまいで実現していることを実証するE2Eテスト
– 暗黙知を暗黙知のまま共有し、新しいメンバにも伝えていくためのペア／モブプロの促進やDR
– 頻発する手戻りに対してデバッグで終わらせず設計まで戻し設計の筋をよくするバグ分析とナビゲーション
– 設計の複雑さを増加させないためのデザインレベルリファクタリングの推進とテスタビリティの作り込み

ソフトウェアQAの取り組みに落とし込む
• AQUAフレームワークの例
– Unveiling weakness
– 多くのユーザを獲得し、市場で存在感を確立した時期に行う品質保証活動
» プロダクトサイズがかなり大きく、開発体制も大規模化し、一つのバグの影響が甚大になる時期
– 大規模化に対応できていること、不具合が出やすい仕様・設計上の弱点に気づき対処できていること、
納得感を共感させる仕組みが浸透していること、などに品質保証をフォーカスさせる
– 大規模化やSoE/SoRの融合のためのマイクロサービス化などのアーキテクチャレベルリファクタリングの推進
– 大規模化でも開発速度を保つためのE2Eテストの自動化（キーワード駆動テスト化）とフルCI
– 暗黙知の形式知化と形式知の実質化（＝反形骸化）のためのドキュメント化とレビュー
– 仕様や設計上の弱点をいぶり出し皆が弱点に気をつけられるための市場バグの根本原因分析と探索的テスト
– Accumulating knowledge
– 次世代、発展型、ファミリ的なプロダクトの開発を検討すべき／始めている時期に行う品質保証活動
» 機能の追加と、コア部分や環境の入れ替えが同時多発的に頻発し、中心メンバが入れ替わる時期
– 俯瞰し見通しよくできていること、シンプルさを保つ仕組みが保たれていること、
開発から知を獲得できていること、メンバの知が向上し循環していること、などに品質保証をフォーカスさせる
– プロダクトライン開発や環境多様化のためのコア資産の抽出やエンジン化、フレームワーク化、仮想化の推進
– 複数チームでの共有や俯瞰のためのモデル化、DSL化とレビュー
– 不具合の未然防止のための工程内バグや過去バグからの仕様・設計上の弱点の抽出とフロントローディング
– 開発全体を見通した俯瞰的なQA活動の把握のためのQAアーキテクチャの記述
– DRなどの作業埋め込み型教育、OJT、集合教育の融合

取り組みへの落とし込みの留意点
• コンテキストやフォーカスと取り組みとは多対多の関係になり、
落とし込みそのものにもコンテキストが影響し、適用部隊ごとに異なるので、
その設計にソフトウェア品質保証の知的リソースをつぎ込まなくてはならない
– 外部のメディアや識者は典型例を示すだけで、自組織にそのまま適合することはほとんどない
• 同じ取り組みでも、取り組みの実装によって成果は大きく異なることを理解する
– 自組織の文化や風土、歴史にあった実装をする方がよいことが多い
• コンテキストは常に変化し移行するものであり、
複合して発生し、先読みも必要になるため、
ソフトウェア品質保証の取り組みを始めれば終わり、とはならない
– Acceleratingの段階からQualifyの段階の取り組みを先読みして実施すべき、
といったことは多々発生する
– 一度にたくさんの取り組みを現場に強いても破綻する
• それは現場に時間が無いことが問題ではなく、取り組みへの落とし込みや実装の問題である
– ソフトウェア品質保証の組織そのものが常に成長し戦略的に思考しなければならない

ソフトウェアQAの取り組みを浸透させる
• 品質を保証するためには、開発現場に取り組みを浸透させる必要がある
– 取り組みが浸透しているからこそ、違和感への感受性が高まり、
知がスケールアウトするので、プロダクトやプロセスがよりよくなっていく
• 取り組みが実施されているが浸透されていない組織では、
よく分からずに取り組みを手がけているため違和感を押し殺す習慣ができてしまい
カイゼンサイクルのスピードが遅く空転ばかりするので「カイゼン疲れ」が発生する
– 労働のスケールアップの組織パラダイムにおいては、
プロセスや手順書／標準の定義、実施確認、ダブルチェック、プロセスメトリクスの盲進
などによってQAが実現されていたが、ソフトウェア開発ではおおむね失敗する
– 知のスケールアウトの組織パラダイムにおいては、
取り組みが浸透し開発現場が納得感を共感し、自然に動いているようQAする
– 取り組みの浸透には、取り組みそのものの浸透と、取り組みで扱う知の浸透がある
• 「なぜそれをやるのか？」と「何をやっているのか？」の両方に納得し共感していなければ、
よい開発などできるわけがない

• 取り組みそのものの浸透：「我々はなぜそれをやるのか？」
– まず大事なことは、組織パラダイム、組織全体における価値観や品質のパッケージ、
ビジネスエッセンス、組織目標、コンテキストを開発現場が納得し共感することである
• 経営陣からの、企業理念やトップの言葉などによる明示的なメッセージや、
人事施策や組織設計などによる暗黙的なメッセージが
組織パラダイムなどに一致していることをQAする
• 経営陣からのメッセージを「あーでもないこーでもない」と開発現場でかみ砕き、
経営陣との反復的なフィードバックや直接対話などによって納得感を共感できているようQAする
– 組織文化を醸成していることを意識するとよい
– 組織なりの方言があると納得感を共感しやすい気がする
• 「これは社の方針だから」「これは業務命令だから」と押しつけてはいけない
– しかし手段が目的化した株式公開などが社の方針に
– 次に、自分たちの組織目標やコンテキストを基に、
どのようにフォーカスを定めどのようにその取り組みに落とし込んだか、
を開発現場が納得し共感する必要がある
• 落とし込みの段階から納得感が共感されている必要があるのは言うまでもない
• 落とし込みに参画しなかったエンジニアとも「あーでもないこーでもない」と
議論したり不満をぶちまけたり思いをぶつけあったりしながら納得感を共感していく

• 取り組みで扱う知の浸透：「我々は何をやっているのか？」
– 開発では様々な工程や作業があり、様々な知が飛び交っている
• ソフトウェア開発では、形式知化されうるものも、形式知化できるが暗黙知のまま留まるものも、
本質的に暗黙知でしか存在ものも、混在している
– 全ての知を形式知化させて浸透させるには限界がある
– 労働のスケールアップの考え方は基本的に
• どうすれば上手くいくかを手順化できない工程や作業がたくさんある
– 労働のスケールアップの考え方に基づくQAとはここが大きく異なる
• 反復的に成長していく知がたくさんある
– 様々な知を共有し納得し共感することを、日々の開発作業に埋め込む
• 無駄な形式知化をしないよう、どの知をどの範囲で共有するかをしっかり考える
• 納得し共感できるまで反復し、反復し、反復する
– 反復は違和感を感じ取るトリガになる
• 形式知化できるほど知がまとまっており、形式知化できる技術が高く、
形式知を自分の周りの具体例に詳細化する力が高い組織なら、
形式知化の活動に力をいれてもよい
• そうでないなら、暗黙知を暗黙知のまま共有する活動に力を入れながら、少しずつ形式知化していく
• そこかしこに、あーでもないこーでもないと議論したり、違和感の感受性と表出力を高める仕掛けを入れる
• 日々の開発作業に埋め込まなければすぐにQAは形骸化し「放課後の掃除」化することを理解する
– その開発現場にとって「楽しい」埋め込みを行う

• 取り組みへの落とし込みの留意点
– プロセスは手段であり容れ物でしかない点を強く意識する
• そもそもソフトウェア開発は「こうすれば上手くいく」が記述できないため、手順を決めても上手くいかない
– ある思考へのインプットとなる知が十分なのか、思考の際の納得感の共感が十分なのか、を記述する
• CMMiやAutomotive SPICEなどのSPIファミリ、機能安全ファミリ、ISO9000シリーズなどによる
外部審査／内部監査がビジネス上必要な組織はプロセスが形骸化しやすいので特に留意する
• プロセスを先に定義するのではなく、また自社プロセスを規格に合わせるのではなく、
各組織にとって知がスケールアウトできる進め方をプロセスとして書き出すようにする
– プロセスに従うから知がスケールアウトするのではなく、
知がスケールアウトできているから結果としてプロセスに沿っている、という構図を崩さない
– その組織のどこの誰に聞いても、その作業を行うことのうれしさや行わない時に困りごとを
自然に言えるくらい浸透させる
• プロセスは作業手順のシーケンスではなく、各作業で必要となるノウハウや知恵、勘所、
技術やツールとセットになって始めて活用できることを理解する
– 国際規格などは、議論可能かつ審査可能にするためにあえて手順だけを抜き出して書いてあり、
それを鵜呑みにすると形骸化にまっしぐらとなる
– メトリクスは手段であり縮退表現でしかない点を強く意識する
• 何をメトリクスとして測るか、よりも、なぜそのメトリクスを測るべきか、
そもそも現場でどのような良いこと／悪いことがどのようなメカニズムで起きているのか、
を理解しなければ、形骸化にまっしぐらとなる
• QAの仮説検証およびカイゼンのためにメトリクスは用いるべきなので、
測定対象は常に変化していなければならない、と理解する
– 統計屋は測定対象の安定化（＝カイゼンへの抵抗）を言い出すが、
母集団分布も分散も不明なサンプルだけから解釈を抽出しようとする時点でそもそも無理がある

• QAの役割はコンテキストやフォーカス、プロジェクトの状況などによって
異なることを理解する
– それらを無視して全社、もしくは事業部で一律に同じQAの戦略を
同じように進めようとするのはQAの怠慢に過ぎない
– コンテキストやフォーカス、プロジェクトの状況に合わせるとQAのリソースが足りない、
というグチを言ってはいけない
• リソースが足りないのではなく、QAの戦略がどこかおかしいことを示している場合の方が多い
• リソースが足りないのではなく、QAが開発と納得感を共感できていないので
ミッションをシェアできていないことを示している場合の方が多い
– QAの役割を自分たちで定義しておくと考えやすい
• 実際にテストなどを行うプレイヤーQA
• 開発が自分たちでQAしやすくなるように動くサーバントQA
• 開発とユーザが乖離している時にその間をつなぐグルーQA
• リリーススピードとリリース時品質リスクとのバランスを取るナビゲータQA
× 最後の砦だけを担うフェーズゲートQAは知のスケールアウトを阻害する効果の方が大きい
× プロセスを守らせるポリスQAは知のスケールアウトを阻害する効果の方が大きい
– QAは知のスケールアウトを促進することは何でもやらなくてはならない
• 自分たちで自分たちの活動のスコープを常に広げようとする方が正しい
– 「それはQAの仕事ではない」というセリフが出てきたら、それは何かがおかしいことを示している
• 開発の労働の肩代わりや便利屋となってはいけない

FAQ: 「ソフトウェアQAとして何に取り組めばいいですか？」
• 「プロセスなんか、もううんざり！」
• 「アジャイルでスクラムでTDDでCIで探索的テストの時代なんだよ！」
• 「ペアプロ！モブプロ！KPT！」
…
vs.
• 「ミッションクリティカルなんだからプロセスは厳密にするのが当たり前だ」
• 「『測定なくして管理なし』と昔から言うのだよ」
• 「PDCAを回して再発防止シートを書きたまえ」
…

FAQ: 「ソフトウェアQAとして何に取り組めばいいですか？」
何に取り組むかが大事なのではなく、
なぜそれに取り組むか、と
どうそれに取り組みか、
が大事なのである

QAもエンジニアリングが必要
～QAアーキテクチャ～

「もうバグは無いんだろうな？」
• そもそも品質の保証ってどうやるんだろう？
– 測定すれば性質が把握できるものは、測定して性質を把握して品質を保証できる
• ただし通常はある確率分布に従うため、確率的保証しかできない
– どうすれば作業が上手くいくかを完全に記述できるものは、
手順を完璧に書き下し手順の遂行を確認すれば品質を保証できる
• しかし実はそんな仕事はほぼ存在しない、ということを
労働スケールアップパラダイムのソフトウェアQAは理解していない
• ソフトウェア開発では、測定や手順による品質の保証はできない
– ソフトウェアは知的人工物のため、測定しても性質がよく分からない
– ソフトウェア開発は知的作業のため、どうすれば上手くいくかを記述することができない
• すなわち「もうバグは無いんだろうな？」という質問に
「はい、もうありません」とシンプルに答えることはできない
– そもそもそれは品質の保証の話ではなく、誰かが責任回避をしたいだけだったり、
ビジネスエッセンスを理解していないので無理ゲーをしてるだけだったりする
• QAはその質問に対しどう答えればよいのか？

ソフトウェアの品質保証の考え方
• ソフトウェアのQAは以下の3x5x3=45種類の保証動作を
成果物や部品、工程などごとに行うトレードオフ行為である
– ソフトウェア開発における品質の保証は3種類ある
出力系検証）作業のアウトプットがよいかどうか、悪くないかどうかを検証する
入力系保証）作業のインプットとして必要なものが揃っているかを検証する
環境系保証）作業を遂行する「装置」である頭脳が最適に働いてくれるような環境条件が整っていることを検証する
– 検証には5レベルある
レベル5) 内容を理解して、きちんとできていることと、ヤバそうなことを防いでいることに自信を持つ
レベル4) 内容を理解して、きちんとできていることに自信を持つ
レベル3) 内容は理解せず、特定の性質だけから（定量化して）比較する
レベル2) 内容は理解せず性質の把握すら行わないが、トレーサビリティを確認する
レベル1) 内容は理解せず、存在していることのみを確認する
– 検証の対象には3種類ある
最終成果物検証）最終成果物そのもの
– 動作実績を積み上げることはできるが、積み上げてない動作を外挿的に予想することは難しい
ユニット検証）最終成果物を構成する部品／ユニット／コンポーネント群
– 「合成の誤謬（部品が全て正しくても組み上げたら不具合が出る）」が発生する可能性がある
入力・中間成果物検証）最終成果物の基となる入力成果物／中間成果物
– 入力成果物と出力成果物が多対多になる場合、入力成果物のよさは出力成果物のよさを示すとは限らない
– 中間成果物の通りにつくられるとは限らない

ソフトウェアの品質保証の考え方
• 45種類の保証動作を組み合わせたり重ね合わせたりトレードオフをすることで、
ビジネスエッセンスに基づく価値が提供できるかどうか自信を持つ行為が
ソフトウェアのQAである
– 例えば、要求レビュー → 設計レビュー → UT → IT → STという伝統的なソフトウェアQAは、
入力成果物や出力成果物から（再帰的）ユニット、最終成果物に対して出力系検証を行うことを
意図している
• これだけでは入力系検証や環境系検証が不足するので、教育やプロセスで補完している
– 価値が提供できればどのようにトレードオフを構成しても構わない
• 入力成果物や中間成果物の質が高く、
エンジニアがモチベーションや集中力を高め常に納得感を共感していられる環境があり、
全てのUTを自動化しており、構造がシンプルなので合成の誤謬が発生するリスクがとても低く、
不具合があってもすぐに切り戻せる機構があるのなら、E2Eのテストは不要というトレードオフをしてもよい
– シフトレフトやシフトライトは目的や潮流なのではなく、トレードオフの結果に過ぎない
– 価値はプロダクトの質だけではないことを常に意識する
• TDDは伝統的なユニットの出力系検証の自動化と捉えるよりも、
エンジニアのリズムを作り納得度を高めるといったユニットの環境系検証であり、
小さい歩幅という行動様式に関する出力系検証と捉える方がよい
– そう捉えた場合、TDDでカバレッジカバレッジと求めるのは不適切である

QAにもエンジニアリングアプローチが必要である
• 労働のスケールアップのパラダイムの組織では、
ソフトウェアQAは「管理屋」になりやすい
– 一覧表やマトリクスを作り、人間が確認し、書棚にしまい、印鑑を確認する
– ソフトウェアQAの”担当者“が「自分のスキルとは何か？」で悩むケースは少なくない
• 知のスケールアウトのパラダイムの組織では、
ソフトウェアQAをエンジニアリングとして捉えるべきである
– ソフトウェアQAは「QAエンジニア」「QAアーキテクト」などになる
– ソフトウェア開発と同じように、エンジニアリングスキルが必要になる
• ソフトスキルももちろん必要である
• エンジニアリングアプローチとは？
– ソフトウェア開発と同じように、ソフトウェアQAもモデルを構築し自動化を進めていく
• モデリングによって理解が深まり伝達しやすくなるため、納得感を共感しやすくなる
• 様々な設計原則によってモデルのよさを高めることができ、思考を研ぎ澄ますことができるようになる
• モデルを構築すると、デザインパターンといったソフトウェア工学の様々な技術を適用できるようになる
• 自動化を進めると、人間が頭を使うべきところに人間のリソースを集中できる
• モデリングと自動化を進めると、ムダな思考や作業が自然と浮き出てくるようになる
– エンジニアリングは属人化の排除ではないし、測定の目的化でもない
• 属人化を排除しようとすると必ずスキルの高い人がやりにくくなる
• 測定は前近代におけるデジタルトランスフォーメンションの一形態でしかない

QAへのエンジニアリングアプローチの例：QAアーキテクチャ
• 成果物や部品、工程などに関して
保証動作を組み合わせたり重ね合わせたりトレードオフをするためには、
全体像を俯瞰する必要がある
– QA観点モデル
• プロダクトの品質を保証するために知っておく／考えておく／気をつけておくべきことをQA観点と呼ぶ
– アーキテクチャ、負荷、同時アクセス、周辺機器、設定、性能、操作性、セキュリティなど多岐に渡る
• QA観点を整理したものをQA観点モデル（スイート）と呼ぶ
– QA観点というオブジェクトを「抽象化」してクラス図やQFDのように整理する
– 複数のモデルで分析・表現する場合もある
– QAパイプラインモデル
• 工程に保証すべき／しているQA観点を対応づけたものをQAパイプラインモデルと呼ぶ
– 設計やコーディング、レビュー、デプロイ前のテスト、デプロイ後のテストなどにQA観点をマッピングする
– QA観点という工程の「責務」を適切に分担させるようデザインする
– 製造業におけるQC工程表やQAネットワーク（保証の網）である
SUT

QAアーキテクチャにおける責務の分担（パイプライン化）
工程の責務を整理すると、どのQA観点のパイプラインを
自動化やフロントローディングによって高速化でき、
かつどの観点は手動テストで保証しなくてはならないのか、
といったことが俯瞰的に把握できるようになる
自動化で
velocityを向上させ
リズムを生み出す

QAアーキテクチャにおける責務の分担（シフトレフト）
フロントローディングで
テストを軽量化し、
自動化でvelocityを向上させて
リリースサイクルを短くする

QAアーキテクチャにおける責務の分担（シフトライト）
リリース
リリース

QAへのエンジニアリングアプローチの例：SaPID
• 管理屋アプローチでなぜなぜ分析を行っても全く役に立たない
– ○○工程を増やす、ダブルチェックをする、厳しくする、気をつける…が「根本原因」として頻出し、
まともな対策が取られることは極めて稀である
• モデリングを行うと様々なことが分かる
– 問題や原因の循環構造（鶏と卵）が把握できる
– 一つの結果には複数の原因があることがあると分かる
– 一つの原因から複数の結果につながることがあると分かる
– 個々の原因→結果の関係が雑なことが分かる
– 「なぜ？」の答えは必ずしも原因→結果とは
限らないことが分かる
– 根本原因にも色々あることが分かる
– 根本原因と対策がつながってないことが分かる
「システムズアプローチに基づくプロセス改善メソッド：SaPIDが意図するコト」
http://www.jaspic.org/event/2012/SPIJapan/session3A/3A3_ID009.pdf

テストの意図をエンジニアリングする
～テスト観点図によるテスト要求モデリング～

テストにもエンジニアリングアプローチが必要である
• 労働のスケールアップのパラダイムの組織では、
ソフトウェアテスターは「軽作業派遣」になりやすい
– 一覧表やマトリクスを埋め、人間が絨毯爆撃し、スクショを取り、という賽の河原
– 探索的テストという名で化粧されたド素人によるモンキーテストやアドホックテスト
• 知のスケールアウトのパラダイムの組織では、
ソフトウェアテストをエンジニアリングとして捉えるべきである
– テスターは「テストエンジニア」「テストアーキテクト」などになる
– ソフトウェア開発と同じように、エンジニアリングスキルが必要になる
• ソフトスキルももちろん必要である
• エンジニアリングアプローチとは？
– ソフトウェア開発と同じように、ソフトウェアテストもモデルを構築し自動化を進めていく
• モデリングによって理解が深まり伝達しやすくなるため、納得感を共感しやすくなる
• 様々な設計原則によってモデルのよさを高めることができ、思考を研ぎ澄ますことができるようになる
• モデルを構築すると、デザインパターンといったソフトウェア工学の様々な技術を適用できるようになる
• 自動化を進めると、人間が頭を使うべきところに人間のリソースを集中できる
• モデリングと自動化を進めると、ムダな思考や作業が自然と浮き出てくるようになる
– エンジニアリングは属人化の排除ではないし、測定の目的化でもない
• 属人化を排除しようとすると必ずスキルの高い人がやりにくくなる
• 測定は前近代におけるデジタルトランスフォーメンションの一形態でしかない

テストにもエンジニアリングアプローチが必要である
• 例えば開発の場合、エンジニアリングアプローチは
趣味で小さいプログラムをいきなりコーディングするなら不要だが、
きちんとビジネスとして大規模なソフトウェアの開発を行うなら必要である
– コーディングは、アルゴリズムとプログラミング言語を分かっていればできる
• （従来の）テスト設計も、テスト設計技法と文書フォーマットを分かっていればできる
• 経験豊富でセンスのある人が規模の小さいプログラムを書くのであれば別に不要である
– ソフトウェア開発は、要求を把握し設計原則を理解・適用して、
段階的に詳細化しながら順序立てて反復的に進めていく必要がある
• テスト開発も、テスト要求を把握しテスト設計原則を理解・適用して、
段階的に詳細化しながら順序立てて反復的に進めていく必要がある
• エンジニアリングアプローチを取らないと、労働の集積になってしまいブラック化する
• エンジニアリングアプローチは「属人化の排除」ではなく、
皆の経験とセンスを結集してソフトウェアを開発するために必要な概念や技術、メソドロジである
• テストの開発のための方法論の一つにVSTePがある
– Viewpoint-based Software Test Process
– ほかにもHAYST法やゆもつよメソッドなど色々あり、それぞれに強みがある

テストへのエンジニアリングアプローチに必要なもの
• エンジニアリングアプローチを取らないと何が起こるか？
– 知恵が蓄積されない
– ゴチャゴチャになる
– 考えがふんわりする
– 考える範囲が狭くなる
– 自動化が進まない
– 特定のツールやメソドロジにロックインされる
• テストのエンジニアリングアプローチには何が必要か？
– 知恵を蓄積して伝達しやすいアプローチ → テストの「知恵」のモデル化
– 責務の分担を適切に行えるアプローチ → テストの知恵と工程の関係のモデル化
– 抽象化・具体化を適切に行えるアプローチ → 抽象度を「調整」できるモデルの導入
– 考えるべきことを限定しないアプローチ → メタモデルと参照モデルの分離
– 自動化すべきことを切り分けやすいアプローチ → 工程ごとのモデリング対象の概念の分離
– ツールやメソドロジを仮想化しやすいアプローチ → モデルと記法、プロセス、ツールの分類

テストへのエンジニアリングアプローチの例：VSTeP
• 工程ごとのモデリング対象の概念の分離：「テスト開発プロセス」
– 説明のためにWFで描いているが、実際は反復的に行う方がよい
テスト
アーキテクチャ
設計
テスト実施テスト設計（or テスト計画 or テスト実施準備）
テスト要求の
獲得と整理・
テスト要求の
モデリング
テストアーキテクチャ
のモデリング
手動／自動
テストスクリプト
（テスト手順）の
記述
テスト項目の抽出
テスト
詳細設計
テスト
実装
テスト
実施
テスト詳細設計
モデリングと
テストケースの
列挙
テスト
要求分析

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

• テスト観点とテストケースとテストスクリプトをきちんと区別する
– テスト観点
• 何をテストするのか（テストケースの意図）のみを端的に記述したもの
– 例）正三角形
– テストケース
• そのテスト観点でテストするのに必要な値などのみを特定したもの
– 例） (1,1,1), (2,2,2), (3,3,3)…
• 何らかのテスト詳細設計モデルに従って、何らかの網羅基準に沿ってテスト値が導出される
– 例）「整数の辺から構成される正三角形」だって立派なモデルである
– 例）状態遷移モデルに従って、1スイッチカバレッジ基準で、状態シーケンスを導出する
• テスト詳細設計モデルが複数組み合わさるなど複雑なテストケースが必要なこともある
– テストスクリプト（テスト手順）
• そのテストケースを実行するために必要な全てが書かれたもの
– 例）1. PCを起動する 2. マイコンピュータからC:¥sample¥Myers.exeを起動する…
• 手動でのテスト手順書の場合もあれば、自動テストスクリプトの場合もある
• 複数のテストケースを集約して一つのテストスクリプトにすることもある
• これらを区別し、異なる文書に記述し、
異なる開発工程に割り当てることによって、
テスト観点のみをじっくり検討することができるようになる

VSTePを分かりやすく理解すると
• テスト戦略立案 – STD
– AQUAフレームワークをテストに適用しよう
• 一般の「テスト戦略」よりも上位である点に注意
• テスト要求分析 - TRA
– テスト観点を思い浮かべて、線でつなげよう
• テストアーキテクチャ設計（コンテナ設計） - TAD
– テストコンテナにまとめて並べよう
• テストアーキテクチャ設計（フレーム設計）
– テストケースのひな形（テストフレーム）を作ろう
• テスト詳細設計 - TDD
– テストケースのひな形に具体的な値を入れよう
• 普通のやり方と同じでよい
• テスト実装 - TI
– テストケースをテスト手順に具体化しよう
• 普通のやり方と同じでよい
ざっくり考えて図にすると
見やすいし整理しやすい！
GUI 機能データ動作環境
プラットフォームネットワーク
OS ハードウェア
OSの種類 OSのバージョン IEのバージョン
電子メール

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

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

テスト観点図によるテスト要求分析の例
どんな意図で
テストすべきかを
整理する
電子メール

NGTによるテスト観点図の記述
• NGT/VSTePではテスト観点図を中心にして進めていく
– NGT (Notation for Generic Testing) という記法を定義している
– テスト観点を階層的に記述していく
– はテスト観点、はテスト対象を表す
– は詳細化関係を表す
– は組み合わせテストの必要性などテスト観点間の関連を表す
– は順序依存など方向を持った関係を表す
– 新たな関係や詳細な関係を
定義したり分かりやすくするために
<<stereotype>>
（ステレオタイプ）を使ってもよい
• マインドマップやロジックツリーで
VSTePを進めても構わない
– UTP2（UML Testing Profile 2.0）を使って
自動テストアーキテクチャと
一緒にモデリングしてももちろん構わない
電子メール

• テスト要求モデルの全体像をどう整理すればいいか、
に唯一絶対の解はない
– 仕様ベースモデル
– 機能ベースモデル
– 画面ベースモデル
– 正常系異常系モデル
– 品質特性モデル
– 一般テストタイプモデル
– CIBFWモデル
• Condition / Item / Behaviour / Fault / World
– 三銃士モデル
• 世界観・コンテキスト・実装＋ユーザ感情
• 全体像の構造によって
モデリングの質がかなり左右される
テスト要求モデルの全体像の種類

テスト観点のモデリングのTips
• 仕様書に書いてある仕様や文、単語を書き写してもテスト観点は網羅できない
– 仕様書は通常不完全であり（もしくは存在せず）、（特に致命的な）バグは
仕様書に書かれていないテスト観点でしか見つけられないことがある
• ここまで例に挙げたテスト観点は、皆さんの組織の仕様書に全て書いてありましたか？
• テスト観点は多面的に挙げる
– 入力に関するテスト観点だけを挙げたり、期待結果やその観測に関するテスト観点
だけを挙げたり、品質特性だけをテスト観点として採用すると、漏れが発生する
• テスト観点を挙げただけでバグが見つかることがある
– 開発者が考慮していなかったテスト観点はバグの温床であり、
テストしなくてもバグだと分かることも多々ある
– 期待結果に関するテスト観点を挙げたり詳細化すると、仕様の抜けが分かることがある
• テストケースにも期待結果を必ず書くのを忘れないこと
• 「正しく動作すること」は期待結果ではない！
• 網羅した風のテスト観点の文書や納品物を作ろうとせず
網羅しようと多面的に様々なことを考え尽くそうとする
– あーでもないこーでもないとワイワイ議論したアイデアのリポジトリがテスト観点図である
• 見逃したバグを見つけうるテスト観点を気軽に追加して整理することも大事である
– 最初から網羅しようと気張ると大事なテスト観点を見逃す
• そもそも網羅することが必要なのか？

テスト観点のモデリングのTips
• 同じテスト観点名を皆が同じように理解しているとは限らない
– 子観点が明示すると理解の齟齬は解消しやすい
• 観点が通り一遍で関連が多いモデルは理解度が低いことが多い
– 不安だから／責任を取りたくないから組み合わせておかなきゃ、と発想していることが多い
– なぜその関連をテストすべきだと思ったのか、という掘り下げを行い、
可能なら関連をテスト観点に変換すると、よりテストの意図が明確になる
• 詳細化のステレオタイプを明示するとよいモデルをつくりやすい
– その親と子はどういう関係なのか、はステレオタイプを明示しないと不明確になりやすい
– 異なるステレオタイプの詳細化が混ざっていると網羅しにくい
• 抽象度は丁寧に落として（具体化して）いく
– 子の数は認知的マジックナンバーの範囲内にできるとよい
• 網羅できた確信が持てないところにはノートを貼っておく
– モデリングの途中では「その他」という一時的なテスト観点を挙げておいてもよい
• 後で適切な観点としてきちんとモデリングすること
– 抜け落ちの危険性が消失することが一番怖い
• 探索的テストにおけるチャーターの記述とテストの（気づいた点の）記録は
テスト観点モデルを用いると表現しやすい

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

• モデリングをせずに行き当たりばったりでテストをすると
テスト観点図が真っ黒になる
– 自分たちがなにをテストしているのか、が分かっていない場合が多い
テスト観点図のリファインの例

モデリングによってテストの再利用性を高める
• バージョンごとの仕様の違いを
テスト観点図で整理すると再利用しやすくなる

テストにも
アーキテクチャがある
～テストアーキテクチャモデリング～

テストコンテナ図によるテストアーキテクチャ設計の例
テストレベルやテストタイプ、
テストサイクルを設計する

テストレベルやテストタイプは自分たちで設計するものである
Difficulty validation
by beginner
Automated testing for Gacha (gamble) probability
Exhaustive automated testing for payment for various items
Business
model
suitability
Validation
Business
model
suitability
Validation
Business
model
suitability
Validation
Business
model
suitability
Validation
Model of World
suitability validation
Background Story
suitability Validation
Equipment and items
Movement
reality
validation
User
thrill & relax
validation
Automated testing
for wall penetration
Addiction
validation
Distraction
validation
Resumption
validation
Various
payment
verification
Mainstream
devices
verification
Minor
devices
verification
SUT
update
testing
Interruption
of other apps
testing
Delightful
payment
validation
Shot&dead
timing
validation
Movement
sync.
verification
Payment
security
verification
by expert
Catharsis
validation
Buzz-ability
validation
Platform
certification
testing
Marketing
materials
suitability
verification
Balance
breaker
exploratory
testing
Competitor
comparison
verification
Compliance
verification
Complicated
payment flow
verification
Load testing
for payment
Basic
network
verification
Various
network
verification
Multi server
handoff
verification
Load
testing
for play

テストレベルやテストタイプは自分たちで設計するものである
by beginner
Automated testing for Gacha (gamble) probability
Exhaustive automated testing for payment for various items
Business
model
suitability
Validation
Business
model
suitability
Validation
Business
model
suitability
Validation
Business
model
suitability
Validation
Model of World
suitability validation
Background Story
Equipment and items
Movement
reality
validation
User
thrill & relax
validation
Automated testing
for wall penetration
Addiction
validation
Distraction
validation
Resumption
validation
Various
payment
verification
Mainstream
devices
verification
Minor
devices
verification
SUT
update
testing
Interruption
of other apps
testing
Delightful
payment
validation
Shot&dead
timing
validation
Movement
sync.
verification
Payment
security
verification
by expert
Catharsis
validation
Buzz-ability
validation
Platform
certification
testing
Marketing
materials
suitability
verification
Balance
breaker
exploratory
testing
Competitor
comparison
verification
Compliance
verification
Complicated
payment flow
verification
Load testing
for payment
Basic
network
verification
Various
network
verification
Multi server
handoff
verification
Load
testing
for play
Holistic
emotional impression
test level
Particular
emotional impression
test level
Basic env.
test level
Various env.
test level
Actual env.
test level
Real usage
test level
Monetization
test type
Business test type

1. Coupling
2. Cohesion
3. Maintainability
4. Automatability
5. Circumstance consistency
6. Development consistency
7. Describability
8. Design direction
9. Design positiveness
10. Execution velocity consistency
11. Stability / Change frequency
テストアーキテクチャ設計で気にすべき性質
性能測定
大規模負荷
テスト
負荷分散
機能確認
テスト
DoSアタック
テスト
性能テスト
適切に
「責務の分担」
がなされているだろうか？

テスト要求分析やテストアーキテクチャ設計で何を検討するか？
• SPLIT
– Scope - テストの対象範囲をどこにするか / TRA
– Phase - テストのどの段階（in dev. / in prod.）に焦点を当てるか / TAD
– Level - どのレベルまでオートメーションを進化させるか / TSD&TAD
– sIze - 対象の範囲をどう切り分けて実行するか / TAD
– Type - どのような種類の目的でテストを行うか / TRA
https://logmi.jp/282805
https://thinkit.co.jp/article/13346

テストケースを導出する
～テストフレームによるテスト詳細設計～

テストフレーム図によるテストケースの構造の明示
• 「テストケースの構造」には単純なものから複雑なものまで色々ありうる
– テストケースの構造をテスト観点で表したものを「テストフレーム」と呼ぶ
– 複雑なテストケースが偉いわけでもバグを見つけやすいわけでもないことに
注意する必要がある
• どのくらい複雑なテストフレームを組むかによってテスト設計の良し悪しが変わるので、
どういうトレードオフをどう考えてから、もしくはどういう意図で
この複雑さのテストフレームにしたか、はきちんと説明できないといけない
【単純なテストフレームの例】
【複雑なテストフレームの例】

テストフレームはテストケースのスケルトンである
• テストフレームの要素を見出しとして表を作るとテストケースになる
– テストフレームをきちんと考えないと、
「大項目－中項目－小項目」という見出しで整理した気になっているけど、
ちっとも整理されておらず網羅しにくいテストケース表ができあがる
– マインドマップやUMLツールなどを併用すると描きやすいが、
全部一覧表やマトリクスでも構わない
【テストフレームの例】
【テストケース表の例】

テスト詳細設計：テスト観点からテスト値を網羅する
• テスト値の網羅は以下の手順で行う
– テスト観点がどのタイプの「テストモデル」なのかを見極める
• 十分詳細化されたテスト観点が「テストパラメータ」となる
– 網羅基準（カバレッジ基準）を定める
– 定めた網羅基準でテストパラメータを網羅するようにテスト値を設計する
• テストモデルのタイプには4つある
– 範囲タイプ、一覧表タイプ、マトリクスタイプ、グラフタイプ
• テスト値には2種類あるので注意する必要がある
– 直接テスト値：テスト値が直接テスト手順の一部（テストデータ）として実施できるもの
• 例） 3辺の長さ (3, 3, 3)
– 間接テスト値：テスト値からさらにテストデータを導く必要があるもの
• 例）制御パス
– 制御パスを網羅して、その後にそれぞれの制御パスを通すテストデータを作成する
• テストパラメータやテストモデルを特定せずに
闇雲にテストケースをあげるのは、質の高いテストとはいえない

範囲タイプのテストモデルの網羅
• 範囲タイプのテストモデルは、
ある連続した範囲を意味するテスト観点を網羅する時に用いる
– 例）辺の長さ（0以上65535以下の整数値）
– 範囲のことを「同値クラス」と呼び、同値クラスを導出する技法を同値分割と呼ぶ
• 範囲タイプのテストモデルの網羅基準は以下の通り
– 全網羅
• 例） 0, 1, 2, 3, 4, 5, 6, 7 … 100 … 10000 … 65534, 65535
• 漏れは無いが、テスト値が膨大になるため現実的では無い
– 境界値網羅
• 例） 0, 65535, -1, 65536
• 境界値分析や境界値テスト、ドメインテストなど独立した技法として説明されることが多い
• 有効境界値だけでなく無効境界値もわすれないこと
• 範囲が開いている（上限や下限が定まっていない）時は、自分で定める必要があるが、
よほどよく検討しないと漏れが発生しやすくなる
– 代表値網羅
• 例） 3
• テスト値は少数に収まるが、漏れが発生する

一覧表タイプのテストモデルの網羅
• 一覧表タイプのテストモデルは、
複数の要素からなる集合を意味するテスト観点を網羅する時に用いる
– 例）ブラウザ
• 一覧表タイプのテストモデルの網羅基準は以下の通り
– 全網羅
• 例） Chrome, Firefox, Safari, Internet Explorer, Edge
• 漏れは無く、通常はテスト値もそれほど膨大にはならないが、
組み合わせになったら無視できない程度にテスト値が多くなってしまう
– 境界値網羅
• 例）一番昔にリリースされたブラウザと一番最近リリースされたブラウザ
• 要素の何らかの属性がある連続した範囲の場合に
その属性の境界値を持つ要素を境界値要素とみなすことができなくもないが、
よほどよく検討しないと漏れが発生しやすくなる
– 代表値網羅
• 例） Chrome

マトリクスタイプのテストモデルの網羅
• マトリクスタイプのテストモデルは、
2つ（以上）のテスト観点の組み合わせを網羅するときに用いる
– 例） OSとブラウザの組み合わせ
– 組み合わせたいテスト観点の数をここでは段数と呼ぶ
• マトリクスタイプのテストモデルの網羅基準は以下の通り
– 全網羅
• 例） (XP, Chrome), (Vista, Chrome) … (Win8.1, Edge）, (Win10, Edge)
• 漏れは無いが、掛け算によりテスト値が膨大になるため現実的では無い
• 禁則（無効な組み合わせ）に注意する
– N-wise網羅
• N+1以上の段数の組み合わせの網羅を意図的に無視することによって、
現実的な数でNまでの組み合わせを全網羅する方法
• N=2の時をPairwiseと呼ぶ
• All-pairsなどN-wise系の網羅手法と、直交配列表を用いた網羅手法がある
• Nまでの組み合わせの網羅で十分かどうかを検討しないと漏れが発生する
– 代表値網羅

グラフタイプのテストモデルの網羅
• グラフタイプのテストモデルは、
丸と線で図が描けるようなテスト観点を網羅するときに用いる
– 例）プログラムのロジック、状態遷移図、シーケンス図、ユーザシナリオ、地下鉄の路線図
• 折れ線グラフや棒グラフのグラフではない
– 丸と線で描ける図を（フロー）グラフ、丸をノード、線をリンク、丸と線による経路をパスと呼ぶ
• 間接テスト値になることが多い
• 制御フローパステスト（プログラムのロジックのテスト）の場合は、
if文の複合判定条件の真理値表の網羅と組み合わせることがある（C2網羅）
• グラフタイプのテストモデルの網羅基準は以下の通り
– 全パス網羅
• 漏れは無いが、テスト値が膨大になるため現実的では無い
– MC/DC（Modified Condition/Decision Coverage）
• 航空宇宙業界などで使われる
– Nスイッチ網羅
• 連続するN個のリンクの組み合わせを網羅する方法 / N+1以上のスイッチのテスト漏れが発生する
– リンク網羅（0スイッチ網羅、C1網羅）
• グラフのリンクを網羅するようにパスを生成する / 1以上のスイッチのテスト漏れが発生する
– ノード網羅（C0網羅）
• グラフのノードを網羅するようにパスを生成する / リンクのテスト漏れが発生する
– 代表パス網羅

講演の流れ
• ソフトウェアQAの戦略立案
～間違った戦略によるQAは必ず失敗する
– 労働のスケールアップから知のスケールアウトへ
– 価値観や品質のパッケージング
– AQUAフレームワーク
• ソフトウェアQAのエンジニアリングアプローチ
～テストの意図をエンジニアリングしよう
– QAアーキテクチャ
– テスト要求分析とテストアーキテクチャ設計
– テストフレームとテスト詳細設計
– VSTeP導入のコツ
– 不具合モードと探索的テスト
– テストの自動化

開発とQAが
一体となって
バグを探す旅をする

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

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

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

探索的テストとは？
• エキスパートによる非記述的なテストを探索的テストと呼ぶ
– テストエンジニアが五感と経験（によって得られたパターン）と感受性を駆使することで
バグを出すことに集中することで創造性を発揮するテストの方法である
– エキスパートが探索しながら学習していくため、事前にしっかりしたテスト設計は行わない
• メモやマインドマップ、大まかなテスト観点図などでアイデアや仮説を思い浮かべておくことはある
– 「ただ触るだけ」のモンキーテストやアドホックテストではない
• 素人に触らせて品質が向上するほどQAは甘くない
– 「素人がしそうな操作ミス」「素人はどう思うか」という明確なテスト観点に絞る場合は例外だが、
その場合でも探索的テストやアドホックテストとは呼ばない
• チャーターとセッションでマネジメントを行う
– 大まかにどの辺をテストするか、どんなことをテストするか、を伝える「チャーター」を用いて
マネジメントを行う
• チャーターを細かく書きすぎると創造性が減るし、粗すぎてもマネジメントできない
• チャーターを使わないフリースタイルというやり方もある
– テストエンジニアが集中力を高めておける時間を1つの「セッション」という単位で捉え、
マネジメントを行う
• 60～120分程度と言われている

探索的テストのポイント
• 探索的テストで何に着目するかはエキスパートに依存する
– バグの出そうな仕様やつくりに着目する（人がいる）
– プロジェクトの状況やエンジニアの納得度に着目する（人がいる）
– バグの出方に着目する（人がいる）
– ユーザの使い方や、そう使うとは想像しない使い方に着目する（人がいる）
– 出てほしくないバグや起こってほしくないハザード・アクシデントに着目する（人がいる）
– ふるまいの一瞬の揺れなど怪しい動作に着目する（人がいる）
– などなど
• 探索的テストは万能ではない
– 探索的テストと記述的テストは補完させるべきである
• 探索的テストだけでテストを構成するのは極めて危険である
– アジャイルだから探索的テスト、と短絡的に考える組織はおそらくアジャイル開発がちゃんとできていない
• 記述的テストを受注する第3者テスト会社でも50%近くを探索的テストで行う場合もある
– 探索的テスト中にテストエンジニアがテスト対象について学習し、
野生に還ったかどうか（感受性を鋭敏にしたかどうか）をマネジメントするとよい
• 網羅性や一貫性などを求めてはいけない
– 探索的テスト後にテストエンジニアが仲間とそのセッションについておしゃべりするとよい
• 学習した結果や気付いた怪しい動作、言語化しにくい経験ベースのパターン化を言語化するチャンスである
• 高い感受性で開発者と対話ができるように心理的安全を確保しておく必要がある

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

反復開発におけるVSTePのコツ
• イテレーションごとに
テスト要求モデルとテストアーキテクチャモデルを反復的に改善していきながら、
イテレーションナビゲーションを行う
– イテレーションごとに何をテストするのかを、テストコンテナ図を地図のように使ってナビゲーションしていく
• テストケースとして実行したテスト観点の種類と網羅度、バグの出方、
開発者の理解度・納得度などによって次に何をするかを動的に決める
• コンテナに色をつけていくと直感的になる
– 最初は曖昧なコンテナ図になっても構わないが、進むに従って地図の精度を上げていく
– 後半は横串を通すようなテストが増えてくるため、イテレーションごとの開発規模を減らすか、
テストチームによるテスト用のイテレーションをつくるか、などの選択が必要になるので、
コンテナ図を用いるなどして早めに予想して事前に仮判断しておく
• 1回のイテレーションコンテナに、スクリプトテストと探索的テストを両方入れる
– スクリプトテストの深掘り的な探索ばかりすると仕様の後追いになりがちでよくない
– イテレーションの時期に応じてスクリプトテストと探索的テストのバランスを変える
• バグの状況が把握しやすく余裕がある時は“スクリプト重→探索重→スクリプト重”のパターンで、
把握しにくく余裕が無い時は“探索重→スクリプト重→探索重”のパターンになる
• 1回のイテレーションで必ずテスト観点リフレクションの時間を取る
– リフレクションによってテスト観点図やテストコンテナ図を書き換えて（書き加えて）いく
– モデルの質を高く保っておかないとすぐに何をテストしているのか分からなくなる

LINE Developer Meetup in Tokyo #39 Presentation (modified)

LINE Developer Meetup in Tokyo #39 Presentation (modified)

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à LINE Developer Meetup in Tokyo #39 Presentation (modified)

Similaire à LINE Developer Meetup in Tokyo #39 Presentation (modified) (20)

Plus de Yasuharu Nishi

Plus de Yasuharu Nishi (12)

LINE Developer Meetup in Tokyo #39 Presentation (modified)