Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Qaアーキテクチャの話

823 views

Published on

QA勉強会「ここは苦しいところですが、どうか一つ、QAアーキテクチャを。」の発表スライドです。

Published in: Software
  • Be the first to comment

Qaアーキテクチャの話

  1. 1. QA勉強会 「ここは苦しいところですが、 どうか⼀つ、QAアーキテクチャ を。」 開催挨拶 2016/12/20 藤沢 耕助
  2. 2. ⾃⼰紹介 • 某企業でQAの仕事をしています、藤沢と申し ます • QAとは何かよくわかっておらず、にしさんの QAアーキテクチャのお話を聞きたいと思い、 今⽇の勉強会を主催しました 2
  3. 3. QAに対する問題意識 • そもそも品質とは何かが曖昧。⼈によって認識も異なる • 「このテストで⼤丈夫」と⾃信を持って判断したい • 誰かが抜けたら回らなくなるようでは困る(属⼈化したプロ セス) • かといって、重たすぎるプロセスを押し付けるのも何か違う 気がする • これらに対するヒントを持ち帰っていただければ幸いです 3
  4. 4. はじめに • 会場について • 本⽇は、電気通信⼤学様に教室をお借りし ています • 開催場所は主催者として本当に困っていた ところでした。ご協⼒いただき感謝いたし ます 4
  5. 5. はじめに • 会場について • お⼿洗いの場所 • 喫煙したい⽅へ 5
  6. 6. はじめに • (会場前⽅にあります)チラシについて • ICST 2017 • JaSSTʼ17 東京 • テスト設計コンテストʼ17 6
  7. 7. はじめに • 本⽇講演くださる、にしさんへ • 発端は私が個⼈的に「にしさんのQAアーキ テクチャ設計のお話を聞きたい」と⾔った ことが始まりでした。 • このたびはお時間を割いていただきまして ありがとうございます 7
  8. 8. はじめに • 参加者の皆様へ • 疑問に思ったことや感じたことは私やにし さんへフィードバックをお願いします • 遠慮は無⽤です。皆様に寄せられた意⾒や 質問が、本勉強会の価値になると思ってい ます 8
  9. 9. 本⽇の流れ ※変更があります • 19:00〜19:05 開催挨拶 • 19:05〜19:20 20:00 「QAアーキテクチャの 話」 • 20:00〜20:10 休憩 • 19:25 20:10〜21:10 「ここは苦しいところで すが、どうか⼀つ、QAアーキテクチャを。」 9
  10. 10. QAアーキテクチャの 話 藤沢 耕助
  11. 11. はじめに • ⾃分の理解でQAアーキテクチャ設計について お話しします。 • あくまで個⼈的な意⾒です。所属する組織や 団体とは⼀切関係ありません 11
  12. 12. はじめに、私の理解 12 QAアーキテクチャ 設計? QA ? アーキテクチャ 設計?
  13. 13. はじめに • QAアーキテクチャ設計とは何かを理解するた めには、「QAとは何か」と「アーキテクチャ 設計とは何か」を理解する必要があると考え ました 13
  14. 14. アジェンダ • QAとは(⼀般的な話) • アーキテクチャ設計とは(テスト設計コンテ ストでの経験を踏まえた、個⼈的な意⾒) • QAアーキテクチャ設計とは 14
  15. 15. アジェンダ • QAとは(⼀般的な話) • アーキテクチャ設計とは(テスト設計コンテ ストでの経験を踏まえた、個⼈的な意⾒) • QAアーキテクチャ設計とは 15
  16. 16. QAとは • 品質を保証すること 16
  17. 17. QAとは • 品質を保証すること 17 品質ってなに? 保証ってどういうこと?
  18. 18. QAとは • 品質とは何かには様々な定義がありますが、 ここでは仮に「顧客の要求との齟齬がどの程 度あるか」であるとします • 要求との齟齬が少ないほど⾼品質であると いう定義です 18
  19. 19. QAとは • 「顧客の要求との齟齬」 • 機能にバグがあり、仕様通りに動作しない • そもそもの仕様が要求と合っていない 19
  20. 20. QAとは • 「顧客の要求との齟齬」 • 機能にバグがあり、仕様通りに動作しない • そもそもの仕様が要求と合っていない 20 こちらを例にとって 説明してみます
  21. 21. 品質を保証するためにできるこ と • (例)テストしてバグが出ないことを証明す る 21
  22. 22. 品質を保証するためにできるこ と • (例)テストしてバグが出ないことを証明す る • 証明することはできない • 完全なバグゼロの開発も不可能 22
  23. 23. 品質を保証するためにできるこ と • 証明は不可能でも、納得してもらうことはで きる(合意の形成) • 特定の範囲に限定すれば「バグゼロ」も可能 23
  24. 24. 品質を保証するためにできるこ と • 証明は不可能でも、納得してもらうことはで きる(合意の形成) • 特定の範囲に限定すれば「バグゼロ」も可能 24
  25. 25. 品質を保証するためにできるこ と • 納得してもらうためにすること • 必要な観点が漏れてないよね?という確認 をクリアしなければならない • 漏れがないことは何をもって確認するのか? 25
  26. 26. 品質を保証するためにできるこ と • 抜け・漏れを⾒つけるためには何かしらの基 準、観点が必要 • 〜という⾒⽅をした時に、漏れはないです よね?という主張をする 26
  27. 27. 品質を保証するためにできるこ と • ISO25010の品質モデルを使った具体例 • カラオケの採点システム • 機能適合性:複数要素を評価し、⼀貫性のある採点が⾏えること • 性能効率性:採点結果や順位がリアルタイムで表⽰されること • 互換性:従来の採点システムと新採点システムのどちらかを選択 して利⽤できること • 使⽤性:評価のプラス要素、マイナス要素が確認できること 27
  28. 28. 品質を保証するためにできるこ と • ISO25010の品質モデルを使った具体例 • カラオケの採点システム • 信頼性:⻑時間の利⽤に耐えられること • セキュリティ:ログインに関する情報など個⼈情報が漏洩しない こと • 保守性:ソフトウェアのモジュール化が⾏われていること • 移植性:インストール⼿順などのドキュメントが整備されている こと 28
  29. 29. 品質を保証するためにできるこ と • 証明は不可能でも、納得してもらうことはで きる(合意の形成) • 特定の範囲に限定すれば「バグゼロ」も可能 29
  30. 30. 品質を保証するためにできるこ と • 障害発⽣確率0%のシステムは構築できない • 起きても仕⽅がない障害と、絶対に発⽣さ せられない障害とを分けて考える必要があ る • リスク分析 30
  31. 31. 品質を保証するためにできるこ と • リスク分析の結果、障害発⽣時の影響が⼤き いもの、利⽤頻度が⾼く障害発⽣の頻度も⾼ まると予想できるものについてはテストを厚 くする • 例)C0, C1といったモデルのカバレッジを 元に網羅性を⾼める 31
  32. 32. 品質を保証するためにできるこ と • そもそも、テスト以前にきちんとしたものを きちんとしたプロセスで作れば良いのでは? (障害発⽣の予防) • きちんと、ものを作っているか(検証) • きちんとしたものを、作っているか(妥当性 確認) 32
  33. 33. 品質を保証するためにできるこ と • ⼿順に沿って⾏えば品質が上がる? • そうとも限らない • 合わないプロセスの押し付けは逆効果 • ⼿順の遵守を保証したところで仕⽅がない 33
  34. 34. 品質を保証するためにできるこ と • とはいえ、⼿順がないことには評価すらでき ない • まず、今の⾃分たちがどう仕事をしているの か⾒えるようにする(⼿順に起こす) • その上で、⾃分たちの仕事に合ったプロセス がどういうものか皆で考える 34
  35. 35. 品質を保証するためにできるこ と • 現場主導でないプロセス改善は上⼿くいかない。 現場の反発を買う • 第三者の⽴場、開発者の⽴場、お互いの役割でで きること、⾒えることを活かして協⼒する • 開発者が「こうやるよ」と⾔ったものなら、「〜っ て⾔ってたけどやってないよ」とかも⾔いやすい 35
  36. 36. まとめ1 品質を保証すること(QA)とは • 何の品質を、何の⽬的で保証しているのかを顧客 に理解してもらう。納得してもらう(What, Why) • リスク分析の結果を踏まえて、品質保証の厚みを コントロールする(How much) • ⾼品質につながるようなプロセスを作っており、 それを守っていることを確認する(How) 36
  37. 37. アジェンダ • QAとは(⼀般的な話) • アーキテクチャ設計とは(テスト設計コンテ ストでの経験を踏まえた、個⼈的な意⾒) • QAアーキテクチャ設計とは 37
  38. 38. 開発におけるアーキテクチャ 設計 • 何を実現するのか(What) • それを実現する⽬的は何か(Why) • どのように実現するのか(How) • あくまで⽅針なので、抽象的なレベルにとどめる 38
  39. 39. テストにおけるアーキテクチャ 設計 • 何をテストするのか(What) • それをテストする⽬的は何か(Why) • どのようにテストするのか(How) • あくまで⽅針なので、抽象的なレベルにとどめる 39
  40. 40. テストにおけるアーキテクチャ 設計 • テストアーキテクチャの設計って、イマイチ よく分からない… • 実践の機会が欲しい • テスト設計コンテストに出場してみよう! 40
  41. 41. 私がテスト設計コンテストに 出てやろうとしたこと • 何をテストするのか(What) • それをテストする⽬的は何か(Why) • どのようにテストするのか(How) 41
  42. 42. 私がテスト設計コンテストに 出てやろうとしたこと • 何をテストするのか(What) • テスト要求が何か具体的に洗い出し、テス ト要求のリストを作成する 42
  43. 43. 私がテスト設計コンテストに 出てやろうとしたこと • それをテストする⽬的は何か(Why) • トップレベルの⽬的を設定し、それに対応 するテスト要求、テスト対象機能、テスト レベル、テストケースまで追跡できるよう にする • 何の⽬的でテストするのか明らかにする 43
  44. 44. 私がテスト設計コンテストに 出てやろうとしたこと • どのようにテストするのか(How) • 各テスト要求をどの統合レベルでテストす るか明らかにすることで、どのレベルでの 検証⼿順をテストケースとして実装すれば 良いかわかるようにする 44
  45. 45. 私がテスト設計コンテストに 出て作ったもの(テストプロセス) 45 QA • テストプロセス概要図
  46. 46. • テストプロセス概要図 私がテスト設計コンテストに 出て作ったもの(テストプロセス) 46 QA
  47. 47. • テストプロセス概要図 私がテスト設計コンテストに 出て作ったもの(テストプロセス) 47 QA
  48. 48. • テストプロセス概要図 私がテスト設計コンテストに 出て作ったもの(テストプロセス) 48 QA
  49. 49. 私がテスト設計コンテストに 出て作ったもの(テスト要求分析) 49 • 達成したい最上位の⽬的を明確にし、そのために 必要な要素をツリー構造で分析していく
  50. 50. 私がテスト設計コンテストに 出て作ったもの(テスト要求分析) 50 • ⽬的達成に必要な要素を 分析 • ⽬的達成を阻害する リスクを分析
  51. 51. 私がテスト設計コンテストに 出て作ったもの(テスト要求分析) 51 • 品質特性をガイドに⽬的の達成要素を分析
  52. 52. 私がテスト設計コンテストに 出て作ったもの(テスト対象分析) 52 • テスト要求を縦軸に配置、テスト対象を横軸 に配置し、テスト要求ごとに確認しなければ ならないテスト対象のスコープを決定する
  53. 53. 私がテスト設計コンテストに 出て作ったもの(テスト条件分析) 53 A ×× A X ×× ×× ×× • 各テスト要求をどの統合レベルでテストするか 明らかにする
  54. 54. • テストプロセス概要図 私がテスト設計コンテストに 出てやろうとしたこと 54 テスト要求分析 テスト対象分析 テスト条件分析 テスト設計 Why, What What What What, How
  55. 55. • テストプロセス概要図 私がテスト設計コンテストに 出てやろうとしたこと 55 A B C D Why, What
  56. 56. • テストプロセス概要図 私がテスト設計コンテストに 出てやろうとしたこと 56 A B C D What
  57. 57. • テストプロセス概要図 私がテスト設計コンテストに 出てやろうとしたこと 57 A B C D What, How
  58. 58. 私がテスト設計コンテストに 出てみた結果(⾃⼰評価) • 何をテストするのか(What):▲ • どういった⽬的でテストするのか(Why):▲ • どのようにテストするのか(How):▲ 58
  59. 59. 私がテスト設計コンテストに 出てみた結果(⾃⼰評価) • テストベースに引っ張られて、純粋な論理構造・階 層構造をツリー化することができなかった(What, Why) • 階層構造の検討不⼗分→”What”がブレる。最初 に挙げていた項⽬とツリー末端の項⽬で不整合に なる、必要な項⽬が漏れる • 論理構造の検討不⼗分→”Why”の説明がつかない 59
  60. 60. 私がテスト設計コンテストに 出てみた結果(⾃⼰評価) • ⾮機能テストについては、別のテスト分析のア プローチを取ってもよかったかもしれない (How) • ペルソナ分析、ユーザシナリオ分析など • 分析の⽅法によって、挙げやすいテストは変 わってくる 60
  61. 61. まとめ2 アーキテクチャ設計とは • ある対象(What)に対して、実現する⼿段 (How)を検討する • 対象を明確に定義した上で、⽬的(Why)と⼿段 (How)が不整合とならないように設計する • 実際にやってみると、最初に設定した⽬的と 末端の⼿段レベルの話で不整合になりがち 61
  62. 62. アジェンダ • QAとは • アーキテクチャ設計とは • QAアーキテクチャ設計とは 62
  63. 63. QAアーキテクチャ設計の例 63 レビューアーキテクチャ テストアーキテクチャ プロセス保証アーキテクチャ インフラアーキテクチャ
  64. 64. まとめ3 QAアーキテクチャ設計とは • まずはテストアーキテクチャの設計ができて から検討すべき • テストだけではなく、プロジェクト全体を俯 瞰してどのように品質を保証していくか⽅針 を決めていく必要がある • テストアーキテクチャ構築よりも範囲が広い 64
  65. 65. 忌憚ないご意⾒をお願いします • ぜひご意⾒・ご感想をお願いします • Twitter: @mhlyc • 参考⽂献 • とある品質保証部_成果物2_011_テスト要求分析.pdf • とある品質保証部_成果物4_プレゼンテーション資料.pptx • QAアーキテクチャの設計による説明責任の⾼いテスト・品質 保証(Yasuharu Nishi) 65

×