Qaアーキテクチャの話

QA勉強会「ここは苦しいところですが、どうか⼀つ、QAアーキテクチャを。」開催挨拶2016/12/20 藤沢耕助

⾃⼰紹介

• 某企業でQAの仕事をしています、藤沢と申します

• QAとは何かよくわかっておらず、にしさんのQAアーキテクチャのお話を聞きたいと思い、今⽇の勉強会を主催しました

2

QAに対する問題意識

• そもそも品質とは何かが曖昧。⼈によって認識も異なる

• 「このテストで⼤丈夫」と⾃信を持って判断したい

• 誰かが抜けたら回らなくなるようでは困る（属⼈化したプロセス）

• かといって、重たすぎるプロセスを押し付けるのも何か違う気がする

• これらに対するヒントを持ち帰っていただければ幸いです

3

はじめに

• 会場について

• 本⽇は、電気通信⼤学様に教室をお借りしています

• 開催場所は主催者として本当に困っていたところでした。ご協⼒いただき感謝いたします

4

はじめに

• 会場について

• お⼿洗いの場所

• 喫煙したい⽅へ

5

はじめに

• （会場前⽅にあります）チラシについて

• ICST 2017

• JaSSTʼ17 東京

• テスト設計コンテストʼ17

6

はじめに

• 本⽇講演くださる、にしさんへ

• 発端は私が個⼈的に「にしさんのQAアーキテクチャ設計のお話を聞きたい」と⾔ったことが始まりでした。

• このたびはお時間を割いていただきましてありがとうございます

7

はじめに

• 参加者の皆様へ

• 疑問に思ったことや感じたことは私やにしさんへフィードバックをお願いします

• 遠慮は無⽤です。皆様に寄せられた意⾒や質問が、本勉強会の価値になると思っています

8

本⽇の流れ ※変更があります

• 19:00〜19:05 開催挨拶

• 19:05〜19:20 20:00 「QAアーキテクチャの話」

• 20:00〜20:10 休憩

• 19:25 20:10〜21:10 「ここは苦しいところですが、どうか⼀つ、QAアーキテクチャを。」

9

QAアーキテクチャの話

藤沢耕助

はじめに

• ⾃分の理解でQAアーキテクチャ設計についてお話しします。

• あくまで個⼈的な意⾒です。所属する組織や団体とは⼀切関係ありません

11

はじめに、私の理解

12

QAアーキテクチャ設計？

QA ？

アーキテクチャ設計？

はじめに

• QAアーキテクチャ設計とは何かを理解するためには、「QAとは何か」と「アーキテクチャ設計とは何か」を理解する必要があると考えました

13

アジェンダ

• QAとは（⼀般的な話）

• アーキテクチャ設計とは（テスト設計コンテストでの経験を踏まえた、個⼈的な意⾒）

• QAアーキテクチャ設計とは

14

アジェンダ




15

QAとは

• 品質を保証すること

16

QAとは

• 品質を保証すること

17

品質ってなに？保証ってどういうこと？

QAとは

• 品質とは何かには様々な定義がありますが、ここでは仮に「顧客の要求との齟齬がどの程度あるか」であるとします

• 要求との齟齬が少ないほど⾼品質であるという定義です

18

QAとは

• 「顧客の要求との齟齬」

• 機能にバグがあり、仕様通りに動作しない

• そもそもの仕様が要求と合っていない

19

QAとは

• 「顧客の要求との齟齬」

• 機能にバグがあり、仕様通りに動作しない

• そもそもの仕様が要求と合っていない

20

こちらを例にとって説明してみます

品質を保証するためにできること• （例）テストしてバグが出ないことを証明す

る

21

品質を保証するためにできること• （例）テストしてバグが出ないことを証明す

る

• 証明することはできない

• 完全なバグゼロの開発も不可能

22

品質を保証するためにできること• 証明は不可能でも、納得してもらうことはで

きる（合意の形成）

• 特定の範囲に限定すれば「バグゼロ」も可能

23




24

品質を保証するためにできること• 納得してもらうためにすること

• 必要な観点が漏れてないよね？という確認をクリアしなければならない

