JSTQBFL1章のまとめ

はじめに

3章5章に引き続き１章を読んでみました。シラバスの内容について「これ大事だな」と思うもの独断と偏見で記述し、「特に大事だな」と思うものboldにしています。また筆者独自の認識を記載しています。

JSTQBFL5章テストマネジメントでの学び - 徒然なるままに

JSTQB FLのシラバス第3章:静的テストでの学び - 徒然なるままに

シラバス内容抽出/解釈

テストの基礎

テストとは何か?

ソフトウェアテストはソフトウェアの品質を評価し、運用環境でソフトウェアの故障が発生するリスクを低減する1つの手段である。

• 動的テスト
  • テスト対象のコンポーネントやシステムを実行すること
• 静的テスト
  • 要件、ユーザーストーリー、ソースコードなどの作業成果物レビュー

よくある誤解

• テストはソフトウェアを実行し結果を確認するだけだというもの。
  • テストプロセスとして、計画、分析、設計、実装、進捗と結果の報告、対象の品質評価などの作業が含まれる。
• テストは要件、ユーザーストーリー、またはその他の仕様の検証に重点を置くことが全てだというもの。
  • 検証だけでなく、ユーザーやステークホルダーのニーズを運用環境でシステムが満たしていることを確認する妥当性確認も行う。

テストに共通する目的

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

テスト対象のコンポーネント、システム、テストレベル、ソフトウェア開発ライフサイクルモデルといった要因により異なり、テストの目的が追加変更されることもある

テストとデバッグ

• テスト
  • 実行することでソフトウェアに存在する欠陥に起因する故障を示す。
• デバッグ
  • 故障の基となる欠陥を見つけて、解析し、取り除く一連の開発の活動。

テストとデバッグは異なる。通常、テスト担当者はテスト対象の初回のテストと最終的な確認テストに責任を持ち、開発担当者はデバッグ、関連するコンポーネントテスト、およびコンポーネント統合テスト(継続的インテグレーション)に責任を持つことになる。

テストの必要性

コンポーネントやシステム、およびドキュメントを厳しくテストすれば、運用環境で問題が発生するリスクを低減できる。
→稼働後に修正することはコストが高くなってしまう。

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

適切なテストレベル、適切なテストの専門知識の適用、適切なテスト技法を使用することで問題を含むリリースの頻度を低減できる。以下がその例の抜粋。

• テスト担当者が要件レビューやユーザーストーリーの洗練作業に関与することにより、これらの作業成果物の欠陥を検出できる。
  • 要件に対する欠陥の検出と除去を行うことにより正しくない、またはテストできないフィーチャーが開発されるリスクを低減できる。
• コード開発時にテスト担当者が開発担当者と密接に連携して作業することにより、両者がコードとそのコードをどうテストするかに対する理解を深めることができる
  • コードとテストケースに欠陥が混入するリスクを低減できる。

品質保証とテスト

品質保証(または単にQA)とテストは、関連してはいるが同じではない。さらに大きな範囲を表す品質マネジメントという概念 が両者を結び付けている。

• 品質マネジメント
  • 品質に関して組織の方針を示し、組織をコントロールするための活動をすべて含む。
  • 品質保証と品質コントロールの両方を含む。
• 品質保証
  • 一般的に、品質が適切なレベルに確実に到達するよう、適切なプロセスを遵守することに重点を置く。プロセスを適切に遂行すると、これらのプロセスで作成される作業成果物は一般的に高い品質を持つ。これにより、欠陥の混入を防止できる。
  • 品質保証の有効性を高めるためには、根本原因分析を使用して欠陥の原因の検出と除去を行い、プロセスを改善するために振り返りでの発見事項を適切に利用することが重要。
• 品質コントロール
  • テスト活動を含め、適切なレベルの品質を達成するために役立つさまざまな活動が含まれる。テスト活動は、ソフトウェア開発またはメンテナンスプロセス全体の一部を構成する。
  • 品質保証では、テストを含むプロセス全体を適切に実行することが必要となるため、適切なテストを支援する。テストはさまざまな方法で品質の達成に貢献する。

※以下のイメージ図(雑)のように捉えている。

エラー、欠陥、および故障

人間はエラー(誤り)を犯す。そのエラーがソースコードや他の関連する作業成果物の欠陥(フォールトまたはバグ)となる。 コードの欠陥が実行されると、故障が起きることがあるが、すべての状況で故障が起きるわけではない。

エラーは以下のものを含むさまざまな理由によって発生する。※属性を付けた。

• 納期のプレッシャー
  • 組織的要因
• 人間の誤りを犯しやすい性質
  • 人的要因
• プロジェクト参加者の経験不足または技術不足
  • 人的要因、組織的要因
• プロジェクト参加者間の誤ったコミュニケーション
  • 人的要因、組織的要因
• コードの複雑さ、設計の複雑さ、アーキテクチャーの複雑さ、解決すべき根本的な問題の複雑さ、使用する技術の複雑さ
  • 技術的要因
• システム内またはシステム間のインターフェースに関する誤解
  • 人的要因
• 新しく不慣れな技術
  • 技術的要因

期待通りではないテスト結果がすべて故障であるとは限らない。テスト実行方法のエラー、テストデータやテスト環境、その他のテストウェアの欠陥などの理由により、偽陽性(誤検出)をしてしまうことがある。状況によっては、類似のエラーまたは欠陥が偽陰性(検出もれ)となることもある。

欠陥、根本原因、および影響

欠陥の根本原因とは、欠陥を埋め込んだ最初の行為または条件のことである。欠陥を分析して根本原因を識別し、類似の欠陥が今後発生しないようにしなければならない。最も重大な根本原因に焦点をあてることはプロセス改善につながり、今後に大量の欠陥が作りこまれるのを防止できる。

テストの7原則

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

テストプロセス

テストプロセスとは、テストの目的を達成する確率を高くする、汎用的なテスト活動のセット。

テストの活動とタスクと作業青果物

テストプロセスを構成する主な活動のグループは以下の通りである。論理的にはシーケンシャルに行われるが、繰り返されることが多い。

• テスト計画
  • テストの目的と、状況により課せられる制約内でテストの目的を達成するためのアプローチを定義する。
  • 例えば、適切なテスト技法とタスクを指定し、納期に間に合うようにテストスケジュールを作成するなど。
  • 作業成果物の例
    • テスト計画書
    • テストのモニタリングとコントロールで使用する終了基準
• テストのモニタリングとコントロール
  • テストモニタリング
    • テスト活動に関する情報を収集して可視化し、フィードバックをかけること
  • テストコントロール
    • 収集、報告されたテストの実施結果を基にガイドや補正のアクションをすることである。
    • 例えばテストの優先度を見直すことやテストスケジュールを変更するなど。
  • 成果物の例
    • テスト進捗レポート
    • テストサマリーレポート
• テスト分析
  • 計測可能なカバレッジ基準から見た「何をテストするか」を決定する。
  • タスクの例
    • テストレベル(コンポーネントテストやユニットテスト)ごとに適切なテストベース(テストの根拠となる仕様書)を分析する。
    • テストベースの分析に基づいて、各フィーチャーのテスト条件を決めて優先度を割り当てる。
  • 作業成果物の例
    • 決定して優先順位を付けたテスト条件
