ソフトウェアテスト教科書 JSTQB Foundation 第4版シラバス2018対応

第１章はテストの基礎となっています。

ソフトウェアが期待通りに動かなかった時の不都合
テスト
テストの目的
テストとデバッグ
成功に対するテストの貢献
当たり前品質と魅力的品質
品質のために行う活動の関係
- 品質保証
- 品質コントロール
テストの７原則
状況に応じたテストプロセス
テストプロセスを構成する主な活動
テスト作業成果物
テストベースとテスト作業成果物のトレーサビリティ
人の心理とテスト
テスト担当者と開発担当者のマインドセット

ソフトウェアが期待通りに動かなかった時の不都合

経済的な損失
時間の浪費
信用の失墜
傷害や死亡事故

一般的な例として挙げられるのが、みずほ銀行の障害でしょう。

https://diamond.jp/articles/-/313919

障害によりATMが使えなくなったり、口座の振替が遅れたり、預け入れができなくなったり。

これらの障害は主に経済的な損失、信用の失墜につながっています。

その裏側で障害解消のため、上層部の報告に追われたり、障害改修のため、機能開発の時間が取れなくなってしまうという問題も起きます。

ソフトウェア開発をしていると、この時間の浪費を目の当たりにすることが割とあります。

傷害や死亡事故は以下のような例でしょう。

自動運転の難しさは、こうしたところにあると、ぼくは思っています。

president.jp

テスト

ソフトウェアを実行して結果を確認することは、テストの一部であって全部ではない、としています。

テストを実行する他に様々な活動を含みます。

例えば、

テスト実行前作業
- テスト計画
- テスト分析
- テスト設計
- テスト実装（必要なものの準備）
テスト実行時の作業
- 実行結果のチェック
- テスト終了基準の評価
テスト完了作業
- テスト結果の報告
- テストウェアの整理
全体を通して行われる作業
- モニタリングとコントロール

といったところです。

これらのことを、きちんと出来ているか？　というと、経験上できていません。

経験したプロジェクトでは、開発の片手間でやっていることが多く、以前のテストを慢性的に繰り返すことが多いです。

特に事前の準備でしょう。

テスト分析、テスト設計といったところは、経験で各担当にお任せで時間がかけられていないのが実情です。

モニタリングとコントロールについてもそうで、進捗率を見える化して把握できていないことがしばしばです。

進捗率を見える化することは、テストの実施において、基礎中の基礎です。

テスト終了基準も暗黙の了解で、とりあえず全部のテスト項目がOK。軽微な不具合は次回リリース、重大な不具合は直して確認してOKみたいな形です。

何をもって軽微な不具合とするかという判断基準も曖昧なことが多いです。

バグ検出による潜在バグをバグ曲線で割り出して、バグを出し切る水準までテストするというのはなかったりします。

とはいえ、バグのサンプルが少なく、そこまで想定するのが難しい部分もあります。

テストの目的

どのような目的でテストをするかで、工数や期間などいろいろなことが変わってきます。

その中で、ISTQBで一般的に共通して必要だと思われるテストの目的は以下です

要件、ユーザーストーリー、設計、およびコードなどの作業成果物の評価
明確にした全ての要件を満たしていることの検証
テスト対象が完成し、ユーザーやその他ステークホルダーの期待通りの動作内容であることの妥当性確認
テスト対象の品質に対する信頼を積み重ねて、所定のレベルにあることの確証
欠陥の作り込みの防止
故障や欠陥の発見
ステークホルダーが意思決定できる、特にテスト対象の品質レベルの十分な情報の提供
不適切なソフトウェア品質のリスクレベルの低減
契約上、法律上、または規則上の要件や標準を遵守する、そして/またはテスト対象がそのような要件や標準に準拠していることの検証

先ほどのテスト終了基準と同様、リリースするに足るか、まだテストを続けるべきかの判断材料をどう提供できるか、というのは、ぼくとしては悩ましい部分です。