• 漏れがないことは何をもって確認するのか？

25

品質を保証するためにできること• 抜け・漏れを⾒つけるためには何かしらの基

準、観点が必要

• 〜という⾒⽅をした時に、漏れはないですよね？という主張をする

26

品質を保証するためにできること• ISO25010の品質モデルを使った具体例

• カラオケの採点システム

• 機能適合性：複数要素を評価し、⼀貫性のある採点が⾏えること

• 性能効率性：採点結果や順位がリアルタイムで表⽰されること

• 互換性：従来の採点システムと新採点システムのどちらかを選択して利⽤できること

• 使⽤性：評価のプラス要素、マイナス要素が確認できること

27

品質を保証するためにできること• ISO25010の品質モデルを使った具体例

• カラオケの採点システム

• 信頼性：⻑時間の利⽤に耐えられること

• セキュリティ：ログインに関する情報など個⼈情報が漏洩しないこと

• 保守性：ソフトウェアのモジュール化が⾏われていること

• 移植性：インストール⼿順などのドキュメントが整備されていること

28




29

品質を保証するためにできること• 障害発⽣確率0%のシステムは構築できない

• 起きても仕⽅がない障害と、絶対に発⽣させられない障害とを分けて考える必要がある

• リスク分析

30

品質を保証するためにできること• リスク分析の結果、障害発⽣時の影響が⼤き

いもの、利⽤頻度が⾼く障害発⽣の頻度も⾼まると予想できるものについてはテストを厚くする

• 例）C0, C1といったモデルのカバレッジを元に網羅性を⾼める

31

品質を保証するためにできること• そもそも、テスト以前にきちんとしたものを

きちんとしたプロセスで作れば良いのでは？（障害発⽣の予防）

• きちんと、ものを作っているか（検証）

• きちんとしたものを、作っているか（妥当性確認）

32

品質を保証するためにできること• ⼿順に沿って⾏えば品質が上がる？

• そうとも限らない

• 合わないプロセスの押し付けは逆効果

• ⼿順の遵守を保証したところで仕⽅がない

33

品質を保証するためにできること• とはいえ、⼿順がないことには評価すらでき

ない

• まず、今の⾃分たちがどう仕事をしているのか⾒えるようにする（⼿順に起こす）

• その上で、⾃分たちの仕事に合ったプロセスがどういうものか皆で考える

34

品質を保証するためにできること• 現場主導でないプロセス改善は上⼿くいかない。

現場の反発を買う

• 第三者の⽴場、開発者の⽴場、お互いの役割でできること、⾒えることを活かして協⼒する

• 開発者が「こうやるよ」と⾔ったものなら、「〜って⾔ってたけどやってないよ」とかも⾔いやすい

35

まとめ１品質を保証すること(QA)とは• 何の品質を、何の⽬的で保証しているのかを顧客

に理解してもらう。納得してもらう(What, Why)

• リスク分析の結果を踏まえて、品質保証の厚みをコントロールする(How much)

• ⾼品質につながるようなプロセスを作っており、それを守っていることを確認する(How)

36

アジェンダ




37

開発におけるアーキテクチャ設計• 何を実現するのか(What)

• それを実現する⽬的は何か(Why)

• どのように実現するのか(How)

• あくまで⽅針なので、抽象的なレベルにとどめる

38

テストにおけるアーキテクチャ設計• 何をテストするのか(What)

• それをテストする⽬的は何か(Why)

• どのようにテストするのか(How)

• あくまで⽅針なので、抽象的なレベルにとどめる

39

テストにおけるアーキテクチャ設計• テストアーキテクチャの設計って、イマイチ

よく分からない…

• 実践の機会が欲しい

• テスト設計コンテストに出場してみよう！

40

私がテスト設計コンテストに出てやろうとしたこと• 何をテストするのか(What)

• それをテストする⽬的は何か(Why)

• どのようにテストするのか(How)

41

私がテスト設計コンテストに出てやろうとしたこと• 何をテストするのか(What)

• テスト要求が何か具体的に洗い出し、テスト要求のリストを作成する

42

私がテスト設計コンテストに出てやろうとしたこと• それをテストする⽬的は何か(Why)