• テスト設計
  • テスト分析は「何をテストするか」を決定し、テスト設計は「それをどうテストするか」を決定する。
  • タスクの例
    • テストケースおよびテストケースのセットを設計し、優先度を割り当てる。
    • テスト条件とテストケースを支援するために必要なテストデータを識別する。
    • テスト環境を設計し、必要なインフラストラクチャーやツールを識別する。
    • 作業成果物の例
      • テスト分析で決定したテスト条件を実行するためのテストケースとテストケースのセット
• テスト実装
  • テスト設計は「それをどうテストするか」の答えであり、テスト実装は「テストの実行に必要なものすべてを準備したか」の答えで ある。
  • タスクの例
    • テスト手順や自動化テストスクリプトからテストスイートを作成する。
    • テスト環境を構築する。また、必要なものすべてが正しくセットアップされていることを確認する。
    • テスト手順や(存在する場合)自動化テストスクリプトからテストスイートを作成する。
  • 作業成果物の例
    • テスト手順とそれらの順序付け
    • テストスイート
    • テスト実行スケジュール
• テスト実行
  • テスト実行スケジュールに従ってテストスイートを実行する。
  • タスクの例
    • テストアイテムまたはテスト対象、テストツール、テストウェアのIDとバージョンを記録する。
    • 故障を観察し、観察に基づいて欠陥を報告する
  • 作業成果物の例
    • テストケースまたはテスト手順のステータスに関するドキュメント
    • 欠陥レポート
• テスト完了
  • 完了したテストの全活動のデータを集め、プロジェクトから得たこと、テストウェア、およびその他の関連する情報すべてをまとめる。
  • タスクの例
    • すべての欠陥レポートがクローズしていることを確認する。または、テスト実行の終了時に未解決として残されている欠陥について変更要求またはプロダクトバックログアイテムを作成する。
    • 完了したテストの全活動のデータを集め、プロジェクトから得たこと、テストウェア、およびその他の関連する情報すべてをまとめる。
    • テストサマリーレポートを作成して、ステークホルダーに提出する。
  • 作業成果物の例
    • 欠陥レポート
    • 後続するプロジェクトまたはイテレーションを改善するためのアクションアイテム
    • 変更要求またはプロダクトバックログアイテム

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

• トレーサビリティ
  • テストベースの各要素とそれに関連するテスト作業成果物の紐付け。テスト作業成果物が何を根拠にどの様に作られたかを判別するもの。

テストカバレッジの評価に加えて、優れたトレーサビリティが役に立つことは以下の通りである。

• 変更の影響度を分析する。
• テストを監査可能にする。
• テストベースの要素のステータス(例えば、テストが合格となった要件、テストが不合格となった要件、テストを保留している要件)を含めることで、テスト進捗レポートとテストサマリーレポートの理解しやすさを向上する。

テストの心理学

ソフトウェア開発は、ソフトウェアテストを含めて人が行うため、人の心理がソフトウェアテストに重要な影響を及ぼす。

人の心理とテスト

欠陥や故障を見つけることはプロダクトおよび開発担当者に対する非難と解釈されることがある。 確証バイアスと呼ばれる人の心理の要素は、持っている信念に合わない情報を受け入れがたくする。例えば、開発担当者は、コードは正しいという思い込みがあるので、確証バイアスにより、コードが正しくないということを受け入れがたい。 さらに、テストからの情報は悪いニュースを含んでいることが多く、悪いニュースをもたらす人は非難される傾向がある。

テストはプロジェクトの進捗とプロダクトの品質に大きく貢献するが、これらの心理的要因により、破壊的な活動と見られる場合がある。これらの心理的傾向を軽減するためには、欠陥や故障に関する情報を建設的な方法で伝えるべきである。テスト担当者およびテストマネージャーは、欠陥、故障、テスト結果、テストの進捗、リスクの情報を効果的に伝えることができ、建設的な関係を構築するための優れた対人スキルが必要となる。コミュニケーションを適切に行う方法には以下のものがある。

• 対決ではなく、協調姿勢で開始する。全員のゴールは、高品質のシステムであることを再認識するとよい。
• テストの利点を強調する。例えば、開発担当者に対しては、欠陥情報は、作業成果物の品質向上と開発担当者のスキル向上に役立つ。組織に対しては、欠陥をテストで検出して修正すると、時間と経費の節約になり、プロダクト品質の全体的なリスクも減る。
• テスト結果や他の発見事項は、中立な立場で、事実に焦点をあてて伝え、欠陥を作りこんだ担当者を非難しないようにする。客観的かつ事実に基づいた欠陥レポートを書いたり、発見事項をレビューしたりする。

テスト担当者も個人的偏見を最小限にして、これらの目的に忠実であることが重要である。

テスト担当者と開発担当者のマインドセット

• 開発担当者
  • 主目的：プロダクトを設計して構築すること。
  • マインドセット：解決策に問題があるかを考えるよりも、解決策の設計と構築により大きな関心がある。また、確証バイアスが、自分自身の犯したエラーに気づくことを困難にする。
• テスト担当者
  • テスト担当者の主目的：プロダクトの検証と妥当性確認、リリース前の欠陥の検出。
  • マインドセット：好奇心、プロとしての悲観的な考え、批判的な視点、細部まで見逃さない注意力、良好で建設的なコミュニケーションと関係を保つモチベーションが必要となる。 目的が異なっており、異なるマインドセットを必要とする。両者のマインドセットを組み合わせることで、より高いレベルのプロダクト品質を達成できる。

感想

• ○○テストやテスト○○って単語が多く、この意味何だっけ？となってしまっています。テストオラクルとかテストハーネスあたりが特によくわからなくなってます。試験までに覚えなきゃ...

• テストプロセスを意識することで、「自分が今これをするためには何が必要なんだっけ？」と明確になった気がします。いきなりテストを実装するのではなく、設計や分析といった作業が必要で、その作業は何をすべきかがわかるので。

• 開発する方から見ると、確証バイアスはかかりがちだなって改めて思います。そして間違ってると指摘されると嫌な気分になるのもわかりますね。開発担当者も確証バイアスがかかりやすくなることは知っておくべきですね。

JSTQBFL5章テストマネジメントでの学び

はじめに

3章引き続き5章を読んでみましたので、今回もシラバスの内容で「これ大事だな」と思うもの独断と偏見で記述しています。また、「特に大事だな」と思うものboldにしています。

tagoaskubeya.hateblo.jp

シラバス内容抽出

テスト組織

独立したテスト

• ある程度の独立性を確立すると、開発者とテスト担当者の間の認知バイアスの違いによって、テスト担当者はより効果的に欠陥を発見できる。ただし、独立性は熟知していることの代わりにはならない。
• ほぼすべての種類のプロジェクトにおいて、複数のテストレベルのいくつかでは独立したテスト担当者がテストを行うのがよい。開発担当者は自分たちの仕事の成果の品質をコントロールするために、特にローレベルのテストに参加すべきである。

