iijlabセミナー
2018.8.29<株式会社インターネットイニシアティブ 13階 Opera2>

ソフトウェアテストの重要性とテストでの考え方
宮崎大学 工学教育研究部
片山 徹郎<kat@cs.miyazaki-u.ac.jp>

自己紹介

【略 歴】
1996(平成 8)年 3月
1996(平成 8)年 4月
2000(平成12)年10月
現在

九州大学大学院博士後期課程修了 博士(工学)を取得
奈良先端科学技術大学院大学情報科学研究科 助手
宮崎大学工学部情報システム工学科 助教授
宮崎大学工学教育研究部 准教授を経て教授【研究分野】
並行処理プログラムや組込みシステムを対象としたテスト手法
プログラムやテストの可視化【主な著書】
テスト技術者交流会 訳: 「ソフトウェアテスト293の鉄則」(共訳) 日経BP社 2003.4
デザインウェーブマガジン編集部編:「組み込みソフトウェア 開発スタートアップ」(共著) CQ出版社 2005.7
情報処理学会組込みシステム研究会 監修：「組込みソフトウェア開発技術 (組込みシステム基礎技術全集)」（共著）CQ出版社 2011.22

自己紹介【対外活動】

情報処理学会、電子情報通信学会、日本ソフトウェア科学会、各会員
ソフトウェアテストシンポジウム(JaSST) 実行委員

NPO法人 ソフトウェアテスト技術振興協会(ASTER)
副理事長
テスト技術者資格認定(JSTQB: Japan Software
Testing Qualifications Board) 技術委員会 委員

九州IT融合システム協議会(ES-Kyushu)幹事会 幹事
NPO法人 九州組込みソフトウェアコンソーシアム(QUEST) 理事
ETロボコン九州(北, 南)地区審査委員

3

目次



ソフトウェアテストの重要性


テストでの考え方

テストにかかる費用
テスト作業に付きまとう問題点



テスト技術者って？
テストプロセス
テスト計画
 テスト分析「テスト対策」をしよう！
テスト技術者のスタンス

