ソフトウェアテストと品質（発表資料）/Software test and quality study (Presentation)_20180925

by nihonbuson

Slide 1

Slide 1 text

ソフトウェアテストと品質（発表資料） D3：グルメなテストテスト設計 - レビュースペシャル - @nihonbuson P1

Slide 2

Slide 2 text

Agenda ● はじめに ● テストの7原則 ● テストの立ち位置とは ● 何をテストすべきか ● どうやってテストケースを作るのか ● どうやってテストを実施すべきか ● おわりに P2

Slide 3

Slide 3 text

はじめに P3

Slide 4

Slide 4 text

今回のスライドについて ● 今回のスライドを読んだだけでは伝えたいことの20%も書いていません。 ● ぜひ、スライドを共有するだけでなく、参加した人の言葉で社内に伝達を！ ● もしも伝えるのが難しければ、私を呼んでください！ – Twitterで連絡を！ ● https://twitter.com/nihonbuson

Slide 5

Slide 5 text

おことわり ● 今日の発表は一個人のお話です。 ● 所属する会社や団体とは一切関係ありません。 ● ただの野菜が喋っているだけです。

Slide 6

Slide 6 text

今日話す内容は… 評価チームはどうしていくべきか

Slide 7

Slide 7 text

今日話す内容は… 評価チームはどうしていくべきか ↓ 開発者はどんなことをすべきか

Slide 8

Slide 8 text

いきなりですが質問です品質とは何でしょうか？テストの目的は何でしょうか？ P4

Slide 9

Slide 9 text

品質とは何か？

Slide 10

Slide 10 text

品質とは何か？「本来備わっている特性の集まりが要求事項を満たす程度。」 (ISO9000) 「品物またはサービスが、使用目的を満たしているかどうかを決定するための評価の対象となる固有の性質・性能の全体」 (JIS Z 8101:1981, 1999年に廃止)

Slide 11

Slide 11 text

品質とは何か？東京海上日動システムズ顧問横塚裕志氏の講演内容より【具体例2】デジタルニュースの普及により、ニュースは、確実な推敲・校正よりも、「早く伝える」「修正」へ【具体例1】トラブルは0でも、国民の5.8%にしか使われない住基ネットカード。「ソフトウェアの品質（＝存在意義）としては失格」 ※ソフトウェア品質シンポジウム 2014の基調講演にて http://www.publickey1.jp/blog/14/_2014.html P5

Slide 12

Slide 12 text

テストの目的は何か？

Slide 13

Slide 13 text

テストの目的は何か？以下のような目的があります。 ● 欠陥の検出 ● 対象ソフトウェアの品質レベルが十分であることの確認 ● 意思決定のための情報の提示 ● 欠陥の作りこみの防止 JSTQBシラバスより http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2011.J02.pdf#page=14 実装前に行うこともあるテストの7原則①テストは「欠陥がある」ことしか示せない P6

Slide 14

Slide 14 text

テストの7原則 P7

Slide 15

Slide 15 text

テストの7原則 1. テストは「欠陥がある」ことしか示せない 2. 全数テストは不可能 3. 初期テスト 4. 欠陥の偏在 5. 殺虫剤のパラドックス 6. テストは条件次第 7. 「バグゼロ」の落とし穴 http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2011.J02.pdf#page=15 P8

Slide 16

Slide 16 text

テストの7原則 1. テストは「欠陥がある」ことしか示せない – テストによって「この製品はバグが無い」とは証明できない。 2. 全数テストは不可能 – すべてのパターン数は膨大なのでテスト不可能。 3. 初期テスト – いかに早く欠陥に気付けるかが重要 – 「テストは後で」とか考えないこと！後で詳しく！後で詳しく！

Slide 17

Slide 17 text

テストの7原則 4. 欠陥の偏在 – 欠陥は満遍なく存在はせず、局所的に発生する 5. 殺虫剤のパラドックス – 同じ殺虫剤を使い続けると虫も耐性を持ち、だんだん効かなくなる – 同様に、同じテストを繰り返すとだんだん新しい欠陥を発見できなくなる後で詳しく！後で詳しく！