プロジェクトマネージャーが納期という約束がある中で、リリースを踏み止まれるだけ納得できる材料を提供して説明できるか？

ステークホルダーと対面して、状況説明できるか？

そこまで出来たQAは、ぼくは会ったことがありません。

テストとデバッグ

エンジニアとしてのデバッグというと、IDEでブレークポイントをおいて、ステップイン・ステップアウトするような作業を思い浮かべてしまいがちです。

JSTQBでのデバッグは、故障の基となる欠陥を見つけて、欠陥の原因を解析し、修正する一連の開発の活動としています。

エンジニア（ぼく）におけるバグ修正がデバッグなのです。

テストは、ソフトウェアに存在する欠陥に起因する故障を発見することを目的としています

例えば

故障 ... テキストボックスに文字をたくさん入れるとアプリケーションが落ちる
欠陥 ... テキストボックスに128文字以上入れると配列サイズをオーバーして例外が発生する
修正 ... テキストボックスに128文字以上入れられないように制御する

といったところです。

エラー(誤り)

エラーというと、エラーダイアログが出てきて、予期せぬエラーが発生しましたとか、名前が入力されていませんとか言ったメッセージが出てくることが思い浮かびます。

しかし、ISTQBでは、そうではありません。エラーを「間違った結果を生み出す人間の行為」と定義しています。

違和感ありますが、和訳した結果とかあるでしょう。なので本書で（誤り）と補足しているのでしょう。

要件についての解釈を間違っていたといった勘違いや思い込みなどで、エラー（誤り）をしてしまうのです。

欠陥(Defect)

作業成果物に存在する、要件または仕様を満たさない不備または欠点のことです。

ISTQBにおいて、欠陥は、バグ、フォールトと同義です。

じゃあ、バグで良くないかと思うのですが、作業成果物なので、プログラムのみならず設計書のようなドキュメントも含まれるから欠陥なのでしょう。

故障(failure)

コンポーネントやシステムが定義された範囲内で要求する機能を実行しないこと、としています。

また期待通りでないテスト結果が故障とは限りません。誤検出してしまうことがあります。

以前の期待通りに動作しない報告を受けて、試してみるので再現しないので、もう一度確認してくださいと報告者に伝えると、テスト手順を間違っていましたというエラーだったことがありました。

こうした誤検出を偽陽性結果と呼びます。

逆に検出漏れしてしまうケースを偽陰性結果と呼びます。

たまに、修正もされていないのに、他の人がこれまでのテスト手順で操作すると期待通りに動作しない報告があって確認すると、故障だったなんてことがありました。

同じ人がテスト続けるとマンネリです。

根本原因

1行のコードの間違いが間違った利子の支払いを引き起こした。欠陥のあるコードはプロダクトオーナーが利子の計算方法を誤解していた。

この場合において、欠陥があるのはコードですが、プロダクトオーナーが利子の計算方法を誤解していたことが根本原因に結論付けられます。

あまり、そこまで根本原因を追求することはしないですよね。

以前の職場で、不具合報告について原因のチェックボックスみたいなのがありましたが、まあなんとなくチェック入れてた気がします

成功に対するテストの貢献

ただ、テストフェーズだけではなく、ソフトウェア開発プロセスにおいて、要求分析、システム設計でもテスト担当者は開発担当者と連携し、欠陥が混入するリスクを軽減することができると述べています。

以前の職場では、要求分析を終えた時点で、品質保証担当に対して説明する場を設けるというルールがありました。

ぼくは、説明するだけの無意味な場だと思っていました。しかし、とある品質保証担当者は事前に資料を読み、内容を把握して、懸念点を挙げていることがありました。

こうした形でテスト担当者は、欠陥が混入するリスクを軽減することができるのです。

当たり前品質と魅力的品質

当たり前品質とは、機能そのものが意図した通りに動くことを指す
魅力的品質とは、使いやすいユーザーインターフェースを搭載するなど製品を使いたくなる特徴を指す

品質のために行う活動の関係