メリット

• 独立したテスト担当者は、開発担当者とは異なる背景、技術的視点、バイアスを持つため、開発担当者とは異なる種類の故障を検出する可能性が高い。
• ベンダーの独立したテスト担当者は、契約元の会社にある(政治的な)圧力なしに、テスト中のシステムについて正直に客観的な態度で報告できる。

デメリット

• 開発チームから隔絶されると、協力関係の欠落、開発チームへのフィードバック提供の遅延、開発チームとの対立を招くことがある。
• 独立したテスト担当者は、ボトルネックとして見られることがある。
• 独立したテスト担当者にテスト対象の情報などの重要な情報が伝わらないことがある。

テスト担当者のタスク

テストレベル	一般的なテスト担当者
コンポーネントテストレベルやコンポーネント統合テストレベル	開発担当者
受け入れテストレベル	ビジネスアナリスト、特定の分野の専門家
システムテストレベルやシステム統合テストレベル	独立したテストチーム
運用受け入れテストレベル	運用担当者またはシステム管理者

テストの計画と見積り

テスト計画書の目的と内容

• プロジェクトやテスト計画が進行するに従い、入手できる情報が多くなり、具体的な情報をテスト計画書に含めることができる。テスト計画は継続する活動であり、プロダクトのライフサイクル全体を通して行う。

テスト戦略とテストアプローチ

• テスト戦略は、プロダクトまたは組織のレベルでのテストプロセスに関する汎用的な考え方を提供する。
• 適切なテスト戦略は、テスト戦略を複数組み合わせて構築する。
• テストアプローチは、テスト技法、テストレベル、テストタイプの選択や、開始基準と終了基準(またはそれぞれ準備完了(ready)の定義と完了(done)の定義)を決めるための出発点である。

テスト戦略の種類

• 分析的
  • いくつかの要因(要件やリスクなど)の分析に基づく。分析的アプローチの例としては、リスクベースドテストがある。
• モデルベースド
  • プロダクトで必要な特性を表すモデル。例えば、機能、ビジネスプロセス、内部構造、非機能特性(信頼性)などに基づいてテストを設計する。モデルの例は、ビジネスプロセスモデル、状態モデル、信頼度成長モデルなど。
• 系統的
  • 事前に定義した一連のテストケースまたはテスト条件を体系的に使用する。
• プロセス準拠
  • 外部のルールや標準を使用してテストの分析、設計、実装を行う。
• 指導ベース(コンサルテーションベース)
  • 外部の人から(テストチームの外部または組織自体の外部のステークホルダー、ビジネスドメインの専門家、技術的専門家から)の助言、ガイダンス、指示に基づいてテストを行う
• リグレッション回避
  • 既存では実現されていた能力のリグレッションを避けることが目的。このテスト戦略には、既存のテストウェア(特にテストケースやテストデータ)、高度に自動化されたリグレッションテスト、および標準テストスイートの再利用が含まれる。
• 対処的
  • 他の戦略とは異なり、テストは事前に計画されず対処的にテストを行う。先に実行したテストの結果により得られた知識に応じて、テストを設計および実装する。対処的戦略では、探索的テストを一般的に使用する。

テスト実行スケジュール

• テストケースやテスト手順を作成(テスト手順は可能な限り自動化)し、テストスイートにまとめた後、テスト実行スケジュールを作成してテストを実行する順序を定義する。

テスト見積もりの技術

• メトリクスを活用する
  • 以前の類似したプロジェクトのメトリクスや、典型的な値を基にしてテスト工数を見積る。
• 専門家の知識を基にする
  • テストのタスクの所有者の経験、または専門家による見積りを基にしてテスト工数を見積る。ワイドバドデルファイ見積り技法などが例となる。

テストのモニタリングとコントロール

• テストモニタリング
  • テスト活動に関する情報を収集して可視化し、フィードバックをかけること
• テストコントロール
  • 収集、報告されたテストの実施結果を基にガイドや補正のアクションをすること（テストの優先度を見直したり、テストのスケジュールの変更など）である

テストで使用するメトリクス

• メトリクスは各テスト活動の期間中、および終了時に収集できる、以下の項目を評価する。

  • 計画したスケジュールや予算に対する進捗
  • テスト対象の現在の品質
  • テストアプローチの十分性
  • テスト目的に対するテスト活動の効果

代表的なテストメトリクス

• 計画したテストケースの準備が完了した割合(または、計画したテストケースを実装した割合)
• 計画したテスト環境の準備が完了した割合
• テストケースの実行(例えば、実行/未実行のテストケース数、合格/不合格のテストケース数、そして/または合格/不合格のテスト条件数)
• 欠陥情報(例えば、欠陥密度、検出および修正した欠陥数、故障率、確認テスト結果)
• 要件、ユーザーストーリー、受け入れ基準、リスク、コードのテストカバレッジ
• タスクの完了、リソースの割り当てと稼働状況、工数
• テストに費やすコスト(現状のコストと、継続して欠陥を見つけていくメリットと比較した場合のコスト、もしくは継続してテストを実行していくメリットと比較した場合のコストなど)

構成管理

目的：プロジェクトやプロダクトのライフサイクルを通じて、コンポーネントやシステムの完全性、テストウェア、およびそれら相互の関係を確立し、維持すること。テスト計画にて構成管理の手順やインフラストラクチャー(ツール)を識別し、実装すべきである。

• 全テストアイテムのバージョン管理して、変更履歴を残し各アイテム間を関連付ける。
• テストウェアの全アイテムを一位に識別してバージョン管理して各アイテム間を関連付ける。また、テストアイテムのバージョンとの関連付けを行い、テストプロセスを通してトレーサビリティを維持できる。
• 識別したすべてのドキュメントやソフトウェアアイテムは、テストドキュメントに明確に記載してある。

リスクとテスト

リスクの定義

リスクは、将来に否定的な結果となる事象が起きる恐れを含む。リスクのレベルは、そのような事象が起きる可能性とその影響(事象による結果がもたらす損害)で決まる。

プロダクトリスクとプロジェクトリスク

• プロダクトリスク
  • 作業成果物(例えば、仕様、コンポーネント、システム、テストケース)がユーザー、ステークホルダーの正当なニーズを満たすことができない恐れを含む。
• プロジェクトリスク
  • プロジェクトの目的達成に悪影響を与えるもの。

リスクベースドテストとプロダクト品質

テスト時に必要な工数についてどこに重点を置くかを決定するために、リスクを使用する。テストは、期待しない事象が発生するリスクを減らしたり、その影響を少なくしたりするために使用する。また、どのテストをいつから開始するかを決定し、さらなるテストが必要な領域を識別するために使用する。

リスクベースのアプローチを採用すると、プロダクトリスクを軽減する予防的措置を講じられる。このアプローチではリスク分析を行い、プロダクトリスクを識別し、各リスクの発生する可能性と発生した場合の影響を評価する。この活動を通して得られるプロダクトリスクの情報を、テスト計画、仕様化、テストケースの準備と実行、テストのモニタリングとコントロールに役立てる。プロダクトリスクを早期に分析することは、プロジェクトの成功に貢献する。