Slide 18

Slide 18 text

テストの7原則 6. テストは条件次第 – ソフトウェアの種類によって、テストしたい内容やテストにかけるコストが変わる。 – 例えば、人命に関わる製品とゲーム製品は同じ品質やテストの工数にはならない 7. 「バグゼロ」の落とし穴 – 必ずしも「欠陥が無い＝素晴らしい」ではない。 – 例：バグは0だけど、システムの起動に5時間かかる

Slide 19

Slide 19 text

全体の開発サイクルの中でのテストの立ち位置とは P9

Slide 20

Slide 20 text

Vモデル(一般的なSIの場合) 要求定義要件定義基本設計詳細設計コーディング単体テスト結合テストシステムテスト受け入れテスト http://jasst.jp/symposium/jasst12tokyo/pdf/D4-1.pdf P10

Slide 21

Slide 21 text

各段階（テストレベル）のテスト例 ● 単体テスト（モジュールテスト） – 商品の個数欄にマイナスの数値を入力できない。 ● 結合テスト – カートに3個入っていて、2個追加したら、確認ページで5個になった。 ● システムテスト – 会員登録→商品購入→商品キャンセル→退会の一連の流れ。 P11

Slide 22

Slide 22 text

Wモデル要求定義要件定義基本設計詳細設計レビュー&受け入れテストの設計レビュー&システムテストの設計レビュー& 結合テストの設計レビュー& 単体テストの設計受け入れテストの実施システムテストの実施結合テストの実施単体テストの実施コーディングデバッグデバッグデバッグデバッグ P12

Slide 23

Slide 23 text

なぜ早期のテスト・レビューをするのか http://www.jaspic.org/event/2009/SPIJapan/keynote/SJ9keynote.pdf#page=31 P13

Slide 24

Slide 24 text

何をテストすべきか P14

Slide 25

Slide 25 text

次の仕様に対してどんなテストをすれば良いか。 ● パスワードは4文字以上12文字以下の英数字のみを許容する ● パスワードを3分以内に4回以上間違って入力するとアカウントを5分間ロックする http://www.slideshare.net/takashiyamasaki378/ss-55384920 例題

Slide 26

Slide 26 text

ステップ1 ● 例題について考えてみてください。 ● あなたが考えたテスト条件を15ページに書いてください。

Slide 27

Slide 27 text

ステップ2 ● 隣の人と2人組を作ってください。 ● お互いに何を書いたのか説明してください。

Slide 28

Slide 28 text

パスワードは4文字以上12文字以下の英数字のみを許容するパスワードを3分以内に4回以上間違って入力するとアカウントを5分間　ロックする文字列長文字種誤入力期間管理誤入力回数管理ロック保持期間状態遷移 P16

Slide 29

Slide 29 text

パスワードは4文字以上12文字以下の英数字のみを許容するパスワードを3分以内に4回以上間違って入力するとアカウントを5分間　ロックする文字列長文字種誤入力期間管理誤入力回数管理ロック保持期間状態遷移許容しないとどうなる？ (ボタン制御orエラー画面) 5回目の入力はどうなる？ P16

Slide 30

Slide 30 text

Aさん設計・開発時点 Bさんはエラー画面を作ってくれるだろう。 Aさんはエラーをボタン制御でやるだろう。 Bさん

Slide 31

Slide 31 text

テスト時点なんでエラー画面を作っていないの？私はボタン制御でエラー管理をしていると思っていたよ！ Aさん Bさん

Slide 32

Slide 32 text

Mr.A Bさんテスト時点なんでエラー画面を作っていないの？私はボタン制御でエラー管理をしていると思っていたよ！追加コストが発生！

Slide 33

Slide 33 text

Slide 34

Slide 34 text

2つの伝えたいこと ● 隣の人はあなたが気付かなかったことを知っていませんでしたか？ – お互いにテスト内容についても議論しましょう。 ●

