JSTQB_FLシラバス_6章：テスト支援ツール

2018/06/07
ということでシラバス読むつづきです。

シラバス学習時間の割合

今回は6章「テスト支援ツール」を読みます。

6章：テスト支援ツール

1. テストツールの種類
2. ツールの効果的な使い方：利点とリスク
3. 組織へのツールの導入

3つの節があり、端から読んではみたものの頭に入ってくる感じがしませんでした。おそらく出てくる単語が難しいせいだと思ったので、
"ツール"を包丁とか鍋とか、料理する場合に置き換えてイメージしつつ読んだら少しつかめた気がしました。 （業務での具体例を思い浮かべられたらよいのですが、経験も知識もないのでイメージできませんでした。。）
そのイメージでつかんだ雰囲気のまま書いていることをご了承ください。

ツールの導入

• ツールを導入する際の基本原則がある。
  　テスト対象に対して効果的なツールなのか、ツールを使う上で組織はどんな教育や訓練が要るか、費用対効果はどのくらいか、などを気にしたほうがよい。

• パイロットプロジェクト
  　選んだツールを使うのは簡単な（限定された）プロジェクトから。

• ツールの展開を成功させるには
  　利用ガイドを定める、ツールを使えるプロセスにする、ツールの利用状況や効果をモニタリングする、新規ユーザーに対してトレーニングする、徐々に展開する、などなど

ツールのよさ/リスク

よさ

• 反復作業が減る
• 同じことを何回も簡単にできる
• 客観的に評価できる
• 統計を取ったりインシデント率の算出が簡単になる

リスク

• ツールがあるだけで神だと思いこんでしまう
• ツール自体が使えなくなる可能性がある
• 予想外の出来事が起こる などなど

このツールはとくに注意

• テスト実行ツール：大量の工数や、専門知識が要りがち
• 静的解析ツール：大量の警告メッセージが出るかもしれないので段階的に導入するといい
• テストマネジメントツール：組織が必要とするフォーマットに合わせないといけない

ツールの種類

テストの活動による分類

ひとつの活動に対してしか支援しないツールもあれば、複数の活動を支援するツールもある。
テストの実際の出力に影響を及ぼすものもあり、（実行タイミングが実際と異なるとか）その結果をプロープ効果という。

テストツールってどんなもの？

• テストに直接利用されるツール
• テストプロセスのマネジメントを支援するツール
• 調査や探索のためのツール
• テストを支援するあらゆるツール（表計算ソフトウェア など）

ツールの目的は？（なんでつかうの？）

• テストの活動の効率を改善するため：反復作業の自動化、テストレポートの支援など
• 手動でやると大きなリソースを要する活動を自動化するため
• 手動では実行できない活動を自動化するため
• テストの信頼性を上げるため：大量のデータ比較や動作のシュミレーション

ひとこと

テストを支援するあらゆるツールはテストツール！
わたしが業務でいちばんつかっているのはスプレッドシートですかね〜〜
テストやテスト結果の管理とか、テストケースを考えるときにつかったりとか。 次回は2章の ソフトウェアライフサイクルを通じてのテスト になる予定です。

JSTQB_FLシラバス_3章：静的技法

2018/06/04
JSTQBのFLまだ持っていません。のでお勉強はじめました！
自分の言葉で整理しなおすと頭に入るらしいのと、未来のわたしが読んだとき、赤面したり涙を流したりするかもしれない、のが楽しみだから書きます。

3章：静的技法

「動的」テストがコードを実行してテストするのに対して、「静的」テストではコードを実行しないでテストする。
故障自体を探す動的テストと比べて、静的テスト技法は故障の原因（欠陥）を探す。
静的テスト技法はシラバスに2つ出てくる。レビュー（人力） と 静的解析（自動） である。

レビュー

レビューとはどんなことをするのか？？

〈一般的な公式レビューの流れ〉

1. 計画
2. キックオフ
3. 個々の準備
4. 実施/評価/結果の記録
5. 再作業
6. フォローアップ

…（個々の準備？？？？？）
レビューミーティングの準備としてドキュメントをレビューしたり、可能性のある欠陥、質問、コメントを書き出したりすることらしい。
考えたらそらそうかな、と思うのですが、「レビュー」に関しては自分以外の他の人の存在があって、ひとりで黙々とするイメージとはちょっと違っていておもしろいなと思いました。