品質マネジメント
- 品質保証
  - テスト結果活用
- 品質コントロール
  - テスト活動全般

品質保証

というわけで、なんと、JSQTBにおいて、品質保証はテスト活動は含まないのです。

品質保証は、当初設定したレベルに確実に到達するよう、適切なプロセスを遵守するための活動です。

適切なプロセスとは、コーディングルール、ウォーターフォールのような開発ライフサイクル、欠陥マネジメント、構成管理の手順。

品質保証部門が別である、開発を経験してきましたが、実際、基本テストをしてくれません。

開発のことを知らないのに、コーディングルールについてとやかく口出ししてきたり、プロジェクトに片手間で入ってきて開発ライフサイクルをやっているか確認してきたりする。

で、開発していないのに余計なことを言うなと揉めるというのがしばしばでした。

考えてみれば、この定義に沿って彼らはやっていたのです。

とはいえ、開発が求めている品質の専門家というのは、後述する品質コントロールをして、品質マネジメント全体においてプロジェクトマネージャーの助けになることではないかとぼくは思います。

品質コントロール

品質コントロールには、プロダクトが適切なレベルの品質を達成するために役立つ様々な活動が含まれます。

こちらの方にソフトウェアを動作確認するテスト活動が含まれるわけです。

テストの７原則

テストは欠陥があることは示せるが、欠陥がないことは示せない
全数テストは不可能
早期テストで時間とコストを節約
欠陥の偏在
殺虫剤のパラドックスにご用心
テストは状況次第
バグゼロの落とし穴

QAの人間は慎重な傾向があり、全部テストしないと気が済まないみたいなところがあります。

欠陥はある部分に集中していること、全数テストは不可能であることを踏まえれば、テストをする部分については比重を変えるべきなのですが、これがなかなかできないものです。

あとで、そこはテストしてなかったと言われたくないという言い訳前提の部分もあるでしょう。

バグゼロの落とし穴は、故障はなくても、処理が遅いといった性能に影響がないことを確認することも大切だ、ということです。

ぼくは、パフォーマンスにやや無頓着なことがあって、やや処理が遅くしてしまうことがしばしばあります。

殺虫剤のパラドックスは分かっていても陥りやすいです。

害虫を退治するのに同じ殺虫剤は効かなくなってくるところから来ていますが、同じテストシナリオを使い回して、それでよしとなりがちなんですよね。とはいえリグレッションテストでは有効だとしています。

状況に応じたテストプロセス

合理的で効率的なテストに取り組むためにはテスト計画が欠かせない。正しいテストプロセスを実行する必要がある、としています。

テストプロセスをいつ、どのようなタイミングや組み合わせで行うのかは、組織の体制やプロジェクトの状況により異なります。

としているのに大企業は、コストメリットのみを取って、画一的なテスト計画を敷かせることが多いです。

多くが、その会社の大きなシステムの進め方に合わせるので、小さなシステムに関わっていると、そのワリを食わさられる、というのをしばしば経験してきました。

テストプロセスを構成する主な活動

テスト計画
テストのモニタリングとコントロール
テスト分析
テスト設計
テスト実装
テスト実行
テスト完了

順に行うこともあれば、仕様が明確なものから先行して行うといった、複数の活動のグループを同時に進めることもあります。

多くはプルリクエストを出して、開発者とレビュワーがテスト。リリース前に一通りの機能をテストしたりしますよね。

テスト分析

シラバスでは以下が定義されています。

テストレベルごとに適切なテストベースを分析する
テストベースとテストアイテムを評価して、さまざまな種類の欠陥を識別する
テストすべきフィーチャーとフィーチャーのセットを識別する
テストベースの分析に基づいて各フィーチャーのテスト条件を決めて優先度を割り当てる
テストベースの各要素と関連するテスト条件の間に双方向のトレーサビリティを確立する

テストベースは、企画書、ユースケース、仕様書などのドキュメントなどになります。