Slide 35

Slide 35 text

2つの伝えたいこと ● 隣の人はあなたが気付かなかったことを知っていませんでしたか？ – お互いにテスト内容についても議論しましょう。 ● この例では何もプログラムを書いていません。 – 実装前にテストすることができる例です。 – もしもこの時点で指摘できれば、総コストは削減できるでしょう。

Slide 36

Slide 36 text

もしもドキュメントが無かったら… パスワードは4文字以上12文字以下の英数字のみを許容するパスワードを3分以内に4回以上間違って入力するとアカウントを5分間ロックするどのようなテストを行えば良いか分からなくなります

Slide 37

Slide 37 text

テストすべき内容（テスト観点）の見つけ方 http://jasst.jp/symposium/jasst13niigata/pdf/S2.pdf P17

Slide 38

Slide 38 text

視座誰が使うのか、物事を見る立場 P18

Slide 39

Slide 39 text

視野物事を考えたり判断したりする範囲 P19

Slide 40

Slide 40 text

視点着目するところ、物事を考える観点 P20

Slide 41

Slide 41 text

（参考）品質特性 http://www.atmarkit.co.jp/ait/articles/0905/13/news124_3.html P21

Slide 42

Slide 42 text

使用性の例

Slide 43

Slide 43 text

使用性の例面白いデザインだ！採用！デザイナーどこに何があるのか分からない！利用者

Slide 44

Slide 44 text

使用性の例並び変えるだけでも分かりやすくなる https://note.openvista.jp/2011/redesigning-shinjuku-building-sign

Slide 45

Slide 45 text

どうやってテストケースを作るのか P22

Slide 46

Slide 46 text

テストケースはいくつ？パスワードは4文字以上12文字以下 1文字、2文字、3文字…100文字膨大な数のテストケーステストの7原則②全数テストは不可能 P23

Slide 47

Slide 47 text

テストケースはいくつ？ ● テストケースは時間とあれば無限にできます。 ● サンプリング方法としてテスト設計技法があります。 – テストケースを合理的に少なくするための技法 ● 同値分割法、　All Pair法 – 多くの欠陥が見つかるようにするための技法 ● 境界値分析、　エラー推測、　探索的テスト – テスト対象を（ある観点で）漏れなくテストするための技法 ● カバレッジ、デシジョンテーブル、状態遷移、ユースケーステスト http://aster.or.jp/business/seminar_text.html

Slide 48

Slide 48 text

テストケース作成者「○○○のテストをします！」司会者「ほぉ～、それはどうしてだい？」テストケース作成者「【理由を一言】」テストケース作成の心得 P24

Slide 49

Slide 49 text

テスト設計技法　～境界値分析～テストの7原則④欠陥の偏在 12 4 有効無効無効 3 13 パスワードは4文字以上12文字以下 P25

Slide 50

Slide 50 text

テスト設計技法　～境界値分析～ ● 「パスワードが4文字以上12文字以下」でなぜ3,4,12,13をテストするのか？ if( x < 3 ){ return “入力したパスワードが短いです”; }

Slide 51

Slide 51 text

テスト設計技法　～境界値分析～ ● 「パスワードが4文字以上12文字以下」でなぜ3,4,12,13をテストするのか？ if( x < 3 ){ return “入力したパスワードが短いです”; } ● 上記の例で、不等号のミスによる不具合を発見できるのは、3の時だけ！

Slide 52

Slide 52 text

テスト設計技法　～境界値分析～テストの7原則④欠陥の偏在 12 4 有効無効無効 3 13 パスワードは4文字以上12文字以下 P25

Slide 53

Slide 53 text

テスト設計技法　～境界値分析～テストの7原則④欠陥の偏在 12 4 有効無効無効 3 13 パスワードは4文字以上12文字以下 P25 0

Slide 54

Slide 54 text

テスト設計技法　～状態遷移テスト～スタート/ストップリセット

Slide 55

Slide 55 text