• トップレベルの⽬的を設定し、それに対応するテスト要求、テスト対象機能、テストレベル、テストケースまで追跡できるようにする

• 何の⽬的でテストするのか明らかにする

43

私がテスト設計コンテストに出てやろうとしたこと• どのようにテストするのか(How)

• 各テスト要求をどの統合レベルでテストするか明らかにすることで、どのレベルでの検証⼿順をテストケースとして実装すれば良いかわかるようにする

44

私がテスト設計コンテストに出て作ったもの（テストプロセス）

45

QA

• テストプロセス概要図



46

QA



47

QA



48

QA

私がテスト設計コンテストに出て作ったもの（テスト要求分析）

49

• 達成したい最上位の⽬的を明確にし、そのために必要な要素をツリー構造で分析していく


50

• ⽬的達成に必要な要素を分析

• ⽬的達成を阻害するリスクを分析


51

• 品質特性をガイドに⽬的の達成要素を分析

私がテスト設計コンテストに出て作ったもの（テスト対象分析）

52

• テスト要求を縦軸に配置、テスト対象を横軸に配置し、テスト要求ごとに確認しなければならないテスト対象のスコープを決定する

��

私がテスト設計コンテストに出て作ったもの（テスト条件分析）

53

A

××

A X

××

××

××

• 各テスト要求をどの統合レベルでテストするか明らかにする


私がテスト設計コンテストに出てやろうとしたこと

54

テスト要求分析

テスト対象分析

テスト条件分析

テスト設計

Why, What

What

What

What, How



55

A

B

C

D

��

Why, What



56

A

B

C

D

��

What



57

A

B

C

D

��

What, How

私がテスト設計コンテストに出てみた結果（⾃⼰評価）• 何をテストするのか(What)：▲

• どういった⽬的でテストするのか(Why)：▲

• どのようにテストするのか(How)：▲

58

私がテスト設計コンテストに出てみた結果（⾃⼰評価）• テストベースに引っ張られて、純粋な論理構造・階

層構造をツリー化することができなかった(What, Why)

• 階層構造の検討不⼗分→”What”がブレる。最初に挙げていた項⽬とツリー末端の項⽬で不整合になる、必要な項⽬が漏れる

• 論理構造の検討不⼗分→”Why”の説明がつかない

59

私がテスト設計コンテストに出てみた結果（⾃⼰評価）• ⾮機能テストについては、別のテスト分析のア

プローチを取ってもよかったかもしれない(How)

• ペルソナ分析、ユーザシナリオ分析など

• 分析の⽅法によって、挙げやすいテストは変わってくる

60

まとめ２アーキテクチャ設計とは• ある対象(What)に対して、実現する⼿段

(How)を検討する

• 対象を明確に定義した上で、⽬的(Why)と⼿段(How)が不整合とならないように設計する

• 実際にやってみると、最初に設定した⽬的と末端の⼿段レベルの話で不整合になりがち

61

アジェンダ

• QAとは

• アーキテクチャ設計とは


62

QAアーキテクチャ設計の例

63

レビューアーキテクチャ

テストアーキテクチャ

プロセス保証アーキテクチャ

インフラアーキテクチャ

まとめ３ QAアーキテクチャ設計とは• まずはテストアーキテクチャの設計ができて

から検討すべき

• テストだけではなく、プロジェクト全体を俯瞰してどのように品質を保証していくか⽅針を決めていく必要がある

• テストアーキテクチャ構築よりも範囲が広い

64

忌憚ないご意⾒をお願いします

• ぜひご意⾒・ご感想をお願いします

• Twitter: @mhlyc

• 参考⽂献

• とある品質保証部_成果物2_011_テスト要求分析.pdf

• とある品質保証部_成果物4_プレゼンテーション資料.pptx

• QAアーキテクチャの設計による説明責任の⾼いテスト・品質保証（Yasuharu Nishi）

65

http://www.slideshare.net/YasuharuNishi/qa-67559281

http://www.slideshare.net/YasuharuNishi/qa-67559281

Qaアーキテクチャの話

Software

Transcript of Qaアーキテクチャの話