「ソフトウェアテスト入門 テスターちゃん」を読んで思ったこと

今期の目標の中にソフトウェアテストを極める！というものがあります(少し大げさかもしれませんが・・・)。その導入のため、ソフトウェアテスト入門 テスターちゃんを通読しました。
その内容を本記事に記載しようと思います。

テストケース

テストケースとして、「第三者が再現できる」ということが大前提となります。あいまいなテストケースは実行する人によって結果が変わってしまうため、新人でもプロでも同じ結果が得られるようなテストケースを作成しましょう。
さらにテストケースは下記項目で考えるとよいです。

• 正常系
• 異常系

Myersの三角形の問題はご存じでしょうか？こちらはとても難しい内容だけなので、こちらでの記載は割愛いたします。

テストケースの実行

テストケースの実行では、「不明点は必ず解決してから実行する」ということが大切です。
そして、担当範囲が完了したら報告しましょう(これは社会人としては当然ですが・・・)！

バグ票

バグが発生したら、「バグ票」を作成しましょう。バグ票の作成では、「バグの情報が明確に伝わるように」「関係者が再現できるように」を念頭に作成しましょう。

ex) 「undefined」と表示された
NG：正しくない
OK：undefinedと表示される

バグ票の作成にあたり、要約(タイトル)と本文(詳細)を記載しましょう。本文の記載には下記内容を中心に記載しましょう。

• バグ発生時の環境
• 再現手順(1ステップ1操作)
• 現状(実際の結果)
• 期待結果

テスト手法

探索的テスト

探索的テストとは、テストケースを使わないで目的に沿って考えながら、自由に行うテストです。
ただし、適当にテストを実施するわけではありません。テストケース作成に時間をかけない代わりに考えながらテスト設計と実行を同時にやります。テストの時間が少ない時やアジャイルの時に有効です。
探索的テストには下記の3タイプが存在します。

• テストチャータを使うタイプ
• フリータイプ
• セッションベースドタイプ

テストチャータを使うタイプ

テストチャータを使うタイプとは、目指す方向を示した仕様書を作成し、探索的テストを実施するもののことを言います。
目指す方向が定まっているため迷いにくくなります。目的や資料のような道しるべを「チャータ」といいます。

フリータイプ

フリータイプはテストする人に「おまかせ」するスタイルです。仕様書等が存在しないため、テストする人が目的を考え、テストを実行します。
管理する人がそれぞれのテストを点検することが大変になり、テストする人が設計に慣れていないと正常系だけを実施するようなテストケースになってしまう可能性があります。

セッションベースドタイプ

セッションベースドタイプとは、上述した「テストチャータを使うタイプ」に制限時間を設けたタイプです。
1回の探索的テストの時間を設け(通常は1~2時間？)ます(この単位をセッションと呼びます)。1回目のセッションが終了したらみんなで結果を話し合います。話し合った結果をもとに次のセッションのやることを調整します。
上記の流れを繰り返します。時間を区切ることで集中力を保てたり、急な変更に対応できたり、テスト管理がしやすくなります。

バグ

テストは仕様通りに動作するかをチェックし、品質保証を行う工程です。テストが完了したら本番環境へのリリースなど実際にユーザが利用するかと思います。
そのため、リリース後に大きなトラブルを防ぐ重要な工程であると言えます。
その中で「仕様通りに動く」ことのチェックも大切ですが、意外と「バグを見つける」ことのチェックも重要です。

バグの出し方のコツ

バグの出し方のことは下記のとおりです。

• 操作を繰り返す
• タイミング
• 境界値
• 種類
• 順番
• 外部制御
• 特殊な状態

操作を繰り返す
1度の操作だけだと正常に動作することがありますが、複数操作すると操作結果が消えたりしてしまうことがあります。エラー処理で赤文字にしたが、操作を繰り返すと赤文字のままだったり・・・

タイミング
ソフトウェアが処理している間に同じ操作をすると2つ同じ処理が実行されてしまう可能性があります。
もし上記が許されてしまうと、決済時に間違えてダブルクリックをすることで2つ同じ商品が届いてしまうような事態が発生してしまいます。

境界値
処理の中で定義している値の範囲のうち、端っこの値にはバグが含まれやすいです。
intの最大値やUNIXタイム等があります。

種類
入力に種類がある場合、いろいろな種類の文字を入力すると予期せぬエラーが発生する可能性があります。
たとえば、数値や文字列、環境依存、絵文字があります。

順番
ある順番だと正常に処理されるが、ある順番だと異常終了してしまうようなケースがあります。
とくに注意なのが、「思い込みの順番」です。「ユーザはこの順番で操作するだろう」と思い込んで操作しないように！！！

外部制御
ブラウザの通信が遅くボタンを連打してしまったことはないでしょうか？どのようなケースが存在します。

特殊な状態
通常、開発をする場合、管理者権限を持っているようなユーザで開発することもあるかもしれません。その場合、制限のあるユーザで操作すると想定しない結果が得られるかもしれません。
そのため、制限のある状態にして確認する必要があります。

振り返り