それだけでなく、ホワイトボードでの開発時点のメモ書きなども含まれるようです。

今だとSlackでのやり取りなんかも含まれるでしょうね。

とはいえ、今時の開発だと、きちっと設計書などが書かれることはなく、それらの記述が曖昧だとか判断するのは、開発スピードの問題で現実的には実施が難しい気がしています。

設計書を書いたところで、いざ実装したら技術的に困難で妥協せざるを得なかったり、実際作ったら使いづらかったため変更を加えるといった形で、設計書から乖離することがあります。

では、どうするかというとテストベースを作っていく方が良いのではないかと僕は思っています。

出来たソフトウェアをドキュメントに落とし込んで、以降のテストにおけるテストベースとする。それが探索的テストの直接的なインプットになります。

フィーチャーは「明示的、暗示的に規定したコンポーネントやシステムの属性」とされています。

バックエンドのAPIをテストするだけならURLを叩くだけで良いし、負荷テストをするならJMeterのようなツールが必要だし、フロントエンドをテストするにはブラウザでログインして、画面操作しないとならないといった判断をすることになります。

テスト条件については、スケジュール面の制約、テストを実行する技術者といったことを検討材料として、テスト条件の優先順位付けを行います。

テスト設計

シラバスでは

テスト分析は「何をテストするか」を分析し、テスト設計は「それをどうテストするか」を決定する

とされています。

主な活動は以下です。

テストケース及びテストケースのセットを設計し、優先度を割り当てる
テスト条件とテストケースを支援するために必要なテストデータを識別する
テスト環境を設計し、必要なインフラストラクチャーやツールを識別する
テストベース、テスト条件、テストケース、テスト手順の間で双方向のトレーサビリティを確立する

いきなりテスト手順や期待結果などを検討するのではなく、テスト条件を網羅するようにテスト技法を用いて設計していきます。

テスト技法とは、境界値分析とかペアワイズテストといった、かっこいい技法です。

現実的に、これらのテスト技法を駆使し、網羅してテストするなんてことはしているほどの工数はないのですが。

網羅性は要求や仕様に対するカバレッジとシステムやソフトウェアの構造に対するカバレッジの両方の視点が重要になるとされています。

テスト実装

テストの手順を開発して優先順位を割り当てる。場合によっては自動化のテストスクリプトを作成する
テスト手順やテストスクリプトからテストスイートを作成する
効率的にテスト実行ができるように、テスト実行スケジュール内でテストスイートを調整する
テスト環境を構築する。また、必要なものが全て正しくセットアップされていることを確認する
テストデータを準備し、テスト環境に適切に読み込ませてあることを確認する
テストベース、テスト条件、テストケース、テスト手順、テストスイート間の双方向のトレーサビリティを検証し更新する

テスト実行

テストアイテムまたはテスト対象、テストツール、テストウェアのIDとバージョンを記録する
手動で、またはテスト実行ツールを使用してテスト実行する
実行結果と期待する結果を比較する
不正を分析して、可能性がある原因を特定する
故障を観察し、観察に基づいて欠陥を報告する
テスト実行の結果（合格、不合格、ブロックなど）を記録する
不正への対応の結果、または計画したテストの一環として、テスト活動を繰り返す
テストベース、テスト条件、テストケース、テスト手順、テストスイートの間で双方向のトレーサビリティを検証し更新する

テスト完了

すべての欠陥レポートがクローズしていることを確認する。またはテスト実行の終了時に未解決として残されている欠陥について変更要求またはプロダクトバックログアイテムを作成する
テストサマリーレポートを作成して、ステークホルダーに提出する
テスト環境、テストデータ、テストインフラストラクチャー、その他のテストウェアを次回も使えるように整理し保管する
テストウェアをメンテナスチーム、他のプロジェクトチーム、及び/またその使用により利益を得る可能性のある他のステークホルダーに引き継ぐ
収集した情報をテストプロセスの成熟度を改善するために利用する

テスト作業成果物