リスクベースのアプローチでは、プロダクトリスク分析の結果を使用して以下を行う。

• 適用するテスト技法を決める。
• 実施するテストレベルおよびテストタイプを決める(例えば、セキュリティテストやアクセシビリティテスト)。
• テストを実行する範囲を決める。
• 重大な欠陥をなるべく早い時期に検出するため、テストの優先順位を決める。
• テスト以外の活動でリスクを減らす方法があるか検討する(経験の少ない設計者に教育を実施するなど)。

リスクベースドテストでは、プロダクトリスクの分析を行うために、プロジェクトのステークホルダーの総合的な知識や洞察力を必要とする。プロダクトが故障を起こす可能性を最小にするため、リスクマネジメントでは、以下のように、きちんと決まったアプローチを備えている必要がある。

• どこが上手くいかないか(リスク)を分析する。定期的に再評価する。
• リスクの重要度を決める。
• 重大なリスクを処理する方法を実装する。
• リスクが実際に事象として発生した場合に備えてコンティンジェンシープランを作る。

欠陥マネジメント

• テストの目的の1つは欠陥を検出することであるため、テスト時に見つかった欠陥は記録を残す必要がある。
• 検出したすべての欠陥を調査し、発見や分類から解決にいたるまで追跡する必要がある。すべての欠陥を解決にいたるまでマネジメントするために、組織で欠陥マネジメントのプロセスを定め、ワークフローと分類の規則を設ける必要がある。
• テスト担当者は、欠陥として報告する偽陽性の数を最小限にする必要がある。
• 欠陥レポートの目的
  • 開発担当者や他の関係者に対して、発生したあらゆる期待に反する事象についての情報を提供す る。また、必要に応じて、もしくは問題を解決するために、具体的な影響を識別して、最小の再現テストで問題の切り分けを行い、欠陥の修正ができるようにする。
  • テストマネージャーに対し、作業成果物の品質や、テストへの影響を追跡する手段を提供する開発プロセスとテストプロセスを改善するためのヒントを提供する。
  • 開発プロセスとテストプロセスを改善するためのヒントを提供する。

感想

テストの計画について

テスト計画は作ってそれをずっと守るわけではない。わかっている情報や知っている情報が出てきてそれを取り入れてテスト計画は成長する。

この考え方はPMBOKにも出てくるのローリングウェーブ計画法で反復計画法の一つでしょうか。予測がつきにくい将来の作業はより上位のレベル（大まかなレベル）でとらえて計画し、詳細レベルは後できめる考え方です。 テストの計画は一度決めてそれを守るのではなく、後から柔軟に変更して良いものだと思えるようになり、変更しなければならないときに「成長するものだから変えましょ」と言いやすくなりました。

※成長する考え方、ローリングウェーブ計画法はマインドマップから始めるソフトウェアテストにも記載されていました。

むずかしそうなとこ

構成管理にドキュメントも、テストアイテムも、テストアイテムもすべて管理するべき〜の様に記載されてます。
べき論で言えばすべて管理したほうが良いし、管理したい。実際のところ、時間がなかったり、めんどくさくなったり、手間をかけて得られる結果が少なく感じてしまったり...すべて管理するのは難しそうだなと感じました。（難しく考えすぎ？）
簡単にできるツールや仕組みを知りたいところです。

欠陥マネジメント

検出したすべての欠陥を調査し、発見や分類から解決にいたるまで追跡する必要がある。すべての欠陥を解決にいたるまでマネジメントするために、組織で欠陥マネジメントのプロセスを定め、ワークフローと分類の規則を設ける必要がある。

したほうが良いことではあるとは思う。が...これはかなりハードルが高そう。組織においてすべての欠陥を解決するまで規則やプロセスを定める苦労と、定めることで開発スピードが遅くなることへの懸念が思い浮かびました。

リスクのレベル

リスクのレベルは、そのような事象が起きる可能性とその影響(事象による結果がもたらす損害)で決まる。

否定的な結果が起きる可能性×影響で覚えました。未来に対して考えるという点では見積もりと同じなのかなと。リスクを考えるときはテスト見積もりの技術にある、メトリクスを活用する 、専門家の知識を基にする しか無いのかな...と考えています。

リスクばかり考えて否定的な考えばかりするのは違うので、リスクリスク！と感情的に可能性だけを考えるのではなく、影響も含めて受容できるリスクも考えていきたいです。

JSTQB FLのシラバス第3章:静的テストでの学び

はじめに

最近ソフトウェアテストに興味を持っていて、8月にJSTQB FLに受験するために学習をしています。今回は3章静的テストを学習したのでそれををまとめます。それ以外の章はまた後日順不同で行う予定です。試験の合格だけでなく実務で活かせるようにします💪

シラバスの内容で「これ大事だな」と思うもの独断と偏見で記述しています。また、「特に大事だな」と思うものboldにしています。

シラバス内容解釈

静的テストの基本

静的テスト＝仕様/資料/コードに対するレビューや静的解析

静的テストの利点

動的テストを実行する前に欠陥を早期に検出できる。早期に検出した欠陥は、本番稼動後のようなライフサイクルの終盤に検出した欠陥よりも、はるかに安価に除去できる。↓イメージ図 *1

静的テストと動的テストの違い

保守性欠陥のほとんどは、静的テストでのみ検出できる。静的テストは作業成果物の整合性と内部品質を向上する事ができる

作業成果物のレビュープロセス

計画→レビューの開始→個々のレビュー（すなわち、個々の準備）→懸念事項の共有と分析→修正と報告

レビュータイプ

非形式的レビュー＜ウォークスルー＜テクニカルレビュー＜インスペクションの順で高度に形式的になっていく。

非形式的レビュー

• 主な目的：潜在的な欠陥の検出。
• その他の目的：新しいアイデアや解決策の創出、影響度の小さい問題の迅速な解決。
• 形式的な（文書化した）プロセスに基づかない。
  • 結果を文書化することもある。
• レビューミーティングを行わないことがある。
• レビューアにより、効果はさまざまである。
• チェックリストの使用は任意である。
• アジャイル開発では一般的に行われる。

形式的レビュー

定義されたプロセスに従うレビュー。多分お硬いやつのレビュー。

形式的レビューでの役割と責務

• 作成者
• マネージャー
• ファシリテーター（モデレーターと一般的に呼ばれる）
• レビューリーダー
• レビューア
• 書記（記録係）

形式的レビューの違い

	ウォークスルー	テクニカルレビュー	インスペクション
