2018/06/04
JSTQBのFLまだ持っていません。のでお勉強はじめました！
自分の言葉で整理しなおすと頭に入るらしいのと、未来のわたしが読んだとき、赤面したり涙を流したりするかもしれない、のが楽しみだから書きます。
3章：静的技法
「動的」テストがコードを実行してテストするのに対して、「静的」テストではコードを実行しないでテストする。
故障自体を探す動的テストと比べて、静的テスト技法は故障の原因（欠陥）を探す。
静的テスト技法はシラバスに2つ出てくる。レビュー（人力） と 静的解析（自動） である。
レビュー
レビューとはどんなことをするのか？？
〈一般的な公式レビューの流れ〉
- 計画
- キックオフ
- 個々の準備
- 実施/評価/結果の記録
- 再作業
- フォローアップ
…（個々の準備？？？？？）
レビューミーティングの準備としてドキュメントをレビューしたり、可能性のある欠陥、質問、コメントを書き出したりすることらしい。
考えたらそらそうかな、と思うのですが、「レビュー」に関しては自分以外の他の人の存在があって、ひとりで黙々とするイメージとはちょっと違っていておもしろいなと思いました。
静的解析
レビューが人力なのに対して、こちらはツールによる自動解析。
わたしの普段の業務ではやらないので馴染みがない。
静的解析はソースコードやソフトウェアのモデルの欠陥を見つけるのが得意！（目的）
なので静的解析ツールをつかうのは主に開発担当者やモデルの設計者、と書いてあったので馴染みがないのも納得。ただ、レビューのほうでもサポートするツールがあるようなので自動＝静的解析（ツール）と繋げてしまわないことー
レビューの種類
静的テスト技法が2種類あるとわかったところで馴染みのあるほう「レビュー」に戻って、レビューにもいろいろ種類があるらしいので整理
- 非公式レビュー
- ウォークスルー
- テクニカルレビュー
- インスペクション
非公式レビュー
お金や時間をかけずにある程度の効果を出したい世界。
ウォークスルー
ソフトウェアの内容を学習、理解し、そして欠陥を見つけにいく世界。
テクニカルレビュー
円卓会議。
ディスカッションする、判断を下す、他の方法を評価する、欠陥を見つける、技術的な問題を解決する、仕様や計画、規定、標準に準拠していることをチェックする。
ここにだけエキスパートの存在が明記されている
インスペクション
テクニカルレビューを読んだあとなのでこの世界の存在意義がわからなくなった。（主観、あくまで主観）主な目的は欠陥の検出。 inspection という単語をググったら「検査」ってでてきた。
レビュー世界におけるキャラクターのロール
- マネージャー：レビューの目的が適切かどうか判断する
- モデレータ：レビューのとりまとめをする。世界を左右する超重要人物
- 作成者：レビュー対象のドキュメントに責任をもつ
- レビューア：レビュー対象物で気がついたことを示したり述べたりする。別名チェッカー/インスペクタ
- 書記：記録係も世界には必要
レビュー攻略法
- レビューをはじめる前には目的を明確にしましょう。
- 目的を達成するために、（ソフトウェア、レビューアのタイプ、レビューアのレベルなどなどに対して）最適のレビュー技術を適用しましょう。
- 欠陥を見つけることは歓迎すべきことですよ
- チェックリストや役割決めは欠陥を効率よく見つけられるならつかおう
- きちんとレビューを進めるには支援が必要です（スケジュールで時間をとってもらうとか）
- レビューの方法を学習したり、プロセスを改善したりすることも目的ですよ
さいごに
なんで3章からなのか
各章のなかで、「レビュー」がいちばんなじみのない用語だったのでしっかり読もうと思いました。
それと、学習時間を見たとき3章がいちばん短かったので最初にやるにはちょうどいいかなと思ってそこから手をつけはじめました。
すると次は「テスト支援ツール」かな？？
テスト設計技法はいまいちばん勉強が必要だけど、重いので最後かもしれないです。
今回はここで終わります。書きなぐりで読みづらかったと思います、読んでいただきありがとうございました。