4ソフトウェアテストの重要性5ソフトウェアテストの重要性＜早速ですが問題です＞
2002年6月に、アメリカのNIST(国立標準技術研究所)が下記のレポートを出しました。
「ソフトウェアのバグが、アメリカに年間？？？円の損害を与えている。」(<参照> https://www.nist.gov/sites/default/files/documents/director/planning/report02-3.pdf)

6ソフトウェア開発におけるテストにかかる費用



各工程での費用
要求分析

仕様書

コストの割合 「運用と保守」を除いた割合
3%

3%

9%

9%

設計

5%

15%

テスト

15%

46%

コーディング
運用と保守

7%

67%

21%
ー

(「基本から学ぶソフトウェアテスト」Cem Kaner, Jack Falk, Hung Quoc
Nguyen著,テスト技術者交流会訳, 日経BP社, ISBN4-8222-8113-2 より)テスト工程は開発におけるボトルネック！

7(「2012年度「ソフトウェア産業の実態把握に関する調査」調査報告書」 情報処理推進機構（IPA) より<参照> http://www.ipa.go.jp/files/000026799.pdf )8

9

「テスト」と言えば何？

一概に「テスト」と言っても…


テスト工程

単体テスト
 結合テスト 機能テスト システムテスト
 性能テスト 負荷テスト ユーザビリティテスト …
回帰テスト テスト技法
 テスト対象
 テストベース：


立場によって、捉え方が異なるテストの領域は広い！

10

テストにおける7つの原則



テストの一般原則

原則１：テストは欠陥があることしか示せない
原則２：全数テストは不可能
原則３：初期テスト


原則４：欠陥の偏在
原則５：殺虫剤のパラドックス


同じテストを何度も繰り返すと、最終的にはそのテストでは新しいバグを見つけられなくなる

原則６：テストは条件次第

テストはソフトウェアシステム開発のライフサイクルのなるべく早い時期に開始し、あらかじめ定義した目的に集中すべき条件が異なれば、テストの方法も変わる。例えば、高信頼性が必要な24時間稼動するシステムのテストは、eコマースのテストとは異なる

原則７：「バグゼロ」の落とし穴


欠陥を見つけて修正しても、ユーザの要件や期待を満足しなければ役に立たない( 「ISTQBテスト技術者資格制度Foundation Levelシラバス日本語版Ver.2011.J02」より<参照> http://jstqb.jp/dl/JSTQB-Syllabus.Foundation_Version2011.J02.pdf )11

テスト作業に付きまとう問題点

今見つけたバグがソフトウェアに潜む最後のバグかどうか判断できない。
テストにかかるコストの問題
 テスト作業をどこで終わらせるかという問題


テストによって、「このプログラムにはまったくバグが存在しない」＝「このプログラムは正しい」ことを示すことはできない。


ソフトウェアに対して、考えられるすべての入力をテストで実行させようとしても、テストに要する時間が膨大になる！


可能な入力の組み合わせが多すぎるプログラムが取りうる実行パスの数が多すぎる
ユーザインタフェース（およびその設計）が複雑すぎる

12

テスト作業に付きまとう問題点

テスト作業は、時間とお金の都合を考えて、結局どこかで妥協するしかない。
≠「納期までの時間、テストしたらおしまい！」=「限られたコストで、いかに効率の良いテストを実施するか」

そこで、テスト設計が重要となる。つまり、
より少ないテストケースで、同値分割法
 オールペアテスト(ペアワイズテスティング)

より多くバグが見つかるようにして、

境界値分析

テスト対象を漏れがないように網羅する。
制御パステスト、カバレッジ(網羅率) デシジョンテーブルテスト
 状態遷移テスト
 ユースケーステスト
13代表的なテスト技法



同値分割法




境界値分析


イベントを起こして、プログラムの状態が正しく変化することをチェックする。

オールペアテスト（ペアワイズテスティング）（直交表の利用）
2つの変数の組み合わせを最低限テストする。

ユースケーステスト


プログラムロジックを条件と動作に分け、マトリクスで表現する。

状態遷移テスト

関数やメソッドのロジックを網羅する。

デシジョンテーブルテスト


同値クラスの中から代表を選ぶときに「端っこ」、つまり、境界の値を選ぶ。

制御パステスト

テストに使う入力値が、同様の結果をもたらす場合、その入力値を「同値」と呼び、同値の取りうる範囲を「同値クラス」と呼ぶ。同値クラスの中から代表を選んでテストする。



ユーザの立場に立ち、シナリオを作成する。

14

テストでの考え方
15

テスト技術者ってどんな人？

(きっと)好きなもの

モデル(グラフ) 表
 マインドマップ、三色ボールペン…
人物像

女性が多い？
 人の揚げ足取りが得意？
 ボタンを見ると、乱打、連打、長押し、2重押しをしたくなる 狙ったところで不具合を見つけると嬉しい ふと、仕様(書)のことを考えてしまう ふと、境界(値)を考えてしまう 他の製品を見て、このテスト担当者に想いをはせてしまう

16

たとえばこんなものが気になる…

パンの自動販売機

の、注意書き「商品のないボタンを押した場合は、商品は出ず、お金も戻りません」

手打ち麺製造機

17

ふと、境界(値)が気になる…

18

テストプロセス

効率的なテストを実施するためには、テストの使命を明らかにし、その目的を定義した「テスト計画」が必要
 そのためには、まずは正しい「テストプロセス」を理解することが必要

標準的なテストプロセス• 計画とコントロール• 分析と設計• 実装と実行• 終了基準の評価とレポート• 終了作業( 「ISTQBテスト技術者資格制度Foundation Levelシラバス日本語版Ver.2011.J02」より)

19

テスト分析

テスト分析をする理由

完璧なテストはできない
 スケジュール、リソース、環境などの制約を踏まえ、もっとも適したテストを遂行するため

テスト要件を洗い出す


テスト計画時にどんなテストが必要なのかをすべて洗い出す
洗い出し方は何でもOK 必要な情報をすべて書き出すことが重要

テストマトリクス
 KJ法
 マインドマップ


テストの狙いどころを決める

20

テスト分析の例



ある組込みシステムの仕様書から、マインドマップを用いて分析した例

2015年度 先進的組込みソフト産学官連携プログラム 「組込み適塾」「検証アーキテクトとしてのシステム分析・テスト設計演習」
2015/8/6-8 グランフロント大阪にて

21

テスト分析の例

先の分析マインドマップを用いてテストケースを作成した例

2015年度 先進的組込みソフト産学官連携プログラム 「組込み適塾」「検証アーキテクトとしてのシステム分析・テスト設計演習」
2015/8/6-8 グランフロント大阪にて22

「テスト対策」をしよう！

ソフトウェア開発者は、テストを軽視している？
「テストは新人にやらせとけばいい」
 「ちゃんと作ったから、テストは必要ないよ」
 「テスト屋はあら探しばかりしてむかつく」
 「だったら、お前がプログラミングしてみろ！」
「テスト工程が開発におけるボトルネック」である理由は？
「テスト対策」とは？

テスト容易性(Testability)を考える
 テスト設計の前倒し「テストありき」を前提に考えることが重要！

23

テスト容易性(Testability)を考える



テスト容易性(Testability) (by J. Bach) 実行円滑性(Operability)








テストの対象範囲を制限することにより、速やかに問題を切り分け、手際よく再テストを行える。

単純性(Simplicity)

テストする項目が少なければ少ないほど、テストを速やかに行える。

安定性(Stability)

ソフトウェアをうまく制御できればできるほど、テストをより自動化し最適化できる。

分解容易性(Decomposability)

見えるものしかテストできない

制御容易性(Controllability)

ソフトウェアがうまく動けば動くほど、テストはどんどん効率的になる。

観測容易性(Observability)

変更が少なければ少ないほどテストへの障害が少なくなる。



より多くの情報があれば、それだけ手際よくテストができる。

理解容易性(Understandability)24

＜参考＞富士通の7つの設計原理



単純原理









一見して明らかに正しいといえるように作る
不透明なものは使わない

安全原理




見通しを良くする状態の数をむやみに増やしたりして分かりにくくしない

明証原理




主従関係、前後関係などの階層関係を常に意識する

透明原理




対になるものは対にするバランスを崩さない

階層原理




同じものは同じように実現する

対称原理




可能な限り単純で小さいままにする

同型原理

(<参照> 久保宏志(監修)「富士通におけるソフトウエア品質保証の実際」
日科技連出版社，1989)



必然性のないところやあいまいなところは、安全サイドで設計・作成しておく

25

テスト設計の前倒し
システムテスト

要求分析

回帰テスト

機能テスト

仕様策定

基本設計

詳細設計

コーディング

結合テスト

単体テスト(ユニットテスト)

コードインスペクション(静的テスト)

ソースコード

V字モデルの限界


コーディングの後にテストを行うため、手戻りが多くなる
 不具合の影響が大きくなってしまう

26

テスト設計の前倒し



テストの設計をいつやるか？


テストの設計とテストの実施は分けることが可能
要求分析

仕様策定

システムテスト

回帰テスト

機能テスト

各テストの実施
システムテスト設計
結合テスト
基本設計
機能テスト設計
詳細設計
単体テスト(ユニットテスト)
結合テスト設計
コードインスペクション(静的テスト)
コーディング
単体テスト設計,
ソースコードTDD(Test DrivenDevelopment)
テスト設計を、作りこみの段階で実施することによって、それぞれの工程をすぐに見直すことができる

27

品質の作りこみ「品質を上げるとコストがかかる」？


レビュー、ドキュメント、テスト、…

コストがかかるのは、不具合の作成、検出、修正が原因
テストでバグが見つかると、デバッグ作業が必要。
 テスト工程は開発の大部分を占めるが、デバッグ作業が多い。


製品の品質は、作りこみの段階で確保することが基本「デバッグは手戻り作業である」という認識を！

28

テスト技術の広がり

テスト技術が開発プロセス全体に組み入れられてきている

XPにおけるテストファースト 継続的インテグレーション(CI)での自動テスト、など


プログラマに、テストのスキルが望まれるテストの重要性
 テストでの考え方

プログラマががりがりテストするようになると…

テスト技術者はどうなる！？

29

テスト技術者のスタンス

スタンス1: テストとは行動である

テストは欠陥があることしか示せない

スタンス2: テストとは説明である


仕様通りに動くことを確認するためにテストする

行動の内容と結果だけを提示する
 「何時間テストした」「何万件のテストケースをこなした」
行動の内容と結果に加えて、根拠や妥当性を提示する
 「C0は100%網羅してます」「仕様書のこの項目はすべてテストしました」「この箇所はオールペア法を適用してます」

スタンス3: テストとは納得して不安を減らすことである


自分と相手の双方が納得し不安を減らすために行動する


納得し不安を減らせるように理解しやすく提示する
 「この箇所は重点的にテストすべきだと考えます」「これが今回のテストの全体像です。一緒に検討して頂けませんか」 30

テスト技術者のスタンス



対象の「良さ」と「悪さ」を理解して評価する

良いソフトウェアとは？

高品質ソフトウェア… 機能性、使用性、応答性、…
 社会のニーズ、ビジネス価値

悪いソフトウェアとは？

ユーザがイライラするポイントは？
 プログラマはどこで間違いやすいか？
チームを支援するテストと製品を批評するテスト
 品質を軸にしたテストを考えるどうしても必要なテストは何か？
 このテストは何のためか？


テスト技術者を巻き込んだ上流工程を！

31

アジャイルテスト

アジャイルテストとは？

アジャイルソフトウェア開発におけるテストの考え方、および、
 そのプラクティス


ビジネスアナリスト

プログラマ
テスター

機能別チーム

プログラ
マ

専門家

テスター
アジャイルチーム(<参照> Janet Gregory, Lisa Crispin, 榊原 彰 (監修, 翻訳),
「実践アジャイルテスト」,翔泳社，2009)32

アジャイルテストの4象限

自動と手動機能テスト
例ストーリーテストプロトタイプシミュレーション

探索的テスト
シナリオ
ユーザビリティテスト
受け入れテストアルファ/ベータテスト

第2象限 第3象限

第1象限 第4象限

パフォーマンステスト
負荷テスト
セキュリティテスト
「～性」テスト

単体テスト
コンポーネントテスト
技術面

手動製品を批評するチームを支援する

自動

ビジネス面

ツール

※「実践アジャイルテスト」より

33

高品質なソフトウェア開発のために…



人に自慢できるような複雑なものは作らない

シンプルで、誰でもすぐに動作が理解できるような、…

いつでもテストのことを頭に置いておく

仕様ができた段階で、ただちにテストケースを作る、
 設計が終わった段階で、真っ先にテストケースを作る、
 作るたびにテストする、 作る前にもテストする、 ハードウェアも一緒にテストする、…


繰り返し使用可能なテスト環境を作る

1年後にも同じテストをしたくなる！？

34

おわりにソフトウェアテストの重要性
 テストでの考え方


設計やコーディングでも生きる！
 「テスト対策」をしよう！！


テスト容易性、Wモデル

今後のソフトウェア開発

ますます大規模、複雑化、多様化、多機能化
 それでいて、短納期化
 加えて、高品質

この課題に対応するためにテスト技術者の知恵を上流工程に！

35

おまけ

テスト技術者交流会(TEF:Testing Engineer’s Forum)

ソフトウェアテストシンポジウム(JaSST:Japan Symposium on SoftwareTesting)JaSST’18 Tokyo
 2018年3月7日(水)-8日(木) 2日間で、のべ1600人が参加
 JaSST’19 Tokyo は、2019年3月27日(水)-28日(木)関西、北海道、九州、四国、東海、新潟、東北、北陸でも！
 http://jasst.jp/
テスト技術者資格認定(JSTQB:Japan Software Testing QualificationBoard)

電気通信大学の西康晴先生が世話人
swtest@qualab.jp



第8回AL(TM)試験 & 第25回FL試験： 2018年8月25日(土)会場：札幌、東京、名古屋、大阪、福岡、他
 毎回1000人近くが受験
http://jstqb.jp/

36