主な目的	・欠陥の発見 ・ソフトウェアプロダクトの改善 ・異なる実装方法の検討 ・標準や仕様への準拠の評価	・合意の獲得 ・潜在的な欠陥の検出	・潜在的な欠陥の検出 ・作業成果物の品質の評価と信頼の積み上げ ・作成者の学習と根本原因分析による将来の類似欠陥の防止
その他の目的	・さまざまな技法やスタイルに関するアイデアの交換 ・参加者のトレーニング ・合意の形成	・作業成果物の品質の評価と信頼の積み上げ ・新しいアイデアの創出 ・作成者のモチベーション向上と将来の作業成果物の改善 ・異なる実装方法の検討	・作成者のモチベーション向上 ・将来の作業成果物およびソフトウェア開発プロセスの改善 ・合意の形成
レビューア	-	作成者の技術領域の同僚、および技術分野が同じ、または別の専門家	作成者の同僚か、作業成果物に関連する別の分野の専門家
書記	必須	必須（作成者ではないのが理想）	必須
レビューミーティング前の個々のレビューアによる準備	任意	必須	必須
ミーティングを主導する人	典型的には作業成果物の作成者	経験を積んだファシリテーター（作成者ではない）が主導するのが理想	経験を積んだ進行役（作成者ではない）
レポート	潜在的な欠陥のログ、およびレビューレポートを作成	潜在的な欠陥の記録やレビューレポートを作成	潜在的な欠陥の記録やレビューレポートを作成
チェックリストの使用	任意	状況による	ルールやチェックリストに基づいたプロセスで進行し、形式に沿ったドキュメントを作成
その他	・シナリオ、ドライラン、シミュレーションの形態を取る場合がある ・運営により、きわめて非形式的のものから、高度に形式的なものまである		・役割が明確に決まっているレビューミーティングで作業成果物を読みあげる人を専任で加えたりすることもある ・開始基準と終了基準が指定されている ・作成者は、レビューリーダー、ドキュメントを読みあげる担当、書記のどの役割も担わない ・メトリクスを収集し、ソフトウェア開発プロセス全体（インスペクションプロセスを含む）の改善に使用する

個人的な覚え方

• ウォークスルー：自分が歩いて来た道を他の人が通ってきてもらうイメージ
• テクニカルレビュー：（いいイメージが浮かびませんでした）
• インスペクション：インポスター。*2メトリクスを収集して作成者は何もしないので健康診断のイメージ。

レビュー技法

個々のレビュー（個々の準備）活動で欠陥を見つけるために適用できるもの

• アドホック
  型なしでおまかせのレビュー技法。果たしてこれは技法と呼べるのか？

  レビューアは、このレビューに関するタスクのガイダンスをほとんどまたはまったく提供されない。アドホックなレビューは、準備を必要としない場合によく行う。

• チェックリストベース
  チェックリストを使ってレビューする技法。

  レビューアはレビューの開始時に配布されるチェックリストを使用して懸念事項を検出する。主な利点は、典型的な懸念事項の種類を体系的にカバーできることである。レビューを行う際には、チェックリストに単純に従うだけでなく、チェックリスト外の欠陥も検出する努力をすることが重要である。

• シナリオとドライラン
  シナリオに沿ってお試し実行。

  作業成果物を読むための構造化されたガイドラインをレビューア に提供する。レビューアはシナリオベースドレビューを使用し作業成果物に対して「ドライラン」を行う。単純なチェックリスト項目よりも、特定の種類の欠陥を検出するためのよいガイドラインとなる。他の種類の欠陥を見逃さないようにするためには、文書化されたシナリオだけにとらわれないようにしなければならない。

• ロールベース
  役割を考えてレビューする。

  レビューアは個々のステークホルダーの役割の観点から作業成果物 を評価する。典型的な役割には、特定のエンドユーザーの種類（熟練者、初心者、年配者、子供など）や組織内の特定の役割（ユーザーアドミニストレーター、システムアドミニストレーター、性能テスト担当者など）がある

• パースペクティブベース
  役割を考える＋その役割に沿った成果物を作成してレビューする。

  レビューアはそれぞれに異なるステークホルダーの観点でレビュー活動を行う。レビュー対象の作業成果物から各レビューアの 役割で導出する成果物を作成してみる必要がある 要件や技術的な作業成果物のレビューの場合、パースペクティブベースドリーディングが最も効果的な技法

レビューの成功要因

※太字は個人的に重要と考えるもの

• 組織的な要因

  • レビュー計画時に、計測可能な終了基準として使用できる明確な目的を定義する。
  • 達成する目的、およびソフトウェア成果物と参加者の種類とレベルに応じてレビュータイプを選択する。
  • レビュー対象の作業成果物で欠陥を効果的に識別するために適切なレビュー技法（チェックリストベース技法やロールベース技法など）を 1 つ以上使用する。
  • チェックリストは、主要なリスクに言及できるよう最新の状態に保つ。
  • 欠陥に関するフィードバックを早期および頻繁に作成者に提供して品質をコントロールするために、大きなドキュメントは小さく分割して記述およびレビューする。
  • 参加者に十分な準備時間を与える。
  • レビューのスケジュールは適切に通知する。

• 人的な要因

  • レビューの目的に対して適切な人たちに関与させる（例えば、さまざまスキルセットまたはパースペクティブを持ち、対象のドキュメントを使うことがある人たち）。
  • 静的テスト担当者は、レビューに貢献するだけでなく、レビュー対象の作業成果物の内容を把握して、有効なテストを早期に準備できると、レビューアとして価値がでる。
  • 参加者には適切な時間を割り当て、細心の注意を払って詳細にレビューしてもらう。
  • レビューアが個人でのレビュー時、および/またはレビューミーティング時に集中力を維持できるよう、レビューは対象を小さく分割して実施する。
  • 見つかった欠陥は客観的な態度で確認、識別、対処をする。
  • ミーティングは参加者にとって有意義な時間となるよう適切にマネジメントする。
  • レビューは信頼できる雰囲気で行い、レビュー結果を参加者の評価に使用しない。
  • 参加者は、自分の言動が他の参加者に対する退屈感、憤り、敵意だと受け取られないように気を付ける。
  • 特にインスペクションなど高度に形式的なレビュータイプには、十分なトレーニングを提供する。
  • 学習とプロセス改善の文化を醸成する。

わからないこと

• 3.2.1 作業成果物のレビュープロセス→ 計画で以下の記載があり、このレビュー特性が何を指しているかはわかっていない。

  レビュー特性を識別する。これには、レビュータイプ、役割、活動、チェックリストなどを含む。

• 3.2.3 レビュータイプ → インスペクションの説明で以下の記載があり、この進行役が何を指すのだろうかわかっていない。ファシリテータとあえて書いていないのだろうからファシリテータではないことはわかるが...

  レビューミーティングは、経験を積んだ進行役（作成者ではなく）が主導する。

感想

今までテストは「動的テスト」のことで、レビューが「静的テスト」と知れたのは、既知の言葉を別の言い方で表現できるので面白かったです。 内容として一番印象に残ったことは、静的テストの利点です。イメージ図を探せたのもあって一番印象に残りました。

動的テストを実行する前に欠陥を早期に検出できる。早期に検出した欠陥は、本番稼動後のようなライフサイクルの終盤に検出した欠陥よりも、はるかに安価に除去できる。

静的テストの利点を自身が効果的にするために何を意識できそうかを考えました。（抽象的な項目が多いですが...）

• 参加者に十分な準備時間を与える。
  →予め情報（レビュー対象）を共有したり、シナリオとドライランにあるようなガイドラインを先に共有する。