静的解析

レビューが人力なのに対して、こちらはツールによる自動解析。
わたしの普段の業務ではやらないので馴染みがない。

静的解析はソースコードやソフトウェアのモデルの欠陥を見つけるのが得意！（目的）
なので静的解析ツールをつかうのは主に開発担当者やモデルの設計者、と書いてあったので馴染みがないのも納得。ただ、レビューのほうでもサポートするツールがあるようなので自動＝静的解析（ツール）と繋げてしまわないことー

レビューの種類

静的テスト技法が2種類あるとわかったところで馴染みのあるほう「レビュー」に戻って、レビューにもいろいろ種類があるらしいので整理

• 非公式レビュー
• ウォークスルー
• テクニカルレビュー
• インスペクション

非公式レビュー

お金や時間をかけずにある程度の効果を出したい世界。

ウォークスルー

ソフトウェアの内容を学習、理解し、そして欠陥を見つけにいく世界。

テクニカルレビュー

円卓会議。
ディスカッションする、判断を下す、他の方法を評価する、欠陥を見つける、技術的な問題を解決する、仕様や計画、規定、標準に準拠していることをチェックする。
ここにだけエキスパートの存在が明記されている

インスペクション

テクニカルレビューを読んだあとなのでこの世界の存在意義がわからなくなった。（主観、あくまで主観）主な目的は欠陥の検出。 inspection という単語をググったら「検査」ってでてきた。

レビュー世界におけるキャラクターのロール

• マネージャー：レビューの目的が適切かどうか判断する
• モデレータ：レビューのとりまとめをする。世界を左右する超重要人物
• 作成者：レビュー対象のドキュメントに責任をもつ
• レビューア：レビュー対象物で気がついたことを示したり述べたりする。別名チェッカー/インスペクタ
• 書記：記録係も世界には必要

レビュー攻略法

• レビューをはじめる前には目的を明確にしましょう。
• 目的を達成するために、（ソフトウェア、レビューアのタイプ、レビューアのレベルなどなどに対して）最適のレビュー技術を適用しましょう。
• 欠陥を見つけることは歓迎すべきことですよ
• チェックリストや役割決めは欠陥を効率よく見つけられるならつかおう
• きちんとレビューを進めるには支援が必要です（スケジュールで時間をとってもらうとか）
• レビューの方法を学習したり、プロセスを改善したりすることも目的ですよ

さいごに

なんで3章からなのか

各章のなかで、「レビュー」がいちばんなじみのない用語だったのでしっかり読もうと思いました。
それと、学習時間を見たとき3章がいちばん短かったので最初にやるにはちょうどいいかなと思ってそこから手をつけはじめました。

すると次は「テスト支援ツール」かな？？ テスト設計技法はいまいちばん勉強が必要だけど、重いので最後かもしれないです。
今回はここで終わります。書きなぐりで読みづらかったと思います、読んでいただきありがとうございました。

ブログはじめました

ブログはじめました

2018/06/01

今日はついたちなのでなにかはじめたくなりました。
ということでブログはじめました！

いままでよりもさらにゆるく気軽にテストの記事投稿したいなと思っていて、アカウントだけは用意していたのです…今日やっと投稿します！

きのうはWACATEのポジションペーパーをなんとか提出し、ひとつの納期を終えた気持ちです。
なんか白いし見た目も内容も地味で、（もっとやりようがあったよな）とごねごねしつつ、「提出した！」ことで1歩進んだ気がしました。

書く内容よりも編集方法で結構つまづいて苦しかったです。まだ誰にも参加するって言ってないし土日の予定も空くしひっそりとやめちゃおっかなーとか思ったのですが、
こんな後ろ向きな理由で参加をやめたら後悔しそうかなぁと思ったのでがんばって提出することにしました。

テスト設計が遅くてもやっているので、解決のヒントにできるかもしれないなという期待があります。
あとはなにより、「WACATEはいいぞ」とよく聞くので自分でたしかめようと思います。 初参加ですが、お会いできる方はぜひ仲良くしてください。

こんな感じで とりあえずやってみる の精神でゆるくやっていきます（内容なくても書かないよりとりあえずやってみる！みた！）のでよろしくお願いします。