書籍要約 「知識ゼロから学ぶソフトウェアテスト 【改訂版】」

何が書いてあるか

読んだ本の要約化で理解と記憶の定着化を目指します。
あくまで個人のエッセンスの列挙になります。実際の内容はこの何十倍も示唆に含まれている素晴らしい書籍です。この素晴らしさを一人でも多くの方が知るキッカケになれば嬉しいです

読んだ本

知識ゼロから学ぶソフトウェアテスト 【改訂版】
高橋寿一著
2013年に出版された本です。

出会ったきっかけ

Podcast番組「texta.fm」で紹介されていました。

要約（本編）

第１章 「はじめに」

・すべてのバグをみるけるのは不可能。
・バグはどこに偏在しどのようなテスト手法でケアすれば十分な品質が得られるかを知ることでテストでは重要である。

第２章 「ソフトウェアテストの基本」

・プログラムの論理構造が正しいかを解析するテストがホワイトボックステスト。
・仕様誤りは掴めない。よってホワイトボックステストのみでテスト終了とはならない。
・制御パステスト、いわゆるカバレッジ率で網羅率を計測。フローチャートをカバーするようにテストする。
・命令を最低１回実行させるステートメントカバレッジより、分岐のTrue/Falseの両方を網羅するブランチカバレッジが良い。
・全てをブランチカバレッジテストするのは大変。傾向を見てバグがたくさん出る所に適用するなどが良い。
・一般の商用ソフトウェアなら60～90%のカバレッジ率で十分。（人命にかかわるものは除く）
・状況の設定が難しいエラー処理や、使われなくなったコードをカバーしようとしない。
・以下のバグはカバレッジテストで見つけることが難しい

1. ループに関するバグ
2. 仕様自体の誤り、機能がそもそもない
3. データに関するバグ
4. タイミングに関するバグ

・ループに関するテストはどのような戦略でテストするか事前に話し合っておくこと。
・マルチタスクに関するテストは、共有データのアクセスパターンや、生成と消滅の全組み合わせ、大量稼働などでテストする。
・カバレッジは数あるテストの１つにしか過ぎないので、単純に100%を目指すのは非効率。特に100%に近づくほどテスト費用は等比級数的に増えるので。
・XPでホワイトボックステストが再注目された。コーディング・テスト・リファクタリングを高サイクルで回すのに必要となったため。一度テストを書いておけば、安心してリファクタリングも行える。品質保証というより変化耐性を持つこと。

第３章 「エンジニアがもっともよく使う手法」

・ソフトウェアテストは４つの振る舞いを確認するだけ、入力、計算、保存、出力だ。
・同値分割法とは部分集合に入る入力値を等価とみなして、テストケースを圧縮する手法。
・条件の閾値近辺で多く発生する不具合を抽出する手法が境界値分析法。異なる処理が行われる一番近いものどうしの値（地点）でテストする。
・経験則として、ゼロ、プログラム的な最大値や最小値、よく使われるデータは基本ケースとして行う。
・GUIは状態遷移で確認する。期待していない状態に遷移したり、遷移ができないといった不具合を見つけることができる。
・状態遷移図はすぐに複雑化するのでxclipboardなどのツールを用いる。
・ランダムテスト（アドホックテスト）はテストフェーズ初期で偏在傾向を探りながらテストするのに用いる。

・QA活動種類ごとのバグ捕捉率

QA活動の種類	捕捉率
カジュアルなデザインレビュー	25%～40%
フォーマルなデザインレビュー	45%～65%
インフォーマルなコードレビュー	20%～35%
フォーマルなコードレビュー	45%～70%
モデル化やプロトタイプの作成	35%～80%
個人的なコードチェック	20%～60%
ユニットテスト	15%～50%
新機能のテスト	20%～35%
統合テスト	25%～40%
回帰テスト	15%～30%
システムテスト	25%～55%
小規模のベータテスト	25%～40%
大規模のベータテスト	60%～75%

第４章「探索的テスト」