テストのプロセスごとに作成すべきテストの作業成果物がシラバスで挙げられています。

ここは、なんともいえない内容が続く部分で、正直、面白くないところ。。。

とはいえ、これがテスト実装の作業成果物、これがテスト実行の作業成果物と把握していないと問題に正答出来ません。

テストのモニタリングとコントロールの作業成果物

テストの作業進捗状況を示すテスト進捗レポート、マイルストーンごとにまとめるテストサマリーレポート。

レポートに含めるべき情報はプロジェクトやテストレベルごとに異なります。

ポイントはプロジェクトのステークホルダーに対して、必要十分かつ的確な内容を含めたレポートを適切なタイミングで提供すること。

くれぐれも間違えてはならないことは、ここでいうテストはテスト実行だけではなく、テスト計画やテスト分析、テスト実装などのテストプロセスも含まれることです。

テスト分析の作業成果物

どのテスト条件がテスト対象となるシステムや製品の成功にとって優先されるべきなのかといった優先順位に関する情報
テストベースの分析によって得られた、テストベースの欠陥（記述不足、間違い、矛盾する仕様がある、単なる誤字脱字、トレーサビリティ不足などテクニカルレビューで指摘があるもの）
探索的テストであればテストチャーター

テストチャーターという言葉は初耳でした。

https://www.jasst.jp/symposium/jasst18tokyo/pdf/E2.pdf

上記の資料によれば、テストの指針となるものだそうです。

ねらいやこうしたことをしてみる、といったことです。

テスト設計の作業成果物

どのテスト技法やテストタイプで実施するのかといったテスト実行のための情報源がテスト設計仕様です。

テスト設計仕様があることで、どうしてそのテストケースだけで品質を保証できるのか証明することが出来ます。

テスト設計仕様は開けずに再利用できるというメリットがあります。

としていますが、これまで経験したプロジェクトでテスト設計仕様は見たことありませんね。

テスト実装の作業成果物

テスト手順とそれらの順序付け
テストスイート
テスト実行スケジュール

テストスイートとは、

ソフトウェアテストの目的や対象ごとに複数のテストケースをまとめたもの。

だそうです。

www.itmedia.co.jp

テストコードを書くテストフレームワークでも、テストケースの上位層にテストスイートの概念がありますね。

テスト実行の作業成果物

テストケースまたはテスト手順のステータスに関するドキュメント（テスト実行可能、合格、不合格、ブロック、意図的にスキップ）
欠陥レポート
テストアイテム、テスト対象、テストツール、テストウェアに関するドキュメント

テスト完了の作業成果物

テストを改善するための情報
今回のテストでは実行うせずに、次のテストサイクルへ持ち越しとしたようなアイテム
テストデータやテスト環境

テストベースとテスト作業成果物のトレーサビリティ

トレーサビリティが確保されていると、要求仕様書の変更があっても、テストケースのどこを変更するか容易い、と。

品質保証の人が、やるのが好きな作業がこのトレーサビリティです。

IDを振れとか、あれがないとか、とやかく言われるのです。

というわけで開発サイドが嫌いな言葉だったりします。。。

人の心理とテスト

開発担当者は「自分自身で何度も繰り返し確認して実装したコードは正しい」と思い込んでしまう。テスト担当者からの指摘を自己への非難と捉えてしまい、素直に受け入れ、欠陥として認識することが難しくなる。

これも経験でありますね。オフラインの職場だと、テスト担当者がの人に声かけられると

そんな嫌そうな顔しないでくださいよ

なんて言われたことがあります。

テスト担当者は、テスト活動に費やすコストや時間が、ソフトウェアの開発に見合った寄与をしていることを説明し、理解してもらうことに努める必要があります。

欠陥や故障の指摘だけでなく、修正によって良くなる点などの動機づけも併せて説明することで、様々な担当者間のコミュニケーションが良好になり、良い信頼関係が構築できます。

信頼関係により、指摘する側と受ける側の間に敵対的な緊張がなくなります。