社内勉強会用に作成した資料です

1. Getting Test World

2. 自己紹介
名前：橘田 隼一
TwitterID：hayabusa333
興味：カーネル、GC、Erlang、Elixir
お仕事：派遣ウェッブプログラマ
所属：Joel教、翔鶴瑞鶴仲良し姉妹同盟

3. 本スライドについて
本スライドはJSTQBときょんさんのブログ・スライドを
まとめた内容になります。
参考文献に載せておりますが、興味を持たれた方は参考
文献に当たった方がよいかと思います。

4. 本スライドの用語解説
・JSTQB：ソフトウェアテスト技術のスキルを証明する
テストの資格
・Beizer：アメリカのソフトウェア開発者でありソフト
ウェアテストについての論文を記載し、テスト関連の本
で引用される人

5. 目次
・ソフトウェアテストの言葉の定義
・ソフトウェアテストの原則
・ソフトウェアテスト
・テストの振り返り
・テストのテスト
・参考文献

6. ソフトウェアテストの言葉の定義
プロジェクト内部で使用する言葉の定義についての話。
言葉の定義だけなので、別に本スライドに記載されてい
る内容と違っていても問題はありません。
プロジェクトにかかわる人の全員と同意できており、全
員が同じ言葉で話せるのならば問題はありません

7. ソフトウェアテストの言葉の定義
・テストレベル
・テスト技法
・テストタイプ
・テスト対象
・テスト目的
・テストプロセス
・テスト観点

8. テストレベル
JSTQBに定義されているテストレベルの定義
・コンポーネントテスト：スタブを使うようなコンポーネントや
クラスなどのテスト
・結合テスト：コンポーネント間やシステム間を統合して動作さ
せるテスト
・システムテスト：ステージング環境などでプロジェクトのスコー
プにあたるソフトウェアの動作をさせるテスト
・受け入れテスト：要求を出した人の意に沿ったものであるかを
確認するテスト

9. テストレベル
Beizerが定義しているテストレベルの定義
・ユニットテスト：1ファイル内で動作が可能なテスト
・コンポーネントテスト：あるユニットが動作するのに必要なユニッ
トを含めたテスト。ある機能を達成するための再帰的なテスト
・統合テスト：コンポーネント間のテスト。
・システムテスト：システム全体を動作させてのテスト。コンポー
ネントテストや、統合テストでは検出されないようなバグを検出す
るためのテストであり、JSTQBのステージング環境が想定され
る。

10. テスト技法
入力パラメータや出力結果の列挙や組み合わせを、
どのように決定するかの手法のこと
・同値分析
・境界値分析
・デジションテーブル
・直交表
・etc

11. テストタイプ
どのような目的でテストを実施するのかを分類
したテスト。
テストレベルと同じくプロジェクト毎に同意し
ていれば問題はない。
実際のテストタイプについては後述

12. テスト対象
ソフトウェアテストの対象物
機能毎に分割でも、インフラ面で分割でも問題
なし。
テストタイプごとに対象となるテストを分割し
て明示的に残すし、テスト対象が他の人にもわ
かるようにしておくことが大事

13. テスト目的
どのような理由でテストを実施するのかでの分類
JSTQBでは、V字モデルの各ドキュメントに沿っ
ていることを目的にしている。

14. テストプロセス
・テスト要求分析：テスト目的を導入したり、リスク分析を行ったり
する。
・テスト戦略策定：テスト観点をベースにしてテストのアーキテクチャ
を作ったり、人的リソースや手段を考慮してテストのライフサイクル
を考える
・テスト設計：テスト実装がうまくいくように設計する
・テスト実装：テスト仕様書の作成やテストケースの作成
・テスト実施：テストを実際に報告し、欠陥があればレポートにする
・テスト報告：テスト結果の報告

15. テスト観点
日本のソフトウェアテスト業界におけるテスト
観点は「テスト対象とテスト目的のペアである」
らしいです。
テストにおける関心毎

16. 上記のようなテストの言葉の定義をしっ
かりと行い、プロジェクトごとに話が
噛み合うようにすることが重要

17. ソフトウェアテストの原則
JSTQBで定められている7つの原則
・テストは「欠陥がある」ことしか示せない
・全数テストは不可能
・初期テスト
・欠陥の偏在
・殺虫剤のパラドックス
・テストは条件次第
・「バグゼロ」の落とし穴

18. テストは「欠陥がある」ことしか示せない
テストにより故障を見つけることができれば、
ソフトウェアに欠陥があることはわかる
しかしテストにより故障が見つからなかった場
合は、欠陥がなかったとはいえない
テスト自身に不備があった場合には、欠陥は見
つからない