・ソフトウェア理解、テスト設計、テスト実行を高速イテレートで行う手法。
・時間的制約があり全てのバグを見つけることは難しい。なるべく効率よくやるなら、机上できっちり計画するより、実態に合わせて設計したテストを実行し、結果をフィードバックしてテストを探究するほうが良いだろうという考え。しながら考えたほうがうまくいくのではという考え。
・ほとんどは要求仕様が曖昧で事前にテストケースを書くことは難しい、または品質を担保できるケースとは乖離する。そして仕様が変わるのでほぼ無駄になる。
・机上の計画や、論理だけの管理では品質の良いソフトはできあがらない。
・自動テストのメリットは回帰チェック。自動で既知パターンをかけながら、ソフトウェアの構成から問題がありそうな箇所を推測して行う、バグがでたら類似抽出や似た箇所を十分テストする、といった姿勢が合わさることが大切。

・まずはクライテリア（OK/NG判定基準）を決める。
・ターゲットを決め、機能をリストアップし、弱いエリアを見つけ、テスト実行とバグを記録し、以上を繰り返す。

第５章「機能あらざるもののテスト、最難関のテストに挑む」

・ISO9126品質特性

品質特性	品質副特性
機能性	合目的性
〃	正確性
〃	相互運用性
〃	機密性
〃	標準適合性
信頼性	成熟性
〃	障害許容性
〃	回復性
〃	標準適合性
効率性	時間効率性
〃	資源効率性
〃	標準適合性
移植性	環境適応性
〃	設置性
〃	共存性
〃	置換性
〃	標準適合性
使用性	理解性
〃	習得性
〃	運用性
〃	注目性
〃	標準適合性

・一般的には機密性、信頼性、パフォーマンスが重要。
・品質特性はトレードオフの関係性をもつものもある。
・要求仕様通りのケースはチェッキングであり、想定外の不具合を抽出するケースを書くことがテストでは大切。
・パフォーマンステストはリカバリーができるタイミングが限られるので、なるべく早い段階で確認すること。
・パフォーマンスチェックは、アーキテクチャの妥当性確認、動くものができたらすぐにベンチマーク、回帰パフォーマンステスト、チューニング、なるべく実態に沿ったデータ（キャッシュを無効化できるようバリエーションも考慮した）での動作確認。
・セキュリティテストはテスト手法が確立されておらず難しい。脅威に直面したときに、解析し変更（もしくは削除）し、監視する、の３つのセキュリティ機能を満たしているかをテストする。
・ソフトウェアの信頼性を測るためには、信頼度成長曲線を書くことが大切。MTBF目線で理論的には不具合はゼロにならない中で、出荷判定の一つの指針となる。

信頼度成長曲線の基本式

m(t) = a(1-e^{-bt})

第６章「ソフトウェアテスト運用の基本」

・テスト費用とサポートにかかる費用が最小になるような力の入れ具合で行う。
・ただし回収や企業の信頼を落とすような不具合は影響が大きすぎるので絶対に防ぐ。
・IEEE829のテストプランテンプレートで以下を固める。

1. 文書番号
2. レファレンス：関連ドキュメント
3. はじめに
4. テストアイテム
5. テストするべき機能
6. テストする必要のない機能
7. アプローチ
8. 合否判定基準
9. 中止基準と再開基準
10. 成果物
11. テスティングタスク
12. 実行環境
13. 責任範囲
14. 人員計画、トレーニングプラン
15. リストとその対策
16. 承認
17. 終了基準：重要度が高いバグが残っていない、テストケースパス率98%、48時間以内に致命的なバグがでていない。など。

・スケジュールは計画をたてるためではなく、実現性の可否を確かめる、可能としてそのペースを把握するためのもの。そして二週間に１度は見直すべき。
・テストケースは誰がやっても同じ結果になるぐらいに、とても具体的にかくべき。
・テストケース管理ツールを活用すべし。TestlinkやQuality Centerなど。
・テストは成果が見えづらいので、重要度バグの割合、信頼度曲線、MTBFなどの客観的なメトリクスで提示していく。
・サイクロマチック数で複雑度を計測しリスク評価する。

第８章　「テストの自動化という悪魔」

・自動化は成果アピールしやすいが、目的はコスト削減なので手動の方が安いなら無理に自動化はしない。
・変化が少なく繰り返し行うものは自動化テストに向いている。

第９章　「それでもテストがうまくいかない人へ」

・直行ケースを全てテストしようとし、現実リソースがなくなっておざなりになっている。同値分割や境界値分析を行い必要最低限のケースで実施する。
・品質をあげるのにテストのみでかんがえるのではなく、アーキテクチャを工夫するやり方もある。
・20%のモジュールが80%のバグを生み出している。

最後までお読みくださりありがとうございました。