• レビューは信頼できる雰囲気で行い、レビュー結果を参加者の評価に使用しない。
• 参加者は、自分の言動が他の参加者に対する退屈感、憤り、敵意だと受け取られないように気を付ける。
  →欠陥を指摘してくれたことに感謝を示す。リスペクトした態度で接する。欠陥を出すときは強く否定しない（特に人格を否定しない）。レビュー結果で人を判断しない。

学習だけでなく自分ができることを考えてみましたが、なかなか簡単ではないですね...！ですが、できることを増やしていきたいので、少しずつでも意識できるようにしてみます！

参考にさせていただいた情報

80号：レビュー技法の適用｜Kouichi Akiyama｜note

http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf

*1:http://www.jaspic.org/event/2009/SPIJapan/keynote/SJ9keynote.pdf及び、「ソフトウェア開発 201の鉄則(日経BP社)」より引用

*2:Among usの印象が強すぎる

ソフトウェアにおける品質/テストについて思っていること

最近テストについて学習しています。

• ソフトウェアテストの教科書を読んだ感想 - 徒然なるままに
• 「システムテスト自動化 標準ガイド」を読んだ感想 - 徒然なるままに
• 「マインドマップから始めるソフトウェアテスト」を読んだ感想 - 徒然なるままに

現時点(2021/5時点)で品質/テストについて思っていることを書いてみました。現時点での思いなので、あとから「これ間違ってるじゃん」と「別の考えになった」とかなると思います。今後変化があったら変更していく予定です。

この記事は箇条書きになっていて取り留めのない記事になっています。文章化したかったのですが力尽きてしまいました。いずれ文章化...できると良いなあ。

品質の定義

• 筆者が考えている品質の定義＝ユーザーに対して提供する価値を正しく届けられているかどうかの度合い。
  • 品質が良い：顧客に届けるべき価値が正しく伝わっている。
    • バグがない/少ない、使いやすい、ユーザーの求めるモノ/コトに合致していて期待と現実にギャップが無い状態。
  • 品質が悪い：顧客に届けるべき価値が正しく伝わっていない。
    • バグが多い、使いづらい、ユーザーの求めるモノ/コトに合致しておらず期待と現実にギャップが有る状態。
    • 狩野モデルでいう「当たり前品質」を充足していないに近いのかも知れない。
• 品質を考える上ではユーザーを常に意識しておく必要がある。
• 品質が悪いことは検知できても、品質良いことはなかなか調査しにくいイメージ。
  • 使いやすさとユーザーの求めるモノコトに合致してたかはアンケートが一番調査しやすいのかも知れない。

テストの定義

• 品質活動の一つ。
• 筆者が考えているテストの定義＝不具合（正確には欠陥）があるかを検査する。
  • ユーザーに対して提供する価値が正しく提供できるかどうか確認するもの。その手段としてテストを行う。
• 検査して品質の善し悪しを図るもの。テストだけを実施しても修正しない限り品質は上がらない。
  • 欠陥を直すこと自体はテスト活動ではないと思っている。
  • 動的テストにおいてはコードが品質を担保できるか検査する。問題のあるコードを修正することで品質が向上する。
  • 静的テストにおいては仕様書が品質を担保できるか検査する。問題のある文章や画像等を修正することで品質が向上する。

品質向上活動を通じて楽しいこと

• 自分が期待している動作を、実際にしてくれているとき。
• リスクを伝えることやリスクを潰すことで感謝されるとき。

品質に拘る理由

• 品質が悪いと顧客からの信頼が下がる。
  • 提供した価値が届いていないことに対して申し訳ない気持ちになる。
• 開発時テストをやってないと品質が悪く、運用/保守フェーズでのサポート担当は大変。
  • サポート担当は顧客に価値が正しく伝わっていない場合、正しい方向へ誘導することが役割だとは思っている。
  • ただ、品質が悪いことで顧客から指摘があり、そのたびに謝って神経がすり減っていく。自分が作っていないのに。
    • サポート担当からすると何でテストしてないの？なんでこんなものを出したの？と思ってくる。
  • 開発元を信頼しなくなる。
    • サポート担当が開発元をから提示されるリリースすべき内容を一旦放置する。
      • バージョンアップの内容の不具合修正（パッチ）が来るのでパッチのリリースを待つ様になる。
  • サポート担当の負荷を減らしたい。

これから先

• 品質を上げるための支援をしたい。
  • 悪いところだけではなく、いい点も積極的に伝えていきたい。
    • 課題や懸念点といった、悪いところだけ伝えてもやる気落ちるとおもうから。
  • 要件定義や基本設計といった早いタイミング、より上位のタイミングで品質が悪くなる可能性を少なくしていきたい。悪くなる可能性を早めに見つけたい。
    • ただし、懸念してたけど実際にはそんなに影響しなかったり大した問題ではないこともあると思う。悲観して行動しないことではなく、品質が低下する可能性を想定/認識しておくことを重要視する。
  • 自動テスト
  • 品質を向上/低下させないためにテスト自体を学ぶ。
    • 目的を達成する一つの手段としてJSTQB FLに合格する。
• 品質を担保することで、本質的にやるべき他の作業（課題解決など）に従事できる時間を増やす
• チームの質も上げたい。どうすればいいかはまだわかってないし、そもそもチームの質って何かわかっていない。とりあえず上げる方法の一つはふりかえりかなと思っている。

まだわかってないこと

• 「品質」と「質」の違い
• チームの質
• 組織の質
• 品質がいいことをどうやって検知できるか

「マインドマップから始めるソフトウェアテスト」を読んだ感想

今回はこの本を読んだので学んだことを書いていきます。

www.amazon.co.jp

なぜ読んだか

マインドマップという方法を使ってテスト活動に活かせることが面白そうだったから。

学んだこと

マインドマップへの知見

• マインドマップの特徴は放射思考。
• マインドマップは考える作業。考えることで確認すべき点や記述漏れを発見できる。
• マインドマップを書くとき、他のブランチとレベルを合わせようとしてスピードを遅くするするよりも、スピードに乗ってとりあえず書くほうが大事。
• マインドマップは中間成果物くらいの位置づけで良い。

仕様転機法(Copy&Paste&Modify)の問題点

仕様転記法＝仕様書に書かれている言葉を裏返して、それをテストケース表に書き写すこと。 この方法の問題点は、テストケースが仕様書の質に依存してしまうこと。仕様書の質が悪いと本来テストすべき項目が漏れてしまう。また、コピペしたテストケースが妥当である判断が無い単純作業となってしまう。
仕様転記法ではなく、本来すべきテストを行うためには仕様書を深く読み込むこと、仕様書の行間を読む行為が求められる。この作業をがマインドマップで実現できる。

感想

マインドマップは自己分析くらいにしか使ったことがなかったので、業務でも使えることを知れたのは大きかったです。
テスト活動ではないですが、早速業務でマインドマップを使ってみました。要件定義〜基本設計くらいのところで作ってみたのですが、わからないことや考慮すべきことが次から次へ思いつくのがいいですね。ブランチからどんどん派生することで、「なんでそれを考えたんだっけ？」がすぐにわかることも良かったです。