テスト設計技法　～状態遷移テスト～待機中計測中一時停止中スタート/ストップリセットスタート/ ストップスタート/ ストップ P26

Slide 56

Slide 56 text

テスト設計技法　～状態遷移テスト～待機中計測中一時停止中スタート/ストップリセットスタート/ ストップスタート/ ストップ P26 計測中

Slide 57

Slide 57 text

テスト設計技法　～状態遷移テスト～ P26 待機中計測中一時停止中スタート/ストップリセットスタート/ ストップスタート/ ストップ

Slide 58

Slide 58 text

テスト設計技法　～状態遷移テスト～ P26 待機中計測中一時停止中スタート/ストップリセットスタート/ ストップスタート/ ストップ

Slide 59

Slide 59 text

テスト設計技法　～状態遷移テスト～ P26 待機中計測中一時停止中スタート/ストップリセットスタート/ ストップスタート/ ストップリセットリセット

Slide 60

Slide 60 text

テスト設計技法　～状態遷移テスト～ P26 待機中計測中一時停止中スタート/ストップリセットスタート/ ストップスタート/ ストップリセットリセット開発者は上記の矢印6か所を最低限実施する必要がある。

Slide 61

Slide 61 text

テスト設計技法　～状態遷移テスト～計測中にリセットボタンを押したら計測中状態から変わらないなんて、問題文（仕様）に書いてない！待機中に変わると思ってた！

Slide 62

Slide 62 text

テスト設計技法　～状態遷移テスト～今回は私なりに答えを定めました。実務では、動作が不明な時点で開発者に確認すべき。仕様に書いていない→抜け漏れの可能性大→バグの可能性大

Slide 63

Slide 63 text

どうやってテストを実施するのか P27

Slide 64

Slide 64 text

テストは実施して終わりではないパスワードを「123」にしてログインしようとしたら、ログインできなかった P28

Slide 65

Slide 65 text

テストは実施して終わりではないパスワードを「123」にしてログインしようとしたら、ログインできなかった何を確認したくて「123」にしたのか？「ログインできない」とはどのような状態なのか？期待通りの結果なのか？ P28

Slide 66

Slide 66 text

テストレポート例テスト目的再現手順期待値 OK or NG 実際の結果パスワードが 3桁以下の時ログイン失敗ページに遷移することパスワード欄に「123」と入力する。ログインボタンを押す。ログイン失敗画面に遷移する NG ログイン画面から遷移せず、「ログイン失敗」と表示される他の人や1年後の自分が見ても分かるように書く P29

Slide 67

Slide 67 text

まとめ P30

Slide 68

Slide 68 text

まとめ ● テストの目的は欠陥の検出以外に欠陥の未然防止がある ● テストには開発開始前に行う活動もある ● 早期にテストやレビューをすることでコストを削減できる ● テストすべき内容には、仕様書から見つけられる内容以外にも、過去の経験から得られることや品質特性などがある ● 全てを闇雲にテストすると膨大なケース数と時間が発生するが、その数を削減できる手法がある ● テストを実施したときは、他の人が分かるように結果を書く P31

Slide 69

Slide 69 text

おまけ（講座中にあった質問）

Slide 70

Slide 70 text

評価チームは何をするの？これだけテストが充実できれば評価チームは必要ないのでは？

Slide 71

Slide 71 text

評価チームは何をするの？これだけテストが充実できれば評価チームは必要ないのでは？ ⇒まだまだ必要なことが多いです。テストエンジニアは 1. システムテストレベルを確認したい！ 2. CheckingではなくTestingを行いたい

Slide 72

Slide 72 text

P11 1. 評価チームはシステムテストレベルを見たい！ ● 単体テスト（モジュールテスト） – 商品の個数欄にマイナスの数値を入力できない。 ● 結合テスト – カートに3個入っていて、2個追加したら、確認ページで5個になった。 ● システムテスト – 会員登録→商品購入→商品キャンセル→退会の一連の流れ。評価チームはここをやりたい！