19. コラム「テストは品質をあげない」
家が傾いているかテストしても、その行為では
品質は上がらないように、品質はソフトウェア
を作るときに上下するものである。
テストは品質の担保をするだけで、テスト単体
では品質をあがらない。

20. 全数テストは不可能
正常系のテストとして100 100のテストパターンが
あった場合に、テストケース数は10000通りとなる。
テストは正常系だけではなく、エラー系も重要である。
通常のテストパターンはもっと複雑であり時間のかかる
ものである
ソフトウェアの性質や目的、使われ方などから重点的
にテストをする場所を絞り、優先順位を決めてテストを
行うことが重要である

21. 初期テスト
欠陥が開発の早い段階で見つかるよりも、リリー
ス前に見つかる方が修正のコストは高くつく
時間がたてばたつほど、修正のコストは指数関数
的に増大する
システム開発のなるべく早い段階からテストを開
始し、欠陥を見つけるようにするのが得策である

22. 欠陥の偏在
ソフトウェアの品質は均一なものでなく、欠陥は一部に集中し
ている。
ソフトウェアの欠陥の8割は全体の2割の箇所に集中して存在
している。
欠陥の偏在は過去の不具合分析や、直近のテスト結果によって
予測可能である
効果的なテストを行うためには、その予測結果に基づいてテス
トする箇所を絞り込む必要がある

23. 殺虫剤のパラドックス
1つのソフトウェアに対して同じテストを何度もなんど
も繰り返すと、最終的にはそのテストでは新しい欠陥は
見つからなくなる。
そのためソフトウェアのテストに対しては新しいテスト
内容を常に作っていく必要がある。
パターンを追加するごとに欠陥が減っているのならば、
ソフトウェアの品質が向上しているといえる

24. テストは条件次第
ソフトウェアが使われる状況、目的によってテストの方
法を変える必要がある
すべてのソフトウェアに共通するテストはない
ユーザーの特性、どのような環境で動作するのか、など
など、様々な条件を見極めてテスト設計とテストの方法
を決める必要がある

25. 「バグゼロ」の落とし穴
ソフトウェアテストで欠陥を見つけて、すべての欠陥を
直したとしてもソフトウェアとしては役に立たないこと
がある。
インシデントの報告をうけ、欠陥をなおしたとしても10
倍遅くなってしまっては意味がない
修正を行う際に、機能や性能、システム全体に影響はな
いかといったことを確認することも修正する上で重要で
ある。

26. テストをするためにまず行うことは

27. そうですね
テスト計画ですね

28. テスト計画書の概要(IEEE Std 829-1998)
・テスト計画識別番号
・はじめに
・テストアイテム
・テストすべき機能
・テストしない機能
・アプローチ
・テストアイテムの合否判定基準
・中止/再開基準
・テスト成果物
・テストのタスク
・環境要件
・責任範囲
・要因計画とトレーニング計画
・スケジュール
・リスクと対策
・承認

29. テスト計画書の概要(IEEE Std 829-1998)
・テスト計画識別番号
テスト計画書につける文章番号
・はじめに
テストの目的や戦略を明文化し、テストアイテムをどの
ようにテストしていくかを要約する
・テストアイテム
テスト対象となるソフトウェアのバージョン/リビジョン
を記す。またはソフトウェアがテストされる環境につい
ても記載

30. テスト計画書の概要(IEEE Std 829-1998)
・テストすべき機能
テストすべき機能のリストアップ
・テストしない機能
テストしないと判断した機能の列挙とその理由
・アプローチ
品質目標や方針に合わせて、どのようにテストレベルを
組み立てるか、誰が担当するかテストの進め方を記載

31. テスト計画書の概要(IEEE Std 829-1998)
・テストアイテムの合否判定基準
テストアイテムごとにテストに合格したか、テストの終了
判断を明示的に記載
・中止/再開基準
テストを中止、再開する基準を明示的に記載
・テスト成果物
テストで作成するドキュメント類のリストアップ
・テストのタスク
準備も含めてテストで必要な作業を列挙

32. テスト計画書の概要(IEEE Std 829-1998)
・環境要件
テストを実施する環境について記述
・責任範囲
テストにかかわる関係者と各関係者の責任範囲について
・要因計画とトレーニング計画
テストに必要なスキルを明らかにして要因計画について
記載

33. テスト計画書の概要(IEEE Std 829-1998)
・スケジュール
テストのマイルストーンを決めて、それまでのスケジュー
ルを作成
・リスクと対策
テストにかかわるリスクと対策について記述
・承認
計画書の承認者の名前を記述