ソフトウェアテストについても初心者に向けてわかりやすく書いている本でした。テストの作業工程を概要レベルで改めて認識できました。
テスト活動で成果物を作るための必要な過程を本のサンプル（負荷テストなど）を通して知れたのが良かったです。特に仕様分析、テスト計画、テスト実装はなんとなくやっている部分があるので、何を考えるべきかヒントを得ることができました。
この本はテスト活動の詳細はスコープ外なので、それについては今後JSTQB等別の学習も通して身につけていきます！

ふりかえりガイドブックを読んでの一人ふりかえり

この本を読み終わったので学んだことを記載していきます📝

なぜ読んだか

ふりかえりを実践することでチームの力を底上げできるのでは？？と考えたためです。現状よりもより良くするために「前へ進むことへの支援」に関心がありました。
特にふりかえりを実践することで期待していることは以下です。

• 良いところを見つけたい。
• 悪いところは改善していくための雰囲気をつくりたい。

ふりかえりの手法やマインドセットなど、幅広いふりかえりに関する知識を学べそう！と思い読んでみました。

まなんだこと

立ち止まることの意味

ふりかえりで「立ち止まる」という観点は今までありませんでした。「立ち止まる」ってなると「いやそんなことしてる暇ないよ」とか「もっとやるべきことがある」となりがちでした。

• 立ち止まることで問題に対して視野が広くなり落ち着いて対処できること
• 定期的にふりかえりを実践することで強制的に立ち止まること

これらはたしかに...と思いました。立ち止まることで「何をしてきたんだっけ？」「何が良くて何が悪かったんだっけ？」を分析することで、「成長した実感」や「成長するために何が必要なのか」も共有できるのかなと思っています。

ふりかえりのふりかえり

これも観点として今まで持っていないものでした。ふりかえりそのものをカイゼンしてチームの目的に合うものにしないと、たしかにふりかえりもやらなくなりますね。なのでふりかえり自体のふりかえりでふりかえりを継続的に行うことでチームを成長できるようにしていきたいです。

「問題vs私達」の構造にできること

個人的にも問題に対して人同士で対立しても意味があまりないと考えています。それは、人同士が対立している暇があったら、いま問題となっている原因/現象についてどうやって良くするかを考えたい気持ちでいっぱいです。
ふりかえりで問題を共有するときに、ホワイトボードを使うことで「問題vs私達」の構造が生まれます。 その結果として問題を仮想敵としてみなして、人同士で団結して「どうやって良くするか」に着手できるのかな、と捉えています。

ふりかえりで思いや感情を共有しても良い

「仕事」となると客観的な事実だけを共有する必要があると思いがちなイメージがあり、感情を共有してはいけないと思っていました。しかしながら、ふりかえりにおいては「思いや感情」を共有して良いのだと学びました。

• チームにとって重要な出来事、事実を思い出させることがある
• 学びや気づきを促したり、チームでアクションを実行するモチベーションを高めたりできる
• プラスの感情は新しいチャレンジを促しやすく、マイナスの感情はカイゼンに繋げるためのきっかけとなる

チームは人で構成されています。「感情」もその人自身にとっては事実と聞いたことがあり、人は「感情」を一つのものさしとして行動していくと考えています。なので上手く「感情」を共有してチームが成長できるようにしていきたいです。

プロセスを改善するとき、小さく変化することの重要性

やっぱり「どーーーーん！」と大きく変更して全ての問題を解決したくなる衝動に駆られるときもあります。変化が大きすぎると影響が大きくなるし、相手の心理的な障壁が上がってしまい、そもそも変化したくなくなる状態となってしまいがちだなーと思っています。

• 大きな変更は上手く行かなかったときの影響が大きく、戻すことも困難になる。小さな変更であればすぐに戻せる
• 問題をすべて解決しようとせず、どこか一か所でも良いので変化を起こせるアイデアを出すようにしてみる

特に共感した言葉はコレ↓です。

• 「1%の変化を探し、1%だけどこかを変えてみる」

チームにとってももちろんですが、自分自身にとってもも少しでもいいから、1%でも進んでいこう！と前を向けるようになれる言葉だなと捉えています。

小さな変化を加えて大きく育てる。巷で言われているスモールスタートの意味がわかった気がします。チームが少しづつ変化し、「変化できてよかった」という共通認識をもてることで、プロセスを変えるための心理的な障壁を作らずにすむのかな、と今は思っています。
バタフライエフェクトを期待し、チームが成長していく過程で行ったことを思い出しつつ、やっていきたいです。

難しそうなところ

ふりかえりのマインドセットをチーム全員が持てればいいけど、なかなか難しそうな印象を持っています。持てるようなふりかえりをやっていっていくことが大事なのかな、と今は考えています。

おわりに

ふりかえりの本を読んだのでそれっぽいタイトルにしましたw
それはともかく、効果的なふりかえりの進め方を楽しく学べる最高の本でした✨ とくに「良いところをみつけよう」となっていることが好きでした。
今まではなんとなく場当たり的にふりかえりをやっていて、アクション全部やろうとかになってました。なんとなくやっているとアンチパターンというのすら気づかないので、効果的な進め方を知れて本当に良かったです！

効果的なふりかえりをやれるだけの勇気とモチベーションをもらったので、今はチーム内でふりかえりを実施できるタイミングを伺っています。そのときはこの本で学んだことを生かしてファシリテータをやってみます！ふりかえりをやってチームの力を底上げできるようにしていきたいです。

最後まで読んでいただきありがとうございました🙇‍♂️

「システムテスト自動化 標準ガイド」を読んだ感想

はじめに

システムテスト自動化 標準ガイドを読みましたので、その感想を書いていきます。

目次

この本を読んだ理由

E2E自動テストを導入する際にどうせなら上手く導入したい。そのために以下の内容を知りたいので読んでみました。

• 自動化のメリットとデメリット
• どのように実現するか、あるいはしないべきか。
• どこまでの範囲をテストすべきか。
• どのようにテスト自動化を導入、保守すべきか。
• 失敗談から学びを得たい。

2014年出版の本、かつ翻訳元はもっと古い（1999年出版）なので情報が古い可能性があることは注意して読み進めました。

学んだ内容

テスト自動化のコンテキスト

テストの自動化は、経済性(テストケースの実行/分析/デバッグがいかに安く行えるかどうか)や発展性(保守性、ソフトウェアの変更に対して追従するのにどれほどの工数がかかるか)を高めることだけができる。
効果性(欠陥検出の効率性がよいか)、典型性(一度のテスト実行で複数のテスト条件をテストできるか)は上げることはできない。

品質属性のレーダーチャート本書及び他ブログ*1より引用。

テスト自動化の利点

• プログラムの新しいバージョンで既存の回帰テストを動かす
  • 回帰テストの工数が下がることで意図しない不具合を減らしデグレードを防ぐことができる
• テストをもっと頻繁に多く実施する
• 手動では困難または不可能だったテストを行う
• リソースの有効利用
  • 単調で退屈な仕事を自動化することにより作業者の士気も高まるし、ヒューマンエラーを防ぐこともできる
• テストの一貫性と再現性
• テストの再利用
• ソフトウェアを市場に早く提供できる
• 自信が持てる