Slide 73

Slide 73 text

P11 1. 評価チームはシステムテストレベルを見たい！ ● 単体テスト（モジュールテスト） – 商品の個数欄にマイナスの数値を入力できない。 ● 結合テスト – カートに3個入っていて、2個追加したら、確認ページで5個になった。 ● システムテスト – 会員登録→商品購入→商品キャンセル→退会の一連の流れ。開発者はここをやりきれ！

Slide 74

Slide 74 text

2. 評価チームはTestingをしたい！ https://www.infoq.com/jp/news/2009/12/testing-or-checking

Slide 75

Slide 75 text

2. 評価チームはTestingをしたい！ https://www.infoq.com/jp/news/2009/12/testing-or-checking Checking 意図通り動くか確認する作業 Testing なんとかして製品を破壊する作業

Slide 76

Slide 76 text

2. 評価チームはTestingをしたい！【参考】アジャイルテストの4象限 Checking Testing

Slide 77

Slide 77 text

2. 評価チームはTestingをしたい！ http://www.jasst.jp/symposium/jasst17tokyo/pdf/A7.pdf#page=29

Slide 78

Slide 78 text

テストの勉強方法を知りたいどうやってテストの勉強をすれば良いの？テストの勉強ができるオススメの書籍が知りたい！

Slide 79

Slide 79 text

テストの勉強でオススメの書籍（入門者向け） https://www.amazon.co.jp/dp/4822282511 https://www.amazon.co.jp/dp/4817193603

Slide 80

Slide 80 text

テストの勉強でオススメの書籍（自動テスト、入門者向け） https://www.amazon.co.jp/dp/4873118166/ 画面上の自動テストの開発に関わらない人も、第1章と第8章を読むべき

Slide 81

Slide 81 text

テストの勉強でオススメの書籍（入門から一歩先行く初心者向け） https://www.amazon.co.jp/dp/4798124699 テストとはどうあるべきかが分かる本資格勉強用の本だが、資格を取らなくても勉強になる

Slide 82

Slide 82 text

品質を高めるための一冊 https://www.amazon.co.jp/dp/4873115655 テストは品質を測るための道具であり、品質は上がらない。品質を上げるためにはコードを綺麗に書こう。

Slide 83

Slide 83 text

おしまい…？

Slide 84

Slide 84 text

この講座で伝えたかったこと（裏の目的）

Slide 85

Slide 85 text

社外イベントからの引用が多い

Slide 86

Slide 86 text

社外イベントからの引用が多い

Slide 87

Slide 87 text

テストの勉強は「習うより慣れよ」 ● 1泊2日のワークショップ形式のイベント ● 半年に1度開催（6月と12月）。 ● 次回は12月15日、16日 ● 10周年を迎えました！ ● 新卒1年目の開発やQAも多く参加 ● 参加費は24000円（35歳以上は27000円） ● ほとんどが宿泊費・経費で利益は無し http://wacate.jp

Slide 88

Slide 88 text

最新のテスト事情を知るには JaSSTがオススメ ● 日本最大級のテストのイベント ● 年に8回、各地で実施 ● 次回は11月22日に長崎で開催 ● 東京では毎年2月～3月に2日間開催 ● 次回は2019年3月27日・28日 http://www.jasst.jp/

Slide 89

Slide 89 text

【宣伝】JaSST Review開催決定！ ● レビューのシンポジウムを開催します！ ● 日程：12月14日 ● 場所：赤坂 http://www.jasst.jp/symposium/jasstreview18.html

Slide 90

Slide 90 text

もっとテスト設計を学ぶならテスト設計コンテストチュートリアル ● テスト設計コンテストとは – 指定された共通の製品に対してテスト設計を行い、その優劣を競うイベント ● テスト設計コンテストチュートリアル – U-30クラス（10月2日開催） ● http://aster.or.jp/business/contest/tutorialu30.html – OPENクラス（10月5日開催） ● http://aster.or.jp/business/contest/tutorial.html