振り返りでの目標は「これから取り組む課題を見つけること」となります。
そのため、振り返りはテストにおいて(すべてにおいて)大切な手順となります。
振り返りを行う際に「KPT(ケプト)」というフレームワークを利用するとよいでしょう。

KPT

KPTはKeep, Problem, Tryの頭文字をとったものです。
手順としては、Keep(これからも続けること・良かったこと)とProblem(困ったこと・問題点)を話し合い、最終的にTry(次に試したいこと)につなげます。
Problem→Try→Keepへ課題が遷移することにより、「自分(チーム)のベストプラクティス」となります。

KPTを実施するうえで大切なことは下記です。

• 当事者意識
• 人の話はさえぎらない
• 個人攻撃をしない
• 悪口を言わない

手順(Keep・Problem)

1. まずは個人で洗い出す
2. 次にみんなで共有する
3. 最後にグループ分けをする

上記をKeep, Problemで繰り返します。
Problemを実施するときの注意点として、具体的に記載します(Tryが具体的になるため)。

Try

Tryでは、KeepをよりよくすることやProblemを改善することを出します。
Tryを出したら、どのTryに取り組むかを選びます。

Point

1. KeepをよりよくするTryは忘れられがちです。
2. ProblemからのTryは原因を考えて解決するTryを出します(「~してない」を「~する」に変換するだけではダメ)。
3. 取り組むTryは「簡単にできるけど効果がありそうなもの」を基準に選びます(「難しい＝効果がある」ではない)。

KPTを実施するうえで大切なこと

KPTは1回では意味がなく、継続することが大切
2回目以降はKPTに取り組む前に必ず「前回からの確認」を取り入れます。
前回「Try」になっていた課題が「Keep」になっていれば継続して実施し、前回「Problem」や「Try」にあった課題が不要であれば削除します。

テストに共通する原則

どのようなテストにも共通する原則があります。それをテストの7原則と呼びます。

テストの7原則

1. テストは欠陥があることは示せるが欠陥がないことは示せない
2. 全数テストは不可能
3. 早期テストで時間とコストを節約
4. 欠陥の偏在
5. 殺虫剤のパラドックスに注意
6. テストは状況次第
7. バグゼロの落とし穴

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

どのようなテストもバグがあることは証明できますが、バグがないことは証明できません。つまり、抽出したテストケースではバグが見つからなかっただけで、他の場所にバグがあるかもしれません。バグが「ない」と「見つからない」は違うのです。

全数テストは不可能

テストを実施する際、すべてを網羅したテストを実施することはできません。時間やコストは有限であるため、どうしてもテストケースを絞る必要があります。そのため、テスト設計では「システムの目的や使われ方に着目し、重点的にテストする箇所」を絞り込まなくてはいけません。

早期テストで時間とコストを節約

適切な段階で欠陥や問題に気づく必要があります。たとえば、テストの段階で仕様に重大な欠陥が見つかった場合、修正に手間ばかかります。本来であれば、仕様検討などの上流工程や実装段階で気づく必要がありました。そのため、早い段階からのテスト(確認)は大切です。

欠陥の偏在

システムに内在するバグは草原の虫(バグ)や森の虫と同じように、シンプルな実装に比べ複雑な実装に多い傾向があります。バグや不具合は均一に存在するわけではなく、特定の場所に集中しやすいです。そのため、テストも均一に行っていると注力すべき場所に時間を避けなくなりことがあります。

殺虫剤のパラドックスに注意

虫は同じ殺虫剤を使い続けると耐性ができることと同じように、同じテストばかり実施していると新しいバグを発見できなくなります。1度検出したバグはのちに修正されます。ほかの実装でも同じような修正が施されるため、耐性ができるというわけです。

テストは状況次第

たとえば、「シミュレーションゲームのテストを経験しているため、本物も同じようにテストする」というというのはあり得ません。システムのテストも同様に状況によってどのようなテストを実施するのかが変わってきます。

バグゼロの落とし穴

バグを修正するため、バグを起こさないために制限を厳しくしたり、複雑な処理を実装しレスポンスが悪くなるというケースがあります。「木を見て森を見ず」にならないために気を付ける必要があります。

仕様把握

テストを実施するうえでそのシステムがどのような仕様なのかを把握することは大切です。仕様書などを読むことが多いかと思いますが、仕様をりかいするうえで大切なことは「考えること」です。仕様書を読んで「考え」ながら、仕様を把握しましょう。
時には仕様書に記載のない仕様についても読み取らなくてはいけません。そのため、仕様を把握する際には下記の点に注意しましょう。

1. 何をするシステムなのか
2. どのような特徴のシステムなのか
3. どのような機能があるのか
4. その機能はどのようなことするのか
5. 仕様書を読んで自分がどのようなことを思ったのか

マインドマップ

仕様把握に有効な思考法として、「マインドマップ」があります。
マインドマップを利用することのメリットとして下記があります。

1. グループ化しやすい
2. 全体を見渡せる

なりたい私になるには

大前提として、「どうなりたいかを強くイメージすること」が大切です。
そのイメージに近づくためには、現在とイメージとのギャップを考えることが重要です。そのうえで、下記の行動が必要になります。

「その差を埋める行動」と「フィードバック」を「継続的に」行うことです。