自動化の限界

• 手動テスティングはなくならない
• 手動テストのほうが自動テストよりも多くの欠陥が見つかる
• 期待結果の正しさを検証することがより重要となる
• テスト自動化をしてもテストが効果的になるわけではない
• ソフトウェアにおける変更に対して自動テストは手動テストに比べて脆弱
• 維持にも労力が必要なので、ソフトウェアの変更や拡張の足かせになることもある
• ツールは想像力ゼロ

テストスクリプティングの技法

データ駆動スクリプト

テストにおける入力値をテストスクリプトの中ではなく別の外部ファイルに格納する技法。

メリット

• 同じスクリプトを別のテストでも素早く追加できる
• スクリプト言語についてのプログラミングの知識がないテスト担当者でも新しいテストの追加を行うことができる
• 同じテストケースで複数テストを行うのために追加のメンテナンス工数がかからない

デメリット

• 初期のセットアップに多くの工数がかかる
• プログラミングについてのサポートが必要である
• よく管理されていなくてはならない

キーワード駆動スクリプト

キーワード駆動スクリプトの発展型。テストデータとは別に操作内容をキーワードとして外部ファイル化する。そのキーワードをテストスクリプトが読み取ることでキーワードに従った操作を行う。スクリプトの数を増やさずに多くの自動テストを実装できる。

自動比較の注意点

自動比較の限界

手動テストではテスト手順書に記載されている以上にテスト結果の妥当性をチェックすることが多い。自動比較は人が手動で行っていた比較の一部分でしか無いことが多いため柔軟性に欠ける。自動ですべてチェックすることは現実的ではない。

比較ではわからないものは何か

比較ツールではテストが成功したかどうかはわからない。比較して差異がある事実がわかるだけ。そもそも期待結果が間違っている場合は予想外の差異が出ずに「テスト成功」したように見える。

自動テストの前処理と後処理について

テストの前処理*2と後処理*3も自動化すべき。手作業が必要だと、夜間や週末に無人のテストができない。
→CI/CDパイプラインが構築できない。
後処理のタスクが一つでも失敗した場合テスト結果に関わらずテストケース自体を失敗とすべき。フェイルセーフポリシー。

自動テストが正常終了の場合

すべての実行結果が期待結果と一致する場合すべての実行結果は削除してしまって良い。
期待結果と同じだとわかってしまえば実行結果を保持する意味は殆どなく、同じものを2つ保つ必要はない。同じようなもの2つ持つものはストレージ容量の無駄なため。テストステータスの情報（成功/失敗）などの情報は削除する必要はない。
※社内規定などでテスト結果の全てを保持することが求められる場合は例外。

自動テストが異常終了の場合

手に入る情報が多いほど解析（原因を調査しやすい）ため、すべての情報を保持したい。
テストケースが失敗する場合に備えてテストスクリプトの中により多くの情報を出力を生成するようにテストを設計することができる。
テストケースが成功すれば多く出力した情報はテストケースの後処理で削除して良い。失敗したときに効果を発揮し、原因解析を助けてくれる。

テストツール選択プロセス

ツール選択はツールで解決すべき問題を把握するところから始める。以下は解決すべき問題の例。重要度や組織に与えるコストによって問題点をランク付けする。

• 手動テストの問題（とても時間がかかる、退屈である、間違いを起こしやすいなど）
• ソフトウェアに対して小さな変更を加えた際の回帰テストを行う時間がない
• テストデータまたはテストケースのセットアップで間違いを起こしやすい
• テストドキュメントが十分ではない
• ソフトウェアがどれくらいテストされているかわからない

別の解決策を探る

大切なのはツールを使った解決法だけでなく、異なる解決法についても合わせて考慮すること。ツールが価値をもたらすか評価するためには、ツールを用いない代替の解決法を考えることが重要。自動化による解決に熱中するあまり他の解決策を顧みなくなることがままある。

テストツールの導入プロセス

ツール選択のプロセスが徐々に選択肢を絞るものだとすると、導入プロセスはその逆。徐々にツールの適用範囲/使い方/利益を広げていくプロセス。
最終的には生産性を向上させるツールであっても、ツールの使い始めには生産性が低下することを意識しておく。

導入時におけるのコスト

• 組織内にツールを売り込むこと
• 支援と訓練を提供すること
• 推進中のテスト自動化の枠組みを支えるインフラを構築すること

ツール導入時において人の問題を管理しないことの危険性

もし人々の仕事のやり方を間違った方法で変えようと試みるなら、疑念を生じさせ抵抗にあう。抵抗を上手く扱わないと敵意を誘発し変革の努力の妨害さえ引き起こしかねない。「我々は一度試みたもう試みるつもりはない」という態度が生まれてしまうと将来的にどのような改革の試みも非常に難しくなってしまう。
次の公式に基づいて人は変化しようとする。

変化の公式：f(a, b, c)>z 

a=現状に対する不満
b=共有された将来のビジョン
c=はa~bへ至る工程についての具体的知識
z=個人が自らの仕事のやり方を変えるのに必要な心理的感情的コスト

abcが合わさってzより大きくなったときにだけ変化が起きる。

わからないこと

fixtureデータ駆動スクリプトにおけるファイルの認識だけどあっているのだろうか。フレームワークによって意味合いが少しづつ異なる？
本書では画像ファイルの比較はしないほうが良いと合ったが、pdfを比較したいケースもある気がする。その時はどうやってなのだろうか？浮かぶ案はdiff-pdfのようなものを使って、後で人力で確認するくらい。

感想

テスト自動化は銀の弾丸ではない

テスト自動化によるメリットとデメリットを把握できたので、あくまで手段の一つであることを認識できました。今まで殆どのテストは自動化しなければならないと思っており、自動化による解決に熱中していましたが、そうではない考えを身につけることができました。
また、自動テストは経済性と発展性を上げるものと認識できたので、今後は自動テスト実行では経済性/発展性を上げるように、自動テスト設計or手動テスト設計･実施では効果性/典型性を上げるように努めます。

変革と人の問題

自動化の技法だけではなく人の問題まで記載されていることが面白かったです。変化の公式はテスト自動化だけのか変わらない話ですし、人が変化できるようにするために変化の公式でtrueを返せるような働きかけをすることが重要である点を知れたことは良かったです。

自動テスト正常終了の話

自動テスト正常終了の後に実行結果を捨てて良いのは少し衝撃でした。でもたしかに期待結果と実行結果はほぼ同じ内容ストレージの無駄なのも納得できる。この視点はなかったので為になりました。

おわりに

最後まで読んでいただいてありがとうございました！！
この本は約450Pあります。ここまで分厚い本は今まで読んだことないので、読み進めるのに時間がかかりました... 今後もいろいろな本を読んで、知識を得るために早くアウトプットできるようにがんばります💪

*1:【社内勉強会】テスト自動化の難しさ(2017/08/25)

*2:テストを実行する前に完了すべき、テストに必要なデータの投入や更新前のファイルの退避するといったタスク

*3:自動テストの後に行われる不要データや不要ファイルの削除、やテスト結果制作物（テストレポートなど）の削除や保管