34. テストマネジメント
詳しくは次回以降
・テスト計画策定
・開始基準について
・終了基準について
・テスト見積もり
・テスト戦略
・テストアプローチ
・テストの進 のモニタリングとコントロール

35. では、どのようなテストを行っていけば良いのか？

36. 品質プロセスのV字モデル
要求定義
要件定義
基本設計
実装
詳細設計
コンポーネント
テスト
統合テスト
システムテスト
受け入れテスト

37. テスト実施内容

38. 機能テスト
以前にテスト技法をまとめているので、そちらを参照
・「ブラックボックステストの技法」
http://www.slideshare.net/hayabusa333/
ss-44959739
・「ホワイトボックステストの技法」
http://www.slideshare.net/hayabusa333/
ss-45271446

39. 非機能テスト
・性能テスト
・ロードテスト
・ストレステスト
・ユーザビリティテスト
・相互運用性テスト
・保守性テスト
・信頼性テスト
・移植性テスト

40. 性能テスト
ソフトウェアのパフォーマンスを測定
するためのテスト
パフォーマンスとは、システムやコン
ポーネントが処理時間やスループット
制約内で、定義した機能の度合いを果
たす割合

41. ロードテスト
コンポーネントやシステムの動作を測定す
るテスト。
負荷（実行ユーザ数やトランザクション数）
を増加させ、コンポーネントやシステムが
どの程度の負荷に耐えられるかを測定する。

42. ストレステスト
要件で定義した限界、またはそれを超えた
条件でシステムやコンポーネントを評価す
るテスト

43. ユーザビリティテスト
ソフトウェア製品が指定された条件下で理
解され、学びやすく、使用しやすくユーザ
にとって魅力的である能力を判定するテス
ト

44. 相互運用性テスト
相互運用性とは、1つ以上の指定されたコ
ンポーネントやシステムと情報を交換でき
るソフトウェア製品の能力のこと

45. 保守性テスト
保守性とは、ソフトウェア製品の変更の容
易さ。
変更には欠陥の修正、新しい要求を支援す
るための変更、将来の保守性をあげるため
の変更、稼働環境の変更に対応するための
変更などがある

46. 信頼性テスト
信頼性とは、あらかじめ決めた運用回数、
指定された期間、決められた条件下で必要
な機能を実施できるソフトウェア製品の能
力

47. 移植性テスト
移植性とは、ソフトウェアを別のハードウェ
ア環境やソフトウェア環境に対して容易に
移植できる度合い

48. 機能テストと非機能テストの実施タイミン
グは決まっているわけではない
コンポーネントテスト・結合テスト・シス
テムテスト・受け入れテストごとに実施す
るべきであるし、テストタイプごとにテス
トの内容も変わる

49. テストを実施していると問題になるのが
テストが正しいことをいかに証明するか

50. テストのテスト
・証明プログラミング
- Coq、SSReflect、Agda
・モデル検査
- Alloy
・仕様記述言語
- VDM++、B-method
・ミューテーションテスト
- RIT
・レビュー

51. テストをしたら
やりっぱなしはダメ

52. インシデント管理
・テスト中に発生したあらゆるインシデント（調査が必
要な事象）を報告するドキュメントの作成管理
・システムの動作不良の問題を明確化し、原因の特定と
解決に導くために記載
・テストリーダーにたいしてシステムの品質やテストの
進 を追跡する手段を提供
・テストプロセス改善のためにヒント

53. テストの振り返り
テストがどのくらい意味のあるものだっ
たか振り返る必要がある
テストの振り返りを行い、次回のテス
トに反映させ、よりよいテストを行う
ことが重要

54. テストの振り返り
・テストコード行数 / テスト件数
・テスト規模 / バグ数
・リリースバグ数 / 全バグ数
・テストスイートサイクルタイム
・TDDサイクルタイム
・計画的テストケース数 / アドホック的テストケース数
・バグタイプ

55. ソフトウェアのテストは片手間に
できるものではありません

56. アメリカではテストエンジニアは、
それ単体が独立したキャリアとして
存在している

57. テストエンジニアになるために

58. ソフトウェアテストの学習対象
・マネジメント
・ストラテジー、アーキテクチャ
・デザイン
・レポート
・アプリケーションドメイン
・ソリューションドメイン

59. 参考文献
・JSTQB Foundation
・テストエンジニアの品格
・ソフトウェアテストのレトロスペクティブ
・うさぎ組

60. ご静聴ありがとうございました